Project

General

Profile

Bug #5260

bootloader goes beyond partition size in modern gcc

Added by laforge 6 days ago. Updated 5 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
firmware
Target version:
-
Start date:
10/13/2021
Due date:
% Done:

0%

Spec Reference:

Description

As we noticed several times now, gcc is becoming more and more inefficient in building our DFU loader, resulting in it no longer fitting the partition on modern compilers.

I think switching to a larger partition is not really an option as it would create a compatibility nightmare with older boards and a lot of fall-out in our user community.

So if we really cannot shrink the bootloader further, then we will have to settle on an old gcc version and create our official DFU loader builds from a specific build slave (or maybe rather docker container).

btw: what about Hoernchen's favorite llvm/clang? Does it generate smaller code for this bare-iron bootloader use case?

@Hoernchen, please specify which exact environment shall be built.

osmith can then (After his holidays next week) work on changing our jenkins setup so that the existing simtrace2 firmware job just builds the applications, and create a new job with a docker image containing the specific gcc version required to build all the DFU loaders.


Checklist

  • report this size regression to upstream gcc (Hoernchen)
  • possibly check llvm/clang? (Hoernchen)
  • specify which compiler version on which distro to use (Hoernchen)
  • jenkins/docker/... stuff to build DFU loaders from simtrace2.git in that specific environment (osmith)

History

#1 Updated by Hoernchen 5 days ago

I actually gave clang a try, there is https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm which conveniently builds clang and compiler-rt and newlib. Of course any distro provided clang package would work as well for compiling, but the issue is that we need a stdlib and compiler runtime as well, so just running that script is the most convenient way to get all of that (until oom, pass --parallel=x). Still needs binutils, but i just used my existing arm gcc package for that to give it a try.

The -Os binaries are about as large as the gcc versions

16324 Okt 13 19:45 firmware/bin/ngff_cardem-dfu-flash.bin
15484 Okt 13 19:45 firmware/bin/qmod-dfu-flash.bin
15104 Okt 13 19:45 firmware/bin/simtrace-dfu-flash.bin

but clang does have a -Oz that offers smaller code:

14704 Okt 13 19:50 firmware/bin/ngff_cardem-dfu-flash.bin
13996 Okt 13 19:50 firmware/bin/qmod-dfu-flash.bin
13612 Okt 13 19:50 firmware/bin/simtrace-dfu-flash.bin

This is significantly smaller than what gcc can do.. We could also try bitcode-level LTO.

The gcc last toolchain I used that "just works" was gcc-arm-none-eabi-9-2020-q2-update - tho I do remember having size issues some time last year with a slightly older one..

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)