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: Q: Support for ST NAND512W3A / bad block relocations


On Tue, Jan 10, 2006 at 04:45:33PM +0100, Manfred Petz wrote:
> Hello,
> 
> I'm trying to include support for the above NAND device (for RedBoot), 
> and I got a question, which I could not get answered by browsing the 
> mail archive and the sources.
> 
> As I understood, there's no support for bad block relocation in the
> flash driver API. So, the caller of the flash_() routines always expects, 
> that the requested memory region can be read/written/erased. By quickly
> browsing through the RedBoot code, I saw, that RedBoot also does not
> support bad block relocation. Right?

All correct.

> My idea to implement this, would be, to reserve a spare are in the
> flash - exclusively for the driver - for bad block relocation. The size
> depends on the specs in the data-sheet. If there are more bad blocks,
> than defined, the flash is considered to be defective. And then, make
> the driver transparently remap bad blocks (by writing the required
> meta information (offset to a valid block) into the flash's spare 
> blocks).
> 
> Is this a good approach, or could this be done better? Or am I
> completely missing something? :)

The question is, do we want to expose all the NAND OOB information up
into the applicationm or should it be hidden down in the generic flash
API and the drivers? 

What you suggest would keep the application unawair of what is going
on and keep the API simple. I think for most of the applications eCos
is being used for, this is the correct approach. The only exception
would be JFFS2 which has the ability to handle OOB. Using your
abstraction JFFS2 would work just as if it was on a NOR device, but it
would not be compatible with JFFS2 in Linux.

Your remapping code should be generic? If so it belongs in IO_FLASH.
You will need to extend the API between the flash driver and IO_FLASH
to add access to the OOB information. Are you aware of the Flash V2
branch? Ideally you would want to work with that code rather than what
is in anoncvs. We intend to merge the branch into the trunk when we
make the next release of eCos. 

You might also find the Toshiba TC58xxx driver interesting. It is a
NAND device. There is code for calculating ecc values. There is some
licensing issues with that code however, so it would be better if you
could find another implementation.

        Andrew


-- 
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]