-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flash map custom source #76856
Flash map custom source #76856
Conversation
When using the RAM loading feature of mcuboot, it's usually necessary to generate the mcuboot-ready image using `--load-addr`, which specifies where in the RAM the image will be loaded. This patch adds a new Kconfig that, when present, will make the generated image have the address information. Signed-off-by: Ederson de Souza <[email protected]>
Currently, there's no prompt for ROM_START_OFFSET config if building for mcuboot. However, not all targets require the default alignment. For instance, mec17 needs 0x400 alignment. Remove the promptless default, so that applications can change the value. Signed-off-by: Ederson de Souza <[email protected]>
Flash map API is built on top of Flash API, which makes sense. However, some other storage devices could benefit from exposing a flash map API - specially in the context of mcuboot, which uses flash map API extensively. This patch adds the possibility, under a new Kconfig FLASH_MAP_CUSTOM_BACKEND, to implement the flash map API directly. One just needs to implement `flash_area_open_custom` method, which is called when `flash_area_open` is called on a qualifying id. This method should be used to dispatch the flash_area creation to the right implementation. Such implementation then needs to fill the new `api` field from `struct flash_area`. Then, the flash map API will simply call the implementation methods from the struct. A "qualifying id" is any id OR'ed with FLASH_MAP_CUSTOM_BACKEND_MASK. This is used to identify when a flash_area has a custom backend implementation, otherwise, default implementation will be used. Signed-off-by: Ederson de Souza <[email protected]>
struct flash_map_backend_api { | ||
void (*close)(const struct flash_area *fa); | ||
int (*read)(const struct flash_area *fa, off_t off, void *dst, | ||
size_t len); | ||
int (*write)(const struct flash_area *fa, off_t off, const void *src, | ||
size_t len); | ||
int (*erase)(const struct flash_area *fa, off_t off, size_t len); | ||
int (*flatten)(const struct flash_area *fa, off_t off, size_t len); | ||
uint32_t (*align)(const struct flash_area *fa); | ||
int (*has_driver)(const struct flash_area *fa); | ||
const struct device *(*get_device)(const struct flash_area *fa); | ||
uint8_t (*erased_val)(const struct flash_area *fa); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. Just implement the flash driver that will do the thing you want, create the flash device and put the partition on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, thanks for the input!
Flash map API is built on top of Flash API, which makes sense. However, some other storage devices could benefit from exposing a flash map API - specially in the context of mcuboot, which uses flash map API extensively.
This PR adds the possibility, under a new Kconfig FLASH_MAP_CUSTOM_BACKEND, to implement the flash map API directly. One just needs to implement
flash_area_open_custom
method, which is called whenflash_area_open
is called on a qualifying id. This method should be used to dispatch the flash_area creation to the right implementation. Such implementation then needs to fill the newapi
field fromstruct flash_area
. Then, the flash map API will simply call the implementation methods from the struct.A "qualifying id" is any id OR'ed with FLASH_MAP_CUSTOM_BACKEND_MASK. This is used to identify when a flash_area has a custom backend implementation, otherwise, default implementation will be used.
Also in this PR are patches that allow one to change ROM start offset for mcuboot and where an image should be loaded by mcuboot, when RAM load is used.
For an example of how this can be used, please refer to mcu-tools/mcuboot#2031