uboot update needed.

[MouettE]

Can I use this image bellow for my Bubba2 too, to connect to the serial port?
http://wiki.excito.org/wiki/index.php/S ... cess_on_B3

No, this is what you need : http://forum.excito.net/viewtopic.php?f=9&t=2658

[Gordon]

I would really much like to understand (and fix) this MAC adress resetting problem. Any help would be welcome!

Did you check the article I linked? That's where you need the console access, to enter and store these values in the uboot environment.

[MouettE]

You don't need the serial console to access the u-boot environnment. You can use uboot-envtools package with proper configuration (see http://forum.excito.net/viewtopic.php?f=7&t=2715)

However if you mess your environment and cannot boot anymore, you'll need a serial console to correct it.

[Gordon]

You don't need the serial console to access the u-boot environnment. You can use uboot-envtools package with proper configuration (see http://forum.excito.net/viewtopic.php?f=7&t=2715)

However if you mess your environment and cannot boot anymore, you'll need a serial console to correct it.

That "proper configuration" is of course the challenge. And there's also that little thing of being able to get to the box after updating uboot and having empty mac addresses. I can see that working all right, but it does require a cookbook that needs to be executed to the letter.

[ReedWood]

I have a serial connection to by B3. Usually I use screen to connect. How do I inject the magic chars (0xBB 0x11 0x22 0x33 0x44 0x55 0x66 0x77) to invoke the hardware loader?

[misty soul]

I would really much like to understand (and fix) this MAC adress resetting problem. Any help would be welcome!

Did you check the article I linked? That's where you need the console access, to enter and store these values in the uboot environment.

Yes, and I already wrote I'm not sure about this: the MAC addresses are already properly set up in the environment, but at boot they seems to not be used, and this is what I don't understand.

[misty soul]

I tried some new things to get the MAC addresses correctly working, without success.

I tried to recompile u-boot with some #define enabled in include/configs/bubba3.h. I first tried simply to set parameters CONFIG_HAS_ETH0 and CONFIG_HAS_ETH1. A second try was adding also CONFIG_ETHADDR and CONFIG_ETH1ADDR with the exact same addresses that are already in the environment as follows (MAC addresses slightly anonymized after common Excito prefix)

Code: Select all

diff --git a/include/configs/bubba3.h b/include/configs/bubba3.h
index fed884f..989f3b5 100644
--- a/include/configs/bubba3.h
+++ b/include/configs/bubba3.h
@@ -258,6 +258,10 @@
 #define CONFIG_PHY_ADDRS       {0x08,0x18}
 #define CONFIG_ENV_OVERWRITE   /* ethaddr can be reprogrammed */
 #define CONFIG_RESET_PHY_R     /* use reset_phy() to init switch and PHY */
+#define CONFIG_HAS_ETH0         1
+#define CONFIG_HAS_ETH1         1
+#define CONFIG_ETHADDR          00:22:02:00:XX:YY
+#define CONFIG_ETH1ADDR        00:22:02:00:XX:ZZ
 #endif /* CONFIG_CMD_NET */ 
 /*

Neither worked, in the sense that when I rebooted the B3 and looked in the boot messages, I still see:

Code: Select all

root@cavae:~# grep "MAC address" /var/log/messages
Jul 12 21:59:58 cavae kernel: [   22.671242] mv643xx_eth_port mv643xx_eth_port.0: eth0: port 0 with MAC address 00:00:00:00:00:00
Jul 12 21:59:58 cavae kernel: [   22.686946] mv643xx_eth_port mv643xx_eth_port.1: eth1: port 0 with MAC address 00:00:00:00:00:00

So I still don't know why these MAC addresses are not passed from u-boot to the kernel.

[MouettE]

I have a serial connection to by B3. Usually I use screen to connect. How do I inject the magic chars (0xBB 0x11 0x22 0x33 0x44 0x55 0x66 0x77) to invoke the hardware loader?

I have writter a small python script for this task, you can download it from uboot-loader.zip. Here's a quick how-to :

• I've successfully tested this script on Linux but it doesn't work on Windows, I don't know why. You will need python 2.x and the pyserial library to make it work.
• You need to use a adapted u-boot file to boot from uart :
  • From the uboot-updated git tree, edit board/Excito/bubba3/kwbimage.cfg and replace the BOOT_FROM value to uart :

    Code: Select all

    -BOOT_FROM	spi
    +BOOT_FROM	uart

  • Configure and compile u-boot, and create the adapted kwb image :

    Code: Select all

    make bubba3_config
    make -j 2
    make u-boot.kwb

• Turn off your b3, remove power plug and close any terminal connected to the serial port.
• Open a first terminal (the control terminal) and start uboot-loader.py with the following arguments :

  Code: Select all

  python uboot-loader.py <usb port> <uboot-file> [<listening port=4689>]

• From a second terminal (the console terminal), open a connection to the created socket wich will become your console after the transfer :

  Code: Select all

  stty raw -echo ; telnet localhost <4689 or the choosen alternate port>; reset

• On the control terminal, press Enter at the prompt to start sending the magic pattern to the serial port and plug your b3
• The LED should not turn on. If it does unlplug and replug with magic pattern still running.
• Once plugged with the LED off (hardware loader is waiting), press Enter again in the control terminal to start the transfer ; You will see the transfer progress
• Once the transfer is completed, the terminal console will be connected to the serial and you will be able to interact with the loaded u-boot.
• When you're finished, press Enter one last time in the control terminal to close the script. You can restart it to attempt another load.

There is room for improvement, any question or suggestion is welcome !

[MouettE]

I would really much like to understand (and fix) this MAC adress resetting problem. Any help would be welcome!

After digging into the source code of u-boot I figured out why the net links weren't properly initialized in u-boot and how to fix it ; you need to edit the file include/configs/bubba3.h and made these changes on lines 256-257 :

Code: Select all

-#define CONFIG_MVGBE_EGIGA /* Enable kirkwood Gbe Controller Driver */
-#define CONFIG_MVGBE_EGIGA_PORTS {1,1} /* enable first port */
+#define CONFIG_MVGBE    /* Enable kirkwood Gbe Controller Driver */
+#define CONFIG_MVGBE_PORTS      {1,1}   /* enable first port */

