Re: version 2.0.2 questions

null@example.com (danielinux) — Tue, 16 Apr 2024 17:59:36 +0000

Hi Arto,

Thanks for reporting these!

- The F4 problem has been fixed now in https://github.com/wolfSSL/wolfBoot/pull/434
- The G0 warnings have been silenced with an explicit cast when retrieving the address of the flags in https://github.com/wolfSSL/wolfBoot/pull/435

We are in the process of releasing a new version (2.1.0) which will contain these fix.

- Regarding the H7 issues they might be indeed small differences in the configuration between the two models. There is a .gdbinit that automatically loads both wolfboot + the test application so you can debug across staging. Please let us know if we can assist further, and adapt the port to support your model. I'd suggest we continue the conversation through our support ticketing system. Feel free to send an email to support at wolfssl.com with as many details you can share about UART3 initialization failure.

Kind Regards,

--
Daniele - wolfSSL

Re: version 2.0.2 questions

null@example.com (arkaksi) — Mon, 15 Apr 2024 19:57:07 +0000

Hello David,

My company has (already) decided to use wolfSSL components, provided that we manage to get them integrated in our products.

I am trying to evaluate the package, and for that I downloaded the latest release 2.0.2 and the accoutrements.

My initial build environment was WSL, but for several reasons, I am going to set up a proper Debian machine.

The first phase is to get the package built and to explore the provided examples: I have begun with the test-app in the release.
Later on I will try out the provided examples in the wolfSSL-examples repository.

We have currently eight STM32 families in active production: F0,F2,F3,F4,G0,H7,L1,L4, with L5 superseding L1 after rewriting (SPL code) for L5 (LL code). L1 is the odd-ball in the portfolio, so I was not surprised to find that you do not have support for it.
Of these families, F4 is the most important, it has been our mainstream controller in many products.

I started by trying to build the package for all of the pertinent controller families (with the configurations in the config/examples -directory and also with make config).
Selected four families for which I had suitable test hardware: F4,G0,H7,L5

The build environment uses a few months old Debian release, latest gcc and tools. I am having some trouble setting a reliable connection to the progrmm

All of the following concentrate on the provided test-app

F4
We use at least STM32F407, STM32F437/STM32F439, STM32F467/STM32F469; all with maximum available memory.
Using Keil MCBSTM32F400 w/ STM32F407 as a test board.

Tried to build this by copying config/examples/stm32f4.config -> .config (in the wolfBoot root).
Below is the entire output produced the build process:

make distclean
make all

make -C tools/bin-assemble/
make[1]: Entering directory '/home/r2/wolfboot-2.0.2/tools/bin-assemble'
gcc -D"WOLFBOOT_SIGN_ED25519" -D"FILL_BYTE=0xFF" -Os -D"WOLFBOOT_HASH_SHA256" -DIMAGE_HEADER_SIZE=256  -Wall -g -ggdb   -c -o bin-assemble.o bin-assemble.c
make[1]: Leaving directory '/home/r2/wolfboot-2.0.2/tools/bin-assemble'
        [CC-ARM] hal/stm32f4.o
        [CC-ARM] src/string.o
        [CC-ARM] src/image.o
        [CC-ARM] src/libwolfboot.o
make[1]: Entering directory '/home/r2/wolfboot-2.0.2'
Building key tools
make[2]: Entering directory '/home/r2/wolfboot-2.0.2/tools/keytools'
make[2]: Leaving directory '/home/r2/wolfboot-2.0.2/tools/keytools'
make[2]: Entering directory '/home/r2/wolfboot-2.0.2/tools/keytools'
Building signing tool
Building keygen tool
make[2]: Leaving directory '/home/r2/wolfboot-2.0.2/tools/keytools'
make[1]: Leaving directory '/home/r2/wolfboot-2.0.2'
Keytype: ED25519
Generating key (type: ED25519)
Associated key file:   wolfboot_signing_private_key.der
Partition ids mask:   ffffffff
Key type   :           ED25519
Public key slot:       0
Done.
        [CC-ARM] src/keystore.o
        [CC-ARM] src/loader.o
        [CC-ARM] src/boot_arm.o
        [CC-ARM] src/update_flash.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/sha256.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/asn.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/sha512.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/ed25519.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/ge_low_mem.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/hash.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/wolfmath.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/wc_port.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/fe_low_mem.o
        [LD] wolfboot.elf
