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]
- 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