You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been recently adding change to MCUboot where it allows to support devices without hardware required erase and found out that it is really hard to do the change in a graceful way as the MCUboot is entangled, for example, with Zephyr.
It also means that any changes to flash_area_ in Zephyr immediately affect MCUboot, without easy way to provide compatibility layer.
Why not redefine the API if we are at it?
Because it would take ages and while we may get blocked by any changes to Zephyr or other system we support. And too many changes at once.
So what would be the change?
All flash_area_ prefixed calls would be renamed to use boot_storage_ prefix and system specific headers will be altered to do inline calls to system native function or MCUboot defined compatibility functions.
What would be Flash cost?
Should be none at this point.
OK, lets do it. Is there something that may block us?
Yes. bootutil_public. It seems that the library shares some headers and flash area macros with callers. Need further investigation and fixing. It also picks flash definitions from sysflash and so on, while executing in context of application that should use system provided definitions for areas.
The text was updated successfully, but these errors were encountered:
Why?
I have been recently adding change to MCUboot where it allows to support devices without hardware required erase and found out that it is really hard to do the change in a graceful way as the MCUboot is entangled, for example, with Zephyr.
It also means that any changes to flash_area_ in Zephyr immediately affect MCUboot, without easy way to provide compatibility layer.
Why not redefine the API if we are at it?
Because it would take ages and while we may get blocked by any changes to Zephyr or other system we support. And too many changes at once.
So what would be the change?
All flash_area_ prefixed calls would be renamed to use boot_storage_ prefix and system specific headers will be altered to do inline calls to system native function or MCUboot defined compatibility functions.
What would be Flash cost?
Should be none at this point.
OK, lets do it. Is there something that may block us?
Yes. bootutil_public. It seems that the library shares some headers and flash area macros with callers. Need further investigation and fixing. It also picks flash definitions from sysflash and so on, while executing in context of application that should use system provided definitions for areas.
The text was updated successfully, but these errors were encountered: