Re: Beaglebone black issue loading booting kernel

[Antony Pavlov <antonynpavlov@gmail.com>]

On Mon, 12 Oct 2015 10:24:17 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> 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 :(

I see that ARM barebox suffering from kexec support absence.
IMHO I have to revive my 'kexec support for MIPS' series.
This series contain special post-barebox relocator
so kernel load memory range can harmlessly overlap barebox memory ranges.
At the long run kexec support can be beneficial for ARM too:
I have just examinied ARM linux kernel, it has relocator too!
(see linux.git/arch/arm/kernel/relocate_kernel.S), we can easely steal it.

-- 
Best regards,
  Antony Pavlov

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