From: Jonathan Larmour <jifl@jifvik.org>
To: Rutger Hofman <rutger@cs.vu.nl>
Cc: Ross Younger <wry@ecoscentric.com>,
eCos developers <ecos-devel@ecos.sourceware.org>
Subject: Re: NAND technical review
Date: Fri, 16 Oct 2009 01:32:00 -0000 [thread overview]
Message-ID: <4AD7CD29.1050701@jifvik.org> (raw)
In-Reply-To: <4AD73386.4030300@cs.vu.nl>
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
next prev parent reply other threads:[~2009-10-16 1:32 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-02 15:51 Jonathan Larmour
2009-10-06 13:51 ` Ross Younger
2009-10-07 3:12 ` Jonathan Larmour
2009-10-07 16:22 ` Rutger Hofman
2009-10-08 7:15 ` Jürgen Lambrecht
2009-10-15 3:53 ` Jonathan Larmour
2009-10-15 11:54 ` Jürgen Lambrecht
2009-10-15 3:49 ` Jonathan Larmour
2009-10-15 14:36 ` Rutger Hofman
2009-10-16 1:32 ` Jonathan Larmour [this message]
2009-10-19 9:56 ` Ross Younger
2009-10-19 14:21 ` Rutger Hofman
2009-10-20 3:21 ` Jonathan Larmour
2009-10-20 12:19 ` Rutger Hofman
2009-10-21 1:45 ` Jonathan Larmour
2009-10-21 12:15 ` Rutger Hofman
2009-10-23 14:06 ` Jonathan Larmour
2009-10-23 15:25 ` Rutger Hofman
2009-10-23 18:03 ` Rutger Hofman
2009-10-27 20:02 ` Rutger Hofman
2009-11-10 7:03 ` Jonathan Larmour
2010-12-11 19:18 ` John Dallaway
2010-12-22 14:54 ` Rutger Hofman
2009-10-15 15:43 ` Rutger Hofman
[not found] ` <4ACDF868.7050706@ecoscentric.com>
2009-10-09 8:27 ` Ross Younger
2009-10-13 2:21 ` Jonathan Larmour
2009-10-13 13:35 ` Rutger Hofman
2009-10-16 4:04 ` Jonathan Larmour
2009-10-19 14:51 ` Rutger Hofman
2009-10-20 4:28 ` Jonathan Larmour
2009-10-07 9:40 ` Jürgen Lambrecht
2009-10-07 16:27 ` Rutger Hofman
2009-10-13 2:44 ` Jonathan Larmour
2009-10-13 6:35 ` Jürgen Lambrecht
2009-10-15 3:55 ` Jonathan Larmour
2009-10-13 12:59 ` Rutger Hofman
2009-10-15 4:41 ` Jonathan Larmour
2009-10-15 14:55 ` Rutger Hofman
2009-10-16 1:45 ` Jonathan Larmour
2009-10-19 10:53 ` Ross Younger
2009-10-20 1:40 ` Jonathan Larmour
2009-10-20 10:17 ` Ross Younger
2009-10-21 2:06 ` Jonathan Larmour
2009-10-22 10:05 ` Ross Younger
2009-11-10 5:15 ` Jonathan Larmour
2009-11-10 10:38 ` Ross Younger
2009-11-10 11:28 ` Ethernet over SPI driver for ENC424J600 Ilija Stanislevik
2009-11-10 12:16 ` Chris Holgate
2009-11-12 18:32 ` NAND technical review Ross Younger
2009-10-13 14:19 ` Rutger Hofman
2009-10-13 19:58 ` Lambrecht Jürgen
2009-10-07 12:11 ` Rutger Hofman
2009-10-08 12:31 ` Ross Younger
2009-10-08 8:16 ` Jürgen Lambrecht
2009-10-12 1:13 ` Jonathan Larmour
2009-10-16 7:29 ` Simon Kallweit
2009-10-16 13:53 ` Jonathan Larmour
2009-10-19 15:02 ` Rutger Hofman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AD7CD29.1050701@jifvik.org \
--to=jifl@jifvik.org \
--cc=ecos-devel@ecos.sourceware.org \
--cc=rutger@cs.vu.nl \
--cc=wry@ecoscentric.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).