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
contemplating.

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
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191