eCos Product
RedBoot Product
Supported Hardware |
![]() RedBoot Flash SupportThe flash driver package must contain the following CDL: cdl_package CYGPKG_DEVS_FLASH_INTEL_BOOTBLOCK { display "Intel boot block flash memory support" parent CYGPKG_IO_FLASH active_if CYGPKG_IO_FLASH implements CYGHWR_IO_FLASH_DEVICE include_dir . include_files ; # none _exported_ whatsoever description "FLASH memory device support for Intel boot block flash memory " compile bootblock_flash.c compile bootblock_flash.c [...] } Note that the flash functions are copied to RAM before they get executed, thus preventing spurious access cycles to the flash device while it is modified. These functions cannot contain non-relocatable code - in particular they cannot call other functions since this is usually done with PC-relative branch instructions. The relocation is made possible by some special CDL build instructions which is why the files are not simply listed by the compile statement above. This is an example of a build rule: make -priority 1 { flash_erase_block.o: $(REPOSITORY)/$(PACKAGE)/src/flash_erase_block.c $(CC) -S $(INCLUDE_PATH) $(CFLAGS) -fno-function-sections \ $(REPOSITORY)/$(PACKAGE)/src/flash_erase_block.c echo "#include This ensures that there is a symbol at the end of the function, allowing it to be copied to RAM before execution. The flash driver must provide the API described below. Note that this API is still being designed, and _will_ change. It will need to provide a pointer to a structure describing the flash area, thus allowing support of mutiple flash areas on the same platform.
Some drivers may also include functionality to lock and unlock areas of the flash device. In that case, the CDL must include a 'implements CYGHWR_IO_FLASH_BLOCK_LOCKING' statement. These functions do not have a consistent interface yet: [FIXME: or is there a reason for one taking a single block and the other a range?]
|