Re: Beaglebone black issue loading booting kernel

[Sascha Hauer <s.hauer@pengutronix.de>]

Hi Mathieu,

On Sun, Oct 11, 2015 at 06:51:06AM -0400, Mathieu Tétreault wrote:
> I compiled barebox to run on the beaglebone black using the
> am335x_mlo_defconfig and am335x_defonfig which gaves me the
> barebox-am33xx-beaglebone.img(barebox.bin) and
> barebox-am33xx-beaglebone-mlo.img(MLO).
> 
> This part works fine since I'm able to get in barebox and the board is
> detected as beaglebone black
> 
> === log ===
> barebox 2015.10.0-00084-g54bf386 #2 Fri Oct 9 15:18:17 EDT 2015
> 
> 
> Board: TI AM335x BeagleBone black
> detected 'BeagleBone Black'
> =========
> 
> If I let the autoboot start it always ends up looking for a NFS server
> which I don't have right now.
> 
> What I have right now is an SD card with a rootfs generated by Yocto.
> This rootfs is able to boot using the u-boot binary that yocto
> compiled.
> 
> When I use:
> ===
> barebox@TI AM335x BeagleBone black:/ global.bootm.image=/boot/uImage
> barebox@TI AM335x BeagleBone black:/ global.bootm.oftree=/boot/boneblack.dtb
> barebox@TI AM335x BeagleBone black:/
> global.linux.bootargs.dyn.root="root=/dev/mmcblk0p2 rootfstype=ext4
> rootwait"
> ===
> 
> I got the following log
> ===
> barebox@TI AM335x BeagleBone black:/ bootm
>    Image Name:   Linux-3.14.19-yocto-standard
>    OS:           Linux
>    Architecture: ARM
>    Type:         Kernel Image
>    Compression:  uncompressed
>    Data Size:    5068000 Bytes = 4.8 MiB
>    Load Address: 80008000
>    Entry Point:  80008000

It seems we stumbled upon another bad image placement. What happens here
is:

- The uImage forces the load address to 0x80008000.
- We put the device tree binary somewhere behind that
- The Kernel uncompresses itself and overwrites the device tree

You have some options to work around this issue. You can use a zImage
rather than a uImage. That's my recommended approach. barebox will put
the zImage to a suitable place. If you insist on uImage you could also
specify the LOADADDR to 0xffffffff. If barebox finds this address it
picks a suitable address itself. The image won't work with U-Boot
though. The LOADADDR must be passed to the kernel during build. I don't
know though how Yocto handles this and how it could be overwritten.

Note that 0x80008000 is a bad choice anyway. This is exactly the place
where the kernel self extractor will place the final kernel. To do so it
must first move the compressed binary to another place, because
otherwise it would overwrite itself.

I would love to fix these load address issues, but unfortunately this
area is full of historic cruft where fixing one issue just raises
another one :(

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox