From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Ungerer Date: Wed, 25 May 2005 10:35:17 +1000 Subject: [U-Boot-Users] [PATCH] add OpenGear CM4008 board support In-Reply-To: <20050524135235.DA370C1512@atlas.denx.de> References: <20050524135235.DA370C1512@atlas.denx.de> Message-ID: <4293C845.2020605@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, Wolfgang Denk wrote: > 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. As far as I know the concat format was first used in 1999. >>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. So powerpc does it. I have used on plenty of other architectures (x86, ARM, SuperH, Sparc, ColdFire, etc) I have never come across "make zImage.initrd". I have used ELF sections before, suffers from the similar problems (and them some extra ones too). >>>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. Please. I have already stated - not my format, and not private. I could argue that the u-boot multi-file format is provate to u-boot. > 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. No it doesn't. Sorry, the whole world is not u-boot. >>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). Wrong, there is a difference. You have some wasted space between the kernel and filesystem. The concat image doesn't. This will make a difference if you are cramped for flash space. Example scenario, your layout: FLASH SIZE 2MB (64k uniform flash segments) u-boot size 85k --> 128k rounded --> 2 flash segments kernel zImage 722k --> 768k rounded --> 12 flash segments cramfs size 1180k --> 1216k rounded --> 19 flasg semgmets This does not fit in the 32 flash segments available. With concat (size = 722k + 1180k = 1902k): u-boot size 85k --> 128k rounded --> 2 flash segments concat size 1902k --> 1920k rounded --> 30 flash segments Fits in 32 flash segments. Size is NOT the same. These sizes are real u-boot binary, kernel zImage and CRAMfs filesystem > Then we've reached a point. You don't want to change anything. I am willing to change how this is done in u-boot, but I am not willing to change the file format. And I sure don't want to be tied to one header format supported by one boot loader. > 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. Yes. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: gerg at snapgear.com SnapGear -- a CyberGuard Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com