AW: getting u-boot to work on raspi 3b (32bit)

Robert Wenisch RWenisch at bfs.de
Fri Jul 28 15:39:29 CEST 2023


Hi Simon,

meanwhile I've tried booting from  an FIT image. I.e. I wrote an ist file and baked an itb for booting.
However, that gave me errors along the lines of "Wrong image format for bootm command".

So I kept trying to boot the thing using the old fashioned way.

After some trial and error (recompiling the kernel with identical setting and hooking up a monitor) u-boot handed control over to the kernel and I was indeed greeted by 4 raspberries.
Unfortunately it got stuck after that, not leaving any (error) messages.
I next tried to boot from a pre-built raspbian kernel which I knew should work. It gave identical results.

For fun, I also tried to boot from the console, entering the commands manually. Then it complained about wrong magic bytes or some such (also for the Raspbian kernel). Why this, all of a sudden?

I'm running out of ideas of might go wrong here.
Am I missing something completely here?

Have a nice weekend
Robert

PS: The problems with the serial port outputting garbage when scanning USB and starting the kernel still persist. I guess this doesn't work as intended?
PPS: A ready to go distribution probably isn't going to help much as, figuring out how to setup the boot process with u-boot from scratch is the whole point of the project. Later on we want to repeat the process on some old, exotic embedded system which is already known to be quite quirky. (Of course, it has dropped out of support a long time ago...)


-----Ursprüngliche Nachricht-----
Von: Simon Glass <sjg at google.com> 
Gesendet: Dienstag, 25. Juli 2023 23:29
An: Robert Wenisch <RWenisch at bfs.de>
Cc: u-boot at lists.denx.de
Betreff: Re: getting u-boot to work on raspi 3b (32bit)

Hi Robert,

On Tue, 25 Jul 2023 at 09:42, Robert Wenisch <RWenisch at bfs.de> wrote:
>
> Hello,
>
> in order to study the boot process of embedded ARM systems, I decided to start with something well documented: booting as raspi 3b using u-boot.
> I downloaded kernel sources and u-boot sources. I built the kernel 
> with
>
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm make bcmrpi_defconfig
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm make -j6 zImage dtbs 
> modules cp arch/arm/boot/zImage /path/to/sdcard-boot-partition cp 
> arch/arm/boot/dts/bcm2710-rpi-3-b.dtb /path/to/sdcard-boot-partition
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm INSTALL_MOD_PATH make 
> modules_install
>
> Further I compiled and setup u-boot:
>
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm make rpi_3_32b_defconfig
> CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm make -j6
>
> cp u-boot.bin /path/to/ sdcard-boot-partition
>
> I then went on to edit the config.txt:
>
> kernel=u-boot-bin
> enable_uart=1
> arm_64bit=0
> device_tree=bcm2710-rpi-3-b.dtb
>
> and boot.txt goes
>
> fatload mmc 0:1 ${fdt_addr_r} bcm2710-rpi-3-b.dtb fatload mmc 0:1 
> $kernel_addr_r} zImage setenv bootargs console=ttyS0,115200 
> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait rw earlyprintk bootz 
> ${kernel_addr_r} - {fdt_addr_r}
>
> I produced an image of boot.txt
>
> mkimage -A arm -O linux -T script -d boot.txt boot.scr
>
> Frustratingly, it didn't go as smoothly as expected.

You should really be using FIT [1] for this, rather than legacy images.

>
> With these setting I got up to state "Starting Kernel ..." over the serial port, then it freezes (or at least doesn't log anything on the tty).
> I can't post the whole log as I only have it on my dev-machine.

You could try things like earlycon to get some console output.

> However some interesting bits for now:
> I'm booting on u-boot 2023-07-0967-g94e7cb181a
> 1 - Pretty much at the beginning it says "Loading Environment from FAT... *** warning - bad CRC, using default environment"
> I suppose this only means we're not providing a .env file?

Yes

>
> 2 - Upon "Scanning bus usb at 7e980000 for devices... it's logging a lot of garbage (as in misinterpreted character codes), what might be going on there?

No...some sort of clock problem?
>
> 3 - A bit further down it states "Found U-Boot script /boot.scr"
>  [...]
> "## Executing script at 02400000"
> As this changes when I edit around the boot.txt and mkimage, I infer u-boot is indeed loading my boot instructions not just some default values.

OK

>
> Then follow some info on kernel image flatted device tree blob and their respective memory addresses.
> It the tries to load the kernel to little apparent success :/
>
> This procedure is what I gathered from a plethora of tutorial and howtos. Most of these are quite old, have there been breaking changes in u-boot's development in the meanwhile?
> For example some sources state the kernel is launched via booti ${kernel_addr_r} - {fdt_addr_r}, however the booti command seem to be absent in my u-boot version.

I believe booti is for arm64 but you are using the 32-bit build of rpi-3, so you should be using bootm.

>
> Is there anything else I#m doing wrong?
>
> I'll be grateful for any hints at this point...

You could send a patch to [1] to help others!

There are also distros like Armbian which you can use out of the box.

Regards,
Simon

[1] https://u-boot.readthedocs.io/en/latest/usage/fit/index.html
[2] https://u-boot.readthedocs.io/en/latest/board/broadcom/raspberrypi.html


More information about the U-Boot mailing list