From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Ungerer Date: Tue, 24 May 2005 20:23:37 +1000 Subject: [U-Boot-Users] [PATCH] add OpenGear CM4008 board support In-Reply-To: <20050524090051.4F212C1512@atlas.denx.de> References: <20050524090051.4F212C1512@atlas.denx.de> Message-ID: <429300A9.9050202@moreton.com.au> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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