Using tftp to update u-boot (and kernel, and root fs)


#1

I have built a u-boot.bin file built using the instructions for the beaglebone black on the linuxonarm eewiki page. I’m trying to load and run it using tftp from u-boot on an existing beaglebone black with the commands:

tftp 0x80800000 u-boot.bin
go 0x80800000

The tftp is successful, but running the new u-boot hangs after printing:

## Starting application at 0x80800000

Building u-boot without the 0002-U-Boot-BeagleBone-Cape-Manager.patch works, so I don’t think the issue is in the build environment. Any ideas on why this doesn’t work or how to fix it?

Longer story:

I’m working on a product that has a beaglebone embedded within it, but the micro-SD card is inaccessible (accessing it requires physically dismantling the entire product). We are hoping to update the operating system (including u-boot, the kernel, and the root file system) on the emmc using tftp over the ethernet port. At a high level, this would require:

  • writing an application that can run in the existing operating system to overwrite the current u-boot image in emmc so that the next time the device boots it will retrieve the new operating system components using tftp

  • when the device reboots, u-boot retrieves the new kernel, device tree blob (?) and root filesystem using tftp (my understanding is that it would have to load these images into ram, then copy the contents of ram into the emmc, is that correct?)

  • boot the new operating system, preferably turning off the u-boot feature to download a new os while maintaining the ability to turn that back on from userspace in the future

I guess the first question is does that seem reasonable?

I have built u-boot using the instructions on eewiki. Another blog (beyondlogic, BeagleBoneBlack_Upgrading_uBoot) describes a method for loading u-boot into ram using tftp boot and executing it:

tftp 0x80800000 u-boot.bin
go 0x80800000

When I try this with the u-boot image created from eewiki, the tftp is successful, but when I try to execute it the process hangs at this line:

## Starting application at 0x80800000

If I try this with the u-boot image created from the instructions on the beyondlogic page, it works. The process is basically identical, but their instructions only apply this patch:
0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
while eewiki’s instructions also apply this patch:
0002-U-Boot-BeagleBone-Cape-Manager.patch

The Cape Manager support is the primary reason for transitioning from the current operating system (ArchLinux) to Debian (Arch does not appear to support the latest cape management and device tree overlay functionality.)

I have looked for ways to turn on additional debugging statements in u-boot, but so far haven’t found anything useful.

So, then:

  1. Any ideas on why loading and execute the eewiki u-boot image over tftp fails, and how to fix it?

  2. I’m also trying to figure out how to write images from ram into emmc, but haven’t found any examples yet.


#2

@don.carter

This could be a tftp transfer issue, I just checked on a BBB with u-boot stored on a sdcard…

U-Boot SPL 2018.03-00002-g254339602c (Mar 16 2018 - 12:36:44 -0500)
Trying to boot from MMC1
Loading Environment from EXT4... ** File not found /boot/uboot.env **

** Unable to read "/boot/uboot.env" from mmc0:1 **
Failed (-5)


U-Boot 2018.03-00002-g254339602c (Mar 16 2018 - 12:36:44 -0500), Build: jenkins-github_Bootloader-Builder-42

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4... ** File not found /boot/uboot.env **

** Unable to read "/boot/uboot.env" from mmc0:1 **
Failed (-5)
Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
=> load mmc 0:1 0x80800000 /home/debian/u-boot/u-boot.bin
422496 bytes read in 135 ms (3 MiB/s)
=> go 0x80800000
## Starting application at 0x80800000 ...


U-Boot 2018.01-dirty (Mar 26 2018 - 16:35:54 +0000)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
=> load mmc 0:1 0x80800000 /home/debian/u-boot/u-boot.bin
422496 bytes read in 135 ms (3 MiB/s)
=> go 0x80800000
## Starting application at 0x80800000 ...


U-Boot 2018.01-dirty (Mar 26 2018 - 16:35:54 +0000)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
=> 

PS: there is a wget implementation being developed for u-boot:
https://lists.denx.de/pipermail/u-boot/2018-March/323699.html

Regards,


#3

@don.carter

Okay looks like i replicated it:

