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
