Re: U-Boot <-> Kernel; NAND operation proposal

["Lambrecht Jürgen" <J.Lambrecht@TELEVIC.com>]

Hi Leon,

you better post this to linux-mtd@lists.infradead.org.
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@lists.infradead.org

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