[U-Boot] fastboot boot base address behaviour

[Rob Herring]

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
- A boot image will only work on 1 platform (because of the kernel and
ramdisk addresses)
- Different kernel Image formats within boot.img: uImage, zImage, Image.gz, etc.
- 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.

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

Rob