Obviously it needs to be compiled again. If you feel lazy and confident I put my compiled and running version here (No guarantee of any kind)

It works here so I finally updated my u-boot in flash Now to the kernel !

[Damarus]

This is great progress! So is this image safe to flash without serial access?

[MouettE]

This is great progress! So is this image safe to flash without serial access?

It should be reasonably safe ... But maybe someone else with serial access should try it first.

[misty soul]

I have tested a recompile u-boot following MouettE advice (i.e. the two lines change in install in include/config/bubba3.h). I have compiled it myself on one of my B3.

I confirm it completely solved the MAC adress problem! Thanks a log MouettE! After reboot, looking at /var/log/demesg shows the MAC adresses are properly set, and removing the "hwaddress ether" statement in /etc/network/interfaces is safe. The device boots normally and can be reached through SSH from a remote host.

I agree with MouettE, the next step now is booting a recent kernel. I don't know if we can try a stock kernel from Debian (there is a linux-image-3.15-trunk-kirkwood package in the experimental distribution).

Once again, big thanks to MouettE!

[misty soul]

I just tried to install the stock kernel 3.15-trunk-kirkwood from Debian experimental distribution.
It failed.

Installing the files themselves is striaghtforward, using just

Code: Select all

aptitude install linux-image-3.15-trunk-kirkwood

after having added the link to experimental in /etc/apt/sources.list. The kernel appears as a file /boot/vmlinuz-3.15-trunk-kirkwood. In order to create an uImage file from this (so u-boot can load it), I used the mkImage, from the u-boot-tools package:

Code: Select all

mkimage -A arm -O linux -T kernel -C none -a 00008000 -e 00008000 -n Linux-3.15-trunk-kirkwood -d /boot/vmlinuz-3.15-trunk-kirkwood /tmp/uImage.3.15

I got the arguments for the command above by first running

Code: Select all

mkimage -l /boot/uImage

to have something similar to the original excito 2.6.39 kernel.

Then, I copied the generated /tmp/uImage.3.15 as /boot/uImage (after of course having preserved a copy of the original file), and tried to reboot.

Reboot failed.

Extracting the hard drive and putting it inot my desktop computer, it seemed the boot did not even start. The last message in /var/log/message was the shutdown previous to reboot. So I replaced the original /boot/uImage, put the hard drive back into the B3 and rebooted. It rebooted without any problem (so I did not break anything yet), on the original 2.6.39 kernel.

I think going further would require booting from the serial console and looking in real time at the messages from u(boot to understand what was wrong in my generated uImage.

[ingo2]

I just tried to install the stock kernel 3.15-trunk-kirkwood from Debian experimental distribution.
It failed.

Is it probably worth to try kernel 3.2.57-3+deb7u2~bpo60+1 from Squeeze backports? It should be fully compatible with existing installation like libc6, ...

[misty soul]

Is it probably worth to try kernel 3.2.57-3+deb7u2~bpo60+1 from Squeeze backports? It should be fully compatible with existing installation like libc6, ...

Thanks for the suggestion, but it didn't work either. Same result has before: device not booting and absolutely no trace on the disk after installing it on a desktop computer for post mortem analysis.

My system is also rather up to date with respect to libc6 and other packages, as I have already moved to jessie for all packages except kernel and removed all bubba specific packages. My libc6 is currently 2.19-7. So I have an almost stock Debian testing here. The only things I had to change were to put an old version of rsyslog on hold to avoid it being upgraded (newer versions don't work with the very old 2.6.39 kernel), and remove systemd since recent versions also need support from recent kernels too.