This is the mail archive of the ecos-devel@sourceware.org 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 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


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