Re: NAND technical review

[Rutger Hofman <rutger@cs.vu.nl>]

Jonathan Larmour wrote:
> Rutger Hofman wrote:
>> Jonathan Larmour wrote:
[snip]
> In E's case, in the EA LPC2468 port example, they have the following in 
> the platform HAL for a port (although it could be a package instead):
> 
> [various functions/macros defined which are used by k9fxx08x0x.inl]
> #include <cyg/devs/nand/k9fxx08x0x.inl>
> CYG_NAND_DEVICE(ea_nand, "onboard", &k9f8_funs, &_k9_ea_lpc2468_priv,
>                 &linux_mtd_ecc, &nand_mtd_oob_64);
> 
> which succinctly brings together the chip driver, accessor functions, 
> ECC algorithm, and OOB layout. It becomes easy for a board port to 
> choose some different chips/layouts/ECC. There's flexibility for the 
> future in that.

Yes, in R that is all in the board's CDL. I am unsure what that means 
w.r.t. flexibility.

> With R's implementation, there seems to be much more code involved. And 
> I sort of see why there's more code, and I sort of don't. Not just in 
> the generic layer, but in the drivers as well, at least looking at the 
> bfin chip, and I don't think the differences are completely explained by 
> the hardware properties of each NFC (but I'm very willing to be 
> corrected!). Comparing E's k9_read_page() along with everything it 
> calls, with R's bfin_nfc_data_read() along with everything it calls (and 
> those call etc. not just in bfin_nfc.c but also 
> nand_ez_kit_bf548.inc[1]) there's a huge difference. If nothing else 
> from what I can tell this may then require a much larger porting effort, 
> compared to E's.

The BlackFin nfc reads/writes in small sub-pages so doing a 512B or 2KB 
read/write needs a loop to traverse the sub-pages. More complexity in 
bfin_nfc_data_read is added because there is support for random 
sub-small-page reads too - ultimately a consequence of the outer API 
capability to do random reads. And things are complicated because the 
BFin NFC wants a handshake with each data byte/word read.

The code in the .inc file (chip select) is more generic than it should 
be. It has support for multiple, possibly heterogeneous, chips, while 
there is only one NAND chip on the EZ-Kit. It figures out at run-time 
though that the only thing to do is handle the CHIP_ENABLE pin.

Shameless plug: I think you might also consider to take a look at the 
example GPIO controller driver that I bundled. That is intended to show 
how small a device-specific controller driver can actually be.

> I see that some of the reasons for larger code in R are due to run-time 
> testing of hardware properties: 8 vs 16-bit bus width, SP vs LP vs ONFI. 
> I also note that E's implementation doesn't do as much error checking as 
> I think it ought to, especially in the Samsung K9 chip driver. But 
> that's not all of it the difference.

> [1] which should really be .inl for consistency in eCos but that's a detail

I'll fix that too.

Rutger