[U-Boot] fastboot boot base address behaviour

[Rob Herring]

On Wed, Apr 29, 2015 at 3:12 AM, Maxime Ripard
<maxime.ripard at 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 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.

You're assuming the dtb is in the boot image. Maybe it is, maybe it
isn't. Who knows.

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

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

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

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

Rob