U-Boot SPL 2018.03-00002-g254339602c (Mar 16 2018 - 12:36:44 -0500)
Trying to boot from MMC1
Loading Environment from EXT4... ** File not found /boot/uboot.env **

** Unable to read "/boot/uboot.env" from mmc0:1 **
Failed (-5)


U-Boot 2018.03-00002-g254339602c (Mar 16 2018 - 12:36:44 -0500), Build: jenkins-github_Bootloader-Builder-42

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Global external warm reset has occurred.
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from EXT4... ** File not found /boot/uboot.env **

** Unable to read "/boot/uboot.env" from mmc0:1 **
Failed (-5)
Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds
=> setenv serverip 192.168.0.10
=> setenv ipaddr 192.168.0.11
=> tftp 0x80800000 u-boot.bin
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.0.10; our IP address is 192.168.0.11
Filename 'u-boot.bin'.
Load address: 0x80800000
Loading: #############################
	 2.9 MiB/s
done
Bytes transferred = 422496 (67260 hex)
=> go 0x80800000
## Starting application at 0x80800000 ...


U-Boot 2018.01-dirty (Mar 26 2018 - 16:35:54 +0000)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB

<hard lock>

#4

Sadly the wget implementation isn’t working for me on v2018.03, it just hard locks.

There’s a couple other “U-Boot” based microSD/eMMC updaters from our GSOC’s:

While they are based on usb booting, once your in u-boot the same techniques for updating the microSD/eMMC can be applied.

Regards,


#5

Thanks Rob. The node-beagle-boot project looks like it does just about everything we need. We should be able to get access to the USB port without too much trouble.

We are having one issue with it. After flashing the image to the the beaglebone, it boots up using the version of u-boot that comes with node-beagle-boot (2015.04, Jun 07 2015 - 19:26:11). I’m not sure how that is possible since it is supposedly overwriting the entire emmc with the supplied image, but we have tried it with images we have created and with images from beagleboard.org. That version of the bootloader fails because it can’t find /boot/zImage (full log appended below):

** File not found /boot/zImage **
No kernel found

We have tried replacing the “spl” and “uboot” files in node-beagle-boot with later versions of the bootloader (compiled from eewiki and beyondlogic), but the application fails before flashing begins (it appears to crash in spl). We’re not certain which file should be used to replace spl (we tried MLO, then the three spl files generated in the spl directory, none of them worked).

We’ll keep digging, but if you have any ideas it would be appreciated.

Thanks,
Don

U-Boot 2015.04 (Jun 07 2015 - 19:26:11)

       Watchdog enabled
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot:  0 
gpio: pin 53 (gpio 53) value is 1
starting USB...
USB0:   Port not available.
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1(part 0) is current device
mmc found on device 1
Checking for: /boot/uEnv.txt ...
gpio: pin 54 (gpio 54) value is 1
1879 bytes read in 16 ms (114.3 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uenvcmd is set ...
gpio: pin 55 (gpio 55) value is 1
** File not found /boot/zImage **
No kernel found
gpio: pin 54 (gpio 54) value is 0
gpio: pin 55 (gpio 55) value is 0
USB is stopped. Please issue 'usb start' first.
USB is stopped. Please issue 'usb start' first.
gpio: pin 54 (gpio 54) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 56 (gpio 56) value is 1
U-Boot#

#6

Progress, of sorts. I recompiled u-boot using the instructions on the eewiki page, but instead of using am335x_evm_defconfig I used am335x_evm_usbspl_defconfig. After copying spl/u-boot-spl.bin to node-beagle-boot/bin/spl and u-boot.img to node-beagle-boot/bin/uboot, the SPL successfully boots. On the serial console I see:

U-Boot SPL 2018.01-00001-g5fc160d-dirty (Mar 28 2018 - 14:26:22)
Trying to boot from USB eth

After that it stops. Comparing wireshark logs of the application running with the original spl/uboot files (which work) and the updated spl/uboot files (which fail), the most obvious difference is the new files start sending messages like this:

Broadcast ARP 42 Who has 169.254.71.8? Tell 0.0.0.0

Broadcast ARP 42 Gratuitous ARP for 169.254.71.8 (Request)

Still looking into what that indicates.

Don