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

Wolfgang Denk
2005-05-24T13:52:30Z

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

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