In message 42932848.7010704@moreton.com.au you wrote:
U-Boot uses multifile images for such a purpose. Please don't blame me if you ignored the existing solutions and came up with somthing different which causes problems (no working boot support).
This makes no sense, nobody ignored an exitsing u-boot solution, it did not exist yet!
Multifile images were added (to PPCBoot) in October 2000.
I don't load anything twice - I load two separate images: one with the kernel, and one with the file system. I always found this to be much more flexible as you can change one component while leaving the
...
It can be somewhat useful for debug. But the majority of use for real products in my experience it is not.
You're just working in a different area of the market.
I don't understand this. This has nothing to do with init ramdisk on Linux. The Linux ramdisk setup doesn't at all care how the ramdisk
Did you check what happens when you run "make zImage.initrd" in a PowerPC Linux tree? Yes, this has a lot to do with these things.
The header (or no header) is completely specific to u-boot/armboot/ ppcboot.
As mentioned before the U-Boot header is just one way. If you prefer to have sections in an ELF file please look around - there are several examples that use such a technology.
Please try to get a bit a wider view on this topic than just from the point of view of your product and just ARM systems.
But for your application I don't see the need to change anything.
I still don't see a solution to using this existing format. You have
So let's get this straight:
I will NOT add support for your private "existing format" because with the same right support for a zilion of other private formats would have to be added, too.
I will not discuss this decision unless (1) you prove that the existing code (i.e. multifile images) cannot be used for the same purpose and (2) it turns out that adapting the multifile support code creates a bigger mess than adding support for your private image format.
argued it is a bad format, you have argued if you re-organize it it could be made to work. That doesn't make u-boot work with this simple existing format as it is.
No. But it solves your problem.
Changing the format opens lots of options for layout, but that is not what this discussion is about. Lets start another thread if anyone wants to talk about that.
OK. Feel free to start such a new thread (or actually to continue this one).
The other part of the discussion is complete. I will reject code to support your private image format, even if you submit it as board-specific code.
Sorry for not being clear about this, but this is what I wanted to tell you right from the beginning.
U-boot is not the only loader that is used, will be used, or has been used on this hardware in the past. Existing devices that rely on the old format (for their tftp loading of images) won't have their boot loaders changed. So changing to a different format is not really an option here.
Then provide two images depending on which boot loade ris used. I understand that your bootloader is capable of checking if an image is valid for this hardware or not?
You have changed the format now, so that is not a solution to the problem.
OK. OK. OK.
You don't want to change your image, I don't want to change U-Boot.
I offered you a compromise (and actually a more powerful solution than what you have now), you don't accept it. It's your decision.
(The reason I would hesitate to use this is that you have now set an arbitrary limit on the kernel size, and you are potentially wasting up to 256k of flash in this example. Ofcourse you could
Ther eis no such limit. This was an EXAMPLE only. Feel free to adjust sizes as needed - and oviously limited by sector boundaries of your flash memory. SInce the kernel has the partition map embedded the map can be adjusted with each new kernel version transparently.
come up with a clever mtd map that let you have any size kernel, but you are still wasting some flash).
Yes, of course we're wasting flash - we have to round up to the next sector boundary - but this is exactly the same amount of flash you lose in your configuratio - in your case it's just "free" (= unused) space after the combined image. There is not a single byte difference (assuming uniform flash sectors).
It is merely about some mechanism to support an additional format - that is all.
And I tell you again that I will not add support for any arbitrary defined new image format.
I am simply make these changes available to the community, and if they are useful to others, then great. Otherwise it just doesn't matter.
Then we've reached a point. You don't want to change anything. I cannot allow arbitray code bloat. Anybody looking for a solution for the problem itself will be able to implement this in the existing U-Boot framework, without need for special code or new commands or boot image formats.
End of this discussion.
Best regards,
Wolfgang Denk