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

[Wolfgang Denk]

In message <42932848.7010704 at 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

-- 
You can love it, change it, or leave it.    There is NO other option.
But do not complain - it is your own choice...                  -- wd