Subject: Re: MTD devices in NetBSD
To: Jachym Holecek <>
From: Garrett D'Amore <>
List: tech-kern
Date: 03/23/2006 15:02:52
Jachym Holecek wrote:
>>>> On NAND, you can't have a bootloader like that.  As a minimum, the
>>>> bootloader needs to be able to deal with bad block management.
>>> Not true.  (See my earlier reply about this.)
>> But if you've hidden away the mapping with some kind of block remapper,
>> you don't have a good way to write those blocks.
> [Assuming you choose to go the "wear levelling layer" way, which I have
>  no qualified opinion on.]
> Is there a good reason why the block remapper should be prevented from
> only operating over a couple of flash device extents and leaving the
> rest mapped 1:1 (in other words, have the bootloader partition 1:1 and
> only block-remap the "/" partition)?
> You'll have the very same issue for NOR devices, AFAICS.

Again, I don't want to do wear-leveling in the translation layer.  Or
block remapping.  I want to expose the stuff directly.  If someone wants
to add wear-leveling, then there are a couple of reasonable approaches:

    1) a separate wear-leveling "shim".  i'm not particularly fond of
that idea.
    2) logic in the filesystem (this is where *I* think it belongs, but
there's been some dissenting opinion on the matter)
    3) some kind of extension to the framework I'm writing (but I won't
be writing the extension)

My plan is *maybe* to do #2 above.  It remains to be seen whether I
actually need to even do that, though.  Possibly just providing raw
physical access to blocks is good enough for the applications I'm

I really believe that if there is a standard way to express the various
device properties and access them, then the rest of the bits can be
handled either by a smart filesystem or by introducing additional
layers.  Hiding those properties I consider a bad idea, because it
forces the design of the upper layers down a constricted path.

FWIW, it also sounds like having a common filesystem between NOR and
NAND is likely a bad idea.  Probably what you really want is "flashfs"
and "nandfs".   "nandfs" would be able to do some very nand-like things,
handle ecc, oob, remapping, etc.  And probably also be totally
unsuitable for use on a boot device.  :-)

"flashfs" would be a more typical journaling filesystem that wouldn't
care about the ugliness of nand.

    -- Garrett
>> The systems that use NAND are likely to have the NAND part
>> locked away behind a USB or CompactFlash adapter.
> They definitely are NOT, but that doesn't invalidate your point of
> focusing on NOR right now and leaving NAND for later/someone else ;-)
> 	-- Jachym

Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134  Fax: 951 325-2191