Board flash partitions can't be tested in tree

[erwango]

Is your enhancement proposal related to a problem? Please describe.
Some boards provide a flash partition which is configured to work with a bootloader, generally mcuboot, which is an external component.
This flash partition is also used by in tree components, such as NVS, which use the storage partition that may impose some constraints on the whole flash partition (at least 2 sectors, less that 64Kb for NVS).
So, when trying to test in tree components with this defined partition, we might hit issues that are faced because the board flash partition is made to work with mcuboot and doesn't operate when linked w/o bootloader at start of the flash.

One good example is trying to run NVS on stm32f4 parts.
Due to NVS constraints, 'storage' can only be put in the first 64 Kb of flash. When building a zephyr application w/o mcuboot application is linked to start of flash, so these slots can not be used.
So either we configure partition coherent with the way it is linked in zephyr w/o bootloader and NVS can't be used, either we configure it to be compatible with NVS, but can't be used w/o bootloader.

Describe the solution you'd like
Have a dead simple bootloader in tree that would only allow to link in the defined board partition and jump on defined slot image (zephyr,code-partition) at boot for in-tree application

Describe alternatives you've considered
Pull mcuboot in order to test boards partitions in-tree.

Additional context
#19895

[erwango]

@Laczen

[carlescufi]

@erwango #17868

[erwango]

@erwango #17868

@carlescufi, I've seen this but do we want to build mcuboot in all samples that rely on board flash partition ?

[carlescufi]

@erwango #17868

@carlescufi, I've seen this but do we want to build mcuboot in all samples that rely on board flash partition ?

Perhaps not, but it wouldn't be too difficult to do so either. There is even a proposal to do this automatically in CMake, that we use internally: #13672.

@nvlsianpu thoughts?

[Laczen]

@carlescufi, it might be a bit more difficult. There are boards were the standard mcuboot partitioning will not work in combination with storage. These boards typically have small flash pages at the start and larger at the end of the flash region. In this case mcuboot should work as a secondary loader.
Mcuboot is too tightly integrated in zephyr, instead of integrating it even more like in #17868 it should be released more. Zephyr should work with any bootloader, not only mcuboot.

[nvlsianpu]

^^ this sounds like some targets need bootloader with two stages, the first stage which only calls second stage which is mcuboot or whatever else. I'm not sure whether no better do that as another mcuboot feature.

[thedjnK]

I don't like the sound of having a separate bootloader for in-tree compilation, this would case issues with an upcoming board we have which uses a different bootloader which should not be touched or erased and our samples all make the assumption that the bootloader is present. In our case, the bootloader resides at the top of flash, and there is a small part of code at the bottom of flash which loads the bootloader, and changing this setup is not an option.

[galak]

DEV-REVIEW: Might already have been thought of, but have a Kconfig option for a 'simple jump loader' that would add code to jump to the 'code-partition' link address. This Kconfig option would also enable some tweaks to the linker script for where the 'simple jump loader' gets linked at. Need to figure out if we can use DT or need Kconfig option for where to link the 'simple jump loader' at.

[erwango]

I don't like the sound of having a separate bootloader for in-tree compilation, this would case issues with an upcoming board we have which uses a different bootloader which should not be touched or erased and our samples all make the assumption that the bootloader is present. In our case, the bootloader resides at the top of flash, and there is a small part of code at the bottom of flash which loads the bootloader, and changing this setup is not an option.

@thedjnK, hard to take constraints from things that are not in tree.
However, I think a Kconfig option can be made available to take this need into account.

[galak]

I don't like the sound of having a separate bootloader for in-tree compilation, this would case issues with an upcoming board we have which uses a different bootloader which should not be touched or erased and our samples all make the assumption that the bootloader is present. In our case, the bootloader resides at the top of flash, and there is a small part of code at the bottom of flash which loads the bootloader, and changing this setup is not an option.

@thedjnK, hard to take constraints from things that are not in tree.
However, I think a Kconfig option can be made available to take this need into account.

As @erwango said, this would only be for the cases that some other bootloader didn't exist.

[Laczen]

The simple jump loader (optionally selected) would be an ideal solution. The information about where to jump to is known (FLASH_LOAD_OFFSET) so no need to try and define that. Only the option to include the simple jump loader is to be added.

[Laczen]

It might be good to create a Kconfig variable for the selected "bootloader":
a. No loader: generates images for offset 0 (default)
a. Simple jump loader: generates images for zephyr, chosen =... and includes the jump loader
c. Other: generates images for zephyr, chosen=... and sets a text_offset (defaults to MCU_boot header size).

[zephyrbot]

Hi @nvlsianpu,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. Please confirm the issue is correctly assigned and re-assign it otherwise.

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.

@erwango 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!