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

Greg Ungerer
2005-05-24T10:23:37Z

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