Why position-independent + direct-xip load mode are not supported?

[pkarashchenko]

Currently in MCUboot docs I read that there is a limitation that image should be "Built to run from a fixed location (i.e., not position-independent).", but also there is a "direct-xip" option. I do not fully understand what are the limitation that image with "position-independent" code + "direct-xip" load mode should not work?

[d3zd3z]

There is probably a little confusion with the term "direct-xip". Hopefully I can clarify:

• Without enabling "direct-xip", MCUboot always runs the code from the first slot. When doing an upgrade, code is moved around in flash to place the desired image in this first slot, and it is executed. Code is generally build to run directly from flash, at this address.
• direct-xip allows code to run from either slot. There are two ways that this can be done. Conventionally, the image is built twice, once for each slot, and during upgrade, the upgrade system figures out which slot does not have the current running image in it, and configures to have the one linked at that address placed there.
• As you mention, it should also be possible to build the image with position independent code such that it would run at either location. Then you would only have a single image to load (the same image for either slot), and direct-xip would be easier to manage.

As far as I know, nobody has implemented position-independent code for any of the platforms supported by MCUboot. Generally, it will take some extra work at the OS level to make this possible, as at a low level, most kernels make assumptions about knowing the address the code is located at. For example, Zephyr points directly to the vector table, which is in flash, and has direct addresses of the code to jump to.

I don't believe there is anything within MCUboot stopping PIC from being implemented, it just hasn't been done.

[pkarashchenko]

Hello.

Thanks for explanation. That actually matches with my assumptions. I agree that most probably each OS has to do an adaptation for the position-independent code to work well most probably because the issues that you describe (relocating vector table to RAM and rebuilding the pointers to actual functions during OS startup process for example, or some alternative way).

The reason why I'm asking is exactly because I would like to reduce the double link and signing of binaries, so only one binary can be maintained and I can still leverage the max erase/program cycles of the flash is device supports XIP.

But now I see that some more design work should be done that is followed by proper implementation most probably on both MCUboot and OS sides.

Thanks again for answering!

[d3zd3z]

But now I see that some more design work should be done that is followed by proper implementation most probably on both MCUboot and OS sides.

Other than issues about possibly needing to pass the offset into the image, I don't think significant changes will need to happen to MCUboot for this. It already supports having XIP images in both slots, and isn't really aware of whether that is done by linking them twice, or using PIC.