All arm64/aarch64 platforms disabled in linux-libre 6.7.x!

The linux-libre 6.7.x package contains ... as far as I can tell, no

supported arm64/aarch64 platforms! This is a pretty significant

regression from the linux-libre 6.6.x packaging!

This appears to have been introduced in

95a3aaf7ad37bb0717f2c9e3faf6f636b586d133

Unfortunately it is all too easy to drop features with non-x86

platforms... especially if you run make *config from an x86 machine.

For example:

diff -u /gnu/store/dnism9x21x0x15k91ngis54w6pcf7gmi-linux-libre-6.6.12/.config /gnu/store/a6xc9aad9kv8xpy7i94ga74h6hs7gdvk-linux-libre-6.7.3/.config | grep -A20 '# Platform selection'

# Platform selection

#

# CONFIG_ARCH_ACTIONS is not set

-CONFIG_ARCH_SUNXI=y

+# CONFIG_ARCH_SUNXI is not set

# CONFIG_ARCH_ALPINE is not set

-CONFIG_ARCH_APPLE=y

-CONFIG_ARCH_BCM=y

-CONFIG_ARCH_BCM2835=y

-# CONFIG_ARCH_BCM_IPROC is not set

-CONFIG_ARCH_BCMBCA=y

-# CONFIG_ARCH_BRCMSTB is not set

+# CONFIG_ARCH_APPLE is not set

+# CONFIG_ARCH_BCM is not set

# CONFIG_ARCH_BERLIN is not set

-CONFIG_ARCH_BITMAIN=y

+# CONFIG_ARCH_BITMAIN is not set

# CONFIG_ARCH_EXYNOS is not set

# CONFIG_ARCH_SPARX5 is not set

# CONFIG_ARCH_K3 is not set

# CONFIG_ARCH_LG1K is not set

There are basically no CONFIG_ARCH platforms enabled!

I am not sure that all the previous platforms were intentionally added,

but at the very least SUNXI, ROCKCHIP, BCM2835 and probably quite a few

others should be added back. I am currently running Guix System in a

virtualized environment, but in the past I've run it on a sunxi systems

such as pinebook and pine64+... and rockchip systems such as

pinebook-pro, rock64-rk3328 and rockpro64-rk3399.

This also makes me wonder what other more subtle features got dropped

along the way, as well as platform support for other architectures... :/

I don't have the time at the moment to come up with a patch, but 6.7.x

should probably not become the default linux-libre until this is

at least partly fixed...

live well,

vagrant

Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> writes:

I'll generate a new arm/arm64 config for the 6.7.x series that doesn't

fall behind the 6.6.x series config; and will test it on my pinebook pro

at least before sending in a patch.

Although I have yet to pin down why this happened in the 6.7.x update as

I didn't do anything significantly different than while preparing the

6.6.x series (e.g. copying the old config, running makeconfig and

enabling as much support as possible in the prompts).

So far as a quick rundown:

λ rg -f <(rg --pcre2 -o '.*(?=\=y)' 6.6-arm64.conf | awk '{print $0 ".*not set"}') 6.7-arm64.conf | wc -l

678

678 config options that previously have been set aren't set anymore.

I hacked together a simple script based on the 6.6.x series platform

selection to use with new releases to check, that all platforms that

have been enabled before stay enabled. But maybe a better way would be

to use #:extra-options in the *-arm-generic package definitions to

ensure there, that the options will stay enabled at least for the ones

mentioned above. WDYT?

Agreed.

--

Kind regards,

Wilko Meyer

w@wmeyer.eu

On Thu, Feb 08, 2024 at 07:57:38AM +0100, Wilko Meyer wrote:

Huh!

When I was generating configs, I never did anything very special to

ensure continued aarch64 support in new kernel series except for `make

ARCH=arm64 oldconfig`.

It would be useful if others would help by testing the patches adding

new kernel series on aarch64 or other non-x86_64 platforms. In my

observation that rarely happens. And then bugs like this can slip in.

Thanks Wilko! Let us know if we can help.

gnu/packages/aux-files/linux-libre/6.7-arm64.conf: Add platform support.

Change-Id: I90dee088ab11a31cb526b396d675e7bc22d67297

---

.../aux-files/linux-libre/6.7-arm.conf | 3447 ++++++++++++-----

.../aux-files/linux-libre/6.7-arm64.conf | 2906 +++++++++-----

2 files changed, 4386 insertions(+), 1967 deletions(-)

severity 68988 important

quit

On Fri, Feb 09, 2024 at 09:28:14PM +0100, Wilko Meyer wrote:

Thanks! Pushed to 'kernel-updates' along with the latest releases.

Pushed as 877abbdae790deaacf30af8a845e2290c39e10ff

On 2024-02-08, Leo Famulari wrote:

Maybe a stray typo, e.g. ARCH=amd64 vs. ARCH=arm64 ? Only one-letter

difference and a slight position shift ... easy to think one thing and

type another!

At any rate, I can confirm that it now works again on a virtualized

arm64 system! I can probably test this when introducing a new series if

given a heads-up.

I haven't yet tested other physical systems, but glancing

over the diff looks promising...

Thanks for the fix!

live well,

vagrant