"Andrew" == Andrew Lunn <andrew@lunn.ch> 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.