U-Boot <-> Kernel; NAND operation proposal

U-Boot <-> Kernel; NAND operation proposal

[Leon Pollak]

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. 
This means that some units from time to time refuse to boot for 
different reasons.

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 
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.

Thanks to all who read this.
Best Regards
-- 
Leon Pollak

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

[Lambrecht Jürgen]

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