The CYGPKG_DEVS_FLASH_AMD_AM29XXXXX_V2
AMD
AM29xxxxx V2 flash driver package implements support for the AM29xxxxx
family of flash devices and compatibles. Normally the driver is not
accessed directly. Instead application code will use the API provided
by the generic flash driver package
CYGPKG_IO_FLASH
, for example by calling functions
like cyg_flash_program
.
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.
Note: Many eCos targets with AM29xxxxx or compatible flash devices will still use the older driver package
CYGPKG_DEVS_FLASH_AMD_AM29XXXXX
. Only newer ports and some older ports that have been converted will use the V2 driver. This documentation only applies to the V2 driver.
The AM29xxxxx 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 AM29xxxx driver package.
There are a number of configuration 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_AMD_AM29XXXXX_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.