Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dfu: mcuboot: define boot_img_magic when FLASH_AREA_IMAGE_SECONDARY #30076

Conversation

mniestroj
Copy link
Member

boot_img_magic[] is needed for boot_magic_write() function, which is
defined if FLASH_AREA_IMAGE_SECONDARY is defined as well.

Make sure boot_img_magic[] is defined when FLASH_AREA_IMAGE_SECONDARY.

Fixes: #30075

@mniestroj mniestroj added bug The issue is a bug, or the PR is fixing a bug area: MCUBoot labels Nov 16, 2020
@mniestroj mniestroj requested a review from nvlsianpu November 16, 2020 23:03
boot_img_magic[] is needed for boot_magic_write() function, which is
defined if FLASH_AREA_IMAGE_SECONDARY is defined as well.

Make sure boot_img_magic[] is defined when FLASH_AREA_IMAGE_SECONDARY.

Fixes: 5cfafb0 ("dfu/boot/mcuboot: made able to compile within
  MCUBoot")
Signed-off-by: Marcin Niestroj <[email protected]>
Currently there are ifdefs using CONFIG_BOOTLOADER_MCUBOOT to prevent
compilation errors when being built as mcuboot bootloader. This macro
however is related to chain-loadable application image, instead of
bootloader image.

Convert this magic ifdeffery to use CONFIG_MCUBOOT macro instead, as a
way to define whether sources are being built as mcuboot bootloader or
Zephyr application.

Fixes: 5cfafb0 ("dfu/boot/mcuboot: made able to compile within
  MCUBoot")
Signed-off-by: Marcin Niestroj <[email protected]>
@mniestroj mniestroj force-pushed the mcuboot-fix-boot-img-magic branch from 1036bcc to 18b0293 Compare November 16, 2020 23:55
@de-nordic
Copy link
Collaborator

According to the description of the problem (#30075), the desired result is to be able to use CONFIG_IMG_MANAGER=y without support for MCUBOOT:

It is possible to use functionality provided by IMG_MANAGER without building firmware for chain-loading with mcuboot.

Shouldn't then the solution be to make a compilation of mcuboot.c optional within CMakeList.txt ?

Copy link
Collaborator

@nvlsianpu nvlsianpu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We decided not to use not in zephyr tree defined Kconfig properties here.
Then fastest patch is to add || defined(CONFIG_IMG_MANAGER) or && !defined(CONFIG_IMG_MANAGER) where needed.
Also want to emphasize that I will work on #29963 soon

@nvlsianpu nvlsianpu self-assigned this Nov 17, 2020
@mniestroj
Copy link
Member Author

We decided not to use not in zephyr tree defined Kconfig properties here.

But still decided to make a logic based on "not in zephyr tree" code, its public functions etc. IMO it doesn't seem any better, because dependency is still there. The only thing is that Compliance check is satisfied, which is kind of artificial gain.

Then fastest patch is to add || defined(CONFIG_IMG_MANAGER) or || !defined(CONFIG_IMG_MANAGER) where needed.

Unfortunately defined(CONFIG_IMG_MANAGER) still doesn't tell us if we are building within mcuboot or not.

Also want to emphasize that I will work on #29963 soon

Seems like a very good idea, we really need that! Any estimates on that already?

What about adding a helper macro #define WITHIN_MCUBOOT (whatever_magic_needs_to_be_here) and then use #if WITHIN_MCUBOOT and #if !WITHIN_MCUBOOT statements all across the codebase? This will at least show what logic we are relying on, while defined(CONFIG_BOOTLOADER_MCUBOOT) doesn't tell anything for now. Personally I think that we should use CONFIG_MCUBOOT, but if that is really not desirable then at least:

#if !defined(CONFIG_BOOTLOADER_MCUBOOT) && !defined(CONFIG_IMG_MANAGER) && !defined(CONFIG_ZTEST)
#define WITHIN_MCUBOOT 1
#endif

@nvlsianpu
Copy link
Collaborator

WITHIN_MCUBOOT sound ok to me.

@mniestroj
Copy link
Member Author

I am not sure that adding a check around CONFIG_IMG_MANAGER (when defining WITH_MCUBOOT) makes sense, because then we will run into function name conflicts with MCUboot once again, because mcuboot.c is compiled only when CONFIG_IMG_MANAGER=y. @nvlsianpu could you confirm?

@nvlsianpu
Copy link
Collaborator

@mniestroj ^^ obviously you are right.
looks like need to find another way - new kconfig or so

@nvlsianpu
Copy link
Collaborator

I started working on #29963

@nvlsianpu
Copy link
Collaborator

@mniestroj shall we close this?

@mniestroj
Copy link
Member Author

This has been superseded with #30370.

@mniestroj mniestroj closed this Jan 14, 2021
@mniestroj mniestroj deleted the mcuboot-fix-boot-img-magic branch January 26, 2021 09:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: MCUBoot bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

dfu: mcuboot: fail to build with CONFIG_BOOTLOADER_MCUBOOT=n and CONFIG_IMG_MANAGER=y
3 participants