search

blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.
GNU General Public License v3.0
3.25k stars 771 forks source link

ST-Link v2 with SWIM as UART configured is too big to fit #1579

Open Joebeazelman opened 1 year ago

Joebeazelman commented 1 year ago

I've encountered a series of issues installing BMP. First, I would prefer to download the latest version of BMP as a binary and flash it to my St-Link v2, but I wasn't sure whether it was configured for SWIM_AS_UART. I presume it must be set at compile time rather than runtime since it's passed as a make argument. There was nothing mentioned about how the firmware was configured. I

After cloning the repository, I received the following error:

libopencm3/usb/bos.h: No such file or directory

I figured the library wasn't installed on my system, so I installed it using brew and the issue persisted. I search online and finally found a BMP issue on GitHub where the user was asked if they had initialized and updated the submodules. Again, nothing mentioned this important step. Ideally, it would be nice if the makefile either checked for the initialization of the submodules and reported an error if they didn't exist or better yet, initialize and update them before starting the build process.

I performed the two git submodule operations and was able to build the project up until the link stage where it complained the firmware was too big for the ROM. I search for a solution and there were two other users who are having the same issue, but there was no resolution given. Interestingly, the resulting elf file size they posted is the same as mine. I am also running version 12.2.1 of GCC.

 ✘ joe@Joes-MacBook-Pro-2  ~/Projects/Repos/blackmagic   main  make PROBE_HOST=stlink ST_BOOTLOADER=1 SWIM_AS_UART=1
  BUILD   lib/stm32/f1
make[2]: Nothing to be done for `all'.
  BUILD   lib/stm32/f4
make[2]: Nothing to be done for `all'.
  BUILD   lib/lm4f
make[2]: Nothing to be done for `all'.
Load address 0x08004000 for original ST-LinkV2 Bootloader
  LD      blackmagic.elf
/Applications/ArmGNUToolchain/12.2.mpacbti-rel1/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: address 0x80214e0 of blackmagic.elf section `.text' is not within region `rom'
/Applications/ArmGNUToolchain/12.2.mpacbti-rel1/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: blackmagic.elf section `.ARM.exidx' will not fit in region `rom'
/Applications/ArmGNUToolchain/12.2.mpacbti-rel1/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: address 0x80214e0 of blackmagic.elf section `.text' is not within region `rom'
/Applications/ArmGNUToolchain/12.2.mpacbti-rel1/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 5888 bytes
Memory region         Used Size  Region Size  %age Used
             rom:      136960 B       128 KB    104.49%
             ram:        3876 B        20 KB     18.93%
collect2: error: ld returned 1 exit status
make[1]: *** [blackmagic.elf] Error 1
make: *** [all] Error 2

The firmware doesn't fit but so you must acquit.

dragonmux commented 1 year ago

When you clone the repository, you should be passing --recursive to the command as in git clone --recursive https://github.com/blackmagic-debug - this will then clone and pull in libopencm3 which is a submodule dependency. That's what you hit initially (the BOS header is from the submodule package)

If you build in the root of the project like you are supposed to, the first thing the Makefiles should do is initialise libopencm3: https://github.com/blackmagic-debug/blackmagic/blob/ee3bd73c39f304272ee2ff4ad8b4d8b509998b0a/Makefile#L15-L20

Regarding it not fitting, 12.2.mpacbti-rel1 is a beta release toolchain, so please use 12.2.Rel1 - the mpacbti version of the toolchain consistently provides worse code generation in our experience, making this problem worse. We're aware that the project is reaching the limits of the Flash of the devices though. If you cannot get the firmware to fit any other way, you can disable a target or two by deleting their .c file lines from src/Makefile to prune the target support down to fit.

Elias-Graf commented 1 year ago

What exactly is the solution to this? I'm doing the following steps:

git clone --recurse-submodules  https://github.com/blackmagic-debug/blackmagic
cd blackmagic/
make PROBE_HOST=stlink ST_BOOTLOADER=1

Which results in this:

/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: address 0x8020b6c of blackmagic.elf section `.text' is not within region `rom'
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: blackmagic.elf section `.data' will not fit in region `rom'
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: address 0x8020b6c of blackmagic.elf section `.text' is not within region `rom'
/usr/lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 3324 bytes
Memory region         Used Size  Region Size  %age Used
             rom:      134396 B       128 KB    102.54%
             ram:       11984 B        20 KB     58.52%
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:133: blackmagic.elf] Error 1
make: *** [Makefile:17: all] Error 2

Okay, I can get it to compile by deleting a few targets, but am I using an incorrect version of the toolchain which is generating lager binaries?

[elias@fedora blackmagic]$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (Fedora 12.2.0-3.fc38) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
dragonmux commented 1 year ago

You're using a completely unsupported version of the toolchain that may well not even be giving you correct codegen. Please use a toolchain from ARM themselves (do note the one we've linked is untested as it's just been released, the most recent tested release toochain is 12.2.Rel1).

One of the PRs that's currently outstanding saves 800 bytes of Flash which should help with this problem too. The project has simply got large and that's causing us to bat up against the limits of the Flash of these parts. Part of the v2.0 goal is a new build system which will make selecting target support and creating cut-down builds much easier.

Elias-Graf commented 1 year ago

@dragonmux Okay, so I've downloaded some of the toolchains and this was my result:

With the newest toolchain:

/usr/local/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: address 0x80219c0 of blackmagic.elf section `.text' is not within region `rom'
/usr/local/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: blackmagic.elf section `.ARM.exidx' will not fit in region `rom'
/usr/local/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: address 0x80219c0 of blackmagic.elf section `.text' is not within region `rom'
/usr/local/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 7128 bytes
Memory region         Used Size  Region Size  %age Used
             rom:      138200 B       128 KB    105.44%
             ram:       12292 B        20 KB     60.02%
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:133: blackmagic.elf] Error 1
make: *** [Makefile:17: all] Error 2

And with the tested one you mentioned:

/usr/local/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: address 0x8020b04 of blackmagic.elf section `.text' is not within region `rom'
/usr/local/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: blackmagic.elf section `.data' will not fit in region `rom'
/usr/local/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: address 0x8020b04 of blackmagic.elf section `.text' is not within region `rom'
/usr/local/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 3212 bytes
Memory region         Used Size  Region Size  %age Used
             rom:      134284 B       128 KB    102.45%
             ram:       12292 B        20 KB     60.02%
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:133: blackmagic.elf] Error 1
make: *** [Makefile:17: all] Error 2

I must be doing something wrong... did I download another incorrect tool chain?

I was running make clean between every build. I build with: make PROBE_HOST=stlink ST_BOOTLOADER=1.

dragonmux commented 1 year ago

You aren't doing anything wrong per se - this is just that the project is approaching the limits of what we can fit in Flash with a full project build. Interesting that the new 12.3.1 compiler results in worse code generation and less optimised binaries.

We would note that you may wish to update your working copy with git pull as PR #1583 was merged a few days ago and improves the Flash usage of the project by ~800 bytes.

Elias-Graf commented 1 year ago

Nice, now I'm not even two percent short of fitting the firmware :D

/usr/local/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: address 0x802075c of blackmagic.elf section `.text' is not within region `rom'
/usr/local/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: blackmagic.elf section `.data' will not fit in region `rom'
/usr/local/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: address 0x802075c of blackmagic.elf section `.text' is not within region `rom'
/usr/local/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 2276 bytes
Memory region         Used Size  Region Size  %age Used
             rom:      133348 B       128 KB    101.74%
             ram:       12168 B        20 KB     59.41%
collect2: error: ld returned 1 exit status

And with the new version:

/usr/local/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: address 0x8021618 of blackmagic.elf section `.text' is not within region `rom'
/usr/local/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: blackmagic.elf section `.ARM.exidx' will not fit in region `rom'
/usr/local/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: address 0x8021618 of blackmagic.elf section `.text' is not within region `rom'
/usr/local/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld: region `rom' overflowed by 6192 bytes
Memory region         Used Size  Region Size  %age Used
             rom:      137264 B       128 KB    104.72%
             ram:       12168 B        20 KB     59.41%

So I guess removing targets in code is still necessary for now :). And yes, it is curious that the newer version produces binaries that are quite a lot larger.

dragonmux commented 1 year ago

Correct - we'll be trying to improve this before the v1.10 release if we can but we really need the new build system we're going to be introducing in v2.0 to allow users to configure what targets they're building in to really solve this given the project's only going to continue growing.

Joebeazelman commented 1 year ago

I can understand. C++'s tooling are still stuck in the 1970s and still doesn't have a package manager. I took one look at CMake and I had to barf. A tool to make another tool easier to configure, which itself is equally if not more complicated to figure out. I'm sure there will be another tool to generate CMake and it will be equally I not more complicated to use.

UNIX technologies have this recursive pattern where layers of fecal matter are built on top of fecal matter until it is so petrified it can no longer be worked with. Instead coming to their senses, its developers continue pile on even more fecal matter hoping it will turn into diamonds at some point in the future.

dragonmux commented 1 year ago

The replacement build system is slated to be a Linux Kernel style Makefile build system and configuration engine like KConfig. However, we will also be trialling a Meson build system.

Meson is a modern build system language designed for readability, ease of use and simplicity and uses the Ninja job engine to execute the build steps it generates as part of configuring a build.

RamKromberg commented 6 months ago

While v1.10.2 was indeed too big, I've managed to build v1.9.3 using the provided nix-shell (on nixos stable):

git clone --recursive https://github.com/blackmagic-debug/blackmagic.git
cd blackmagic
git checkout v1.9.3
nix-shell
make PROBE_HOST=stlink ST_BOOTLOADER=1 SWIM_AS_UART=1

I've flashed it with the windows build of the stlink-tool using 'stlink-tool.exe blackmagic.bin'.

Here you go: stlink_v2-BlackMagicV1_9_3-PROBE_HOST=stlink-ST_BOOTLOADER=1-SWIM_AS_UART=1.zip

Good luck.