This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: NAND review

Bart Veer wrote:
"Andrew" == Andrew Lunn <> 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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]