From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 10 Nov 2011 09:15:16 -0700 Subject: [U-Boot] [PATCH 1/2] image: Implement IH_TYPE_KERNEL_ANYLOAD In-Reply-To: <20111110115903.F01EC13BE0E2@gemini.denx.de> References: <1320860840-6347-1-git-send-email-swarren@nvidia.com> <20111110115903.F01EC13BE0E2@gemini.denx.de> Message-ID: <4EBBF894.2000409@nvidia.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 11/10/2011 04:59 AM, Wolfgang Denk wrote: > Dear Stephen Warren, > > In message <1320860840-6347-1-git-send-email-swarren@nvidia.com> you wrote: >> The legacy uImage format includes an absolute load and entry-point >> address. When bootm operates on a kernel uImage in memory that isn't >> loaded at the address in the image's load address, U-Boot will copy >> the image to its address in the header. >> >> Some kernel images can actually be loaded and used at any arbitrary >> address. An example is an ARM Linux kernel zImage file. To represent > > You write: an example is... > > Are there other Linux kernel image types in addition to zImage that > have this property? I'm sorry, I really don't know. Note that I even specifically said /ARM/ Linux kernel zImage, because I have no idea if zImage on other architectures is relocatable or not. >> this capability, IH_TYPE_KERNEL_ANYLOAD is implemented, which operates > > I don't like this name. "ANYLOAD" doesn't really make sense to me; I > would interpet this as "U-Boot is free to load the image to any > address it likes" - which is not what I think you mean. I think ANYLOAD describes the situation correctly: For IH_TYPE_KERNEL, the image is physically loaded to whatever address the U-Boot environment/script loads it to, and then U-Boot relocates the image to the load address in the header if it's not already there (for uncompressed images). With ANYLOAD, there is still a load address (wherever the U-Boot environment/script placed the image), yet any load address is accepted without relocation rather than just the one specified in the image header, so U-Boot always just skips the relocation. Put another way: extload/fatload load the image, and bootm just relocates/copies the image rather than loads it. > I guess "IH_TYPE_KERNEL_NOLOAD" would better match what the code is > supposed to do. I did consider that name too, but decided not to use it given my explanation above. I can rename it if you want though. > But then, I'd like "IH_TYPE_ZIMAGE" even better - assuming of course > that only zImages are used here. Are we sure about this? I deliberately didn't pick ZIMAGE, since I can't say for certain that only zImages are relocatable across all kernel image formats across all architectures. And note that ANYLOAD could well be applicable to non-Linux OSs for all I know; bootm appears to be able to boot a whole variety of other OSs, and I wouldn't be entirely surprised if at least one of them had fully relocatable images like ARM Linux kernel zImages. >> + if (images.os.type == IH_TYPE_KERNEL_ANYLOAD) { >> + images.os.load = images.os.image_start; >> + images.ep += images.os.load; >> + } > > I'm not sure if we give up flexibility here without need. > > Suggestion: IH_TYPE_KERNEL_NOLOAD images should read the entry point > address from the image header, and interpret it as an offset relative > to the image_start. Isn't that exactly what the code is doing; note ep is calculated as += not just =. > This adds basicly no code size, an no effort if > you don't want to use it (when running mkimage you will probably > always use "-a 0 -e 0" anyway), but in case you ever need a different > EP you have it, more or less for free. > >> + { IH_TYPE_KERNEL_ANYLOAD, "kernel_anyload", "Kernel Image (any load address)", }, > > ...IH_TYPE_KERNEL_NOLOAD ..."Kernel Image (no loading done)" ? Perhaps "(no relocation)"? -- nvpublic