From: "Jürgen Lambrecht" <J.Lambrecht@televic.com>
To: Jonathan Larmour <jifl@jifvik.org>
Cc: Ross Younger <wry@ecoscentric.com>,
Rutger Hofman <rutger@cs.vu.nl>,
eCos developers <ecos-devel@ecos.sourceware.org>,
Deroo Stijn <S.Deroo@TELEVIC.com>
Subject: Re: NAND technical review
Date: Tue, 13 Oct 2009 06:35:00 -0000 [thread overview]
Message-ID: <4AD41FA6.2020600@televic.com> (raw)
In-Reply-To: <4AD3E92E.5020301@jifvik.org>
Jonathan Larmour wrote:
> Jürgen Lambrecht wrote:
>
>> Ross Younger wrote:
>>
>>> - E's high-level driver interface makes it harder to add new functions
>>> later, necessitating a change to that API (H2 above). R's does not; the
>>> requisite logic would only need to be added to the ANC. It is not thought
>>> that more than a handful such changes will ever be required, and it
>>> may be
>>> possible to maintain backwards compatibility. (As a case in point,
>>> support
>>> for hardware ECC is currently work-in-progress within eCosCentric, and
>>> does
>>> require such a change, but now is not the right time to discuss that.)
>>>
>> Therefore we prefer R's model.
>>
>> Is it possible that R's model follows better the "general" structure of
>> drivers in eCos?
>> I mean: (I follow our CVS, could maybe differ from the final commit of
>> Rutger to eCos)
>> 1. with the low-level chip-specific code in /devs
>> (devs/flash/arm/at91/[board] and devs/flash/arm/at91/nfc, and
>> devs/flash/micron/nand)
>> 2. with the "middleware" in /io (io/flash_nand/current/src and there
>> /anc, /chip, /controller)
>> 3. with the high-level code in /fs
>>
>
> I don't see E's model as being much different in that perspective. There
> is stuff in devs/flash, io/nand and (presumably) fs as well.
>
> The difference is more the separation out of the controller functionality
> into a different layer.
>
>
>> Is it correct that R's abstraction makes it possible to add partitioning
>> easily?
>> (because that is an interesting feature of E's implementation)
>>
>
> As Rutger said, it could be done - there's nothing in his design which
> presents it. It's not there now though, so unless someone's working on it
> it's probably not something to consider in the decision process.
> Especially since it would be a big user API change.
>
>
>> We also prefer R's model of course because we started with R's model and
>> use it now.
>>
>
> You haven't done any profiling by any luck have you? Or code size
> analysis? Although I haven't got into the detail of R's version yet (since
> I was starting with dissecting E's), both the footprint and the cumulative
> function call and indirection time overhead are concerns of mine.
>
>
No...
>>> (b) Availability of drivers
>>>
> [snip]
>
>>> - One chip: the ST Micro 0xG chip (large page, x8 and x16 present but
>>> presumably only tested on the x8 chip on the BlackFin board?)
>>>
>>>
>> - Two: also the Micron MT29F2G08AACWP-ET:D 256MB 3V3 NAND FLASH (2kB
>> page size, x8)
>> Because if this chip, Rutger adapted the hardware ECC controller code,
>> because our chip uses more bits (for details, ask Stijn or Rutger).
>>
>
> I'd be interested in what the issue was. From admittedly a quick look I
> can't find anything about this in the code.
>
Maybe Rutger can better answer this. Else Stijn can look-up his mail on
this issue.
>
>>> (d) Degree of testing
>>>
> [snip]
>
>> We have it very well tested, amongst others
>> - an automatic (continual) nand-flash test in a clima chamber
>> - stress tests: putting it full over and over again via FTP (both with
>> af few big and many small files) and check the heap remaining:
>> * Put 25 files with a filesize of 10.000.000 bytes on the filesystem
>> * Put 2500 files with a filesize of 100.000 bytes on the filesystem
>> * Put 7000 files with a filesize of 10.000 bytes on the filesystem
>> Conclusion: storing smaller files needs more heap, but we still have
>> plenty left with our 16MB
>> * Write a bundle of files over and over again on the filesystem. We put
>> everytime 1000 files of 100.000 bytes filesize on the flash drive.
>> - used in the final mp3-player application
>>
>
> That's extremely useful to know, thanks! But a couple of further questions
> on this: (1) Did any bad blocks show up at any point? (2) Were you using a bad
> block table? (3) Presumably there were factory-marked bad blocks on some?
>
(3) Yes, there are almost always factory-marked bad blocks.
(2) yes
(1)Yes, certainly! We have from time to time bad blocks, and they are
handled correctly.
Kind regards,
Jürgen
> Thanks,
>
> Jifl
> --
> --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
>
totally agree ;-)
next prev parent reply other threads:[~2009-10-13 6:35 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
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 [this message]
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=4AD41FA6.2020600@televic.com \
--to=j.lambrecht@televic.com \
--cc=S.Deroo@TELEVIC.com \
--cc=ecos-devel@ecos.sourceware.org \
--cc=jifl@jifvik.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).