Hi Sergey, On Sun, Feb 17, 2008 at 10:15:57AM -0800, [EMAIL PROTECTED] wrote: > > Thanks for pointing that patch out! I agree with Sergey that it > > should be a run-time option. Perhaps some generic infrastructure > > to support additional NAND commands could be leveraged upon > > later. > > The proper way to do this would be adding an additional command to NAND > tools suite. Something like "nand write-ubl" or something.
Yep. If the write.jffs2 syntax is actually used and valid, it would seem logical to have write.ubl too. > > Personally, I think it's silly to have one tool to write one > > part of flash and another tool to write the other, but I can > > understand why people want to do it in different ways. > > Those are totally different tools. Initial bootloader is used on virgin > DaVinci hardware that doesn't have any software on it. Sure one can use > U-Boot to write UBL and U-boot into NAND but one has to load that U-Boot > somehow first. Rudy's UBL flasher will boot u-boot over the UART. From there you could download UBL & application code over the network. Also, it only takes one unforgiving slip of the hand to cause "nand erase\n" on unprotected flash to give you a virgin board, so I claim it's not that much of a special case. > And if an initial boot loader is required anyways (it is required > to boot off of NAND anyways, U-Boot can NOT boot itself from NAND) > why not use it for writing itself and user application (e.g. > U-Boot) into NAND? Because then you have two tools for writing different parts of flash and a bloated UBL. Typically you'd have in flash the UBL (possibly up to 5 times), an optional bootloader (possibly duplicated also), a kernel, and a filesystem (perhaps two - one RO, one RW). There is not yet a single tool that can do all of these, though there are *many* tools that can do some of these. > Another consideration is that U-Boot is not omnipresent and omnipotent. Yes, > it is most frequently used user application but it is not mandatory. One can > use something else (e.g. some standalone OS-less app, some OS kernel etc.) > instead of U-Boot thus having no other options for writing into NAND... I agree, however that shouldn't rule out the possibility for people that do use U-boot. > > From a quick Google and glance at the uboot code > > (drivers/mtd/nand/nand_util.c), it seems there are already > > differences in ECC formats between jffs2 and yaffs. > > No, ECC is the same. ECC is on driver level and it is the same no matter > what data is written to NAND. ECC takes just a _PART_ of OOB area and ECC > code doesn't care what is written to unused OOB parts. That is where YAFFS > and JFFS2 differ -- they use those _UNUSED_ OOB bytes differently. Ahh, thanks for clarifying. Maybe write.ubl isn't the best option from a code standpoint, but it probably still makes more sense to the user. My 2.2c. Cheers, Bernard. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
