On Wed, Apr 29, 2015 at 09:11:03AM -0500, Rob Herring wrote: > On Wed, Apr 29, 2015 at 3:12 AM, Maxime Ripard > <[email protected]> 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 > >> <[email protected]> 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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
