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
