[U-Boot-Users] [PATCH] add OpenGear CM4008 board support

Greg Ungerer
2005-05-25T00:35:17Z

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 at 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