From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-lb0-x22c.google.com ([2a00:1450:4010:c04::22c]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1ZlZ2h-0006WR-R9 for barebox@lists.infradead.org; Mon, 12 Oct 2015 09:05:16 +0000 Received: by lbbck17 with SMTP id ck17so15997205lbb.1 for ; Mon, 12 Oct 2015 02:04:53 -0700 (PDT) Date: Mon, 12 Oct 2015 12:27:37 +0300 From: Antony Pavlov Message-Id: <20151012122737.3c7d9de51a1d12ed6536a213@gmail.com> In-Reply-To: <20151012082417.GP7858@pengutronix.de> References: <20151012082417.GP7858@pengutronix.de> Mime-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "barebox" Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: Beaglebone black issue loading booting kernel To: Sascha Hauer Cc: Mathieu =?ISO-8859-1?Q?T=E9treault?= , barebox@lists.infradead.org On Mon, 12 Oct 2015 10:24:17 +0200 Sascha Hauer wrote: > Hi Mathieu, > = > On Sun, Oct 11, 2015 at 06:51:06AM -0400, Mathieu T=E9treault 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 > > = > > =3D=3D=3D log =3D=3D=3D > > barebox 2015.10.0-00084-g54bf386 #2 Fri Oct 9 15:18:17 EDT 2015 > > = > > = > > Board: TI AM335x BeagleBone black > > detected 'BeagleBone Black' > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > = > > 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: > > =3D=3D=3D > > barebox@TI AM335x BeagleBone black:/ global.bootm.image=3D/boot/uImage > > barebox@TI AM335x BeagleBone black:/ global.bootm.oftree=3D/boot/bonebl= ack.dtb > > barebox@TI AM335x BeagleBone black:/ > > global.linux.bootargs.dyn.root=3D"root=3D/dev/mmcblk0p2 rootfstype=3Dex= t4 > > rootwait" > > =3D=3D=3D > > = > > I got the following log > > =3D=3D=3D > > 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 =3D 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. --=A0 Best regards, =A0 Antony Pavlov _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox