building gcc-arm-none-eabi from source

building gcc-arm-none-eabi from source

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

Hello folks,

we (Weidmueller/Linutronix) have a use case where gcc-arm-none-eabi needs
to run on a 32 bit arm host to dynamically build binaries for an arm32
baremetal RTOS. Existing pre-built recipe cannot fulfill this, so I'd like
to propose swapping this for a recipe that builds gcc-arm-none-eabi from
source for any target to run on, similar to Debian:

https://packages.debian.org/bullseye/gcc-arm-none-eabi

The other reason to do this is that gcc is open source: taking prebuilt
binaries for it goes against OE principles.

I can do the technical work, but would like to hear opinions and feedback
first.

Alex

[-- Attachment #2: Type: text/html, Size: 865 bytes --]

Re: [meta-arm] building gcc-arm-none-eabi from source

[Richard Purdie]

On Mon, 2022-01-03 at 20:58 +0100, Alexander Kanavin wrote:
> Hello folks,
> 
> we (Weidmueller/Linutronix) have a use case where gcc-arm-none-eabi needs to
> run on a 32 bit arm host to dynamically build binaries for an arm32 baremetal
> RTOS. Existing pre-built recipe cannot fulfill this, so I'd like to propose
> swapping this for a recipe that builds gcc-arm-none-eabi from source for any
> target to run on, similar to Debian:
> 
> https://packages.debian.org/bullseye/gcc-arm-none-eabi
> 
> The other reason to do this is that gcc is open source: taking prebuilt
> binaries for it goes against OE principles.
> 
> I can do the technical work, but would like to hear opinions and feedback
> first.

Can't you just use the normal OE gcc compiler with the right flags passed in to
disable the auto library pieces? or if that doesn't work, use an OE built
baremetal compiler?

Cheers,

Richard

Re: [meta-arm] building gcc-arm-none-eabi from source

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Mon, 3 Jan 2022 at 23:27, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> Can't you just use the normal OE gcc compiler with the right flags passed
> in to
> disable the auto library pieces? or if that doesn't work, use an OE built
> baremetal compiler?
>

The normal compiler would then no longer be suited for native compilation
on the target, right?

The baremetal compiler would have to be set up in a cross-canadian fashion
- existing cross-canadian pieces cannot be used as they're made for SDK
builds. I'm not sure how to do it without making multiple copies of the
recipe for each canadian target, and then having to support and update them
in a private layer.

Basically both options seem worse to me from maintenance and testability
perspective than just building the vendor toolchain from source, but maybe
there is something specific to them I'm not seeing?

Alex

[-- Attachment #2: Type: text/html, Size: 1417 bytes --]

Re: [meta-arm] building gcc-arm-none-eabi from source

[Richard Purdie]

On Tue, 2022-01-04 at 08:55 +0100, Alexander Kanavin wrote:
> On Mon, 3 Jan 2022 at 23:27, Richard Purdie <richard.purdie@linuxfoundation.org>
> wrote:
> > Can't you just use the normal OE gcc compiler with the right flags passed in
> > to
> > disable the auto library pieces? or if that doesn't work, use an OE built
> > baremetal compiler?
> > 
> 
> 
> The normal compiler would then no longer be suited for native compilation on the
> target, right?

I was wondering if you could use the normal compiler but just with some extra
flags, e.g. -Wl,-nostdlib to disable the standard libraries. You could use
wrapper scripts around the standard toolchain if needed and the extra options
were problematic. There isn't a huge difference between the target
compiler/linker and the baremetal one.

> The baremetal compiler would have to be set up in a cross-canadian fashion -
> existing cross-canadian pieces cannot be used as they're made for SDK builds.
> I'm not sure how to do it without making multiple copies of the recipe for each
> canadian target, and then having to support and update them in a private layer.
> 
> Basically both options seem worse to me from maintenance and testability
> perspective than just building the vendor toolchain from source, but maybe there
> is something specific to them I'm not seeing?

It is true that you'd need a different target variant for the second option I
mentioned.

I did have something slightly similar with extensions to the gcc/binutils
recipes for a cross AVR toolchain that runs on an arm target. I found some
copies here, based on daisy which whilst old, gives the idea:

https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/daisy&id=f58f90257a5af3e6b6974090e62cad9d90d53ae5

I definitely have something more recent locally too (pyro, can't remember if I
made it to dunfell with that code), I can dig that out if it is interesting. I
thought somewhere I had a BBCLASSEXTEND recipe which added multiple cross
compiler arches on target but I can't find that one :/.

Cheers,

Richard

Re: [meta-arm] building gcc-arm-none-eabi from source

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Tue, 4 Jan 2022 at 10:24, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> It is true that you'd need a different target variant for the second
> option I
> mentioned.
>
> I did have something slightly similar with extensions to the gcc/binutils
> recipes for a cross AVR toolchain that runs on an arm target. I found some
> copies here, based on daisy which whilst old, gives the idea:
>
>
> https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/daisy&id=f58f90257a5af3e6b6974090e62cad9d90d53ae5
>

Right, I think I'll end up doing something like this, the question is
whether it should go directly to meta-arm, build from arm-provided gcc
source, and replace the prebuilt binary recipe already in place - for
better maintenance and testing. The customer does prefer that toolchain, as
they're already using Debian packaged one for development, and this would
align better.

Alex

[-- Attachment #2: Type: text/html, Size: 1446 bytes --]

Re: [meta-arm] building gcc-arm-none-eabi from source

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Tue, 4 Jan 2022 at 11:01, Alexander Kanavin via lists.yoctoproject.org
<alex.kanavin=gmail.com@lists.yoctoproject.org> wrote:

> Right, I think I'll end up doing something like this, the question is
> whether it should go directly to meta-arm, build from arm-provided gcc
> source, and replace the prebuilt binary recipe already in place - for
> better maintenance and testing. The customer does prefer that toolchain, as
> they're already using Debian packaged one for development, and this would
> align better.
>

Another alternative is offline SDK installs into target images by
repackaging them via helper recipes :) I started working in that direction,
but it's significantly more complex, so we're exploring direct toolchain
builds first.

Alex

[-- Attachment #2: Type: text/html, Size: 1278 bytes --]

Re: [meta-arm] building gcc-arm-none-eabi from source

[Ross Burton]

On Mon, 3 Jan 2022 at 19:58, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> we (Weidmueller/Linutronix) have a use case where gcc-arm-none-eabi needs to run on a 32 bit arm host to dynamically build binaries for an arm32 baremetal RTOS. Existing pre-built recipe cannot fulfill this, so I'd like to propose swapping this for a recipe that builds gcc-arm-none-eabi from source for any target to run on, similar to Debian:
>
> https://packages.debian.org/bullseye/gcc-arm-none-eabi
>
> The other reason to do this is that gcc is open source: taking prebuilt binaries for it goes against OE principles.
>
> I can do the technical work, but would like to hear opinions and feedback first.

Considering that the Arm GCC is mostly standard GCC with some
backports, and our GCC is often newer, simply using the standard GCC
(if the baremetal is arm-a) with -nostdlib should be sufficient?

Ross

Re: [meta-arm] building gcc-arm-none-eabi from source

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

On Tue, 4 Jan 2022 at 16:39, Ross Burton <ross@burtonini.com> wrote:

>
> Considering that the Arm GCC is mostly standard GCC with some
> backports, and our GCC is often newer, simply using the standard GCC
> (if the baremetal is arm-a) with -nostdlib should be sufficient?
>

Stefan, can you clarify please? I think the baremetal side is not actually
arm-a?

Alex

[-- Attachment #2: Type: text/html, Size: 782 bytes --]

Re: [meta-arm] building gcc-arm-none-eabi from source

[Sumit Garg]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

On Tue, 4 Jan 2022 at 23:21, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> On Tue, 4 Jan 2022 at 16:39, Ross Burton <ross@burtonini.com> wrote:
>>
>>
>> Considering that the Arm GCC is mostly standard GCC with some
>> backports, and our GCC is often newer, simply using the standard GCC
>> (if the baremetal is arm-a) with -nostdlib should be sufficient?
>
>
> Stefan, can you clarify please? I think the baremetal side is not actually arm-a?
>

I have attached readme.txt provided as part of arm-a toolchain source
[1]. This provides a list of features supported by arm-a toolchain.
AFAICS, arm-a toolchain provides additional support for newlib-nano
which seems missing from the OE compiler with libc as baremetal or
newlib.

[1] https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-src.tar.bz2

-Sumit

> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#2790): https://lists.yoctoproject.org/g/meta-arm/message/2790
> Mute This Topic: https://lists.yoctoproject.org/mt/88134451/1777089
> Group Owner: meta-arm+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub [sumit.garg@linaro.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: readme.txt --]
[-- Type: text/plain, Size: 9243 bytes --]

GNU Arm Embedded Toolchain 10.3-2021.10
Pre-built GNU toolchain for Arm Cortex-A/R and Cortex-M processors
GCC Version: 10.3

Table of Contents
* Installing executables on Linux
* Installing executables on Mac OS X
* Installing executables on Windows
* Invoking GCC
* Architecture options usage
* Available multilibs
* C Libraries usage
* Linker scripts & startup code
* Samples
* GDB Server for CMSIS-DAP based hardware debugger

* Installing executables on Linux *
Unpack the tarball to the install directory, like this:

    $ cd ${install_dir} && tar xjf gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2
    $ cd ${install_dir} && tar xjf gcc-arm-none-eabi-10.3-2021.10-aarch64-linux.tar.bz2

If you want to use gdb python build (arm-none-eabi-gdb-py), then
install python2.7.

* Installing executables on Mac OS X *
Unpack the tarball to the install directory, like this:

    $ cd ${install_dir} && tar xjf gcc-arm-none-eabi-10.3-2021.10-mac.tar.bz2

* Installing executables on Windows *
Run the installer (gcc-arm-none-eabi-10.3-2021.10-win32.exe) and follow the
instructions. The installer can also be run on the command line. When run on
the command-line, the following options can be set:
  - /S Run in silent mode
  - /P Adds the installation bin directory to the system PATH
  - /R Adds an InstallFolder registry entry for the install.

For example, to install the tools silently, amend users PATH and add registry
entry:

    > gcc-arm-none-eabi-10.3-2021.10-win32.exe /S /P /R

The toolchain in Windows zip package is a backup to Windows installer for
those who cannot run the installer.  You must decompress the zip package
and then invoke it following instructions in the next section.

To use gdb python build (arm-none-eabi-gdb-py), you must install 32 bit
python2.7 irrespective of 32 or 64 bit Windows.  Please get the package from
https://www.python.org/downloads/.

* Invoking GCC *
On Linux and Mac OS X, either invoke with the complete path like this:

    $ ${install_dir}/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc

Or set path like this:

    $ export PATH=$PATH:${install_dir}/gcc-arm-none-eabi-10.3-2021.10/bin
    $ arm-none-eabi-gcc --version

On Windows (although the above approaches also work), it can be more
convenient to either have the installer register environment variables, or run
INSTALL_DIR\bin\gccvar.bat to set environment variables for the current cmd.

For Windows zip package, after decompression we can invoke the toolchain either with
complete path like this:
TOOLCHAIN_UNZIP_DIR\bin\arm-none-eabi-gcc
or run TOOLCHAIN_UNZIP_DIR\bin\gccvar.bat to set environment variables for the
current cmd.

* Architecture options usage *

This toolchain is built and optimized for Cortex-A/R/M embedded development.
This section describes how to invoke GCC/G++ with the correct command line
options for variants of Cortex-A/R and Cortex-M architectures.

    $ arm-none-eabi-gcc [-mthumb] -mcpu=CPU[+extension...] -mfloat-abi=ABI

-mcpu:
For the permissible CPU names and extensions, see the GCC online manual:
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/ARM-Options.html#index-mcpu-2
Use the optional extension name with -mcpu to disable the extensions that are
not present in your CPU implementation.

By default, -mfpu=auto and this enables the compiler to automatically select
the floating-pointing and Advanced SIMD instructions based on the -mcpu option
and extension.

-mfloat-abi:
If floating-point or Advanced SIMD instructions are present, then use the
-mfloat-abi option to control the floating-point ABI, or use -mfloat-abi=soft
to disable floating-point and Advanced SIMD instructions.
For the permissible values of -mfloat-abi, see the GCC online manual:
https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/ARM-Options.html#index-mfloat-abi

-mthumb:
When using processors that can execute in Arm state and Thumb state, use -mthumb
to generate code for Thumb state.

Examples with no floating-point and Advanced SIMD instructions:
    $ arm-none-eabi-gcc -mcpu=cortex-m7+nofp
    $ arm-none-eabi-gcc -mcpu=cortex-r5+nofp -mthumb
    $ arm-none-eabi-gcc -mcpu=cortex-a53+nofp -mthumb
    $ arm-none-eabi-gcc -mcpu=cortex-a57 -mfloat-abi=soft -mthumb

Examples with single-precision floating-point with soft-float ABI:
    $ arm-none-eabi-gcc -mcpu=cortex-m7+nofp.dp -mfloat-abi=softfp
    $ arm-none-eabi-gcc -mcpu=cortex-r5+nofp.dp -mfloat-abi=softfp -mthumb

Examples with single-precision floating-point with hard-float ABI:
    $ arm-none-eabi-gcc -mcpu=cortex-m7+nofp.dp -mfloat-abi=hard
    $ arm-none-eabi-gcc -mcpu=cortex-r5+nofp.dp -mfloat-abi=hard -mthumb

Examples with double-precision floating-point with soft-float ABI:
    $ arm-none-eabi-gcc -mcpu=cortex-m7 -mfloat-abi=softfp
    $ arm-none-eabi-gcc -mcpu=cortex-r5 -mfloat-abi=softfp -mthumb

Examples with double-precision floating-point with hard-float ABI:
    $ arm-none-eabi-gcc -mcpu=cortex-m7 -mfloat-abi=hard
    $ arm-none-eabi-gcc -mcpu=cortex-r5 -mfloat-abi=hard -mthumb

Example with floating-point and Advanced SIMD instructions with soft-float ABI:
    $ arm-none-eabi-gcc -mcpu=cortex-a53 -mfloat-abi=softfp -mthumb

Example with floating-point and Advanced SIMD instructions with hard-float ABI:
    $ arm-none-eabi-gcc -mcpu=cortex-a53 -mfloat-abi=hard -mthumb

Example with MVE and floating-point with soft-float ABI:
    $ arm-none-eabi-gcc -mcpu=cortex-m55 -mfloat-abi=softfp

Example with MVE and floating-point with hard-float ABI:
    $ arm-none-eabi-gcc -mcpu=cortex-m55 -mfloat-abi=hard

* Available multilibs *

GNU Arm Embedded Toolchain 10.3-2021.10 offers both rmprofile and
aprofile set of multilibs.

How to list all multilibs supported by the toolchain:

    $ arm-none-eabi-gcc --print-multi-lib

How to check which multilib is selected by toolchain based on -mthumb, -mcpu,
-mfpu and -mfloat-abi with --print-multi-dir command line option:

    $ arm-none-eabi-gcc [-mthumb] -mcpu=CPU -mfpu=FPU -mfloat-abi=ABI --print-multi-dir

For examples:

    $ arm-none-eabi-gcc -mcpu=cortex-a55 -mfpu=auto -mfloat-abi=hard --print-multi-dir
    thumb/v8-a+simd/hard

    $ arm-none-eabi-gcc -mcpu=cortex-r5 -mfpu=auto -mfloat-abi=softfp --print-multi-dir
    thumb/v7+fp/softfp

    $ arm-none-eabi-gcc -mcpu=cortex-m0 -mfpu=auto -mfloat-abi=soft --print-multi-dir
    thumb/v6-m/nofp

* C Libraries usage *

This toolchain is released with two prebuilt C libraries based on newlib:
one is the standard newlib and the other is newlib-nano for code size.
To distinguish them, we rename the size optimized libraries as:

    libc.a --> libc_nano.a
    libg.a --> libg_nano.a

To use newlib-nano, users should provide additional gcc compile and link time
option:

    --specs=nano.specs

At compile time, a 'newlib.h' header file especially configured for newlib-nano
will be used if --specs=nano.specs is passed to the compiler.

nano.specs also handles two additional gcc libraries: libstdc++_nano.a and
libsupc++_nano.a, which are optimized for code size.

For example:

    $ arm-none-eabi-gcc src.c --specs=nano.specs ${OTHER_OPTIONS}

This option can also work together with other specs options like:

    --specs=rdimon.specs

Please note that --specs=nano.specs is both a compiler and linker option. Be
sure to include in both compiler and linker options if compiling and linking
are separated.

** additional newlib-nano libraries usage

Newlib-nano is different from newlib in addition to the libraries' name.
Formatted input/output of floating-point number are implemented as weak symbol.
If you want to use %f, you have to pull in the symbol by explicitly specifying
"-u" command option.

    -u _scanf_float
    -u _printf_float

e.g. to output a float, the command line is like:

    $ arm-none-eabi-gcc --specs=nano.specs -u _printf_float ${OTHER_LINK_OPTIONS}

For more about the difference and usage, please refer the README.nano in the
source package.

Users can choose to use or not use semihosting by following instructions.
** semihosting
If you need semihosting, linking like:

    $ arm-none-eabi-gcc --specs=rdimon.specs ${OTHER_LINK_OPTIONS}

** non-semihosting/retarget
If you are using retarget, linking like:

    $ arm-none-eabi-gcc --specs=nosys.specs ${OTHER_LINK_OPTIONS}

* Linker scripts & startup code *

Latest update of linker scripts template and startup code is available on
https://developer.arm.com/tools-and-software/embedded/cmsis

* Samples *
Examples of all above usages are available at:

    ${install_dir}/gcc-arm-none-eabi-*/share/gcc-arm-none-eabi/samples

Read readme.txt under it for further information.

* GDB Server for CMSIS-DAP based hardware debugger *
CMSIS-DAP is the interface firmware for a Debug Unit that connects
the Debug Port to USB.  More detailed information can be found at
http://www.keil.com/support/man/docs/dapdebug/.

A software GDB server is required for GDB to communicate with CMSIS-DAP based
hardware debugger.  The pyOCD is an implementation of such GDB server that is
written in Python and under Apache License.

For those who are using this toolchain and have board with CMSIS-DAP based
debugger, the pyOCD is our recommended gdb server.  More information can be
found at https://github.com/mbedmicro/pyOCD.

Re: [EXTERNAL] Re: [meta-arm] building gcc-arm-none-eabi from source

[Stefan Herbrechtsmeier]

Am 04.01.2022 um 18:50 schrieb Alexander Kanavin:
> On Tue, 4 Jan 2022 at 16:39, Ross Burton <ross@burtonini.com 
> <mailto:ross@burtonini.com>> wrote:
> 
> 
>     Considering that the Arm GCC is mostly standard GCC with some
>     backports, and our GCC is often newer, simply using the standard GCC
>     (if the baremetal is arm-a) with -nostdlib should be sufficient?
> 
> 
> Stefan, can you clarify please? I think the baremetal side is not 
> actually arm-a?

We need a multilib compiler with newlib support for 32 bit arm-a, arm-r 
and most likely arm-m.

Re: [meta-arm] building gcc-arm-none-eabi from source

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

On Tue, 4 Jan 2022 at 10:24, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> It is true that you'd need a different target variant for the second
> option I
> mentioned.
>
> I did have something slightly similar with extensions to the gcc/binutils
> recipes for a cross AVR toolchain that runs on an arm target. I found some
> copies here, based on daisy which whilst old, gives the idea:
>
>
> https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/daisy&id=f58f90257a5af3e6b6974090e62cad9d90d53ae5
>
> I definitely have something more recent locally too (pyro, can't remember
> if I
> made it to dunfell with that code), I can dig that out if it is
> interesting. I
> thought somewhere I had a BBCLASSEXTEND recipe which added multiple cross
> compiler arches on target but I can't find that one :/.
>

After poking at the vendor toolchain a bit, I don't think building that
from source is a great option either. Perhaps the best solution is to use
the mcextend class to do the needed tweaks directly inside the binutils/gcc
recipes (or as bbappends in meta-arm perhaps). Does that sound about right?

Alex

[-- Attachment #2: Type: text/html, Size: 1712 bytes --]