public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: "Jürgen Lambrecht" <J.Lambrecht@televic.com>
To: Rutger Hofman <rutger@cs.vu.nl>
Cc: Jonathan Larmour <jifl@jifvik.org>,
	Ross Younger <wry@ecoscentric.com>,
		eCos developers <ecos-devel@ecos.sourceware.org>
Subject: Re: Re: NAND technical review
Date: Thu, 08 Oct 2009 07:15:00 -0000	[thread overview]
Message-ID: <4ACD9191.60102@televic.com> (raw)
In-Reply-To: <4ACCC13F.40009@cs.vu.nl>

Rutger Hofman wrote:

<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.
>
>   
Correct, only for raw NAND chips to be soldered on a board. The others 
have an embedded controller and are already packaged.
>> 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."
>
>   
Indeed, a oneNAND is to be threated as a NOR flash, like a pseudoSRAM is 
a DRAM with SRAM interface.
And SSD has a hard disk drive interface, just like MMC and SD card; they 
mostly have a FAT file system on them but also UFS ...

Kind regards,
Jürgen

  reply	other threads:[~2009-10-08  7:15 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 [this message]
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=4ACD9191.60102@televic.com \
    --to=j.lambrecht@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).