Ricardo Wurmus <rek...@elephly.net> 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’.
