This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: NAND technical review
Rutger Hofman wrote:
Jonathan Larmour wrote:
Rutger Hofman wrote:
Jonathan Larmour wrote:
Does your implementation _require_ a BBT in its current
implementation? For simpler NAND usage, it may be overkill e.g. an
application where the number of rewrites is very small, so the
factory bad markers may be considered sufficient.
I had forgotten: there is a configuration option to bypass BBT and only
use factory-bad markers (and caveat emptor).
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.
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?
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.
NB the chip ID table can be const can't it?
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.
Is your BBT compatible with Linux MTD? Including your use of a mirror?
Yes, I read MTD, and tried to copy their BBT handling as faithfully as
possible without actually copying code. It is on my stack to check if
the BBTs are indeed identical; as you may have noticed elsethread, my
eCos application wants to share a YAFFS 'disk' with u-boot which has MTD.
Okay. Obviously compatibility is very important, especially for those
using eCos/RedBoot just to load Linux.
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.
[memory use]
If you know what it's going to be (at most), it could just be
allocated statically and just used directly surely? That's got the
lowest overheads.
E's implementation had a good idea of a CDL variable for the maximum
supported block size. Then individual HALs or driver packages can use
a CDL 'requires' to ensure it's >= the block size of the chips really
in use.
I can follow Ross's example here. Together with a switch to constructor
and a cleanup of printfs, that will take some days. If it matters in the
decision, I will schedule this to be finished within one month.
I'll make a note about it - again I don't want you to be adjusting things
before the decision has been made - I for one certainly haven't made up my
mind either way. But thanks very much for your willingness to do so! I
doubt either implementation will be checked in with zero further changes
anyway.
[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.
Ross, if you're reading, I would be interested to know whether something
with a different access model, like OneNAND, would work with E's layer, in
your opinion. While I think the answer is yes, I had better check.
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine