[U-Boot] fastboot boot base address behaviour

[U-Boot] fastboot boot base address behaviour

[Maxime Ripard]

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?

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/20150422/7af29e79/attachment.sig>

[U-Boot] fastboot boot base address behaviour

[Marek Vasut]

On Wednesday, April 22, 2015 at 03:04:47 PM, Maxime Ripard wrote:
> Hi,

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.

Looks like MX6 DRAM base address, so this should definitelly not be
fixed to this address here. The +0x8000 offset is the kernel load
offset.

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

Yep.

> 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'd expect the image to be correct in the first place though ;-)

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

Then I'd say such "default" address should be something like 0xffffffff .

> 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?
> 
> Maxime

Best regards,
Marek Vasut

[U-Boot] fastboot boot base address behaviour

[Maxime Ripard]

On Wed, Apr 22, 2015 at 05:56:23PM +0200, Marek Vasut wrote:
> > 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.
> 
> Looks like MX6 DRAM base address, so this should definitelly not be
> fixed to this address here. The +0x8000 offset is the kernel load
> offset.
> 
> > 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.
> 
> Yep.
> 
> > 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'd expect the image to be correct in the first place though ;-)
> 
> > 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.
> 
> Then I'd say such "default" address should be something like 0xffffffff .

I'd probably agree if we were on a perfect world :)

But the fact is that the tools that are creating these boot.img in
Android all have this default, and *will* fill the kernel address
header to this value.

https://android.googlesource.com/platform/system/core/+/master/fastboot/fastboot.cpp, line 72
https://android.googlesource.com/platform/system/core/+/master/mkbootimg/mkbootimg.c, line 112

So even if we send a patch to Android itself, that won't fix the tools
that are already in the source code of published Android versions, or
the packages bundled in the distribution.

So I think that instead of blindly trusting these tools, U-Boot should
handle that address has the de facto default, even if it doesn't make
any sense :)

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/20150423/0c57fbf0/attachment.sig>

[U-Boot] fastboot boot base address behaviour

[Marek Vasut]

On Thursday, April 23, 2015 at 09:41:04 AM, Maxime Ripard wrote:
> On Wed, Apr 22, 2015 at 05:56:23PM +0200, Marek Vasut wrote:
> > > 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.
> > 
> > Looks like MX6 DRAM base address, so this should definitelly not be
> > fixed to this address here. The +0x8000 offset is the kernel load
> > offset.
> > 
> > > 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.
> > 
> > Yep.
> > 
> > > 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'd expect the image to be correct in the first place though ;-)
> > 
> > > 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.
> > 
> > Then I'd say such "default" address should be something like 0xffffffff .
> 
> I'd probably agree if we were on a perfect world :)
> 
> But the fact is that the tools that are creating these boot.img in
> Android all have this default, and *will* fill the kernel address
> header to this value.
> 
> https://android.googlesource.com/platform/system/core/+/master/fastboot/fas
> tboot.cpp, line 72
> https://android.googlesource.com/platform/system/core/+/master/mkbootimg/m
> kbootimg.c, line 112
> 
> So even if we send a patch to Android itself, that won't fix the tools
> that are already in the source code of published Android versions, or
> the packages bundled in the distribution.
> 
> So I think that instead of blindly trusting these tools, U-Boot should
> handle that address has the de facto default, even if it doesn't make
> any sense :)

OK, now I agree. Maybe we should fix both -- the tools and U-Boot.

Best regards,
Marek Vasut

[U-Boot] fastboot boot base address behaviour

[Maxime Ripard]

On Thu, Apr 23, 2015 at 02:00:01PM +0200, Marek Vasut wrote:
> On Thursday, April 23, 2015 at 09:41:04 AM, Maxime Ripard wrote:
> > On Wed, Apr 22, 2015 at 05:56:23PM +0200, Marek Vasut wrote:
> > > > 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.
> > > 
> > > Looks like MX6 DRAM base address, so this should definitelly not be
> > > fixed to this address here. The +0x8000 offset is the kernel load
> > > offset.
> > > 
> > > > 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.
> > > 
> > > Yep.
> > > 
> > > > 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'd expect the image to be correct in the first place though ;-)
> > > 
> > > > 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.
> > > 
> > > Then I'd say such "default" address should be something like 0xffffffff .
> > 
> > I'd probably agree if we were on a perfect world :)
> > 
> > But the fact is that the tools that are creating these boot.img in
> > Android all have this default, and *will* fill the kernel address
> > header to this value.
> > 
> > https://android.googlesource.com/platform/system/core/+/master/fastboot/fas
> > tboot.cpp, line 72
> > https://android.googlesource.com/platform/system/core/+/master/mkbootimg/m
> > kbootimg.c, line 112
> > 
> > So even if we send a patch to Android itself, that won't fix the tools
> > that are already in the source code of published Android versions, or
> > the packages bundled in the distribution.
> > 
> > So I think that instead of blindly trusting these tools, U-Boot should
> > handle that address has the de facto default, even if it doesn't make
> > any sense :)
> 
> OK, now I agree. Maybe we should fix both -- the tools and U-Boot.

