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

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

Hi Wolfgang,

I guess we have a mismatch here somewhere, lets try and straiten this out.


Wolfgang Denk wrote:
>>To get the filesystem size you have to look at the first few
>>words when you get it in memory. Once you figure out the filesystem
>>type (since there is only a couple of interresting types that
>>can work here you only need to check for the magic number header)
>>you know how to determine its size.
> 
> 
> Did you read my proposal of using a multifile image?

Yes, I read it. I don't currently see how it solves the problem.


>>You don't know where the kernel starts until you have a look in the
>>header of the filesystem. If it is CRAMfs or ROMfs (or that type of
> 
> 
> I understand this problem., It results from an unadept choice of your
> image layout - put the kernel first, and the problems  just  go  away
> :-)

I geuss I disagree. We see a different problem. I see u-boot doesn't
support an established image format. You see that it does (well I think
that is what you are saying?).

I don't want to neccessarily turn this into a discussion about the
merits of the format. I want this to be a discussion about how to go
about best supporting it.


>>>I think it is not a good idea to use header-less kernel images - most
>>>projects I've seen were happy enough to be able to  find  outr  which
>>>image is installed in flash and if it's corrupted or not. YMMV.
>>
>>Some people want that, some don't. There is a pretty big installed
>>base of configurations that don't use headers.
> 
> 
> Well, the only disadvantage you  get  from  having  a  header  is  an
> additional  64  bytes  (or  68  +  4  * number of images in case of a
> multi-image file). More memory is saved by NOT  adding  special  boot
> code for headerless images.

The size of the header is not important.


>>>"tftp ..." followed by using $filesize seems not too  complicated  to
>>>me.
>>
>>As I pointed out that does not work, it is not filesize you want.
> 
> 
> It does work. I use it all the time. You just have to use tftp  twice
> - once for the filesystem and a second time for the kernel :-)

Hmm, ok, you didn't say that earlier. Seems like an awful
kludge to have to load it twice - don't you think?


>>This method is in common use. The snapgear guys have been
>>doing it for years. They would have a pretty large installed
>>base (though that is not relevant to this discussion).
> 
> 
> Well, I cannot prevent anybody from not reading the documentation  or
> from  doing  non-standard  things.  I don't consider it my problem if
> Snapgear comes up with a solution that ignores the existing  standard
> methods and creates their own proprietary solutions or problems.

This isn't about reading documentation. And I suspect this method
predates u-boot anyway. When you say standard you really mean
u-boots own methods don't you?  Does any other boot loader support
the same format headers?  (I actually don't know the answer to
this, thus I am genuinely asking the question).


> Quote:
> 
> "UNIX was not designed to stop you from doing stupid things,  because
> that would also stop you from doing clever things."       - Doug Gwyn

Yes, illustrates my point really...
For one, u-boot has no mechanism for generating arm boot tags for
anything other than its own defined kernel format.


> But I will try to enforce some  design  principles  on  the  official
> U-Boot tree, and one of these is to avoid duplication of code.

Certainly. I have no issue with that. Never have.


> Don't use "a pretty large installed base" as an argument - it doesn't
> count. You could have discussed your design here on the mailing  list
> BEFORE implementing your own proprietary stuff.

That makes no sense, I want to use u-boot with an existing format.
No point asking years later what would be a good load format.


>>It is not a question of tolerating anything, it is about
>>finding a solution that is acceptable to you for something
>>that u-boot cannot currently do.
> 
> 
> Did you *read* me previous message? Why do you continue to ignore  my
> proposal of using a multifile image instead? I really don't see where
> exactly your problem is.

Ok, this is where I guess I don't understand your argument.

How can I take a multi-part image, and in Linux do

     erase /dev/mtd1
     cat imagefile > /dev/mtd1
     mount /dev/mtdblock1 /mnt

If there is any header then that is not directly mountable as
a filesystem.

You would need additional tool support to do this, and this
either goes in Linux or u-boot.


[snip a lot of stuff that all goes back to the above question]
>>2. you need to determine the kernel start address so you can
>>    run it (irrespective of whether it is in flash or network
>>    loaded into RAM
> 
> 
> You created this problem  yourself.  It  results  from  your  unadept
> design.

Sorry, just don't agree. Unadept design. It works very well
for its intended purpose. Just not with u-boot as it is.

Regards
Greg