Build failure for Giga R1 WiFi (

[schnoberts1]

I noted the instructions:

mbed config root . && mbed deploy
mbed compile -m PORTENTA_H7_M7 -t GCC_ARM --profile=release --profile custom.json

and read the MBED Studio issue (which I am not using) so came up with this:

Install mbed-cli like this:

pip3 install -q -r https://raw.githubusercontent.com/ARMmbed/mbed-os/master/requirements.txt
python3 -m pip install -q mbed-cli

Build like this:

mbed config root -G "${repo_dir}/compilers/gcc-arm-none-eabi-7-2018-q2-update"  . && mbed deploy
mbed compile -c -m GIGA -t GCC_ARM --app=mbed_app_giga_wifi.json --profile=custom.json -N mcuboot_giga_wifi

The compiler referenced is the one used in the Arduino IDE I was using, and it produces bit identical output compared with the IDE.

The result:

[Warning] main.cpp@221,12: 'MEM[(struct boot_rsp *)&rsp].br_image_off' may be used uninitialized in this function [-Wmaybe-uninitialized]
./app/main.cpp: In function 'main':
./app/main.cpp:221:12: warning: 'MEM[(struct boot_rsp *)&rsp].br_image_off' may be used uninitialized in this function [-Wmaybe-uninitialized]
   uint32_t address = rsp.br_image_off + rsp.br_hdr->ih_hdr_size;
            ^
./app/main.cpp:210:19: note: 'MEM[(struct boot_rsp *)&rsp].br_image_off' was declared here
   struct boot_rsp rsp;
                   ^
/home/andy/code/dbc/test/compilers/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5/softfp/libc_nano.a(lib_a-calloc.o): In function `calloc':
calloc.c:(.text.calloc+0x8): undefined reference to `__wrap__calloc_r'
collect2: error: ld returned 1 exit status
[ERROR] ./app/main.cpp: In function 'main':
./app/main.cpp:221:12: warning: 'MEM[(struct boot_rsp *)&rsp].br_image_off' may be used uninitialized in this function [-Wmaybe-uninitialized]
   uint32_t address = rsp.br_image_off + rsp.br_hdr->ih_hdr_size;
            ^
./app/main.cpp:210:19: note: 'MEM[(struct boot_rsp *)&rsp].br_image_off' was declared here
   struct boot_rsp rsp;
                   ^
/home/andy/code/dbc/test/compilers/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5/softfp/libc_nano.a(lib_a-calloc.o): In function `calloc':
calloc.c:(.text.calloc+0x8): undefined reference to `__wrap__calloc_r'
collect2: error: ld returned 1 exit status

Obviously the warnings are a bit disconcerting as they aren't suppressed in the code with a comment so I'm not sure if these are a problem. I am guessing there maybe a default initialisation assumption but not checked.

The bigger issue is the calloc link problem. Looks like it's using the nano spec, is that right?

[pennam]

Hi @schnoberts1 I'm not able to replicate your issue, but looks like is related to the custom.json profile file and to the --wrap,_calloc_r linker flag.

Which version of the mbed tool are you using? I'm using an old version i think 1.10.4

I've tested the build with gcc-arm-none-eabi-9-2019-q4-major and 7-2017q4 that is the one that comes with the arduino IDE.

[schnoberts1]

I'm using 1.10.5. I just downgraded to 1.10.4 and have the same issue so it must something about my environment.

I'm on HEAD of mcuboot-arduino-stm32h7: 370dce2

The early part of the build process looks like this:

[mbed] No global root set
[mbed] Working path "/home/andy/code/dbc/test/3rdparty/mcuboot-arduino-stm32h7" (program)
[mbed] Adding library "es/SFU/extra/mbed-os" from "https://github.com/arduino/mbed-os" at rev #d7ccde9f58b3
[mbed] Updating library "mcuboot" to rev #f53a4d0c7b86
[mbed] Updating library "mbed-os" to rev #2e1da01300f1
[mbed] WARNING: Cannot find the mbed tools directory in "/home/andy/code/dbc/test"
---
[mbed] Working path "/home/andy/code/dbc/test/3rdparty/mcuboot-arduino-stm32h7" (program)
[mbed] WARNING: Could not find mbed program in current path "/home/andy/code/dbc/test/3rdparty/mcuboot-arduino-stm32h7".
       You can fix this by calling "mbed new ." in the root of your program.

Is this what yours looks like?

I will investigate futher given you can't replicate it.

[pennam]

pennam@xps:/tmp/mcuboot-arduino-stm32h7$ mbed config root . && mbed deploy
mbed compile -m PORTENTA_H7_M7 -t GCC_ARM --profile=release --profile custom.json
[mbed] . now set as default root in program "mcuboot-arduino-stm32h7"
[mbed] Working path "/tmp/mcuboot-arduino-stm32h7" (program)
[mbed] Adding library "mbed-os" from "https://github.com/arduino/mbed-os" at rev #2e1da01300f1
[mbed] Adding library "mcuboot" from "https://github.com/arduino/mcuboot" at rev #f53a4d0c7b86
[mbed] Working path "/tmp/mcuboot-arduino-stm32h7" (program)

maybe the issue is related to this lines of your log

[mbed] No global root set
...
[mbed] WARNING: Could not find mbed program in current path "/home/andy/code/dbc/test/3rdparty/mcuboot-arduino-stm32h7".
       You can fix this by calling "mbed new ." in the root of your program.

[schnoberts1]

I'm not getting very far :). If you don't mind me asking, what process did you go through to create /tmp/mcuboot-arduino-stm32h in the first place? What do you have setup in your dev environment that makes you efficient working with these?

[pennam]

To create /tmp/mcuboot-arduino-stm32h7 I just clone the repo

cd /tmp
git clone https://github.com/arduino/mcuboot-arduino-stm32h7.git

then in my home pc i have my toolchain in /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/ and mbed tools in /opt/mbed-studio-tools/python/bin/ so I export both folders

export PATH="/opt/gcc-arm-none-eabi-9-2019-q4-major/bin/:$PATH"
export PATH="/opt/mbed-studio-tools/python/bin/:$PATH"

and to build i use the commands in the readme or in the generate_rel.sh script

cd mcuboot-arduino-stm32h7
mbed config root . && mbed deploy
mbed compile -m PORTENTA_H7_M7 -t GCC_ARM --profile=release --profile custom.json

[schnoberts1]

Thanks. The only difference here is I’m not using the cli that comes with mbed studio, I’m pulling it down using pip. I will remedy this. On 11 Feb 2025, at 07:38, Mattia Pennasilico ***@***.***> wrote: To create /tmp/mcuboot-arduino-stm32h7 I just clone the repo cd /tmp git clone https://github.com/arduino/mcuboot-arduino-stm32h7.git then in my home pc i have my toolchain in /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/ and mbed tools in /opt/mbed-studio-tools/python/bin/ so I export both folders export PATH="/opt/gcc-arm-none-eabi-9-2019-q4-major/bin/:$PATH" export PATH="/opt/mbed-studio-tools/python/bin/:$PATH" and to build i use the commands in the readme or in the generate_rel.sh script mbed config root . && mbed deploy mbed compile -m PORTENTA_H7_M7 -t GCC_ARM --profile=release --profile custom.json —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[pennam]

I can provide you my mbed-studio.tools folder if you want to try.

[schnoberts1]

That would be very helpful. Thanks.

…

On 11 Feb 2025, at 09:28, Mattia Pennasilico ***@***.***> wrote: I can provide you my mbed-studio.tools folder if you want to try. — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMQSMUFREXAMVDSSQJFJGD2PG7D5AVCNFSM6AAAAABW2MYY5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJQGI2DOMZRGI>. You are receiving this because you were mentioned.

[schnoberts1]

I am a bit further, if I do mbed config root $(pwd) the warning messages go but the core issue remains. As an experiment I tried to build mbed_app_bootutil.json from HEAD and it fails with a link error that is resolved by adding "system-storage" to the dependencies. Puzzling all this works for you without amendments of HEAD.

[pennam]

mbed config root . && mbed deploy needs to be typed inside this project folder mcuboot-arduino-stm32h7

[schnoberts1]

Ok, I think I have solved the issue. I noticed in custom.json common linker arguments :"-u __wrap_printf", "-u main", "-u malloc", "-u __wrap_snprintf", "-u _malloc_r". I see you added these:

commit 5c1c578f9817a6d03e0dc25800bdbb1b7eef1355
Author: pennam <m.pennasilico@arduino.cc>
Date:   Tue Sep 6 16:33:40 2022 +0200

    Fix ld options to improve lto

I reckon you were fixing some linker errors? I applied the following:

diff --git a/custom.json b/custom.json
index 3638fec..537aaf3 100644
--- a/custom.json
+++ b/custom.json
@@ -12,7 +12,7 @@
         "ld": ["-Wl,--gc-sections", "-Wl,--wrap,main", "-Wl,--wrap,_malloc_r",
                "-Wl,--wrap,_free_r", "-Wl,--wrap,_realloc_r", "-Wl,--wrap,_memalign_r",
                "-Wl,--wrap,_calloc_r", "-Wl,--wrap,exit", "-Wl,--wrap,atexit",
-               "-Wl,-n", "-u __wrap_printf", "-u main", "-u malloc", "-u __wrap_snprintf", "-u _malloc_r"]
+               "-Wl,-n", "-u __wrap_printf", "-u main", "-u malloc", "-u __wrap_snprintf", "-u _malloc_r", "-u __wrap__calloc_r"]
     },

and the build works. I'm guessing this an issue with linker order perhaps combined with FLTO but why this works for you and not me is a puzzle.

[pennam]

I reckon you were fixing some linker errors?

I do not think so, i was probably only try to fit the bootloader binary in one flash sector and trying to improve linker time optimization.

I'm guessing this an issue with linker order perhaps combined with FLTO but why this works for you and not me is a puzzle.

the only possible reason that comes to my mind is the toolchain version. Did you tried to build using gcc-arm-none-eabi-9-2019-q4-major

[schnoberts1]

Did you tried to build using gcc-arm-none-eabi-9-2019-q4-major

This always resulted in a system that crashed in dsi_init in the giga display shield initialisation. I fixed the cause of that on my fork of the Arduino Core but there’s a non-zero number of warnings that are related to potential undefined behaviour violations across the whole core and mbed codebase and I don’t want to fix them (as I’m trying to get something finished) so I stayed in the last patched version of gcc 7 and I’d like to build the entire system using the same compiler so I have a predictable toolchain at all points. Note: If I remove your changes the linker is unable to resolve the symbols mentioned in the -u lines. It could well be a gcc7 FLTO issue. When I deploy this boot loader successfully I’ll close the ticket if that’s ok with you.

…

On 11 Feb 2025, at 14:32, Mattia Pennasilico ***@***.***> wrote: I reckon you were fixing some linker errors? I do not think so, i was probably only try to fit the bootloader binary in one flash sector and trying to improve linker time optimization. I'm guessing this an issue with linker order perhaps combined with FLTO but why this works for you and not me is a puzzle. the only possible reason that comes to my mind is the toolchain version. Did you tried to build using gcc-arm-none-eabi-9-2019-q4-major — Reply to this email directly, view it on GitHub <#35 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMQSMTBCLCLPPMGDQO7BRT2PICWVAVCNFSM6AAAAABW2MYY5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJQHE4TIOBTGQ>. You are receiving this because you were mentioned.

[pennam]

I stayed in the last patched version of gcc 7 and I’d like to build the entire system using the same compiler so I have a predictable toolchain at all points.

Makes perfectly sense

When I deploy this boot loader successfully I’ll close the ticket if that’s ok with you.

👍