bootloader project in nCS

[Ubaid_M]

Hi,

1. Is bootloader file and firmware file, different for projects build on nCS..?
    Or a single executable build file consists both bootloader & firmware..?

2. Can you suggest a sample program to build a bootloader project..?

Thanks,

[Edvin]

Hello,

In NCS, the bootloader is enabled through configurations, mostly. 

I suggest that you check out the documentation of FOTA upgrades:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/nrf/ug_nrf52.html#fota-upgrades

And there is also a written guide on how to add DFU to your project, that I can recommend:

https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/software/posts/ncs-dfu

If you struggle with the implementation, I suggest that you follow the guide first, and add DFU to the smp_svr sample from NCS, so that you know that everything around (uploading via nRF Connect for iOS/Android/mcumgr) is working as it should, before you start looking into potential issues in your custom application.

BR,

Edvin

[Ubaid_M]

Hello Edvin,

Edvin said:

And there is also a written guide on how to add DFU to your project,

Towards DFU, i see that we make the following configuration to the project:

# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y

So,
1. By enabling MCUBOOT what happens..?
2. Where is the bootloader image file in the device memory..?
3. Is the boot loader image file different than firmware image file or bootloader code is integrated into the firmware image file..?

Thanks,

[Edvin]

1: By enabling MCUBOOT the compiler will build the MCUBOOT bootloader for you, and add it to the build folder. This means that when you flash your project, it will flash the bootloader and the application. Also, when you build, it will build the uppdate binary file in build\zephyr\app_update.bin, so if you do any updates, you can use this to update using DFU.

2: In the beginning. After enabling CONFIG_BOOTLOADER_MCUBOOT=y your build folder will contain a file called partitions.yml, which will list all the partitions in the flash. 

part of this file will say something like:

app:
  address: 0xc200
  end_address: 0x80000
  region: flash_primary
  size: 0x73e00
littlefs_storage:
  address: 0xf8000
  end_address: 0xfe000
  placement:
    align:
      start: 0x4000
    before:
    - end
  region: flash_primary
  size: 0x6000
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000

So in this case you can see that the bootloader is located at address 0x0, while the app is located at 0xc200.

3: Depending on what chip you are working on. If your chip only have one core, then the build folder will have one .hex file that is called either zephyr.hex or merged.hex. If you have several cores, then there will be a separate file for each core. However, the bootloader will be included in the files if CONFIG_BOOTLOADER_MCUBOOT=y.

BR,
Edvin

[Ubaid_M]

Hello Edvin,

Thank you for the info,

Further,

1. How does how does the image boot if I have not enabled CONFIG_BOOTLOADER_MCUBOOT=y..?

2. Some preexisting bootloader does the job or if system does not find anything at the address,

Edvin said:

bootloader is located at address 0x0

It will straight away jump to the firmware file address 

Edvin said:

app is located at 0xc200

..??

3. Can you please suggest if this "BOOTLOADER_MCUBOOT" checks for firmware file image code signing before booting the image..?

4. If it does, how does it use the key for code signing check on the firmware file..?

5. How can I update this key..?

Thanks,

[Edvin]

Hello,

Ubaid_M said:

1. How does how does the image boot if I have not enabled CONFIG_BOOTLOADER_MCUBOOT=y..?

Then there is no bootloader. The application will be located at 0x00.

Ubaid_M said:

Some preexisting bootloader does the job or if system does not find anything at the address,

no. See 1.

Ubaid_M said:

3. Can you please suggest if this "BOOTLOADER_MCUBOOT" checks for firmware file image code signing before booting the image..?

Yes it does.

Ubaid_M said:

4. If it does, how does it use the key for code signing check on the firmware file..?

It uses a default key, which you should see when you compile. Some message saying that this is a default key which should not be used for production, and that you should change it.

Ubaid_M said:

5. How can I update this key..?

I believe it says in the same warning.

Best regards,

Edvin

[Ubaid_M]

Thank you Edvin,

Edvin said:

Then there is no bootloader. The application will be located at 0x00.

It is clearer now.

Now if I want to generate a private key and add it into the MCUBOOT, what process do I follow..?

Please suggest.

Thanks

[Edvin]

Please see this link on how to generate new key pairs.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/tfm/docs/technical_references/design_docs/tfm_secure_boot.html#second-stage-bootloader-in-tf-m

There is also a Kconfig definition

CONFIG_BOOT_SIGNATURE_KEY_FILE (described as "config BOOT_SIGNATURE_KEY_FILE" in NCS\nrf\modules\mcuboot\Kconfig) where you can set the absolute path of the key file that you have generated.

Best regards,

Edvin