| Message ID | 20230518182434.15531-1-GNUtoo@cyberdimension.org |
|---|---|
| Headers | show |
| Series | Add aarch64-none-elf-gcc-toolchain. | expand |
On Thu, May 18, 2023 at 08:24:34PM +0200, Denis 'GNUtoo' Carikli wrote: > Hi, > > Here's a patch serie to add a GCC cross toolchain for aarch64-none-elf. For > now it doesn't contain C++ support but that can be added on later. > > I've validated by building u-boot locally with it. I'm not entirely sure what this means. How is it different from how we build u-boot now? > I didn't test it for microncontroller development as I don't know what board > to get to test it. Apparently support for 64bit was added to Armv8-R, so it > might be possible to find some boards with 64bit CPUs at some point. Pity, this is what I was going to ask about. > Denis 'GNUtoo' Carikli (4): > gnu: Add aarch64-none-elf-binutils. > gnu: Add aarch64-none-elf-gcc. > gnu: Add aarch64-none-elf-newlib. > gnu: Add aarch64-none-elf-gcc-toolchain. > > gnu/local.mk | 1 + > gnu/packages/aarch64-none-elf-toolchain.scm | 159 ++++++++++++++++++++ > 2 files changed, 160 insertions(+) > create mode 100644 gnu/packages/aarch64-none-elf-toolchain.scm > > > base-commit: 5b700945fb0b33eec410de8979cae2fbf0d4f118 > -- > 2.40.1 I'm not opposed to adding these packages, but I want to make sure that they're useful for what people would be looking for. I also think that they'd be best in gnu/packages/embedded.scm near the very similar arm packages.
On Sun, 4 Jun 2023 11:43:16 +0300 Efraim Flashner <efraim@flashner.co.il> wrote: > On Thu, May 18, 2023 at 08:24:34PM +0200, Denis 'GNUtoo' Carikli > wrote: > > Hi, > > > > Here's a patch serie to add a GCC cross toolchain for > > aarch64-none-elf. For now it doesn't contain C++ support but that > > can be added on later. > > > > I've validated by building u-boot locally with it. > > I'm not entirely sure what this means. How is it different from how we > build u-boot now? My use case here is not to build the u-boot package but rather to build kernels and u-boot images outside of Guix, to build not-yet released revisions and/or to do kernel or u-boot development. That use case works fine if the host and target architectures are the same as people can simply install the gcc-toolchain package. But when it's not, it's convenient to be able to simply install packages of cross toolchains. Some distributions like Arch Linux[1], Debian[2], Ubuntu[3], and their derivatives (Parabola, PureOS, Trisquel, etc) do provide packages for cross toolchains. Here I've confirmed that the patches I submitted work fine by building u-boot from source (for aarch64) on an x86 laptop running Guix and by running the resulting u-boot images on hardware like the Pinephone (with u-boot patched to not use crust, and I didn't try to boot Linux) and the Rock 4C plus (this was more extensively tested than the Pinephone, I booted a Guix image on it etc). However I am unsure if the approach I took with my patch serie is the way to go here as here we have some duplication as some of the toolchain packages generated specifically for u-boot are for the exact same architecture (here aarch64). I also plan to add more toolchain packages (at least for or1k, RISCV 32). So at the end it kind of doubles the maintenance. In another hand my approach works and it also doesn't interfere with u-boot packages (so we don't have a risk of u-boot breakages when my toolchain packages are updated). What approach do you think would be best? Do you have ideas of better approaches than the ones I proposed here? PS: I also noticed later on that I need to update newlib to 4.1.0, but I can do that with a v2 or in a later patch depending on what you think is best. PPS: Note that when building u-boot or kernels locally (not as packages), in addition to the toolchain, there are also some tricks needed to make things work out of the box. For u-boot I use 'guix shell -D u-boot-rockpro64-rk3399 openssl@3 python python-pyelftools'. As I don't have to redistribute the binaries I didn't look into not using openssl@3, but I'll have to look into it at some point. I then have to pass HOSTCC=gcc to make as cc isn't defined. I also have to pass the usual CROSS_COMPILE=, BL31=, etc to make. For xconfig I have to use something like that: 'PKG_CONFIG_PATH=/gnu/store/[...]-qtbase-5.15.8/lib/pkgconfig/ make ARCH=arm HOSTCC=gcc xconfig'. References: ----------- [1]https://archlinux.org/packages/extra/x86_64/aarch64-linux-gnu-gcc/ [2]https://packages.debian.org/bullseye/gcc-10-aarch64-linux-gnu [3]https://packages.ubuntu.com/kinetic/gcc-10-aarch64-linux-gnu Denis.
On Sun, 4 Jun 2023 11:43:16 +0300 Efraim Flashner <efraim@flashner.co.il> wrote: > > I didn't test it for microncontroller development as I don't know > > what board to get to test it. Apparently support for 64bit was > > added to Armv8-R, so it might be possible to find some boards with > > 64bit CPUs at some point. > > Pity, this is what I was going to ask about. I've looked at it and there are no cortex-M that are 64bit yet. The only 64bit ARM CPUs are in cortex-A or cortex-R. Do you want me to write some simple code that outputs something on the serial port of a cortex A to validate the toolchain? > I'm not opposed to adding these packages, but I want to make sure that > they're useful for what people would be looking for. I also think that > they'd be best in gnu/packages/embedded.scm near the very similar arm > packages. Should I go forward and propose a v2 in gnu/packages/embedded.scm ? Should I keep the patch mostly as-is (with updated IASL, moved in embedded.scm) or should I rework it somehow? Denis.