./hal/stm32f4.o ./src/string.o ./src/image.o ./src/libwolfboot.o ./src/keystore.o ./src/loader.o src/boot_arm.o ./src/update_flash.o ./lib/wolfssl/wolfcrypt/src/sha256.o ./lib/wolfssl/wolfcrypt/src/asn.o ./lib/wolfssl/wolfcrypt/src/sha512.o ./lib/wolfssl/wolfcrypt/src/ed25519.o ./lib/wolfssl/wolfcrypt/src/ge_low_mem.o ./lib/wolfssl/wolfcrypt/src/hash.o ./lib/wolfssl/wolfcrypt/src/wolfmath.o ./lib/wolfssl/wolfcrypt/src/wc_port.o ./lib/wolfssl/wolfcrypt/src/fe_low_mem.o
        [BIN] wolfboot.bin

        [SIZE]
   text    data     bss     dec     hex filename
  11096       0      40   11136    2b80 wolfboot.elf

make[1]: Entering directory '/home/r2/wolfboot-2.0.2/test-app'
        [CC-ARM] app_stm32f4.o
        [CC-ARM] led.o
        [CC-ARM] system.o
        [CC-ARM] timer.o
        [CC-ARM] ../test-app/libwolfboot.o
        [CC-ARM] startup_arm.o
        [LD] image.elf
/usr/lib/gcc/arm-none-eabi/13.2.1/../../../arm-none-eabi/bin/ld: section .ARM.exidx LMA [08020fc8,08020fcf] overlaps section .data LMA [08020fc8,0802150f]
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:340: image.elf] Error 1
make[1]: Leaving directory '/home/r2/wolfboot-2.0.2/test-app'
make: *** [Makefile:147: test-app/image.bin] Error 2

This has just a minor overlap in the linking phase, but it prevents the binary to be built.
It appears that the F4 uses the 'oldest' of the linking scripts (possibly ARM.ld), combining several families together.

G0
From what I remember, we use at least STM32G031 and STMG071
Using NUCLEO-G070RB as a test board.

Tried to build this by copying config/examples/stm32g0.config -> .config (in the wolfBoot root).
Below is the entire output produced the build process:

make distclean
make all

make -C tools/bin-assemble/
make[1]: Entering directory '/home/r2/wolfboot-2.0.2/tools/bin-assemble'
gcc -D"WOLFBOOT_SIGN_ED25519" -D"RAM_CODE" -D"FILL_BYTE=0xFF" -D"NVM_FLASH_WRITEONCE" -Os -D"WOLFBOOT_HASH_SHA256" -DIMAGE_HEADER_SIZE=256  -Wall -g -ggdb   -c -o bin-assemble.o bin-assemble.c
make[1]: Leaving directory '/home/r2/wolfboot-2.0.2/tools/bin-assemble'
        [CC-ARM] hal/stm32g0.o
        [CC-ARM] src/string.o
        [CC-ARM] src/image.o
        [CC-ARM] src/libwolfboot.o
make[1]: Entering directory '/home/r2/wolfboot-2.0.2'
Building key tools
make[2]: Entering directory '/home/r2/wolfboot-2.0.2/tools/keytools'
make[2]: Leaving directory '/home/r2/wolfboot-2.0.2/tools/keytools'
make[2]: Entering directory '/home/r2/wolfboot-2.0.2/tools/keytools'
Building signing tool
Building keygen tool
make[2]: Leaving directory '/home/r2/wolfboot-2.0.2/tools/keytools'
make[1]: Leaving directory '/home/r2/wolfboot-2.0.2'
Keytype: ED25519
Generating key (type: ED25519)
Associated key file:   wolfboot_signing_private_key.der
Partition ids mask:   ffffffff
Key type   :           ED25519
Public key slot:       0
Done.
        [CC-ARM] src/keystore.o
        [CC-ARM] src/loader.o
        [CC-ARM] src/boot_arm.o
        [CC-ARM] src/update_flash.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/sha256.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/asn.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/sha512.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/ed25519.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/ge_low_mem.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/hash.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/wolfmath.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/wc_port.o
        [CC-ARM] lib/wolfssl/wolfcrypt/src/fe_low_mem.o
        [LD] wolfboot.elf
./hal/stm32g0.o ./src/string.o ./src/image.o ./src/libwolfboot.o ./src/keystore.o ./src/loader.o src/boot_arm.o ./src/update_flash.o ./lib/wolfssl/wolfcrypt/src/sha256.o ./lib/wolfssl/wolfcrypt/src/asn.o ./lib/wolfssl/wolfcrypt/src/sha512.o ./lib/wolfssl/wolfcrypt/src/ed25519.o ./lib/wolfssl/wolfcrypt/src/ge_low_mem.o ./lib/wolfssl/wolfcrypt/src/hash.o ./lib/wolfssl/wolfcrypt/src/wolfmath.o ./lib/wolfssl/wolfcrypt/src/wc_port.o ./lib/wolfssl/wolfcrypt/src/fe_low_mem.o
        [BIN] wolfboot.bin

        [SIZE]
   text    data     bss     dec     hex filename
  12568       0    2104   14672    3950 wolfboot.elf

