[U-Boot] fastboot boot base address behaviour

[Maxime Ripard <maxime.ripard@free-electrons.com>]

On Wed, Apr 29, 2015 at 09:11:03AM -0500, Rob Herring wrote:
> On Wed, Apr 29, 2015 at 3:12 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Rob,
> >
> > On Tue, Apr 28, 2015 at 05:24:59PM -0500, Rob Herring wrote:
> >> On Wed, Apr 22, 2015 at 8:04 AM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > Hi,
> >> >
> >> > I've been trying to use fastboot (and especially the boot command) on
> >> > sunxi recently, and got it to work pretty fine (apart from PSCI, but
> >> > that's another story).
> >> >
> >> > The only thing that worries me a bit is that by default, both the
> >> > fastboot tool and mkbootimg will generate an image with the kernel
> >> > address set to 0x10008000.
> >> >
> >> > While it might work on some targets, it obviously doesn't on the
> >> > Allwinner SoCs that most of the time have the RAM mapped to 0x4000000,
> >> > which result in the kernel being relocated to some address that is not
> >> > in RAM, failing badly.
> >> >
> >> > I would expect U-Boot to relocate the kernel to some reasonable
> >> > address, and not try to do something dumb by actually trusting
> >> > completely the boot image.
> >> >
> >> > I guess one way to solve this would be to really treat 0x10008000 as
> >> > the default, and relocate the kernel to whatever value make sense on
> >> > the current platform (even though that needs to be defined).
> >> >
> >> > That way, "fastboot boot zImage" would actually work out of the box,
> >> > without requiring to set the optional "-b" option to set the kernel
> >> > base address to some decent value.
> >> >
> >> > The others implementation I could find seem to just ignore this field
> >> > in the image header, and always load it to the same address, which
> >> > might not really be what we're after here.
> >> >
> >> > What do you think?
> >>
> >> Android boot image is pretty broken in a variety of ways and with
> >> vendors doing their own extensions/hacks. The issues I see are:
> >>
> >> - Addresses are 32-bit
> >
> > I've not really thought about that since it still haven't had my hands
> > on a 64 bit system, but that's true.
> >
> >> - A boot image will only work on 1 platform (because of the kernel and
> >>   ramdisk addresses)
> >
> > Is that really a thing? I mean, the kernel and dtb combination will
> > be different, no matter what kind of image you make.
> 
> You're assuming the dtb is in the boot image. Maybe it is, maybe it
> isn't. Who knows.

Well, there's a good chance it will, at least appended to the zImage.

> > And there's a good chance that the ramdisk image itself will change
> > too from one platform to another, to handle the different hardware,
> > have different packages, etc.
> 
> Agreed, today everything in Android is built to a single platform much
> like the kernel used to be. There is no kernel ABI in Android. There's
> no boot interface ABI either. Maybe all that changes and then this
> will be a problem.

IIRC, in Android, you already have some support already for a
multi-devices image (at least for all that HAL stuff). So the ramdisk
might be the same, but I'm not sure anyone is really building such an
image.

> > So yeah, it will only work on a single platform (even a single board),
> > but I really wouldn't expect it to do more.
> >
> >> - Different kernel Image formats within boot.img: uImage, zImage,
> >>   Image.gz, etc.
> >
> > Can that really happen? I thought that you could only have "real"
> > bootable kernel images in boot.img (ie, not uImage)
> 
> Yes, a vendor's Android I've worked on does just that. The dtb is
> placed at 15MB offset in the boot.img with that offset hardcoded in
> u-boot. It's good thing that a kernel+ramdisk will never be bigger
> than 15MB. ;)

My current kernel is bigger than that ;)

> >> - No standard way to deal with dtb. arm32 is somewhat "standard" with
> >> appended dtb. AOSP adds appended dtb for arm64, but it is never going
> >> upstream.
> >
> > I've also tried to add DTB support in the boot.img file format. I'm
> > struggling for now with the u-boot code to handle this properly, but I
> > don't think I'm that far.
> >
> >> For the kernel address, we should probably just ignore it. For zImage,
> >> it doesn't really need to be moved from where ever the boot.img is
> >> loaded to (assuming it is within the zImage address requirements). It
> >> is going to relocate itself anyway. Putting in a correct kernel
> >> address will just cause a double copy.
> >
> > That's true if we only care about the zImage, which is what happens so
> > far. But if we also care about the embedded initramfs and the embedded
> > dtb, we will have to relocate those to avoid the kernel uncompressing
> > over these two images.
> >
> > I'm not sure what a good address for that would be (ramdisk_addr_r and
> > fdt_addr_r maybe?), but we still need to do it.
> 
> We know the kernel must be within a certain offset of start of RAM(2MB
> on arm64 and 16MB on arm32 IIRC). So the boot.img load address should
> be somewhere above 64 or 128MB offset from start of RAM.

Yeah, but I would hope the various platforms define appropriate values
for these variables so that everything just works.

> >> For arm64 Image, the image header defines the offset and u-boot must
> >> load it to that offset or you won't boot. There's only 1 correct
> >> address and 2^32 - 1 wrong addresses the boot.img could have.
> >
> > Ok, so the simplest thing to do would be to always relocate the kernel
> > then.
> 
> Probably so as it is likely smaller than the ramdisk and needing
> decompression also (once we support arm64 Image.gz).

Ok.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150501/24c4afe9/attachment.sig>