4

What I want to do:

I am working on a project where we want to update our RPi on boot. We are working with buildroot successfully for almost one year. Now I am trying to get it work with U-boot.

What versions I am working with:

  • RPi 3
  • buildroot 2017.05 which contains U-boot 2017.03

What I already have read:

I have read over 100 web pages. My main inspirations are:

What I have done so far:

So I build on a Debian (32bits). I configure buildroot with raspberrypi3_defconfig, and in the bootloader menu I select U-boot and set the U-boot config to rpi_3_32b. The simple rpi config does not work (hangs in rainbow) and obviously I am unable to build with rpi_3 config as it implies 64bits, which my host is not able to provide. (If I really must switch to 64bits for host and RPi and U-boot, I think I would be able to do it, but I am fairly sure I should be able to achieve my project with 32bits too.)

In the linux menuconfig of buildroot, I also changed some kernel settings to have early printk, logging level to 7 and to enable low-level debug.

What I am able to do:

I can boot and stop in U-boot menu.

The problem now:

When I proceed the fatload+bootz commands, I only get the starting kernel message and it hangs there. I am connected through UART serial line and I also have the official RPi touchscreen on the DSI. I tried to change the console in the bootargs since there are different minds on the web, I tried ttyAMA0, ttyS0, tty0, tty1.

But if I only changed the kernel= line in the config.txt, my RPi hangs in rainbow screen. I had to disable the overlay setting to fix this.

Since I get no output at all, it is really difficult to guess what the problem is... Any advice would be welcome :)


Update 2017-06-15

Here are some more information regarding the comments I received:

  • The link to the RPi forums is in a comment. As I do not have enough reputation, I cannot post more than 2 links here, sorry...
  • If in config.txt I replace kernel=u-boot.bin by kernel=zImage, it boots properly. Also in config.txt, I had to disable the pi3 overlays otherwise U-boot does not work and I got stuck in the rainbow screen.
  • Building buildroot with raspberrypi3_64_defconfig and U-boot with rpi_3 (instead of rpi_3_32b), the compilation fails
  • 2
    "the official Raspberry forums where I posted the exact same question" -> It would be courteous of you to provide an actual link here so that other people do not waste their time trying to help you with advice you have already received. – goldilocks Jun 8 '17 at 15:23
  • Whether your host is 32/64 and the target is 32/64 are two completely independent things. You can build an ARM64 system from a x86 32 bits system. – Thomas Petazzoni Jun 8 '17 at 15:24
  • You need to discern whether this is purely a kernel issue, or a problem with your bootloader. 1) Copy your kernel and the modules into a stock Raspbian (or whatever) image and try it there, 2) Copy a stock pre-compiled kernel into your u-boot/buildroot install and try that. If #1 fails and #2 succeeds, your cross toolchain is no good. Conversely if #1 succeeds and #2 fails, it is presumably the bootloader. – goldilocks Jun 8 '17 at 15:30
  • @XonqNopp, I am trying out the same thing (except without using buildroot, building u-boot and kernel manually and trying to use existing rootfs) without success. I am not even able to reach to u-boot prompt (when building with 32bit configuration using 32bit toolchain). Can you please provide info on what toolchain you are using for building u-boot? – vtha Jun 9 '17 at 14:06
  • @goldilocks I would have been happy to provide the link, but I am limited as I don't have enough reputation. Here it is: raspberrypi.org/forums/… – XonqNopp Jun 12 '17 at 6:01
2

I had similar issues with Buildroot 2017.5: The kernel ran fine without u-boot, but when booted via u-boot it was hanging after "Starting kernel...".

It turned out that the predefined address for the device tree ${fdt_addr_r} was causing the problem (looks like there was some overlap with the kernel). Loading the device tree to 0x2000000 worked for me:

mmc dev 0  
fatload mmc 0:1 ${kernel_addr_r} zImage  
fatload mmc 0:1 0x2000000 bcm2710-rpi-3-b.dtb  
setenv bootargs 8250.nr_uarts=1 root=/dev/mmcblk0p2 rootwait console=ttyS0,115200
bootz ${kernel_addr_r} - 0x2000000

Note that I did not use the overlay to set the serial port to ttyAMA0. In my config.txt I only have

enable_uart=1
kernel=u-boot.bin

The serial port therefore remains on ttyS0 which I pass in the bootargs (see above).

  • Thanks for the answer. Just tried and seem to work. I'll make more extensive tests but I'll be in holidays pretty soon... Be sure I'll get back here afterwards :) – XonqNopp Aug 4 '17 at 13:48
  • It works, thanks. I am currently going with buildroot 2017.08 (rc1 for now) where U-boot got updated, but this workaround is still required. – XonqNopp Aug 11 '17 at 8:19
1

In my case, the FDT file provided in the firmware package was incorrect and caused the kernel to hang. When booting, the firmware passes an internal version of the FDT to u-boot, and this one worked. So, instead of loading the FDT from a file, I had to pass the version provided by the firmware. The address of the provided FDT is in the variable fdtcontroladdr. This example is for aarch64 kernel, but you can try variations. For example, booti worked in my case, but other kernel formats may require bootm or bootz.

fatload mmc 0 ${kernel_addr_r} kernel.img
setenv bootargs console=ttyS0,115200n8 console=ttyAMA0,115200n8 console=tty0
booti ${kernel_addr_r} - ${fdtcontroladdr}

If one prefers to load the FDT from a file, for example to apply overlays, u-boot can save the FDT from the memory to a USB stick. Saving to the SD card did not work for me, it received an error condition and got stuck.

0

I was facing similar issue with Buildroot 2017.5, uboot-2017.03 and kernel-4.9.

When you get uboot prompt, try these commands:

mmc dev 0  
fatload mmc 0:1 ${kernel_addr_r} zImage  
fatload mmc 0:1 ${fdt_addr} bcm2708-rpi-b.dtb  
setenv bootargs console=tty1 root=/dev/mmcblk0p2 rootwait  
bootz ${kernel_addr_r} - ${fdt_addr}

Hope, this will help!

  • Thanks for the answer. This is almost what I have been trying when following the article from ltekieli.com. Still hanging at "starting kernel..." Do you by any chance have any other hint? – XonqNopp Jul 18 '17 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.