• State Not Answered
  • Replies 7 replies
  • Subscribers 74 subscribers
  • Views 2142 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 284271
Options

nRF5340 nRF Secure Immutable Bootloader and Network core bootloader

Eighth

Hello!

I have a problem updating network core firmware through MCUboot when NSIB is enabled (through "CONFIG_SECURE_BOOT=y" in my application prj.conf).

Without NSIB enabled, I can see in MCUboot logs that network core is being updated as per netboot testing tutorial (message "Done updating network core" is printed). With NSIB enabled, however, nothing network-core-related is printed by MCUboot after restarting with new network core update image written to secondary slot.

I found a related discussion, where it is stated that nRF53 is not supported by nRF Secure Immutable Bootloader:

https://devzone.nordicsemi.com/f/nordic-q-a/73819/issue-about-nrf5340-network-core-bootloader

Is that still the case? If yes, is it mentioned in documentation? Can I get more details on why exactly isn't it working? I was able to use NSIB and update MCUboot, and I can't imagine why b0 and b0n would conflict as they are completely unrelated as I see it.

nRF Connect SDK version: 1.8.0

Best regards

Parents
  • 0

    Hi, 

    This is still the case as the PCD is used only from mcuboot hooks and we believe it is needed for DFU of the network core. 

    Regards,
    Amanda

  • 0 in reply to Amanda Hsieh

    Sorry, I'm not sure if you understood my questions. I'm not trying to update Network core using NSIB, I understand that it's MCUboot job. That's exactly why I don't understand why enabling NSIB breaks Network core updates by MCUboot - I don't see how they are related.

    What I'm trying to accomplish:

    1. Two-stage bootloaders - NSIB verifies and starts MCUboot from one of two slots. MCUboot is able to update itself by writing to unused slot.

    2. MCUboot is able to update Application core AND Network core applications.

    Currently I can get either 1 or 2 working, but not both.

    Best regards,

    Vladislav

  • 0 in reply to Eighth

    Hi, 

    Sorry for the delay. We are looking into the issue, and need time to reply. 

    -Amanda

  • 0 in reply to Amanda Hsieh

    Hi, 

    From the team: 

    From the current investigation, there is nothing actually stopping the network core from being updated. However, if you enable both SECURE_BOOT and MCUBoot the generated update files seem to be invalid. We are looking into the issue trying to figure out a fix for it, but cannot promise any schedule. Sorry for the inconvenience. 

    -Amanda

  • 0 in reply to Amanda Hsieh

    Hello! There's a bit of additional info on the issue, although not completely relevant to what I've originally asked, because it involves storing secondary slots on QSPI Flash (yep, NSIB + Network updates doesn't work that way too).

    I was able to pinpoint why Network core update breaks. It's because of influence of PM_B0_ADDRESS on FLASH_AREA_IMAGE_PRIMARY and FLASH_AREA_IMAGE_SECONDARY macros, see boorloader/mcuboot/boot/zephyr/include/sysflash/sysflash.h:17:

    #elif (MCUBOOT_IMAGE_NUMBER == 2)

/* If B0 is present then two bootloaders are present, and we must use
 * a single secondary slot for both primary slots.
 */
#ifdef PM_B0_ADDRESS

extern uint32_t _image_1_primary_slot_id[];

#define FLASH_AREA_IMAGE_PRIMARY(x)            \
        ((x == 0) ?                            \
           PM_MCUBOOT_PRIMARY_ID :             \
         (x == 1) ?                            \
          (uint32_t)_image_1_primary_slot_id : \
           255 )

#define FLASH_AREA_IMAGE_SECONDARY(x) \
        ((x == 0) ?                   \
            PM_MCUBOOT_SECONDARY_ID:  \
        (x == 1) ?                    \
           PM_MCUBOOT_SECONDARY_ID:   \
           255 )
#else

#define FLASH_AREA_IMAGE_PRIMARY(x)          \
        ((x == 0) ?                          \
           PM_MCUBOOT_PRIMARY_ID :           \
         (x == 1) ?                          \
           PM_MCUBOOT_PRIMARY_1_ID :         \
           255 )

#define FLASH_AREA_IMAGE_SECONDARY(x) \
        ((x == 0) ?                   \
           PM_MCUBOOT_SECONDARY_ID:   \
        (x == 1) ?                    \
           PM_MCUBOOT_SECONDARY_1_ID: \
           255 )

#endif /* PM_B0_ADDRESS */

    So, when NSIB is present, MCUboot "doesn't know" where Network core primary slot is, and that there is more than one secondary slot.

    I feel the need to express that the design decision to by default use the single secondary slot for everything AND to hardcode a lot of magic logic into MCUboot to allow this, is, by my humble oppinion, a very poor design decision.

    A couple points:

    • It uses a tool (MCUboot) incorrectly and disregarding tool's intended design.
    • It brings a lot of headache and unexpected side effects. For example, the reset vector address check in loader.c ignores the fact that the secondary is on external flash, and only by pure luck does not lead to memory fault in default configuration.
Reply
  • 0 in reply to Amanda Hsieh

    Hello! There's a bit of additional info on the issue, although not completely relevant to what I've originally asked, because it involves storing secondary slots on QSPI Flash (yep, NSIB + Network updates doesn't work that way too).

    I was able to pinpoint why Network core update breaks. It's because of influence of PM_B0_ADDRESS on FLASH_AREA_IMAGE_PRIMARY and FLASH_AREA_IMAGE_SECONDARY macros, see boorloader/mcuboot/boot/zephyr/include/sysflash/sysflash.h:17:

    #elif (MCUBOOT_IMAGE_NUMBER == 2)

/* If B0 is present then two bootloaders are present, and we must use
 * a single secondary slot for both primary slots.
 */
#ifdef PM_B0_ADDRESS

extern uint32_t _image_1_primary_slot_id[];

#define FLASH_AREA_IMAGE_PRIMARY(x)            \
        ((x == 0) ?                            \
           PM_MCUBOOT_PRIMARY_ID :             \
         (x == 1) ?                            \
          (uint32_t)_image_1_primary_slot_id : \
           255 )

#define FLASH_AREA_IMAGE_SECONDARY(x) \
        ((x == 0) ?                   \
            PM_MCUBOOT_SECONDARY_ID:  \
        (x == 1) ?                    \
           PM_MCUBOOT_SECONDARY_ID:   \
           255 )
#else

#define FLASH_AREA_IMAGE_PRIMARY(x)          \
        ((x == 0) ?                          \
           PM_MCUBOOT_PRIMARY_ID :           \
         (x == 1) ?                          \
           PM_MCUBOOT_PRIMARY_1_ID :         \
           255 )

#define FLASH_AREA_IMAGE_SECONDARY(x) \
        ((x == 0) ?                   \
           PM_MCUBOOT_SECONDARY_ID:   \
        (x == 1) ?                    \
           PM_MCUBOOT_SECONDARY_1_ID: \
           255 )

#endif /* PM_B0_ADDRESS */

    So, when NSIB is present, MCUboot "doesn't know" where Network core primary slot is, and that there is more than one secondary slot.

    I feel the need to express that the design decision to by default use the single secondary slot for everything AND to hardcode a lot of magic logic into MCUboot to allow this, is, by my humble oppinion, a very poor design decision.

    A couple points:

    • It uses a tool (MCUboot) incorrectly and disregarding tool's intended design.
    • It brings a lot of headache and unexpected side effects. For example, the reset vector address check in loader.c ignores the fact that the secondary is on external flash, and only by pure luck does not lead to memory fault in default configuration.
Children
Related
Terms of service