RE: flash driver interface improvement

["Koeller, T." <Thomas dot Koeller at baslerweb dot com>]

I am currently dealing with a flash chip that has
one sector of size 16kB, then two sectors of size
8kB each, then one sector of size 480kB(!). I think
a well-defined interface should provide support for
arbitrary sector layouts.

What do you mean by 'no need for callbacks'?
My proposed solution does not use any callbacks,
just a query function for the client to call to
learn about the properties of a particular sector.

tk
----------------------------------------------- 
Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 
Germany 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390

mailto:Thomas.Koeller@baslerweb.com 
http://www.baslerweb.com 




> -----Original Message-----
> From: Jani Monoses [mailto:jani@iv.ro]
> Sent: Friday, August 23, 2002 3:04 PM
> To: Koeller, T.
> Cc: ecos-devel@sources.redhat.com
> Subject: Re: flash driver interface improvement
> 
> 
> What do you mean by uniform sector layout ?Fixed erase size?
> If yes then I also thought about how this might be done...
> Mostly because I only saw flash chips with a small number or various 
> sized blocks and then the large equally sized blocks (top or 
> bottom boot variants)
> If there are other then what I'm going to describe below is 
> not generic enough :(
> So just like the intel 28Fxxxx does we could have a struct in 
> the upper layer
> which contains the number of special blocks and their sizes 
> (also top or bottom)
> So the lower layer might not need to pass up a callback 
> instead it could just fill
> that structure with its values.
> The code to check which block we are in while 
> erasing/programming could be device independent..
> And this could be backwards compatible as well since drivers 
> which don't fill those fields
> are presumed old type.Say we add these new fields at the end 
> of flash_info and if low level says
> block_size = 0 the upper knows it filled the new 
> fields.Anyway backward compatibility is not that big
> of an issue if we can configure almost anything.New drivers 
> will just require something to be defined 
> and then some ifdefs in the upper layer do their work.
> What do you think?
> 
> > Hi all,
> > 
> > it appears to me that the current flash driver interface is
> > very inflexible, supporting only flash chips with uniform
> > sector layout. I'd therefore like to propose an extension that
> > I am going to describe below, and that I would volunteer to
> > implement if the ecos maintainers agree to this proposal.
> > 
> > The idea goes as follows: If during initialization the driver
> > returns a non-zero sector size (as all existing drivers are
> > supposed to do), the everything stays as it is now, thus
> > backward compatibility is ensured. A flash driver implementation
> > that wants to support a non-uniform sector layout returns a
> > sector size of zero (0x0), and it provides a function for
> > its clients to call with a sector index as an argument, that
> > returns a sector descriptor struct giving the base address,
> > size, and maybe other information about that sector.
> > 
> > Any comments?
> > 
> > tk
> > ----------------------------------------------- 
> > Thomas Koeller, Software Development 
> > 
> > Basler Vision Technologies 
> > An der Strusbek 60-62 
> > 22926 Ahrensburg 
> > Germany 
> > 
> > Tel +49 (4102) 463-390 
> > Fax +49 (4102) 463-46390
> > 
> > mailto:Thomas.Koeller@baslerweb.com 
> > http://www.baslerweb.com 
> > 
> > 
>