Linker scripts, custom linker scripts

[JojoS62]

It took some time for me to figure out how the linker scripts where created, As far as I understand:

• In Mbed5, the raw linker file is used, as defined in targets/vendor/family/board/toolchain/
• In Mbed6 CLI2, the raw linker file preprocessed (for gcc) and stored in build_cmake/.../targets/vendor/family/
• In Mbed-CE, the raw linker file preprocessed (for gcc) and stored in build/ per distro. A distro is an app with common mbed-os and libs

please confirm someone that this right.

Now I see a need for custom linker scripts without having the overhead of creating a new target. Custom allocation becomes neccessary when dealing with DMA, large buffers or aligned buffers and MPU settings for D-Cache.

The custom linker script could be set in the applications CMakeLists and provide a my-modified.ld also as raw linker script. When set, the mbed_set_linker_script.cmake will use the custom script instead of the default.

[multiplemonomials]

Hmm. Is it a big problem to create a new custom target to hold the linker script? Isn't it just a few lines of JSON plus a few lines of CMake?

[JojoS62]

The linker script depends on the target hardware, but is also application dependent. E.g., I want to use lvgl graphics and this needs buffers and the position is relevant as DMA is not working with all RAM types. DMA is difficult because these different RAM and bus structure.

I have created a number of custom targets, but it requires more than just a linker script. Many times my custom targets were not compiling because changes in mbed-os were not compatible with targets.json or pinnames.h. So the single modification of the linker script is much easier to maintain.

My PR for adding a custom linker script is working already, I want to test it now with the multiple distro feature.

[multiplemonomials]

You know that you can add a custom target without any source files, right? This removes the need to keep any headers up to date.

Making an example for this is high on my list, promise.

[JojoS62]

An example for custom targets would be great, I have also a repo with custom targets and would like to upgrade this for mbed-ce.
But I still would like to have the option for the custom linker script, it is now a single line in the projects CMakeLists. I think it is also possible to define it per target by using properties, I have to brush up my CMake experience.

[multiplemonomials]

My job has been kinda busy the last few weeks, but I got a start on that example repo: https://github.com/mbed-ce/mbed-ce-custom-targets

The first two targets are implemented, the third will require some Mbed code changes that I'm still working on.

[JojoS62]

thanks, but I don't give up on just adding a linker script to per executable.
The linker script is now handled and finished at mbed-os/baremetal configuration. But add_executable happens after that, so a part of the things that happen in mbed_setup_linker_script have to be done again.
Custom targets are needed as well, but its a different thing to just modify a linker script per application.

I want to keep the existing linker script because this is needed for the tests. Then add the preprocessed custom script to the build/app dir and use this for linking the app.

[JohnK1987]

I think it is good to have things connected - #103

BR, Jan

[lefebvresam]

What do you think about adding an example building script in the docs, like this one:

#!/bin/sh

set -e

TARGET=HMC20
PROFILE=develop
BIN_FILE=MyProgram.bin

CLEAN=0
FLASH=0
ERASE=0

# Define the toolchain location
export PATH=/usr/local/gcc-arm/bin:$PATH

usage()
{
  echo "$0: Build the HMC20 application with mbed-os CE edition"
  echo "Optional arguments:"
  echo "\t-c --clean  perform make clean first"
  echo "\t-b --build  build profile develop, release or debug"
  echo "\t-d --delete delete the build dir"
  echo "\t-f --flash  flash the chip"
  echo "\t-p --probe  probe and reset the chip"
  echo "\t-e --erase  erase the whole chip"
  echo "\t-h --help   show this help"
}

parse_args() {
  while [ "$1" != "" ]
  do
    case "$1" in
      --clean | -c)
        CLEAN=1
        ;;
      --build | -b)
        shift
        case "$1" in
          develop)
            PROFILE=develop
            ;;
          release)
            PROFILE=release
            ;;
          debug)
            PROFILE=debug
            ;;
          *)
            echo "Specify build profile develop, release or debug" 
            exit 1
            ;;
        esac
        ;;
      --delete | -d)
        rm -rf build
        exit 0
        ;; 
      --flash | -f)
        FLASH=1
        ;;
      --probe | -p)
        st-info --probe
        exit 0
        ;;           
      --erase | -e)
        ERASE=1
        ;; 
      --help | -h)
        usage
        exit 0
        ;;        
    *)
    usage
    exit 1
    ;;
    esac
    shift
  done
}

# Parse the arguments
parse_args "$@"

BUILD_DIR=build/${PROFILE}
BIN_DIR=$BUILD_DIR/$BIN_FILE

# Erase the chip
if [ ${ERASE} -eq 1 ]
then
    st-flash --freq=4M  erase  0x8000000 0x100000 | sed 's/\r/\n/g'
    exit 0
fi

# Create build dir if not exists
mkdir -p ${BUILD_DIR}
cd ${BUILD_DIR}

# Clean the build
if [ ${CLEAN} -eq 1 ]
then
    echo "Clean the build dir"
    ninja clean || (echo "Cleaning failed" ; exit 1)
fi

# Create the build
echo "Build the code for target ${TARGET} with profile ${PROFILE}"
cmake -GNinja -DCMAKE_BUILD_TYPE=$PROFILE -DMBED_TARGET=$TARGET ../..

# Compile the code
echo "Compile the code"
ninja || (echo "Compiling failed" ; exit 1)
cd ../..

# Flash the chip
if [ ${FLASH} -eq 1 ]
then
  echo "Flash the chip with ${BIN_DIR}"
  #python3 append.py $BIN_DIR
  st-flash --freq=4M --reset write $BIN_DIR 0x8000000
fi

I know it can be made more generic but at least there is an example and it makes the development cycle much easier.

[multiplemonomials]

hmm, fwiw, you can replace quite a lot of this by using the upload method system to upload your code. While stlink and openocd 0.12 may not work out of the box with STM32U5, I just tested latest git OpenOCD with U5 and it works a treat!

[lefebvresam]

Yes but you are limited to programming only and you have to recreate all arguments each time you open the project and want to compile. I see some disadvantages there:

• You don't know what happens 'behind the scene'
• You cannot do a full erease