From: Rutger Hofman <rutger@cs.vu.nl>
To: Jonathan Larmour <jifl@jifvik.org>
Cc: Ross Younger <wry@ecoscentric.com>,
eCos developers <ecos-devel@ecos.sourceware.org>
Subject: Re: NAND technical review
Date: Wed, 07 Oct 2009 16:22:00 -0000 [thread overview]
Message-ID: <4ACCC13F.40009@cs.vu.nl> (raw)
In-Reply-To: <4ACC0722.9020601@jifvik.org>
I should have stated this in my first mail...
I am not at all qualified to say anything about E's work, because I
didn't have time to do any kind of review of it. So, I will mainly limit
myself to comments on things that concern R's work, and where I say
anything on E it will be based on the E's mails on the list.
Jonathan Larmour wrote:
[snip]
> A device number does seem to be a bit limiting, and less deterministic.
> OTOH, a textual name arguably adds a little extra complexity.
This will be straightforward to change either way.
> I note Rutger's layer needs an explicit init call, whereas yours DTRT using a constructor, which is good.
I followed flash v2 in this. If the experts think a constructor is
better, that's easy to change too.
> 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.
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.
Also, what to do if a block grows bad during usage, and that block
doesn't allow writing a marker in its spare area? BBT seems a solution.
>> (b) Dynamic memory allocation
>>
>> R's layer mandates the provision of malloc and free, or compatible
>> functions. These must be provided to the cyg_nand_init() call.
>
> That's unfortunate - that limits its use in smaller boot loaders - a key
> application.
Well, it is certainly possible to calculate statically how much space
R's NAND layer is going to use, to allocate that statically, and write a
tiny function to hand it out piecemeal at the NAND layer's request.
There is no call to free() here except at shutdown, so nothing
malloc-like is necessary. (An exception is in the debug handling, see
below.)
>> E's doesn't; instead it declares a small number of static buffers.
>
> I assume everything is keyed off CYGNUM_NAND_PAGEBUFFER, and there are
> no other variables. Again I'm thinking of the scenario of single
> firmware - different board revs. Can you confirm?
>
>> Andrew Lunn opined on 6/3/09 that R's requirement for malloc is not a
>> major
>> issue because the memory needs of that layer are well-bounded; I think I
>> broadly agree, though the situation is not ideal in that it forces
>> somebody
>> who wants to use a lean, mean eCos configuration to work around.
>
> The overhead of including something like malloc/free in the image may
> compare badly with the amount of memory R's needs to allocate in the
> first place. I also note that if R's implementation has program verifies
> enabled it allocates and frees a page _every_ time. If nothing else this
> could lead to heap fragmentation.
Program verifies should be considered a very deep debugging trait.
Still, another possible implementation for this page buffer would be on
the stack (not!), or in the controller struct. That would grow then by
8KB + spare.
[snip]
>> - R's model shares the command sequence logic amongst all chips,
>> differentiating only between small- and large-page devices. (I do not
>> know
>> whether this is correct for all current chips, though going forwards
>> seems
>> less likely to be an issue as fully-ONFI-compliant chips become the
>> norm.)
>
> Hmm. Nevertheless, this is a concern for me with R's. I'm concerned it
> may be too prescriptive to be robustly future-proof.
Well, there is no way I can see into the future, but I definitely think
that the wire command model for NAND chips is going to stay -- it is in
ONFI, after all. Besides, all except the 1 or 2 most pioneering museum
NAND chips use it too. There are chips that use a different interface,
like SSD or MMC or OneNand, but then these chips come with on-chip bad
block management, wear leveling of some kind, and are completely
different in the way they must be handled. I'd say E's and R's
implementations are concerned only with 'raw' NAND chips.
> One could say that makes it a more realistic emulation. But yes I can
> see disadvantages with a somewhat rigid world view. Thinking out loud, I
> wonder if Rutger's layer could work with something like Samsung OneNAND.
See my comment above. The datasheet on e.g. KFM{2,4}G16Q2A says:
"MuxOneNAND™‚ is a monolithic integrated circuit with a NAND Flash array
using a NOR Flash interface."
> Incidentally I note Rutger has a "Samsung" ECC implementation, whereas
> you support Samsung K9 chips, but use the normal ECC algorithm. Did
> Samsung change their practice?
The ECC algorithm is not something that is related to chips. It is
either software, or it is in the controller's ECC hardware and may need
software support. Controller EEC hardware seems to use one of two public
algorithms that are known as 'Toshiba ECC' and 'Samsung ECC'.
> I would certainly appreciate feedback from anyone who has used R's
> layer. What you say would seem to imply that both small page and OFNI
> are untested in R's layer.
That is correct. I would love some small-page testing. I have seen no
ONFI chips on the market yet, so testing will be future work for both E
and R.
> I'd need feedback from Rutger as to what level of testing has been done
> with his.
I ran YAFFS tests, some took more than an hour to complete on my
BlackFin. But for serious testing, see Jurgen Lambrecht's mail.
Rutger
next prev parent reply other threads:[~2009-10-07 16:22 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 [this message]
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
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=4ACCC13F.40009@cs.vu.nl \
--to=rutger@cs.vu.nl \
--cc=ecos-devel@ecos.sourceware.org \
--cc=jifl@jifvik.org \
--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).