Re: NAND review

Rutger Hofman <[email protected]>
Newsgroups gmane.os.ecos.devel
Message-ID <[email protected]>
Bart Veer wrote:
>>>>>> "Andrew" == Andrew Lunn <[email protected]> writes:
> 
>     >> The partition definition is necessarily platform-specific, so
>     >> doesn't fit anywhere else.
> 
>     Andrew> I simply don't get this. 
> 
>     Andrew> Take a case i recently had with a NOR based system. I had
>     Andrew> a linux kernel bug i had to trace down. So that i had
>     Andrew> human readable kernel opps information, i rebuilt the
>     Andrew> kernel to include debug symbols. The resulting kernel was
>     Andrew> too big to fit in the space allocated to it. So i used
>     Andrew> redboot fis to zap both the root filesystem and the space
>     Andrew> holding the kernel. I recreated the kernel partition a bit
>     Andrew> bigger and made the root filesystem a bit smaller. I then
>     Andrew> installed the new kernel and the root filesystem. I then
>     Andrew> had a booting system with opps with symbols, not hex
>     Andrew> addresses.
> 
>     Andrew> At no point did i need to edit the HAL, rebuild and
>     Andrew> install a new redboot. Why should NAND be different? Why
>     Andrew> cannot this partition information be configured by
>     Andrew> redboot? Why must it be platform specific?
> 
> I am not a NAND expert, but I think the answer is that NAND is
> fundamentally different from NOR: it is unreliable.
> 
[snip]
> Or, we could try to implement a robust layer on top of the basic NAND
> layer. If you want to store N pages reliably, reserve (N+f(N)+k)
> pages in the NAND flash. When one of the pages starts failing, start
> using one of the spare pages. Assume that updates will be infrequent
> so that you do not need to worry about wear-levelling, just bad
> blocks. This would give us a way of storing the partition info in the
> NAND flash with a high degree of reliability. Unfortunately it means a
> fairly complicated extra layer which will not be needed by e.g.
> NAND-aware flash filesystems - those expect to handle the bad pages
> etc. themselves.

FWIW, this is the approach taken by MTD with the BBT (Bad Block Table).

Rutger
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.