Overview — eCos Support for Intel Strata Flash Devices and Compatibles
flash driver package implements support for the Intel Strata
family of flash devices and compatibles. The driver is not normally
accessed directly. Instead application code will use the API provided
by the generic flash driver package
CYGPKG_IO_FLASH, for example by calling functions
cyg_flash_program. There are a small number
of additional functions
specific to Strata devices.
The driver imposes one restriction on application code which developers should be aware of: when programming the flash the destination addresses must be aligned to a bus boundary. For example if the target hardware has a single flash device attached to a 16-bit bus then program operations must involve a multiple of 16-bit values aligned to a 16-bit boundary. Note that it is the bus width that matters, not the device width. If the target hardware has two 16-bit devices attached to a 32-bit bus then program operations must still be aligned to a 32-bit boundary, even though in theory a 16-bit boundary would suffice. In practice this is rarely an issue, and requiring the larger boundary greatly simplifies the code and improves performance.
Many eCos targets with Strata or compatible flash devices will
still use the older driver package
The Strata flash driver package will be loaded automatically when
configuring eCos for a target with suitable hardware. However the
driver will be inactive unless the generic flash package
CYGPKG_IO_FLASH is loaded. It may be necessary to
add this generic package to the configuration explicitly before the
driver functionality becomes available. There should never be any need
to load or unload the Strata driver package.
The Strata flash driver package contains a small number of
configuration options which application developers may wish to tweak.
controls the program operation. On typical hardware programming the
flash requires disabling interrupts and possibly the cache for an
extended period of time. If the hardware does not provide any way of
bypassing the cache when writing to the flash then the cache must be
disabled or the commands written to the flash may get stuck inside the
cache instead of going directly to the flash chip. Some or all of the
flash hardware will be unusable while each word is programmed, and
disabling interrupts is the only reliable way of ensuring that no
interrupt handler or other thread will try to access the flash in the
middle of an operation. This can have a major impact on the real-time
responsiveness of the typical applications. To ameliorate this the
driver will perform writes in small bursts, briefly re-enabling the
cache and interrupts between each burst. The number of words written
per burst is controlled by this configuration operation: reducing the
value will improve real-time response but will add overhead, so the
actual flash program operation will take longer; conversely more
writes per burst will worsen response times but reduce overhead. For
flash devices which support buffered writes the driver will always try
to use a full buffer so there is no point in reducing the burst size
to less than the buffer size, but setting the burst size to a larger
value is permitted.
Similarly erasing a block of flash safely requires disabling
interrupts and possibly the cache. Erasing a block can easily take a
second or so, and disabling interrupts for such a long period of time
is usually undesirable. Hence the driver can also perform the erase in
bursts, using the hardware's suspend and resume capabilities.
controls the number of polling loops during which interrupts are
disabled. Reducing its value improves responsiveness at the cost of
performance, and increasing its value has the opposite effect. Note
that too low a value may prevent the erase operation from working at
all: the chip will be spending its time suspending and resuming,
rather than actually performing the erase. The minimum value will
depend on the specific hardware.
There are a number of other options, relating mostly to hardware
characteristics. It is very rare that application developers need to
change any of these. For example the option
CYGNUM_DEVS_FLASH_STRATA_V2_ERASE_REGIONS may need
a non-default value if the flash devices used on the target have an
unusual boot block layout. If so the platform HAL will impose a
requires constraint on this option and the configuration system will
resolve the constraint. The only time it might be necessary to change
the value manually is if the actual board being used is a variant of
the one supported by the platform HAL and uses a different flash chip.
|Open Publication License