Issues cross-compiling arm with QMK

Issues cross-compiling arm with QMK

[Kristoffer Ström]

When trying to compile keyboard firmware using the qmk toolkit, i run
into this error:

./lib/pico-sdk/src/rp2_common/hardware_base/include/hardware/address_mapped.h:94:19: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

     uint32_t rc = (uintptr_t)addr;


Which seems to me to indicate that the cross-toolchain is trying to
produce 64-bit binaries.

i based my build shell manifest off of
https://github.com/mrvdb/qmk_atreus which is an avr-based board and
replacing (make-avr-toolchain) with
(make-arm-none-eabi-nano-toolchain-x), i have tried all available
versions.

Is there a way to specify a toolchain for cross-compiling into 32bit arm
binaries?

Re: Issues cross-compiling arm with QMK

[Ekaitz Zarraga]

Hi Kristoffer,

On 2024-03-09 18:50, Kristoffer Ström wrote:
> 
> When trying to compile keyboard firmware using the qmk toolkit, i run
> into this error:
> 
> ./lib/pico-sdk/src/rp2_common/hardware_base/include/hardware/address_mapped.h:94:19: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> 
>       uint32_t rc = (uintptr_t)addr;
> 
> 
> Which seems to me to indicate that the cross-toolchain is trying to
> produce 64-bit binaries.
> 
> i based my build shell manifest off of
> https://github.com/mrvdb/qmk_atreus which is an avr-based board and
> replacing (make-avr-toolchain) with
> (make-arm-none-eabi-nano-toolchain-x), i have tried all available
> versions.
> 
> Is there a way to specify a toolchain for cross-compiling into 32bit arm
> binaries?

You should use `(make-arm-none-eabi-toolchain-*whatever*)` but I have 
bad news.

There are *many* issues with this. I reported this a while ago:

https://lists.gnu.org/archive/html/help-guix/2023-09/msg00087.html

And many other people did more questions after that:

https://lists.gnu.org/archive/html/guix-devel/2023-12/msg00180.html

But I didn't manage to fix this yet.

In fact, I found similar issues in other architectures, mostly because 
all of them share the same problem:

https://issues.guix.gnu.org/69394

Maybe making a Guix package which has your firmware as an output might 
work, at this very moment, the problem is our modified GCCs are unable 
to find the proper libraries and they explode.

I can't fix this, and it's affecting me severely and I feel a little bit 
helpless about it... I don't know what we should do.

I might organize in the near future and make my own toolchain like the 
one shown in the second link to fix my personal issue and start helping 
everyone that reports this... But at the moment there's not much I can do.

Maybe someone else can help better.

I'll try to keep an eye in this subject, but if you fix it, please let 
me know.

Best,
Ekaitz