This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about FIS Directory when using NAND flash.


On 2010-08-13, Ross Younger <wry@ecoscentric.com> wrote:
> Grant Edwards wrote:

>> When I allocated spare blocks to the FIS directory partition, the
>> Linux FIS parsing code pukes [...] once it's found the directory
>> it does something stupid [.]
>> I'm wondering exactly how RedBoot handles bad NAND blocks when it
>> comes to the FIS directory "partition".
>
> It doesn't.

Thanks, that's certainly clear enough.  :)

> One might well argue that the Linux FIS parsing code is at fault
> here,

I think I'll try to make that argument.  Since the parsing code does
handle the skipping of bad blocks when looking for the FIS directory,
that implies that the FIS directory "partition" can be larger than one
block.

> but the underlying issue is that nobody (AFAIK) is seriously using
> NAND as FIS at the moment; bad blocks, ECC and wear-levelling pose
> too many difficult questions. NAND doesn't look enough like NOR to
> really fit the io/flash interface, hence the existence of two
> competing NAND interfaces. To my knowledge, neither is directly
> usable as FIS, though both support fileio.

Nor am I really using NAND as FIS.  But the FIS directory structure is
the only type of partition table currently supported by Linux for
flash devices.  I don't want to hard-code the partitioning info in
either my bootloader or kernel images (which would make using varying
flash chip sizes difficult). So using a partition table seems like the
logical thing to do -- that puts all of the partitioning info in a
single, stand-alone step that can be very late in the production
process.

> A simple translation layer to make eCosCentric's NAND layer look more
> like NOR so that it would be usable as FIS is somewhere on my todo
> list, though I don't think it would really scratch your itch unless
> it was ported to Linux?

I'm not using FIS, and all of the code I currently use does handle bad
blocks.  The only issue is Linux's conflicting assumptions that the
FIS directory partition 1) contains exactly one block, and 2) can
contain bad blocks that must be skipped to find the good block
containing the FIS directory structure.

-- 
Grant Edwards               grant.b.edwards        Yow! I am a traffic light,
                                  at               and Alan Ginzberg kidnapped
                              gmail.com            my laundry in 1927!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]