Flash area functions for listing active and specified type flash memory areas/partitions #33144
Conversation
github-actions
bot
added
area: API
de-nordic
force-pushed
the
flash-map-area-type
branch
3 times, most recently
from
c8467c9
to
4b4aca1
Compare
de-nordic
force-pushed
the
flash-map-area-type
branch
from
4b4aca1
to
8884501
Compare
de-nordic
force-pushed
the
flash-map-area-type
branch
from
8884501
to
d3486ec
Compare
The commit adds bindings for following compatibles: zephyr,mcuboot-image zephyr,mcuboot-scratch zephyr,application-image These compatobles may be used to specify partitions that are capable to be used for mcuboot image, mcuboot scratch and application image respectively. Signed-off-by: Dominik Ermel <[email protected]>
The flash_area structure has been extended with flash area type filed, fa_type, that is supposed to have one of FLASH_AREA_TYPE_* predefined values which represent the purpose of the area. Signed-off-by: Dominik Ermel <[email protected]>
The commit adds macros that allows to extract flash area type and translate it from C specific "compatible" identifier, for example zephyr_application_image, to FLASH_AREA_TYPE_* constants. The commit modifies defaullt flash_map generator with new macros to assign the area type to fa_type for each partition. Signed-off-by: Dominik Ermel <[email protected]>
The is example of zephyr,mcuboot-image, zephyr,mcuboot-scratch and zaphyr,applicaiton-image usage. [TODO] Other boards. Signed-off-by: Dominik Ermel <[email protected]>
The commit adds macros that allow to get information on currently active flash partition and perform operations on partitions of selected type. Following macros have been added in this commit: FLASH_AREA_ACTIVE_ID -- returns ID of flash area an active application is running from; FLASH_AREA_FOR_EACH_COMPATIBLE -- allows to invoke macro on each instance of compatible type partition/flash area. Signed-off-by: Dominik Ermel <[email protected]>
de-nordic
force-pushed
the
flash-map-area-type
branch
2 times, most recently
from
530016f
to
0b4f365
Compare
The commit adds: flash_area_active_app -- that returns pointer to flash_area occupied by active application flash_area_enum_type -- that enumerates flash_area for specified type [TODO] Tests Signed-off-by: Dominik Ermel <[email protected]>
The flash_area_type sample has been added that presents how user may utilise flash_area_api, to get information on current active partition and enumerate list of partitions to access partitions of specified type. This sample presents usage of functions: flash_area_active flash_area_enum_type and macros FLASH_AREA_FOR_EACH_COMPATIBLE Signed-off-by: Dominik Ermel <[email protected]>
de-nordic
force-pushed
the
flash-map-area-type
branch
from
0b4f365
to
87287ea
Compare
| description: | | ||
| Partition or other storage area for mcuboot bootloader image. | ||
|
|
||
| compatible: "zephyr,mcuboot-image" |
There was a problem hiding this comment.
Is there a reason not to use generic identifiers, e.g. just bl-image/bl-scratch, for bootloader areas?
There was a problem hiding this comment.
This is zephyr/mcuboot specific. Probably other bootloader could be used, or be chained to/in front of the mcuboot, and that booloader would have different compatibility to recognize its partitions.
There was a problem hiding this comment.
This does not explain why generic partition identifiers cannot be used. MCUboot is also only a Zephyr application.
| #define FLASH_AREA_NODE_COMPAT_TYPE(n, c, t) COND_CODE_1(DT_NODE_HAS_COMPAT(n, c), (t), ()) | ||
|
|
||
| #define FLASH_AREA_NODE_TYPE(n) \ | ||
| FLASH_AREA_NODE_COMPAT_TYPE(n, zephyr_mcuboot_image, FLASH_AREA_TYPE_MCUBOOT) \ |
There was a problem hiding this comment.
Since this is MCUboot specific, should not it be in flash_map_mcuboot.h?
| /** | ||
| * @brief Return pointer to flash_area occupied by running application. | ||
| * | ||
| * @return non-NULL pointer to @p flash_area structure holding information on area an application is |
There was a problem hiding this comment.
All this long lines here can be reshaped.
| description: | | ||
| Partition or other storage area for mcuboot bootloader image. | ||
|
|
||
| compatible: "zephyr,mcuboot-image" |
There was a problem hiding this comment.
This does not explain why generic partition identifiers cannot be used. MCUboot is also only a Zephyr application.
| @@ -67,6 +68,12 @@ struct flash_area { | |||
| const char *fa_dev_name; | |||
| }; | |||
|
|
|||
| #define FLASH_AREA_TYPE_UNSPECIFIED 0x00 /* No type */ | |||
| #define FLASH_AREA_TYPE_MCUBOOT 0x01 /* zephyr,mcuboot,image */ | |||
There was a problem hiding this comment.
This does not look right. Should every bootloader place its ID here?
Disk subsystem offers possibility to find a block device without such hard-coded IDs.
There was a problem hiding this comment.
This does not look right. Should every bootloader place its ID here?
No, the ID should be added when support for bootloader within Zephyr is added.
Disk subsystem offers possibility to find a block device without such hard-coded IDs.
Yes, but the disk subsystem may use for example names of mount points.
I am trying to avoid bringing the "compatible" identifiers into flash; the space on mcuboot partition becomes tight.
There was a problem hiding this comment.
Yes, but the disk subsystem may use for example names of mount points.
I am trying to avoid bringing the "compatible" identifiers into flash; the space on mcuboot partition becomes tight.
How the disk subsystem identifiers are formed is debatable and not set in stone. This approach here does not scale and is not generic, like so much around flash.
|
Unfortunately I have lost confidence in the feature or it being required at all: the mcuboot is the only supported bootloader and its support for compile-time resolved image placement is very much hardcoded in common code and would require a lot of rework in mcuboot. |
The PR adds:
TODO
Resolves #32257