This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
RE: flash driver interface improvement
- From: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- To: 'Jani Monoses' <jani at iv dot ro>
- Cc: ecos-devel at sources dot redhat dot com
- Date: Fri, 23 Aug 2002 12:25:21 +0200
- Subject: RE: flash driver interface improvement
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
> >
> >
>