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 <s...@google.com> 
Gesendet: Dienstag, 25. Juli 2023 23:29
An: Robert Wenisch <rweni...@bfs.de>
Cc: u-boot@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 <rweni...@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@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

Reply via email to