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: Re: NAND flash driver considerations: RFC


On Thu, Sep 25, 2008 at 02:29:42AM +0200, Rutger Hofman wrote:
> I have received no responses for this RFC.
>
> Wouldn't anybody care to comment?

O.K. I'll comment. However i've never used NAND, i've no idea how they
work, how they differ between devices and what quirks they have...  So
this is probably not the most educated reply....

> Or do you think it is more useful if I just present my proposed NAND  
> controller interfaces (public and controller-specific), my proposed NAND  
> chip interfaces, and my proposed .cdl config setup? For sure that is  
> some stages later in the design.

Once the basic architecture is agreed, i would say such header files
with lots of comments are a good way to go. When i wrote the first
version of the flash_v2 package that is what i did. I wrote the header
files which defined the interface between the application and the
generic part and between the generic part of the specific flash
drivers. Lots of comments described how the interfaces worked and
allowed me to get my ideas straight. Some changes were made later to
the API but they were relatively minor.

>> eCos directory structure
>> ------------------------
>>
>> Should NAND be grouped under flash in packages/io and packages/devs? To 
>> be honest, the interface under which NAND flash is approached only  
>> vaguely resembles that for NOR flash. When we would choose for  
>> flash/nand, then we should also have to have flash/nor/ and move all  
>> things currently flashing down there.
>>
>> +++ My proposal:
>>
>> have packages/io/nand/ and packages/devs/nand/* *beside* 
>> packages/flash/ and packages/devs/flash/*. They are very different. 
>> Also, who wants refactoring of flash/* into flash/nor/*.
>> Is there a case to be made for separate nand/controller/ and nand/chip/ 
>> trees?

I don't see there being any problem mixing up NOR and NAND drivers in
packages/dev/flash/ The CDL rules will prevent somebody from trying to
use a NAND driver with the NOR generic parts and vica-verse. 

You talk about separate controllers and chips directories. Do we
actually need chip packages. You said that mostly any controller can
talk to any chip. This makes me think a chip packages are not
needed. What are needed are target hardware specific packages which
contain all quirks and configuration information needed for a specific
controller and chips pairing on a specific board. I think we probably
have enough structure in the packages/dev/flash/ to handle this.

>> NAND eCos device type
>> ----------------

...

>> +++ My proposal:
>>
>> = I would rather create NAND devices as just DEVTAB_ENTRYs, and mark  
>> them as NAND (or OTHER or ...) i.s.o. CHAR/BLOCK type. The function  
>> dispatch block ptr can be cast, or it can be put in the private area.  
>> This way one can do device lookup in the normal way with 
>> cyg_io_lookup() ("/dev/nand0" resolves to a device handle).
>>
>> = I propose to create two separate device types: NAND controllers and  
>> NAND chips. The two device types might be designated as "/dev/nand0" 
>> for controller 0, and "/dev/nand0.2" for the third chip connected to  
>> controller 0.

The disk package uses the naming scheme 

/dev/XXXdiskY/Z

XXX is the type of disc, eg mmc, ide etc. Y is the disk number, Z is
the partition. Maybe for nand /dev/namdX/Y might be better. X being
the controller number and Y being the chip number. 

>> I agree that this is kind of broken. But I have trouble thinking of a  
>> way to do device lookup otherwise. Besides, we might consider  
>> generalization of the device structure in the sense that the functions  
>> block is no longer strictly typed. Its actual type might be derived 
>> from the device driver type field.

What we probably need to do is think about how we would want to use
the devices. eg for a filesystem we don't really care about how many
chips there are and how they are arranged. We just want to put a
filesystem on it, or a subsection of it. The filesystem probably does
not want to address controller:chip:block, it wants to use a more
abstract interface, maybe even just a block number.

I would say some more thought is required here...

>> External interface of NAND devices (controller on top of chip)
>> --------------------------------------------------------------
>>
>> +++ My proposal:
>> the ONFI functions exported by the generic NAND controller code are  
>> sufficient.

So you are saying there will not be any generic code in io/nand/ 

   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]