Re: [WIP] Cross-compiler for arm-none-eabi

[Ludovic Courtès]

Ricardo Wurmus <address@hidden> skribis:

> Now, I have a problem with this toolchain: it doesn’t seem to work
> properly.  While I can build “patches” for Axoloti that are linked with
> the pre-compiled firmware from upstream, I cannot seem to create a
> working firmware binary (that’s ChibiOS with extensions).  There are no
> errors when I build it; it generates an elf file.  But when it is
> uploaded to the board the system won’t boot.  I have to flash upstream’s
> binary firmware with dfu-util to revive the board.

You’re using the exact same GCC, Binutils, and newlib as others, right?

> Generating “patches” on the other hand works fine.  It’s really just
> this:
>
> ~~~~~~~~~~~
> /gnu/store/p787lrv17m25v0cdrdzw66r9b7hk1109-gcc-cross-sans-libc-arm-none-eabi-4.9.3-1.224288/bin/arm-none-eabi-g++
>  -nostdlib -fno-exceptions -fno-rtti -mcpu=cortex-m4 -O3 -fomit-frame-pointer 
> -falign-functions=16 -mfloat-abi=hard -mfpu=fpv4-sp-d16 
> -fsingle-precision-constant -Wunused-parameter -DCORTEX_USE_FPU=TRUE 
> -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -mthumb -DTHUMB 
> -std=c++11 -DARM_MATH_CM4 -D__FPU_PRESENT -H 
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/CMSIS/Include
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/ports/common/ARMCMx/CMSIS/include
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/ports/common/ARMCMx
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/ports/GCC/ARMCMx
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/ports/GCC/ARMCMx/STM32F4xx
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/kernel/include
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/include
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32F4xx
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32/GPIOv2
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32/I2Cv1
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32/OTGv1
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32/RTCv2
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32/SPIv1
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32/TIMv1
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/os/hal/platforms/STM32/USARTv1
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/boards/ST_STM32F4_DISCOVERY
>  
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios/ext/fatfs/src
>  -I. 
> -I/gnu/store/ysyi04kr6y4sbp5s6yyvpy3kl2yhppyh-axoloti-patcher-1.0.6/share/axoloti/chibios
>  -Winvalid-pch -MD -MP --include /home/rekado/axoloti/build/xpatch.h -c 
> /home/rekado/axoloti/build/xpatch.cpp -o /home/rekado/axoloti/build/xpatch.o 
> ~~~~~~~~~~~
>
> Since the command that works does not involve the linker as far as I can
> tell my guess is that the linker is somehow broken (or that maybe
> linking with “newlib” instead “glibc” doesn’t quite work).

I don’t understand this sentence, because you’re saying it does *not*
involve the linker.

But anyway, is a “patch” a standalone, statically-linked executable?  Or
is it just an object file like the one produced by the command above?

If it’s just a .o, then the linker cannot be faulty (but then newlib
isn’t used at all, apart from its headers.)

Some comments on the patch while I’m at it:  ;-)

> +      (arguments
> +       `(,@(substitute-keyword-arguments (package-arguments parent)
> +             ((#:configure-flags flags)
> +              `(cons "--enable-multilib"
> +                     (delete "--disable-multilib" ,flags)))))))))

`(,@foo) is equivalent to: foo.

Would be nice to comment on why it enables multilib support.

> +              `(modify-phases ,phases
> +                 (add-after 'unpack 'fix-genmultilib
> +                   (lambda _
> +                     (substitute* "gcc/genmultilib"
> +                       (("#!/bin/sh") (string-append "#!" (which "sh"))))

I would expect this to be handled by the ‘patch-source-shebangs’ phase,
no?

Good luck!  :-)

Ludo’.