* Beaglebone black issue loading booting kernel
@ 2015-10-11 10:51 Mathieu Tétreault
2015-10-12 8:24 ` Sascha Hauer
0 siblings, 1 reply; 4+ messages in thread
From: Mathieu Tétreault @ 2015-10-11 10:51 UTC (permalink / raw)
To: barebox
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
Loading U-Boot uImage '/boot/uImage'
Loading devicetree from '/boot/boneblack.dtb'
commandline: console=ttyO0,115200n8 ip=dhcp root=/dev/mmcblk0p2
rootfstype=ext4 rootwait
===
The last line I see on the terminal is the commandline:.... and then
it hangs there. I compared the load address and entry point with the
one that u-boot is using and they're the same.
I tried using the barebox internal dtb and providing an external one
that didn't changed anything.
From my understanding even if the rootpath is wrong the kernel should
start and later on I should receive an kernel panic/oops or something
like that.
Does anyone knows how I could debug that issue?
Regards,
Mathieu
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Beaglebone black issue loading booting kernel
2015-10-11 10:51 Beaglebone black issue loading booting kernel Mathieu Tétreault
@ 2015-10-12 8:24 ` Sascha Hauer
2015-10-12 9:27 ` Antony Pavlov
0 siblings, 1 reply; 4+ messages in thread
From: Sascha Hauer @ 2015-10-12 8:24 UTC (permalink / raw)
To: Mathieu Tétreault; +Cc: barebox
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Beaglebone black issue loading booting kernel
2015-10-12 8:24 ` Sascha Hauer
@ 2015-10-12 9:27 ` Antony Pavlov
2015-10-12 10:14 ` Sascha Hauer
0 siblings, 1 reply; 4+ messages in thread
From: Antony Pavlov @ 2015-10-12 9:27 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Mathieu Tétreault, barebox
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Beaglebone black issue loading booting kernel
2015-10-12 9:27 ` Antony Pavlov
@ 2015-10-12 10:14 ` Sascha Hauer
0 siblings, 0 replies; 4+ messages in thread
From: Sascha Hauer @ 2015-10-12 10:14 UTC (permalink / raw)
To: Antony Pavlov; +Cc: Mathieu Tétreault, barebox
On Mon, Oct 12, 2015 at 12:27:37PM +0300, Antony Pavlov wrote:
> 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.
This is not a real issue on ARM. I mean it's currently not supported
that the kernel overlaps barebox memory regions, but we can work around
it quite well.
The issue on ARM is the various constraints where to place images some
of which stated explicitly somewhere, others documented nowhere. Some of
the constraints are:
- With CONFIG_AUTO_ZRELADDR=y the zImage has to be placed in the first
128MiB of lowmem. How do we know we are about to load a kernel with
this option enabled?
- Documentation/arm/Booting states that:
The dtb must be placed in a region of memory where the kernel
decompressor will not overwrite it, whilst remaining within the
region which will be covered by the kernel's low-memory mapping.
Aha. How do we know a place where the kernel decompressor will not
overwrite it? We can only guess that, so at some point we used to move
the dtb up in RAM, sometimes so high that we trapped into the "within
the region which be covered by the kernel's low-memory mapping"
constraint. The recommendation is:
A safe location is just above the 128MiB boundary from start of
RAM.
Apparently systems with less than 256MiB of memory are no longer
interesting.
- With CONFIG_AUTO_ZRELADDR=y the kernel could be placed anywhere in the
128MiB in RAM, but unfortunately the u-boot uImage format does not
allow to leave the load address unspecified. So while the kernel
supports runtime determined SDRAM addresses, the uImage format does
not and makes this feature unusable with uImages.
IMO the Kernel decompressor overwriting the dtb is a bug that should be
fixed. In the bootloader we have no way to know where the kernel will
decompress itself and I think it should not have to know. The kernel
should just move the dtb somewhere else if it's not happy with the
current place. While this is really annoying I haven't been annoyed
enough to come up with a patch :(
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-10-12 10:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-11 10:51 Beaglebone black issue loading booting kernel Mathieu Tétreault
2015-10-12 8:24 ` Sascha Hauer
2015-10-12 9:27 ` Antony Pavlov
2015-10-12 10:14 ` Sascha Hauer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox