Hi Leon, you better post this to linux-mtd@xxxxxxxxxxxxxxxxxxx. You will get a better response there. On 12/04/2013 05:39 PM, Leon Pollak wrote: > Hello, all. > > I beg your pardon ahead for possible stupidity and inconsistency of what > I am going to say - this may be simply because of the lack of > experience. Below is my story and proposal as the result. > > During the last 2 years, my product, which is based on DM368 (ARM7 based > TI CPU) and Micron's NAND flashes (256MiB, 2K page) behaves unstably. You have linux on ARM7, uClinux then? > This means that some units from time to time refuse to boot for > different reasons. I think booting from NAND is a bad idea for embedded devices. NAND has bit-rot (also called read-disturb(http://ecos.sourceware.org/ml/ecos-discuss/2011-05/msg00074.html)) (http://www.linux-mtd.infradead.org/doc/ubifs.html#L_ubifs_mlc), even when just reading (the bootloader binary). So suddenly the boot binary could have e.g. a bit-flip. But maybe you already have redundant boot images? We always use NOR flash to boot. > > Today, after so long time and so many corrections, I can say that most > of the problems (not all!), which lead to the unit unable to start to > the end (to the application) where because of the incompatible modes of > NAND operating between u-boot and kernel. > > For example, in the configuration I started from, which was supplied by > some vendor as evaluation board, u-boot was configured to use 4-bit HW > ECC, while kernel used 1-bit SW ECC. > > The OOB layouts used in both systems were different. > Also BBT were configured differently. > > There were several other "small things", which combination was > inconsistent and produced the incorrect NAND functioning, which finally > in some cases made the unit inoperative. > > -- > > The major issue here is that such inconsistencies are not manifested in > some way, until the unit suddenly refuse to boot up after 2 weeks or 2 > years. > > All this lead me to the following thought (very draftly): > > Each NAND has the "spare free" area in the first (zero) block, which is > used for storing CIS information. This information does not occupy all (I think the experts on linux-mtd will know this stands for Card Information Structure, but I didn't ;-) > the block, which usually is several hundreds of kilobytes. > So, this "spare" place may be used for storing some descriptive > information of ALL possible NAND flash and its service parameters. > I am speaking about ECC bits, Sw/HW, OOB layout, BBT layout, patter > places, bad block marks, and everything else you can imagine. > > Further, this information must be used both by u-boot and kernel. Or > even by other components, for example, RBL/UBL in DM36x from TI. I think that is a good idea. I recently also had nand flash issues with BBT layout. You better also post this to the uboot and barebox (uboot v2) mailing list; I only know barebox: barebox@xxxxxxxxxxxxxxxxxxx Kind regards, Jürgen > > Thanks to all who read this. > Best Regards -- Jürgen Lambrecht R&D Associate Mobile: +32 499 644 531 Tel: +32 (0)51 303045 Fax: +32 (0)51 310670 http://www.televic-rail.com Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium Company number 0825.539.581 - RPR Kortrijk ��.n��������+%������w��{.n�����{��w��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
