On Mon, 12 Oct 2015 10:24:17 +0200 Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
