[U-Boot] fastboot boot base address behaviour
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
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
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/fast..., line 72 https://android.googlesource.com/platform/system/core/+/master/mkbootimg/mkb..., 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
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
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
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
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
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
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
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.
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
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.
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.
participants (4)
-
Marek Vasut -
Maxime Ripard -
Rob Herring -
Tom Rini