* [U-Boot] fastboot boot base address behaviour @ 2015-04-22 13:04 Maxime Ripard 2015-04-22 15:56 ` Marek Vasut 2015-04-28 22:24 ` Rob Herring 0 siblings, 2 replies; 13+ messages in thread From: Maxime Ripard @ 2015-04-22 13:04 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-22 13:04 [U-Boot] fastboot boot base address behaviour Maxime Ripard @ 2015-04-22 15:56 ` Marek Vasut 2015-04-23 7:41 ` Maxime Ripard 2015-04-28 22:24 ` Rob Herring 1 sibling, 1 reply; 13+ messages in thread From: Marek Vasut @ 2015-04-22 15:56 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-22 15:56 ` Marek Vasut @ 2015-04-23 7:41 ` Maxime Ripard 2015-04-23 12:00 ` Marek Vasut 0 siblings, 1 reply; 13+ messages in thread From: Maxime Ripard @ 2015-04-23 7:41 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-23 7:41 ` Maxime Ripard @ 2015-04-23 12:00 ` Marek Vasut 2015-04-25 6:22 ` Maxime Ripard 0 siblings, 1 reply; 13+ messages in thread From: Marek Vasut @ 2015-04-23 12:00 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-23 12:00 ` Marek Vasut @ 2015-04-25 6:22 ` Maxime Ripard 2015-04-25 15:53 ` Marek Vasut 0 siblings, 1 reply; 13+ messages in thread From: Maxime Ripard @ 2015-04-25 6:22 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-25 6:22 ` Maxime Ripard @ 2015-04-25 15:53 ` Marek Vasut 0 siblings, 0 replies; 13+ messages in thread From: Marek Vasut @ 2015-04-25 15:53 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-22 13:04 [U-Boot] fastboot boot base address behaviour Maxime Ripard 2015-04-22 15:56 ` Marek Vasut @ 2015-04-28 22:24 ` Rob Herring 2015-04-29 8:12 ` Maxime Ripard 1 sibling, 1 reply; 13+ messages in thread From: Rob Herring @ 2015-04-28 22:24 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-28 22:24 ` Rob Herring @ 2015-04-29 8:12 ` Maxime Ripard 2015-04-29 14:11 ` Rob Herring 0 siblings, 1 reply; 13+ messages in thread From: Maxime Ripard @ 2015-04-29 8:12 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-29 8:12 ` Maxime Ripard @ 2015-04-29 14:11 ` Rob Herring 2015-04-29 14:25 ` Tom Rini 2015-05-01 20:30 ` Maxime Ripard 0 siblings, 2 replies; 13+ messages in thread From: Rob Herring @ 2015-04-29 14:11 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-29 14:11 ` Rob Herring @ 2015-04-29 14:25 ` Tom Rini 2015-04-29 14:30 ` Rob Herring 2015-05-01 20:30 ` Maxime Ripard 1 sibling, 1 reply; 13+ messages in thread From: Tom Rini @ 2015-04-29 14:25 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-29 14:25 ` Tom Rini @ 2015-04-29 14:30 ` Rob Herring 2015-04-29 15:46 ` Tom Rini 0 siblings, 1 reply; 13+ messages in thread From: Rob Herring @ 2015-04-29 14:30 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-29 14:30 ` Rob Herring @ 2015-04-29 15:46 ` Tom Rini 0 siblings, 0 replies; 13+ messages in thread From: Tom Rini @ 2015-04-29 15:46 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] fastboot boot base address behaviour 2015-04-29 14:11 ` Rob Herring 2015-04-29 14:25 ` Tom Rini @ 2015-05-01 20:30 ` Maxime Ripard 1 sibling, 0 replies; 13+ messages in thread From: Maxime Ripard @ 2015-05-01 20:30 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-05-01 20:30 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-22 13:04 [U-Boot] fastboot boot base address behaviour Maxime Ripard 2015-04-22 15:56 ` Marek Vasut 2015-04-23 7:41 ` Maxime Ripard 2015-04-23 12:00 ` Marek Vasut 2015-04-25 6:22 ` Maxime Ripard 2015-04-25 15:53 ` Marek Vasut 2015-04-28 22:24 ` Rob Herring 2015-04-29 8:12 ` Maxime Ripard 2015-04-29 14:11 ` Rob Herring 2015-04-29 14:25 ` Tom Rini 2015-04-29 14:30 ` Rob Herring 2015-04-29 15:46 ` Tom Rini 2015-05-01 20:30 ` Maxime Ripard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.