From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20100308154243.GA21591@knaagkever.ueber.net> References: <20100224185312.GA1892@zoidberg.hsd1.mi.comcast.net> <20100308154243.GA21591@knaagkever.ueber.net> Date: Wed, 10 Mar 2010 02:38:34 +1100 Message-ID: <7f56b5561003090738x30c363eufa8047e93fc579c9@mail.gmail.com> From: Graham Gallagher To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] sheevaplug port available Topicbox-Message-UUID: e59013f2-ead5-11e9-9d60-3106f5b1d025 > but i think inferno's logfs and ftl both assume 512 byte pages instead > of 2048 byte pages that the sheevaplugs nand flash has (though it has > writable subpages of 512 bytes), so i'm not sure how hard/easy an fs on > it will be. Some NAND flash definitions: block =3D smallest erasable unit page =3D smallest writable/readable unit. Inferno's logfs limits the maximum number of pages per block to 32 because it uses a 32-bit integer bit mapping. The flash you're using, has 64 pages per block. You'll need to switch to vlong and change all the associated bit bashing code. > > if anyone has tips & tricks for dealing with nand flashes, i'm interested > in hearing them. =A0one question i have: =A0can you read the erase/progra= m > times from the chip? (hard-coding a table with properties based on data > sheets isn't so great). =A0another: my new sheevaplug has samsung memory > instead of hynix, so a different vendor id in the chip. =A0but the "devic= e > id" is the same (identifying chip properties (size, voltages, etc)). > are those device id's standardized? =A0that would make a hard-coded table > less annoying at least... NAND flash technology is moving very quickly and new standards will give you timing info. However, the hardware you mention will require you to put the timing numbers in a table. I don't know if device IDs are standardized, so I make no such assumption. For Samsung chips, pure data retention is guaranteed for 10+ years. Repetitive reading, without erasing the blocks is verified to 1E6 cycles. The number of program/erase operations is guaranteed up to 1E6 cycles if the system adopts ECC. I've not seen much agreement with ECC and bad block mapping when it comes to either linux or uboot. There are slabs of NAND specific code in the linux tree that are never used. There are more slabs of code that are used sometimes. You can do whatever you want. I've only dealt with embedded systems and they're all different. Read word size, write size, it's all an experiment to what works. If you're lucky, you can put a probe on a pin and look at a signal but normally it's just trial and error.