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. 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). > 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". > I will be happy loading the maximum image size always. This makes no sense. What is "the maximum image size always"? 4 MB, so we can also load a Linux kernel as payload? 8 MB, so we can stil do this in a year from now? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A metaphor is like a simile. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
