This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: NAND technical review
Jonathan Larmour wrote:
Rutger Hofman wrote:
I was referring to the "layout" field of cyg_nand_chip_id_t. Whereas spare_scatter_fill()/extract() use the spare_layout field of the cyg_nand_chip_info_t. I haven't yet found where the "layout" field of cyg_nand_chip_id_t is used.
This represents the fourth byte of the 'regular' read_ID response.
(First is manufacturer, second is device type, third is often 0, but may
be defined to give further architectural details.) The specx for this
layout byte:
bit meaning description
0..1 1KB, 2KB, 4KB, 8KB page size
2 8, 16 spare bytes per 512 data bytes
4..5 64KB, 128KB, 256KB, block size (without spare)
6 x8, x16 bus width
The other bits differ across manufacturers.
Reading and parsing this byte is still insufficient to fully access the
chip: its total size is unknown. It can be in the third byte, in which
case the chip table needn't wouldn't need an entry for this chip because
it is sufficiently self-descriptive.
For the record: MDT/Blackfin/u-boot has support for this different
layout, but it is build-static. MDT cannot hot-swap layouts (at the
moment).
That's reasonable given it's associated with the controller.
Well, not completely. The layout is only associated with the *boot
mode*. For other use, there is no prescription of the layout, so it's
typical to use the MTD layout - then one can share with Linux or
u-boot. Rotten consequence: if one wants to program a new boot image
into the first block(s) of the NAND, the boot-compatible layout must
be used.
So I believe that means if you want to rewrite the boot program on
Blackfin _and_ use a normal layout, you wouldn't be able to use R as it
stands at the moment. Ack, OK.
Hot-swapping is necessary to pull this tric. It would be doable in my
current svn version (which is coming up one of these days). It would
imply crossing through all layers though, and it would indeed be
horribly risky.
OTOH, if anything else of the NAND is going to be used, the MTD layout
is required. So hot-swapping is highly desirable
Hot swapping sounds like a risky thing to do, with potentially multiple
subsystems wanting access to flash, not just the application.
[snip]
But also, since R does not have partitioning, won't that potentially
interfere with compatibility with MTD? A Linux booted image may not
be using the whole chip as a single FS.
Linux has no fixed approach to partitioning, as I learned during the
discussions on this list.
Yes, but that isn't the same as not supporting partitions. Just that
they aren't fixed. They're specified on the kernel boot line, and so can
be configured by the user arbitrarily.... it's just that you can't
change them without rebooting. So I believe anyone who is using multiple
partitions with MTD would have difficulties interoperating with R.
If this is so (I am not conversant enough yet with Linux internals) then
it is a very useful addition. Using multiple YAFFS devices is
straightforward right now (I did this and met no problems).
[OneNAND (and things like it) fitting into R's model]
My guarded guess now is that integration into R would imply a
replacement of the Common Controller code (by configuration or by
'object-oriented' indirect calls over a device struct). I will
report on this later.
Thanks. Although of course adding more indirection may have its own
disadvantages.
That guarded guess was correct. OneNAND is no raw NAND chip so R's
common controller code won't fit. The thing to do is make a driver
that comes in place of the common controller, as suggested above. Once
ANC supports a pluggable controller (which I will do if it makes a
difference), adding a OneNAND will take the same amount of effort as
for E's implementation.
Would that not require a significant reworking and relayering of code?
It seems to me that controller drivers and the chip drivers used by
controller drivers under this system will still want to be able to
access the infrastructure support for BBTs, ECCs and spare layout. From
what I can see, preserving that without large amounts of indirection
(imposing further performance and size hits) would pose quite some
challenge. The result would be something really quite different to what
R is like today.
The reworking would just be to replace the calls in the ANC of the
controller-common API with indirect calls, and supporting this
configurability in the CDL. OneNAND doesn't need ECC code because things
are handled in hardware (the datasheet recommends not even checking the
ECC status register for 2-bit failures because they are so rare). Maybe
BBT is necessary too for OneNAND; I didn't think that through yet, but I
would hope the BBT implementation would support different controllers
without a lot of reworking - right now, accessing the chip already goes
through controller calls. The indirections would be few: one for each
top-level API call (unless the ANC must redistribute application pages
to chip pages, which is only in case of heterogeneous chips).
In conclusion: a driver in R for a different class of chip than 'raw
NAND' would indeed replace R's controller-common, any
controller-device-specific, and any chip, because these are all code for
raw NAND. I would hope that linker magic remove the code as unused from
the binary.
A driver for OneNAND would still need to be written obviously, and it
would share no or little code with controller-common and raw chip. My
guess is that would hold for E too - although I don't really know
because I have had no time to review E's code.
Rutger