[U-Boot] fastboot boot base address behaviour

[Maxime Ripard]

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 at 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.

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.

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)

> - 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.

> 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.

Maxime

-- 
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/20150429/75b5a906/attachment.sig>