[ECOS] Flash infrastructure rework

Andrew Lunn andrew@lunn.ch
Wed Aug 4 19:06:00 GMT 2004

On Wed, Aug 04, 2004 at 03:54:46PM +0300, Jani Monoses wrote:
> Hi Andrew
> just two small comments after a quick glance.
> > #ifdef CYGPKG_KERNEL
> > __externC int cyg_flash_mutex_lock(const cyg_flashaddr_t from, 
> >                                    const size_t len);
> > __externC int cyg_flash_mutex_unlock(const cyg_flashaddr_t from, 
> > #endif
> could use the cyg_drv_mutex API so that even in non-kernel configs such as
> redboot, the flash driver is safe from interrupts. This just happened to us:
> with interrupts enabled in redboot, flash operations hung sometimes.

This is not simple. See the "Danger, Will Robinson! Danger!" section
of the documentation. The setup makes a big difference as to what is
safe and what is not. Disabling all interrupts is the only guarantee
that something will not cause a crass. But in many cases this is not
needed. Also, since eCos is an RTOS, disabling interrupts for a long
time is not a good idea. So i decided it was better to document the
problem and let the programmer decide what to do, ie arrange that
everything runs in RAM, is disable interrupts before calling into
FLASH code.

> > // Structure of pointers to functions in the device driver
> > struct cyg_flash_dev_funs {
> [...]
> >   int (*flash_hwr_map_error) (struct cyg_flash_dev *dev, int err);
> >                             
> should this be exposed? It looks like it is used after program/erase etc to
> convert the stat already returned. Drivers should already return 'normal'
> flash errors IMHO.

I was following the old API here. The value from the driver could be
useful when it returns more information than can be returned by the
defined error codes. It also makes it easier to port code from the old
API. If we decide to change this, i would keep the driver API as it
is, and add the call to flash_hwr_map_error inside the io flash layer.
> Also what do you and the other maintainers think of converting the actual
> flash code to the cyg_ namespace soon? That way your patch too would have
> less differences, and drivers would be easier to adapt to the new API.

My patch is about ready to go, by the end of this week i think. So i
think this makes no sense.


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

More information about the Ecos-discuss mailing list