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:
Jonathan Larmour wrote:
Rutger Hofman wrote:
Jonathan Larmour wrote:
Ah. Your documentation includes:
"Before the second initialization stage, some properties of the NAND
system can be configured. These are en/disabling of ECC generation and
en/disabling of a Bad Block Table (BBT). By default, ECC and BBT are
enabled."
I hadn't noticed that these are not in fact CDL configuration options.
They ought to be really.
OK. I'd say no-ECC is a property of the application/ANC and no-BBT is a
property of a chip. I'll move these to CDL.
When I am done with this and a number of other small changes, I'll put
up a new revision.
This is a bit hairy in my opinion, and one reason is that there is
no Standard Layout for the spare areas. One case where a BBT is
forced: my BlackFin NFC can be used to boot from NAND, but it
enforces a spare layout that is incompatible with MTD or anybody. It
is even incompatible with most chips' specification that the first
byte of spare in the first page of the block is the Bad Block
Marker. BlackFin's boot layout uses this first byte in a way that
suits it, and it may be 0 -- which would otherwise mean Bad Block.
I infer that your layer can cope with that? I didn't see the handling
for that in io_nand_chip_bad_block.c.
No (not yet).
If it doesn't sound too silly, how were you able to test your layer on
the bfin then?
Well, this mode is *only* for booting a BlackFin from NAND, and for
writing the boot blocks into NAND. For all other usage, one still uses
the standard MTD spare layout.
To use the NAND controller in this way, a different spare layout must
be used for the chip. Although there are no obstacles to selecting
different spare layouts, there is no support for that yet. It would
require one extra parameter in the chip device struct 'constructor'
(e.g. with NULL for 'choose default = MTD compatible').
You mean CYG_NAND_DRIVER_CHIP()? Presumably some way to pass a different
layout?
I was wondering about the extensibility of the spare layouts given how
much stuff is sort of hard coded - sure it may fit plenty of existing
chips but more can come along. In the chip ID table in io_nand_chip.c I
haven't worked out what the layout field is for - I can't find where it
is used. I also can't see how a driver in a new port can add a new chip
with a new layout. There's talk in read_id() of being able to do a
custom chip device (does that mean also you can do a custom spare
layout?), but it's not clear to me how a new port can add that to the
table since read_id() only searches the table. Obviously it's not
sensible to have to keep changing io/nand, and may be inappropriate for
custom spare layouts.
OK, a custom spare layout now is a parameter to CYG_NAND_DRIVER_CHIP().
The layout is used in the common controller code, see calls to function
spare_scatter_fill() and spare_scatter_extract(). These serve ECC and
application spare slots in the same fashion.
NB the chip ID table can be const can't it?
Thanks, fixed.
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.
OTOH, if anything else of the NAND is going to be used, the MTD layout
is required. So hot-swapping is highly desirable
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.
[OneNAND (and things like it) fitting into R's model]
I will take a better look at the OneNAND datasheet. You are right, it
is software-wise as different from NOR as from 'raw' NAND. 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.
Rutger