Hi Wolfgang, On Wednesday 18 May 2011 11:36 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4dd352ea.3090...@ti.com> you wrote: >> >>> What you are doing here is defining an image format. Such an image >>> format must be good enough not only for OMAP4 and for loading U-Boot >>> as second stage, but for all other architectures and use cases as >>> well. >> >> I am not defining and publishing a format for the external world. It's > > In the essence this is what you are doing: you are defining an > interface how the payload has to look like. Anything not meeting this > "specification" or "image format" or "ABI" or whatever you call it > will not be directly loadable by the SPL.
This is not exactly true. I had implemented a fall-back option albeit with a maximum size assumed for U-Boot. > > But I want to make sure that we can load arbitrary payloads as second > stage, not only U-Boot images. Because we cannot guarantee that we > can embed such information into other payloads we may want to load, we > must prepend or append such information, but not embed it somewhere > within the image itself. > >> just an internal information much like any other info embedded in >> start.S such as _bss_end_ofs, _end_ofs etc. It's just that SPL, being >> an insider, can take advantage of it. > > This is not quite correct. SPL needs this information. We are defining > an API here, and we should make sure it fits the use cases we can see > now (and ideally is flexible enough so we can adjust/extend it for > future use). Agree that mkimage approach works better for different types of payloads. > >> I feel creating a new mkimage target just for this will be an overkill. > > We don't have to create a new format. We can, for example, use the > existing format with a prepended 64 byte header. The only thing that > needs changes is that we now have to consider the header when loading > the image, but the same problem will always exist when we accept that > we cannot embed the information within the payload. We don't need any > new code to implement this solution. We can easily create the images > using "mkimage -T firmware -O u-boot". The existing target u-boot.img works for me. Just a couple of questions: 1. I see that size is at offset 0xC in this header. Is this a standard? 2. I see that the header is 64 bytes. Is that again a standard for mkimage. 3. Is it ok to add u-boot.img to the target "ALL"? 4. If not, is it ok to add it to "ALL" when CONFIG_SPL is defined? Something like this: ifeq ($(CONFIG_SPL),y) .PHONEY : SPL -ALL += SPL +ALL += SPL u-boot.img endif Is it ok to add support for kernel payload as a subsequent incremental step. That's, right now I intend to parse the mkimage header, find the size and load address and load the image and pass control to it, but *without* passing any parameters. Is that ok? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
