Enable sharing of image size information in multi-image builds

[danieldegrasse]

This issue is created to track the use case for multi image in #41579. In this instance of Zephyr multi image, the primary core must copy the secondary core application into RAM at boot. The current approach in #41579 is to link the second image binary into the primary image as a binary blob, and then use the LOADADDR the linker provides, along with the calculated image size to allow the primary core to copy the second image into RAM. However, the minimum requirements for this use case are the following:

1. Primary image must know where the secondary image is stored in flash
2. Primary image must know how much data to load. This can be the binary image size, or a series of section LMA/VMAs and sizes.

Beyond these requirements, there is a general need to enforce a dependency on the secondary image within the primary one. This is because the primary image cannot finish building until it knows how much data is contained in the secondary image, and thus how much must be loaded to RAM.

Describe the solution you'd like
I would like a solution capable of exposing all LMA/VMAs of the secondary image, to ensure that the primary image knows which addresses to load (and where). Beyond this, I feel that a way to share the secondary image's devicetree.h may be useful in the future, but it is not required for this specific application.

Describe alternatives you've considered
The current solution simply exposes the offsets of the second image binary in flash, and so even empty sections will be copied into RAM. This solution does have the advantage of building a single loadable binary, but is not as clean as building and flashing two separate images.

[carlescufi]

I think this is somewhat related to #31073

[carlescufi]

@tejlmand @mbolivar-nordic @carlocaione @JordanYates FYI

[Laczen]

@danieldegrasse, couldn't you just add a header to the image that describes where it should be loaded and what the image side is.

[danieldegrasse]

@Laczen yes, that would work fine. The question is how to generate the header. #41685 is an example of a possible approach.

[Laczen]

@Laczen yes, that would work fine. The question is how to generate the header. #41685 is an example of a possible approach.

I was more thinking about adding this information to the image, just like the header that is used in mcuboot images.

[mbolivar-nordic]

Beyond this, I feel that a way to share the secondary image's devicetree.h may be useful in the future, but it is not required for this specific application.

The long-term approach is system devicetree, https://github.com/devicetree-org/lopper/blob/master/specification/specification.md, but progress has been pretty slow.

[zephyrbot]

Hi @tejlmand,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@danieldegrasse you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!

[danieldegrasse]

Thanks for the reminder @zephyrbot :) #41685 provided a usable solution for this. Closing this issue.