> [syndrome] > So can you just confirm that (E) supports that form of hardware ECC > implementation?
I've just googled up the outline of syndrome mode (which seems, incidentally, to be at least a de facto standard term). I don't see any reason I couldn't fit it in given my current hooks. > I also note > with the SAM9260 that the hardware ECC registers get wiped if you start > to read/write another page, so can you confirm or otherwise that no > other NAND API user can cause that to happen in (E)? The standard per-device locking provided by (E) will take care of this. If there is a risk of concurrent access to other devices causing problems it's trivial to add a further board-level lock in the driver. > The SAM9260 also > requires you to read the entire page data, followed immediately by the > spare area locations where the ECC is stored. Is that also supportable > by (E)? It looks like that's standard for syndrome-type ECC. I think this is just a funny OOB area layout, though as ever I'd have to try it and see to be sure. Ross (PS. BTW, I am still working on that fresh anon-based drop I promised the other week, but am trying to find out why the benchmarks are so screwy on the EA LPC2468 before I finish cutting the drop. And - speaking of ECC - sitting in my pile of queued commits I have a major speed-up in software ECC calculation...) -- Embedded Software Engineer, eCosCentric Limited. Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK. Registered in England no. 4422071. www.ecoscentric.com
