This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Immutable bootloader partition setting

Hi,

I am using nrf Connect SDK v1.5.0

The immutable bootloader is located in nrf\samples\bootloader

My question is about the partition setting in the pm.yml.

This is the screen shot from the pm.yml.

Why si_image has to be align with end:CONFIG_FPROTECT_BLOCK_SIZE?

This alignment will cause a empty area between s1_pad & s1_image in the flash

Can I comment out the alignment setting for s1_image.

Another question is that what is s0_pad & s1_pad? Are they image header info? Can you link me to any source about this.

Thank you,

Jason

  • Hi, and sorry for the late answer.

     

    Why si_image has to be align with end:CONFIG_FPROTECT_BLOCK_SIZE?

     The immutable bootloader disables writing to the flash pages it and its data resides in.

    But, the application must be able to receive and write a new version to flash, the s1 partition must be in unprotected flash.

     

    Another question is that what is s0_pad & s1_pad? Are they image header info? Can you link me to any source about this.

     Yes, they are used to hold information about the FW image in the slot.

    See https://github.com/nrfconnect/sdk-nrf/blob/master/include/fw_info.h

    Best regards,

    Didrik

  • Hi Didrik,

    /*
     * Copyright (c) 2018 Nordic Semiconductor ASA
     *
     * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
     */
    
    #include <zephyr/types.h>
    #include <sys/printk.h>
    #include <pm_config.h>
    #include <fw_info.h>
    #include <fprotect.h>
    #include <bl_storage.h>
    #include <bl_boot.h>
    #include <bl_validation.h>
    
    
    static void validate_and_boot(const struct fw_info *fw_info, uint16_t slot)
    {
    	printk("Attempting to boot slot %d.\r\n", slot);
    
    	if (fw_info == NULL) {
    		printk("No fw_info struct found.\r\n");
    		return;
    	}
    
    	printk("Attempting to boot from address 0x%x.\n\r",
    		fw_info->address);
    
    	if (!bl_validate_firmware_local(fw_info->address,
    					fw_info)) {
    		printk("Failed to validate, permanently invalidating!\n\r");
    		fw_info_invalidate(fw_info);
    		return;
    	}
    
    	printk("Firmware version %d\r\n", fw_info->version);
    
    	if (fw_info->version > get_monotonic_version(NULL)) {
    		set_monotonic_version(fw_info->version, slot);
    	}
    
    	bl_boot(fw_info);
    }
    
    #define BOOT_SLOT_0 0
    #define BOOT_SLOT_1 1
    
    void main(void)
    {
    	int err = fprotect_area(PM_B0_ADDRESS, PM_B0_SIZE);
    
    	if (err) {
    		printk("Failed to protect B0 flash, cancel startup.\n\r");
    		return;
    	}
    
    	uint32_t s0_addr = s0_address_read();
    	uint32_t s1_addr = s1_address_read();
    
    	if ((s0_addr == 0xFFFFFFFF) || (s1_addr == 0xFFFFFFFF))
    	{
    		printk("No provision data.\n\r");
    		return;
    	}
    
    	const struct fw_info *s0_info = fw_info_find(s0_addr);
    	const struct fw_info *s1_info = fw_info_find(s1_addr);
    
    	if (!s1_info || (s0_info->version >= s1_info->version)) {
    		validate_and_boot(s0_info, BOOT_SLOT_0);
    		validate_and_boot(s1_info, BOOT_SLOT_1);
    	} else {
    		validate_and_boot(s1_info, BOOT_SLOT_1);
    		validate_and_boot(s0_info, BOOT_SLOT_0);
    	}
    
    	printk("No bootable image found. Aborting boot.\n\r");
    	return;
    }
    

    This is the source code of immutable bootloader.

    It only fprotect(disable write) its own flash (b0 slot from 0x0 to 0x8000). It doesn't disable writing in s0 & s1 slot.

    And same to mcuboot, it only protect its own flash (0x8200 - 0x14200) 

    So after 0x14200 is all unprotect area.

    Please correct me if I am wrong here.

    My question is that why s1_image couldn't be arranged right after the s1_pad (from 0x18200 to 0x28000)?

    Why it needs to be 0x1c000 - 0x28000?

    Why it needs to have empty space in 0x18200 - 0x1c000

    Please find the above image for reference.

    Thanks,

    Jason

  • I've talked to the developers, and they agree that it is sufficient that the pad region is aligned as long as the image region comes directly behind it.

    I will create an internal ticket to have the alignment requirement removed.

Related