Re: NAND technical review

[ Sorry all for the loss of momentum. Real life intervened for a while. ]

Ross Younger wrote:
> Jonathan Larmour wrote:
> 
>>Can you at least shed light on the API changes (by cut'n'pasting
>>relevant sections of headers/code even if not the whole thing)?
> 
> 
> I have changed the device interface (nand_device.h) by carving up the read
> and write page functions into three. (The prototype changes are the same for
> both, with only the obvious semantic differences when writing, so I'll only
> paste in read for the sake of brevity.)
> 
> Reading a page used to be an all-in-one call:
> 
> int (*read_page) (cyg_nand_device *dev, cyg_nand_page_addr page,
>           void * dest, size_t size, void * spare, size_t spare_size);
> 
> Now, the NAND layer calls "begin" once to set up the read:
> 
>     int (*read_begin)(cyg_nand_device *dev, cyg_nand_page_addr page);
> 
> ... "stride" one or more times to actually transfer data
> 
>     int (*read_stride)(cyg_nand_device *dev, void * dest, size_t size);
> 
> ... and then "finish" once to do the spare area and any finishing up that
> may be necessary (e.g. send the "program confirm" command, unlock the device).
> 
>     int (*read_finish)(cyg_nand_device *dev,
>                        void * spare, size_t spare_size);
> 
> The ECC interface (nand_ecc.h, not well documented) has also expanded
> slightly. I had had just a 'calc' call, but have now added an 'init' call so
> that any device-specific registers can be tweaked. The interaction is
> perhaps best sketched out as pseudocode; here's what the NAND library looks
> like in a call to read a page:
> 
>   dev->read_begin(page number);
>   while (there are still bytes to send) {
>     ecc->init(); // may be a no-op
>     dev->read_stride(ecc->datasize bytes);
>     if (ecc is hardware)
>       ecc->calc(the block we've just read);
>   }
>   dev->read_finish(spare data);
>   if (ecc is software)
>     ecc->calc(the whole thing);
>   ecc->repair(the whole block, looping as necessary, comparing the
> calculated ECC against what's in the spare area);
> 
> 
> I have renamed the device interface struct and macros on the grounds of
> "change the interface, change the name" (but not the ECC interface, because
> nothing outside that package had used it before now).

This seems reasonable at first glance. But to double check.... if you have 
an SoC with both built-in NFC and hardware ECC, it may be able to calc the 
ECC automatically as the pages are read/written through the NFC. What you 
can then get with reads is a direct result of whether the ECC has failed, 
whether it's recoverable or not. You don't have to actually look at the 
ECC value itself at any point. This is what Rutger calls ECC "syndrome" 
mode, which isn't a very descriptive term, but OTOH I can't think of 
anything much better either!). You can consider the Atmel SAM9260 to be a 
concrete example if that helps (although in that particular case you can 
see the actual computed ECC too - but (R) implies that that may not always 
be the case for reads).

So can you just confirm that (E) supports that form of hardware ECC 
implementation? Or does it actually require the ECC to be directly 
available (as opposed to potentially just being a token)? 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 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 does seem that it is supported by (R), albeit complicated by the 
abstracted scatter-gather spare layout management.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine