• State Not Answered
  • Replies 6 replies
  • Subscribers 90 subscribers
  • Views 4246 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 277779
Options

Different Fail Points Building MCUBoot With Different Zephyr Sources

vindicator

I've got the zephyr sources for https://github.com/nrfconnect/sdk-zephyr.git and https://github.com/zephyrproject-rtos/zephyr (everything I get is master/main)

$ west init -l zephyr/
 //zephyr-project version
$ west --verbose update -o=--depth=1 -n --fetch=smart --path-cache=. hal_nordic cmsis mcuboot mbedtls
$ ZEPHYR_TOOLCHAIN_VARIANT=zephyr ZEPHYR_SDK_INSTALL_DIR=<pathTo>/toolchain/ west build --build-dir ./build/mcuboot --board nrf52840dongle_nrf52840 --pristine=always bootloader/mcuboot/boot/zephyr/ -DCONFIG_USB_DEVICE_VID=<#> -DCONFIG_USB_DEVICE_PID=<#>

This fails with:

[58/280] Building C object zephyr/CMakeFiles/zephyr.dir/...rdic/bootloader/mcuboot/boot/zephyr/serial_adapter.c.obj
FAILED: zephyr/CMakeFiles/zephyr.dir<pathTo>/bootloader/mcuboot/boot/zephyr/serial_adapter.c.obj 
<pathTo>/toolchain/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DBUILD_VERSION=a81f8af70173 -DKERNEL -DNRF52840_XXAA -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I<pathTo>/zephyr/kernel/include -I<pathTo>/zephyr/arch/arm/include -I<pathTo>/zephyr/include -I<pathTo>/build/mcuboot/zephyr/include/generated -I<pathTo>/zephyr/soc/arm/nordic_nrf/nrf52 -I<pathTo>/zephyr/subsys/usb -I<pathTo>/modules/hal/cmsis/CMSIS/Core/Include -I<pathTo>/modules/hal/nordic/nrfx -I<pathTo>/modules/hal/nordic/nrfx/drivers/include -I<pathTo>/modules/hal/nordic/nrfx/mdk -I<pathTo>/zephyr/modules/hal_nordic/nrfx/. -I<pathTo>/bootloader/mcuboot/boot/zephyr/include -I<pathTo>/bootloader/mcuboot/boot/bootutil/include -I<pathTo>/bootloader/mcuboot/boot/boot_serial/include -I<pathTo>/bootloader/mcuboot/boot/bootutil/src -I<pathTo>/bootloader/mcuboot/boot/bootutil/zephyr/.. -I<pathTo>/bootloader/mcuboot/boot/bootutil/zephyr/../include -I<pathTo>/bootloader/mcuboot/boot/bootutil/zephyr/../../zephyr/include -isystem <pathTo>/zephyr/lib/libc/minimal/include -isystem <pathTo>/toolchain/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.3.0/include -isystem <pathTo>/toolchain/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.3.0/include-fixed -Os -imacros <pathTo>/build/mcuboot/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m4 -mthumb -mabi=aapcs -mfp16-format=ieee -imacros <pathTo>/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=<pathTo>/bootloader/mcuboot/boot/zephyr=CMAKE_SOURCE_DIR -fmacro-prefix-map=<pathTo>/zephyr=ZEPHYR_BASE -fmacro-prefix-map=<pathTo>=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT zephyr/CMakeFiles/zephyr.dir<pathTo>/bootloader/mcuboot/boot/zephyr/serial_adapter.c.obj -MF zephyr/CMakeFiles/zephyr.dir<pathTo>/bootloader/mcuboot/boot/zephyr/serial_adapter.c.obj.d -o zephyr/CMakeFiles/zephyr.dir<pathTo>/bootloader/mcuboot/boot/zephyr/serial_adapter.c.obj -c <pathTo>/bootloader/mcuboot/boot/zephyr/serial_adapter.c
In file included from <pathTo>/zephyr/include/sys/util_macro.h:34,
 from <pathTo>/zephyr/include/sys/util.h:17,
 from <pathTo>/zephyr/include/kernel/sched_priq.h:9,
 from <pathTo>/zephyr/include/kernel_includes.h:23,
 from <pathTo>/zephyr/include/kernel.h:17,
 from <pathTo>/zephyr/include/init.h:11,
 from <pathTo>/zephyr/include/device.h:29,
 from <pathTo>/zephyr/include/drivers/uart.h:26,
 from <pathTo>/bootloader/mcuboot/boot/zephyr/serial_adapter.c:18:
<pathTo>/bootloader/mcuboot/boot/zephyr/serial_adapter.c: In function 'boot_uart_fifo_init':
<pathTo>/zephyr/include/sys/util.h:62:55: error: size of unnamed array is negative
 62 | #define ZERO_OR_COMPILE_ERROR(cond) ((int) sizeof(char[1 - 2 * !(cond)]) - 1)
 | ^
<pathTo>/zephyr/include/sys/util_internal.h:67:26: note: in definition of macro '__DEBRACKET'
 67 | #define __DEBRACKET(...) __VA_ARGS__
 | ^~~~~~~~~~~
<pathTo>/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)
 | ^~~~~~~~~~~~~~~~~~~~
<pathTo>/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)
 | ^~~~~~~~~~~
<pathTo>/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)
 | ^~~~~~~~~~~~~
<pathTo>/zephyr/include/device.h:300:2: note: in expansion of macro 'COND_CODE_1'
 300 | COND_CODE_1(DT_HAS_COMPAT_STATUS_OKAY(compat), \
 | ^~~~~~~~~~~
<pathTo>/zephyr/include/device.h:302:8: note: in expansion of macro 'ZERO_OR_COMPILE_ERROR'
 302 | (ZERO_OR_COMPILE_ERROR(0)))
 | ^~~~~~~~~~~~~~~~~~~~~
<pathTo>/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);
 | ^~~~~~~~~~~~~~~~~
[63/280] Building C object zephyr/CMakeFiles/zephyr.dir/subsys/usb/usb_device.c.obj

Okay, this freaking editor is torquing me off! I select text, set the format to "pre", go to start a new paragraph and change the format back to "paragraph" and it changes the previous "pre" as well.
It's inconsistent too as demonstrated by the changes between the texts at the top that are "paragraph/pre". It seems changing the "Font" by itself is enough. Nope. Changing the source-code it is then. Ah, finally!

Okay, after that error, I rename/move the zephyr directory and rename the sdk-zephyr directory to zephyr and run the same build command, resulting in:

-- Including generated dts.cmake file: <pathTo>/build/mcuboot/zephyr/dts.cmake

warning: CONSOLE_HANDLER (defined at drivers/console/Kconfig:39) was assigned the value 'y' but got
the value 'n'. Check these unsatisfied dependencies: UART_CONSOLE (=n). See
docs.zephyrproject.org/.../CONFIG_CONSOLE_HANDLER.html and/or look up
CONSOLE_HANDLER in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.


warning: LOG_DEFAULT_LEVEL (defined at subsys/logging/Kconfig.filtering:13) was assigned the value
'0' but got the value ''. Check these unsatisfied dependencies: LOG (=n). See
docs.zephyrproject.org/.../CONFIG_LOG_DEFAULT_LEVEL.html and/or look up
LOG_DEFAULT_LEVEL in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.


warning: The choice symbol LOG_MODE_MINIMAL (defined at subsys/logging/Kconfig.mode:45) was selected
(set =y), but no symbol ended up as the choice selection. See
docs.zephyrproject.org/.../CONFIG_LOG_MODE_MINIMAL.html and/or look up
LOG_MODE_MINIMAL in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.


warning: USB_DEVICE_STACK (defined at boards/arm/nrf52840dongle_nrf52840/Kconfig.defconfig:32, subsys/usb/Kconfig:6) has direct dependencies (USB && BOARD_NRF52840DONGLE_NRF52840) || USB_DEVICE_DRIVER || ARCH_POSIX with value n, but is currently being y-selected by the following symbols:
 - BOOT_SERIAL_CDC_ACM (defined at <pathTo>/bootloader/mcuboot/boot/zephyr/Kconfig:486), with value y, direct dependencies <choice> (value: y), and select condition <choice> (value: y)
Parsing <pathTo>/bootloader/mcuboot/boot/zephyr/Kconfig
Loaded configuration '<pathTo>/zephyr/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840_defconfig'
Merged configuration '<pathTo>/bootloader/mcuboot/boot/zephyr/prj.conf'
Merged configuration '<pathTo>/bootloader/mcuboot/boot/zephyr/boards/nrf52840dongle_nrf52840.conf'
Merged configuration '<pathTo>/build/mcuboot/zephyr/misc/generated/extra_kconfig_options.conf'

error: Aborting due to Kconfig warnings

Here we see it is also related to UART/CDC/ACM. Not quite sure why this is happening as doc/_build/html/boards/arm/nrf52840dongle_nrf52840/doc/index.html shows mcuboot being used in "Option 2".

EDIT0: I dropped west and went with custom attempts again and it's working for me now:

$ cmake -B./build -S./samples/zephyr/hello-world/ -GNinja -DBOARD=nrf52840dongle_nrf52840 -DCMAKE_C_FLAGS="--specs=nosys.specs" -DCMAKE_CXX_FLAGS="--specs=nosys.specs" -DZEPHYR_MODULES="<pathTo>/hal_nordic/;<pathTo>/zephyr_cmsis"
$ cmake --build ./build --target zephyr_final

EDIT1: Oh, and this was using mainline zephyr and hal_nordic from the zephyrproject-rtos repository. I tried building using mainline ARM CMSIS, but found that the zephyr CMSIS has a bunch of custom CMakeLists.txt and who knows what else, so I stuck with zephyr's version.

Parents
  • 0

    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).

  • 0 in reply to Einar Thorsrud

    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.

  • 0 in reply to vindicator
    vindicator said:
    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?

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

    vindicator said:
    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.

    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.

    vindicator said:
    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.

    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.

Reply
  • 0 in reply to vindicator
    vindicator said:
    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?

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

    vindicator said:
    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.

    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.

    vindicator said:
    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.

    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.

Children
  • 0 in reply to Einar Thorsrud

    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.

Related