Hi,
we like the github repos of F+S and already adopted the repos.
What is missing is the toolchain repo (precompiled). I already created this repo on our side ([1]), but it would be great to simply mirror the latest github repo from F+S.
Can you do this. I can also share my repo with older versions (maybe not complete (see [2]).
[1]:
toolchain-armv7ahf
toolchain-armv8ahf
[2]:
Hello,
We would like to avoid hosting binaries files in a git repository, as it is not good practice and github restricts filesizes to 50MB max
(https://docs.github.com/en/rep…out-large-files-on-github)
What we are already planning, is hosting a git repository with the defconfig files of the toolchains and adding the binarie files as github releases, hosted on our SFTP servers.
(https://docs.github.com/en/rep…-on-github/about-releases)
Would this also be sufficient for you?
Your F&S Support Team
Hi.
Indeed. Binaries in repos are not a good thing. A download page with a list of all (and the latest) toolchains would be great and sufficient.
But please povide a link specially to the latest toolchain with every update (just like in github releases)
Thanks.
Hello again,
can you please update the status regarding:
QuoteWhat we are already planning, is hosting a git repository with the defconfig files of the toolchains and adding the binarie files as github releases, hosted on our SFTP servers.
On the otherside I noticed that the provided F+S toolchains are a combination of release and kernel (header files).
For some special projects we need to pair new projects with older kernels, e.g. toolchain 11.2 with the kernel 4.9 (all from the F+S universe).
Can you please provide the steps to compile the toolchains that are delivered with the F+S releases. Please include also the sources (links).
I would like to finish this in CW49. So please give me a fast feedback.
Thanks for your help.
Although there should be no dependency between the software and the toolchain version, the reality is different. There actually *are* some dependencies. For example newer toolchains do a more indepth analysis of the code to add more optimizations. However this has the "disadvantage", that those compilers may detect some irregularities in the code of older packages that were silently accepted in older toolchains. The new toolchain may issue lots of warnings or even errors then. On the other hand, a very old toolchain may not support all the language features of new packages (e.g. C++23) and may fail to build the package at all.
This is why the toolchain should always be of a roughly similar age as the packages it is used for. If the gap between the versions is very big, this condition may be difficult to fulfill.
We typically provide a new toolchain, if the userland packages of Buildroot need it, because there are new language features used by at least one package that the old toolchain was not capable to deal with. When configuring the toolchain, we typically provide headers so that at least the newest and the directly previous F&S release can be built. Otherwise also the headers and the support code increases and the toolchains get bigger and bigger.
There may also be dependencies between kernel and userspace packages. For example video deocding or OpenGL handling on NXP SoCs is split between a kernel driver and a userland library. And of course these two have to match properly. So if you use an older kernel with a new Buildroot rootfs, then these two may not cooperate correctly and the kernel may even crash. So be careful not to have a too big version gap between them.
We use crosstool-ng (https://crosstool-ng.github.io/) for our toolchains. After configuring the toolchain in a menuconfig-like selection system, you can start the build and then crosstool-ng will download all the source code packages and builds the toolchain. This is rather similar to Buildroots own concept.
Please note that there is also the possibility to let Buildroot build a toolchain or use a precompiled toolchain from other sources like codelinaro. This may be better related to your remaining build processes because it is not out-of-tree. Just play a little bit with the toolchain entry in the top menu of Buildroot's menuconfig.
Your F&S Support Team
Thanks for the reply.
I checked the options and decided to go for the buildroot toolchain. With the simple changes unter [1] the image was build with buildroot 2023.02.6 with the Linux kernel version 4.9.88.
Before the F+S toolchain version 8.3 was needed (11.2 was available), but buildroot was able to build the image with 11.4.
Thanks. CASE CLOSED.
[1]:
$ git show configs/fsimx6sx_min_efus_defconfig
commit bd2cebbf2fd03b439aae5836434b40ef0e7cb627 (HEAD -> STACC-LoadMuxer, origin/STACC-LoadMuxer)
Author: Maik Brenke <maik.brenke@continental-corporation.com>
Date: Mon Dec 9 16:43:03 2024 +0100
adjust kernel config to old version; set toolchain from ext. to int.; add note to README
diff --git a/configs/fsimx6sx_min_efus_defconfig b/configs/fsimx6sx_min_efus_defconfig
index 1da90b69..6d59e5eb 100644
--- a/configs/fsimx6sx_min_efus_defconfig
+++ b/configs/fsimx6sx_min_efus_defconfig
@@ -3,15 +3,7 @@ BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_ARM_FPU_NEON=y
-BR2_TOOLCHAIN_EXTERNAL=y
-BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
-BR2_TOOLCHAIN_EXTERNAL_PATH="/usr/local/arm/toolchain-armv7ahf"
-BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="arm-linux"
-BR2_TOOLCHAIN_EXTERNAL_GCC_11=y
-BR2_TOOLCHAIN_EXTERNAL_HEADERS_5_15=y
-BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
-# BR2_TOOLCHAIN_EXTERNAL_INET_RPC is not set
-BR2_TOOLCHAIN_EXTERNAL_CXX=y
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
BR2_TARGET_OPTIMIZATION="-pipe"
BR2_CCACHE=y
BR2_OPTIMIZE_3=y
@@ -26,7 +18,7 @@ BR2_ROOTFS_OVERLAY="rootfs_overlay"
BR2_ROOTFS_POST_BUILD_SCRIPT="board/f+s/fsimx6/finalscript_min-fsimx6sx"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="5.15.131"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.9.88"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="Kconfig"
BR2_LINUX_KERNEL_DTS_SUPPORT=y
