Different Fail Points Building MCUBoot With Different Zephyr Sources

RE: Different Fail Points Building MCUBoot With Different Zephyr Sources

MikeInAtlanta — Thu, 30 Dec 2021 22:34:41 GMT

I had the identical error when trying to make MCUBOOT for the nrf52840 Dongle under Zephyr 2.7 and was able to fix the root problem. I used the mcuboot disty that came with the Zephyr install (bootloader\mcuboot).

After getting this error

  from /home/miked/proj/partworks/sw/zephyr/bootloader/mcuboot/boot/zephyr/serial_adapter.c:18:
/home/miked/proj/partworks/sw/zephyr/bootloader/mcuboot/boot/zephyr/serial_adapter.c: In function 'boot_uart_fifo_init':
/home/miked/proj/partworks/sw/zephyr/zephyr/include/sys/util.h:78:55: error: size of unnamed array is negative
 78 | #define ZERO_OR_COMPILE_ERROR(cond) ((int) sizeof(char[1 - 2 * !(cond)]) - 1)
 | ^
/home/miked/proj/partworks/sw/zephyr/zephyr/include/sys/util_internal.h:67:26: note: in definition of macro '__DEBRACKE
'
 67 | #define __DEBRACKET(...) __VA_ARGS__
 | ^~~~~~~~~~~
/home/miked/proj/partworks/sw/zephyr/zephyr/include/sys/util_internal.h:59:2: note: in expansion of macro '__GET_ARG2_DEBRACKET'
 59 | __GET_ARG2_DEBRACKET(one_or_two_args _if_code, _else_code)
 | ^~~~~~~~~~~~~~~~~~~~
