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


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


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