I'll try to cook up a patch, send it to AOSP and see how it goes.

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/20150425/ecee03b1/attachment.sig>

[U-Boot] fastboot boot base address behaviour

[Marek Vasut]

On Saturday, April 25, 2015 at 08:22:26 AM, Maxime Ripard wrote:
> On Thu, Apr 23, 2015 at 02:00:01PM +0200, Marek Vasut wrote:
> > On Thursday, April 23, 2015 at 09:41:04 AM, Maxime Ripard wrote:
> > > On Wed, Apr 22, 2015 at 05:56:23PM +0200, Marek Vasut wrote:
> > > > > 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.
> > > > 
> > > > Looks like MX6 DRAM base address, so this should definitelly not be
> > > > fixed to this address here. The +0x8000 offset is the kernel load
> > > > offset.
> > > > 
> > > > > 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.
> > > > 
> > > > Yep.
> > > > 
> > > > > 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'd expect the image to be correct in the first place though ;-)
> > > > 
> > > > > 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.
> > > > 
> > > > Then I'd say such "default" address should be something like
> > > > 0xffffffff .
> > > 
> > > I'd probably agree if we were on a perfect world :)
> > > 
> > > But the fact is that the tools that are creating these boot.img in
> > > Android all have this default, and *will* fill the kernel address
> > > header to this value.
> > > 
> > > https://android.googlesource.com/platform/system/core/+/master/fastboot
> > > /fas tboot.cpp, line 72
> > > https://android.googlesource.com/platform/system/core/+/master/mkbootim
> > > g/m kbootimg.c, line 112
> > > 
> > > So even if we send a patch to Android itself, that won't fix the tools
> > > that are already in the source code of published Android versions, or
> > > the packages bundled in the distribution.
> > > 
> > > So I think that instead of blindly trusting these tools, U-Boot should
> > > handle that address has the de facto default, even if it doesn't make
> > > any sense :)
> > 
> > OK, now I agree. Maybe we should fix both -- the tools and U-Boot.
> 
> I'll try to cook up a patch, send it to AOSP and see how it goes.

Ok, thank you!

Best regards,
Marek Vasut

[U-Boot] fastboot boot base address behaviour

[Rob Herring]

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

[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@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>

[U-Boot] fastboot boot base address behaviour

[Rob Herring]

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.

> 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

[U-Boot] fastboot boot base address behaviour

[Tom Rini]

On Wed, Apr 29, 2015 at 09:11:03AM -0500, Rob Herring wrote:

[snip]
> >> 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).

Not to side-track things much but we "support" Image.gz today but yes as
a two-step thing.  I think there was some talk about trying to be clever
enough to decompress the first page so we could peek at the Image
header, see where things needed to end up, and then decompress to that
location but it either wasn't feasible or more likely didn't get too
high in priority.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150429/4d098fb9/attachment.sig>

[U-Boot] fastboot boot base address behaviour

[Rob Herring]

On Wed, Apr 29, 2015 at 9:25 AM, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Apr 29, 2015 at 09:11:03AM -0500, Rob Herring wrote:
>
> [snip]
>> >> 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).
>
> Not to side-track things much but we "support" Image.gz today but yes as
> a two-step thing.  I think there was some talk about trying to be clever
> enough to decompress the first page so we could peek at the Image
> header, see where things needed to end up, and then decompress to that
> location but it either wasn't feasible or more likely didn't get too
> high in priority.

Is that documented how somewhere? Presumably it is load, gunzip,
booti? This would not work if contained within a boot.img. We'd need
the auto detect as you mention.

Rob

[U-Boot] fastboot boot base address behaviour

[Tom Rini]

On Wed, Apr 29, 2015 at 09:30:17AM -0500, Rob Herring wrote:
> On Wed, Apr 29, 2015 at 9:25 AM, Tom Rini <trini@konsulko.com> wrote:
> > On Wed, Apr 29, 2015 at 09:11:03AM -0500, Rob Herring wrote:
> >
> > [snip]
> >> >> 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).
> >
> > Not to side-track things much but we "support" Image.gz today but yes as
> > a two-step thing.  I think there was some talk about trying to be clever
> > enough to decompress the first page so we could peek at the Image
> > header, see where things needed to end up, and then decompress to that
> > location but it either wasn't feasible or more likely didn't get too
> > high in priority.
> 
> Is that documented how somewhere? Presumably it is load, gunzip,
> booti? This would not work if contained within a boot.img. We'd need
> the auto detect as you mention.

That we have 'unzip' as a command?  No, that's a little "hidden" I
suppose, but it's enabled for Juno and the Xilinx ARMv8 platforms.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150429/5f9d814e/attachment.sig>

[U-Boot] fastboot boot base address behaviour

[Maxime Ripard]

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>