Hi Robert,
On Fri, 28 Jul 2023 at 07:39, Robert Wenisch <rweni...@bfs.de> wrote:
>
> 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".
I wonder whether you have somehow disabled CONFIG_FIT ?
>
> 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 not sure...perhaps if you send the error message people might be
able to help?
>
> 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?
I don't know, but there is some strange clocking on at least one
UART...perhaps a conflict? I typically use the UART that requires
gpu_freq=250 in the config.txt file.
> 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...)
Sure...it's just that when you start with that you can understand what
it is doing, then follow along, building up your knowledge. When you
start from a blank slate it can be a bit of a shot in the dark.
Regards,
Simon
>
>
> -----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
