Hi Wolfgang,
On Wednesday 18 May 2011 11:36 AM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4DD352EA.3090007@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?