/home/miked/proj/partworks/sw/zephyr/zephyr/include/sys/util_internal.h:54:2: note: in expansion of macro '__COND_CODE'
 54 | __COND_CODE(_XXXX##_flag, _if_1_code, _else_code)
 | ^~~~~~~~~~~
/home/miked/proj/partworks/sw/zephyr/zephyr/include/sys/util_macro.h:157:2: note: in expansion of macro 'Z_COND_CODE_1'
 157 | Z_COND_CODE_1(_flag, _if_1_code, _else_code)
 | ^~~~~~~~~~~~~
/home/miked/proj/partworks/sw/zephyr/zephyr/include/device.h:368:2: note: in expansion of macro 'COND_CODE_1'
 368 | COND_CODE_1(DT_HAS_COMPAT_STATUS_OKAY(compat), \
 | ^~~~~~~~~~~
/home/miked/proj/partworks/sw/zephyr/zephyr/include/device.h:370:8: note: in expansion of macro 'ZERO_OR_COMPILE_ERROR'
 370 | (ZERO_OR_COMPILE_ERROR(0)))
 | ^~~~~~~~~~~~~~~~~~~~~
/home/miked/proj/partworks/sw/zephyr/bootloader/mcuboot/boot/zephyr/serial_adapter.c:197:13: note: in expansion of macro 'DEVICE_DT_GET_ONE'
 197 | uart_dev = DEVICE_DT_GET_ONE(zephyr_cdc_acm_uart);
 | ^~~~~~~~~~~~~~~~~
[118/285] Building C object zephyr/arch/arch/arm/core/aarc...CMakeFiles/arch__arm__core__aarch32__mpu.dir/arm_mpu.c.obj

I found a clue at https://github.com/mcu-tools/mcuboot/issues/1127 that said that with Zephyr >= 2.7 they moved the cdc acm uart from the config files to devicetree. So I added a nrf52840dongle_nrf52840.overlay file with the following (see https://github.com/mcu-tools/mcuboot/blob/main/boot/zephyr/usb_cdc_acm.overlay)

&zephyr_udc0 {
  cdc_acm_uart0 {  
  compatible = "zephyr,cdc-acm-uart";
  label = "CDC_ACM_0";
  };
};

That allowed me to compile and use MCUBOOT on Zephyr with the nrf52840 Dongle.

RE: Different Fail Points Building MCUBoot With Different Zephyr Sources

vindicator — Tue, 12 Oct 2021 14:10:02 GMT

Welp, I ended up downloading the entire 2GB's-worth of modules. That was disappointing that it was needed because from the warnings/errors, it couldn't be determined what was missing.

I'm thinking it's TFM that I was missing since I do see that as one module that is included.

The build works now and I see mcuboot is expected to take up 90% of flash memory.

I'll still be trying to explore how to cut it all down (mcuboot size as well as modules that are actually used). I know about the doc regarding decreasing the flash size.

Yeah, I know about the 1.8V/3.0V warning. I've fried my old odroid some years ago because I switched the jumper incorrectly (inattention) for my usb uart.

I'm archiving(/compressing) the modules folder so I'll have it if I still need any other missing modules in the future when I cut things down.

I swear I just don't get why west/cmake throws every module in the build folder (listed in zephyr_modules.txt and elsewhere) when I specifically state the BOARD for my dongle and the project that it is going to build.

Even when I add 'message(STATUS "${COMMON_KCONFIG_ENV_SETTINGS}")' after it gets set in zephyr/cmake/kconfig.cmake, all of those *_MODULE_DIRs get added. I mean, I have no interest in cypress for example. I'm guessing everything is included in case someone needs something via menuconfig. But again, it makes no sense to have cypress/ti/st/atmel if I'm using nordic.

EDIT0: OH! Okay, so apparently I was already fine with the modules. But when I changed from sdk-zephyr to mainline zephyr, the USB issue cropped up again. I'll have to see what's different there.

RE: Different Fail Points Building MCUBoot With Different Zephyr Sources

Einar Thorsrud — Tue, 12 Oct 2021 12:37:34 GMT

[quote user="vindicator"]EDIT0: I should also say, I don't know why you mentioned that link to "get a working toolchain" when my first test in my OP showed I was using the zephyr toolchain (arm-zephyr-eabi-gcc (crosstool-NG 1.24.0.378_e011758) 10.3.0). Or is that not valid?[/quote]

You are free to use it, bu tit is not supported by Nordic semiconductor.

[quote user="vindicator"]Also what does "does not work well" regarding the bootloader supposed to mean? It looks like the dongle has a general bootloader that is run by pressing the "reset" button. My understanding is that mcuboot would be flashed like a regular app and, once installed, becomes flashable for other apps to run on top of it.[/quote]

I guess everything is a regular app in some ways. It is certainly possible to use MCUBoot as a second bootloader after the nRF5 SDK based USB bootloader on the dongle, but it causes a bit of problems and is not supported. I would recommend to avoid it.

[quote user="vindicator"]It also appears the dongle has 2 soldering pad areas for flash/debug. It's on my mind that I'll likely get a header and a cable to connect them to my SWD-capable ST Discovery device.[/quote]

Note sure about the ST device, but any SWD debugger will let you program and debug it, yes. Note that you may have problems with the VDD voltage then, as described for instance in the last part of this old tutorial.

RE: Different Fail Points Building MCUBoot With Different Zephyr Sources

vindicator — Tue, 12 Oct 2021 09:42:59 GMT

I'll just put it out there that the way I'm doing it should also work, but something is off when I'm using "-DZEPHYR_MODULES":

$ /usr/bin/cmake -DWEST_PYTHON=/usr/bin/python -B<pathTo>/build -S<pathTo>/zephyr/samples/net/mqtt_publisher -GNinja -DBOARD=nrf52840dongle_nrf52840 2>&1 | grep here
-- here PYTHON_EXECUTABLE=/usr/bin/python3.9;srctree=<pathTo>/zephyr;KERNELVERSION=0x2076300;KCONFIG_CONFIG=<pathTo>/build/zephyr/.config;ARCH=arm;ARCH_DIR=<pathTo>/zephyr/arch;BOARD_DIR=<pathTo>/zephyr/boards/arm/nrf52840dongle_nrf52840;KCONFIG_BINARY_DIR=<pathTo>/build/Kconfig;TOOLCHAIN_KCONFIG_DIR=<pathTo>/zephyr/cmake/toolchain/gnuarmemb;TOOLCHAIN_HAS_NEWLIB=$<IF:$<BOOL:ON>,y,n>;EDT_PICKLE=<pathTo>/build/zephyr/edt.pickle;ZEPHYR_CMSIS_MODULE_DIR=<pathTo>/modules/hal/cmsis;ZEPHYR_HAL_NORDIC_MODULE_DIR=<pathTo>/modules/hal/nordic;ZEPHYR_HAL_NORDIC_KCONFIG=<pathTo>/zephyr/modules/hal_nordic/Kconfig;ZEPHYR_MBEDTLS_MODULE_DIR=<pathTo>/modules/crypto/mbedtls;ZEPHYR_MBEDTLS_KCONFIG=<pathTo>/zephyr/modules/mbedtls/Kconfig 

$ rm -rf build 
$ /usr/bin/cmake -DWEST_PYTHON=/usr/bin/python -B<pathTo>/build -S<pathTo>/zephyr/samples/net/mqtt_publisher -GNinja -DBOARD=nrf52840dongle_nrf52840 -DZEPHYR_MODULES="<pathTo>/modules/hal/nordic/;<pathTo>/zephyr_cmsis/;<pathTo>/zephyr_mbedtls/" 2>&1 | grep here 
-- here PYTHON_EXECUTABLE=/usr/bin/python3.9;srctree=<pathTo>/zephyr;KERNELVERSION=0x2076300;KCONFIG_CONFIG=<pathTo>/build/zephyr/.config;ARCH=arm;ARCH_DIR=<pathTo>/zephyr/arch;BOARD_DIR=<pathTo>/zephyr/boards/arm/nrf52840dongle_nrf52840;KCONFIG_BINARY_DIR=<pathTo>/build/Kconfig;TOOLCHAIN_KCONFIG_DIR=<pathTo>/zephyr/cmake/toolchain/gnuarmemb;TOOLCHAIN_HAS_NEWLIB=$<IF:$<BOOL:ON>,y,n>;EDT_PICKLE=<pathTo>/build/zephyr/edt.pickle;ZEPHYR_HAL_NORDIC_MODULE_DIR=<pathTo>/ARM/Nordic/hal_nordic;ZEPHYR_HAL_NORDIC_KCONFIG=<pathTo>/zephyr/modules/hal_nordic/Kconfig;ZEPHYR_ZEPHYR_CMSIS_MODULE_DIR=<pathTo>/ARM/zephyr_cmsis;ZEPHYR_ZEPHYR_MBEDTLS_MODULE_DIR=<pathTo>/ARM/zephyr_mbedtls

The first command is the command issued when using "west" (which works).

The second command is my alteration of west's "cmake" command where I use -DZEPHYR_MODULES.

Note the difference in the names for each command output:

1: ZEPHYR_CMSIS_MODULE_DIR
2: ZEPHYR_ZEPHYR_CMSIS_MODULE_DIR

1: ZEPHYR_HAL_NORDIC_MODULE_DIR
2: ZEPHYR_HAL_NORDIC_MODULE_DIR

1: ZEPHYR_HAL_NORDIC_KCONFIG
2: ZEPHYR_HAL_NORDIC_KCONFIG

1: ZEPHYR_MBEDTLS_MODULE_DIR
2: ZEPHYR_ZEPHYR_MBEDTLS_MODULE_DIR

1: ZEPHYR_MBEDTLS_KCONFIG
2: <non-existant because it errors out>

What is up with the "ZEPHYR_ZEPHYR_" instances for the second command?

Oh wow! I just found out. It's because whatever script is in charge of naming those variables are actually taking the folder names.

For example, I changed "zephyr_cmsis" to "wtf_cmsis" and the variable name changed to "ZEPHYR_WTF_CMSIS_MODULE_DIR".

That bites because I'm wanting to control my folder structure.

It SHOULD be enough that I just provide the path and the script should be going through the provided paths, looking for something like "export(PACKAGE MbedTLS)" in the CMakeLists.txt and set the associated name with that (<ZephyrProjectName>_<ExportedModuleName>_MODULE_DIR".

At least I know what's up with that now. Perhaps a bug I should report in mainline? Whether it be for how I say it should behave or it be clearly defined in the docs about module-path-naming (I hope I didn't miss it if it did)?

EDIT0: I should also say, I don't know why you mentioned that link to "get a working toolchain" when my first test in my OP showed I was using the zephyr toolchain (arm-zephyr-eabi-gcc (crosstool-NG 1.24.0.378_e011758) 10.3.0). Or is that not valid?

I've also been able to build/flash/run the button/LED sample using the arm-none-eabi- toolchain, so it should have nothing to do with the toolchain given that worked.

Also what does "does not work well" regarding the bootloader supposed to mean? It looks like the dongle has a general bootloader that is run by pressing the "reset" button. My understanding is that mcuboot would be flashed like a regular app and, once installed, becomes flashable for other apps to run on top of it.

It also appears the dongle has 2 soldering pad areas for flash/debug. It's on my mind that I'll likely get a header and a cable to connect them to my SWD-capable ST Discovery device.

RE: Different Fail Points Building MCUBoot With Different Zephyr Sources

Einar Thorsrud — Mon, 11 Oct 2021 12:54:00 GMT

Hi,

Please follow the instructions for installing the nRF Connect SDK manually to the point. That should give you a working toolchain and then example applications should build out of the box when you build using west.

I see you are using the nRF52840 dongle. Please note that this has a USB bootloader from the nRF5 SDK, and does not work well together with MCUBoot. I recommend testing without MCUBoot if you are using the dongle, or use a development kit instead (that is typically a better choice in most cases, particularly because of the onboard debugger).

RE: Different Fail Points Building MCUBoot With Different Zephyr Sources

vindicator — Mon, 11 Oct 2021 12:39:19 GMT

While I got it to build and I flashed it, my device doesn't show up when I plug it in with SW0 pressed.

The system journal/dmesg doesn't even show any activity from its insertion.

Just to make sure, I used the same build/zip/flash commands to build samples/basic/button, and that ran and the LED lights up when I press SW0.

As probably expected, the"button" sample doesn't show up as a device either.

When I press the "reset" button, the device shows up as "/dev/serial/by-id/usb-Nordic_Semiconductor_Open_DFU_Bootloader_<sanitized>-if00". I know the mcuboot should show up similar to that, except have the name mcuboot contained within it.

EDIT0: Ugh! Ignore this dummy. I shouldn't have been trying to run that sample I think. Next attempt coming...