Add config for MIMXRT1060_EVK, add section to README detailing how to configure the project for a new target

[multiplemonomials]

This adds a config that at least gets the bootloader building and working on MIMXRT1060_EVK. It also adds extensive docs on how I arrived at this configuration.

Unfortunately it isn't 100% working yet; I have not gotten it to successfully swap images. However, I think it's a step forward nonetheless.

Please let me know if this documentation is useful! Hopefully it can help explain how to get the project set up on your own devices.

[zhiyong-ft]

@multiplemonomials how do we incorporate the c format public key for signing and private key for encryption into code? I have been using something like the following since porting from Mr. Beckstein's repo:

set(MBED_MCUBOOT_BOOTLOADER_SOURCES
	secondary_bd.cpp
	shared_data.c
	keys/enc-key-priv.c
	keys/signing-key-pub.c)

I am starting to write documentation on encrypted images, and noticed in your repo that neither key files are included. Is the public key in c format automatically derived from the signing key?

[multiplemonomials]

Oh, I added a new CMake variable for that. If you enable encryption in mbed_app.json it will ask you to set it.

By the way, I updated the mcuboot PR with your suggestion to add --clear!

[zhiyong-ft]

Oh, I added a new CMake variable for that. If you enable encryption in mbed_app.json it will ask you to set it.

By the way, I updated the mcuboot PR with your suggestion to add --clear!

Where can I see the script? As of MCUboot v2.1.0, apparently we can use the same image for both initial download and update if encryption is not enabled, --pad seems no longer needed for initial download images. If encryption is enabled, we will need to pass encryption key to both initial download and update images, but add --clear to initial images.

[multiplemonomials]

See here: https://github.com/mcu-tools/mcuboot/blob/289485156355d4373735534b11baa7ab50a9d6c6/boot/mbed/mcuboot_imgtool.cmake#L35

[zhiyong-ft]

See here: https://github.com/mcu-tools/mcuboot/blob/289485156355d4373735534b11baa7ab50a9d6c6/boot/mbed/mcuboot_imgtool.cmake#L35

Do you think it is a good idea to use the same key for both signing and encryption? My concern is having both private and public key of the same key co-exist in bootloader. I guess if someone already has a copy of bootloader, anything can go from there, and it doesn't matter if the private and public key are an pair or not.

[lefebvresam]

I did what you said, also -E key for primary image with -c flag, but I see the primary image is encrypted in that way. When not encrypted I should see readable text at the end of the bin. So what's the sense of the -c then?

[zhiyong-ft]

@lefebvresam are you sure the -c or --clear is added? When I tried it manually with imgtool frm MCUboot v2.1.0, once an encryption key is included, without '-c' or --clear, the initial image won't be able to run.

[lefebvresam]

@lefebvresam are you sure the -c or --clear is added? When I tried it manually with imgtool frm MCUboot v2.1.0, once an encryption key is included, without '-c' or --clear, the initial image won't be able to run.

Yes I updated my script and it stays working:

# Sign the update image
if [ ${SIGN} -eq 1 ]; then
    if [ ${SIGN_DEMO} -eq 1 ] || [ ${PRIM} -eq 1 ]; then
      echo "Sign image '${HEX_APP_FILE}' as the primary application version ${PRIM_IM_VER} and fit into the primary slot size ${PRIM_SLOT_SIZE}"
      mcuboot/scripts/imgtool.py sign -k signing_keys.pem --align 4 -v $PRIM_IM_VER --header-size $HDR_SIZE --pad-header -S $PRIM_SLOT_SIZE -E enc_key_pub.pem -s auto $HEX_APP_FILE -c signed.hex
    fi
    if [ ${SIGN_DEMO} -eq 1 ] || [ ${PRIM} -eq 0 ]; then
      APP_FILE_LENGTH=$(($(hexinfo.py $HEX_APP_FILE | grep 'length: 0x[0-F]*' -o | sed 's/length: //') + $HDR_SIZE + $TRL_SIZE))
      APP_FILE_LENGTH=$(printf '0x%X' $(($APP_FILE_LENGTH + (0x1000 - $APP_FILE_LENGTH % 0x1000)))) #alignment 4k

      echo "Sign image '${HEX_APP_FILE}' as the update application version ${UPD_IM_VER} and schrink to ${APP_FILE_LENGTH} to minimize memory occupation"
      mcuboot/scripts/imgtool.py sign -k signing_keys.pem --align 4 -v $UPD_IM_VER --header-size $HDR_SIZE --pad-header -S $APP_FILE_LENGTH -E enc_key_pub.pem -s auto $HEX_APP_FILE signed-update.hex 
    fi
    if [ ${SIGN_DEMO} -eq 1 ]; then 
      echo "Shift the update image to fit in an unused space of the primary slot (0x40000)"
      arm-none-eabi-objcopy --change-addresses 0x40000 --set-start 0x7FC0345 signed-update.hex signed-update.hex

      echo "Combine the 3 images:"
      hexmerge.py -o merged.hex --no-start-addr $HEX_MCUBOOT_PATH signed.hex signed-update.hex
      hexinfo.py merged.hex
    else
      if [ ${PRIM} -eq 0 ]; then
        hexinfo.py signed-update.hex
        echo "Convert signed-update.hex to ${BIN_APP_UPD_FILE}"
        arm-none-eabi-objcopy -I ihex -O binary signed-update.hex $BIN_APP_UPD_FILE
      else
        echo "Combine the 2 images:"
        hexmerge.py -o merged.hex --no-start-addr $HEX_MCUBOOT_PATH signed.hex
        hexinfo.py merged.hex
      fi
    fi
    if [ ${SIGN_DEMO} -eq 1 ] || [ ${PRIM} -eq 1 ]; then
      echo "Convert merged.hex to ${BIN_APP_FILE}"
      arm-none-eabi-objcopy -I ihex -O binary merged.hex $BIN_APP_FILE
    fi
    echo "Delete temporary files"
    rm -f signed.hex
    rm -f signed-update.hex
    rm -f merged.hex
fi

[zhiyong-ft]

try to run imgtool manually, you shall be able to see the difference. I only tried it manually because most of my code base is still with Mbed-OS. It will take time to migrate them to CE.

[lefebvresam]

try to run imgtool manually, you shall be able to see the difference. I only tried it manually because most of my code base is still with Mbed-OS. It will take time to migrate them to CE.

What should be the difference when running manually?

[zhiyong-ft]

What should be the difference when running manually?

Because something may go wrong in your automated script. I just tried again, without --clear, all plain debug text in built hex images will be scrambled. In the attached screenshot, someone included a list of workdays and month names somewhere in mbed-os, and they are built as it is into hex image. They should be gone once --clear is not present as we do for update images.

[lefebvresam]

You are right. I tested again and indeed primary image is only encrypted when you ommit the -c flag. I think I was looking to the wrong bin yesterday. So the reason that the primary image won't boot when it is encrypted is because the signature checking will be done on an encrypted image and will not succeed? And why you need to specify the encryption key when the primary image is not encrypted?