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

[Greg Ungerer <gerg@moreton.com.au>]

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