make[1]: Entering directory '/home/r2/wolfboot-2.0.2/test-app'
        [CC-ARM] app_stm32g0.o
        [CC-ARM] led.o
        [CC-ARM] system.o
        [CC-ARM] timer.o
        [CC-ARM] ../test-app/libwolfboot.o
../src/libwolfboot.c: In function 'nvm_select_fresh_sector':
../src/libwolfboot.c:243:12: warning: array subscript -1 is outside array bounds of 'uint8_t[2147483647]' {aka 'unsigned char[2147483647]'} [-Warray-bounds=]
  243 |     word_0 = *((uint32_t*)(base - sizeof(uint32_t)));
      |     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/libwolfboot.c:244:12: warning: array subscript -513 is outside array bounds of 'uint8_t[2147483647]' {aka 'unsigned char[2147483647]'} [-Warray-bounds=]
  244 |     word_1 = *((uint32_t*)(base - WOLFBOOT_SECTOR_SIZE - sizeof(uint32_t)));
      |     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        [CC-ARM] startup_arm.o
        [LD] image.elf
        [BIN] image.bin
make[1]: Leaving directory '/home/r2/wolfboot-2.0.2/test-app'
   text    data     bss     dec     hex filename
   2380       0     324    2704     a90 test-app/image.elf
        [SIGN] test-app/image.bin
wolfBoot KeyTools (Compiled C version)
wolfBoot version 2000002
Update type:          Firmware
Input image:          test-app/image.bin
Selected cipher:      ED25519
Selected hash  :      SHA256
Public key:           wolfboot_signing_private_key.der
Output  image:        test-app/image_v1_signed.bin
Target partition id : 1
Found ed25519 key
image header size calculated at runtime (256 bytes)
Calculating SHA256 digest...
Signing the digest...
Output image(s) successfully created.
        [MERGE] factory.bin
        Added        12568 bytes at 0x08000000 from wolfboot.bin
        Added        20200 bytes of 0xff fill
        Added         2636 bytes at 0x08008000 from test-app/image_v1_signed.bin

This build is otherwise ok, but the warnings about the out-of-bounds indices are somewhat ominous.

H7
We currently use STM32H7A3 and STM32H7B3.
Using NUCLEO-H743ZI as a test board (identical to NUCLEO-H753ZI [checked], except for crypto peripherals)

The build was successful. I transferred the binary to the board; it launched ok, or nearly.
The middle led stays unlit, indicating that the initialization of USART3 failed.
I'll need to setup remote GDB to find out what went wrong.
The two other LEDs are lit after reset, indicating that the boot was successful.

It would be greatly appreciated, if you could help us out with these minor issues in this otherwise fine product.
Your components fit nicely in our functional-safety-first architecture.

Respectfully yours,
Arto Kallio, Hedengren R&D

Re: version 2.0.2 questions

null@example.com (dgarske) — Mon, 15 Apr 2024 17:09:21 +0000

Hi Arto,

Thank you for your interest in wolfBoot on the STM32. Which STM32 part are you trying to evaluate for?

We have automated testing that builds and runs most of the supported targets, so I am surprised you had issues. I will specifically try and reproduce the STM32G0 and STM32F4 issues.

We provide example configurations in config/examples that are good starting points, but typically you need some customizing for your specific part. The test-apps are really just for testing to demonstrate and can be useful for showing how to adjust your application to support the signed image header.

We will also reach out directly as we'd like to here about your project and how we can support you.

Thanks,
David Garske, wolfSSL

version 2.0.2 questions

null@example.com (arkaksi) — Sun, 14 Apr 2024 17:54:29 +0000

hello all,

trying to evaluate the product, using wolfBoot version 2.0.2 and gcc-arm-none-eabi (gcc 13.2.1) toolchain.

using preconfigured configuration files (from config/examples) for now, just to get started.

compilation of STM32H7 and STM32L5 targets were successful.

STM32G0 compilation gives warnings about negative array indices.

STM32F4 might be missing something, it does not compile properly, gives error about overlapping sections; a F4-targeted linker script is not found in test-app (while H7 & L5 & G0 each have their own scripts).

I was sort of expecting the provided examples to work out-of-the-box. any idea what could be wrong, do I _need_ to use 'make config'?

wolfSSL - Embedded SSL Library — version 2.0.2 questions

Re: version 2.0.2 questions

Re: version 2.0.2 questions

Re: version 2.0.2 questions

version 2.0.2 questions