Hi Wolfgang,
Wolfgang Denk wrote:
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.
As far as I know the concat format was first used in 1999.
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.
So powerpc does it. I have used on plenty of other architectures (x86, ARM, SuperH, Sparc, ColdFire, etc) I have never come across "make zImage.initrd".
I have used ELF sections before, suffers from the similar problems (and them some extra ones too).
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.
Please. I have already stated - not my format, and not private. I could argue that the u-boot multi-file format is provate to u-boot.
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.
No it doesn't. Sorry, the whole world is not u-boot.
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).
Wrong, there is a difference. You have some wasted space between the kernel and filesystem. The concat image doesn't. This will make a difference if you are cramped for flash space.
Example scenario, your layout:
FLASH SIZE 2MB (64k uniform flash segments)
u-boot size 85k --> 128k rounded --> 2 flash segments kernel zImage 722k --> 768k rounded --> 12 flash segments cramfs size 1180k --> 1216k rounded --> 19 flasg semgmets
This does not fit in the 32 flash segments available.
With concat (size = 722k + 1180k = 1902k):
u-boot size 85k --> 128k rounded --> 2 flash segments concat size 1902k --> 1920k rounded --> 30 flash segments
Fits in 32 flash segments.
Size is NOT the same. These sizes are real u-boot binary, kernel zImage and CRAMfs filesystem
Then we've reached a point. You don't want to change anything.
I am willing to change how this is done in u-boot, but I am not willing to change the file format. And I sure don't want to be tied to one header format supported by one boot loader.
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.
Yes.
Regards Greg
------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com