XPost: linux.debian.ports.arm
[dropped some recipients, this mail is not about d-i and the problem at
hand]
Hi
On Wed, Jan 10, 2024 at 08:34:27AM +0100, Arnd Bergmann wrote:
The most important ARMv5 platform is now probably at91, as
Microchip still releases new sam9 chips[1] and is going to
keep supporting it for a while.
If I interpret arch/arm/mach-at91/Kconfig correctly, then at91 is a
family with v4, v5 and v7 devices. The v7 ones should work with armhf,
so here we are only concerned about the v4 and v5 ones. For none of
them does Debian provide a kernel.
Since armel userland should work fine with any armhf or
arm64 kernel, it might still be useful to repackage
one or both of those for the armel archive and use this
to have an installation method for armel on modern
hardware.
But why? What is provided by an armel userland that armhf can't?
[Side note: I would also like to see an arm64
kernel image added to armhf, it's probably more useful
than the armmp-lpae kernel in terms of enabling users.]
Not gonna happen. "dpkg --add-architecture arm64" is the way to go.
At the moment, it is possible to enable support for
arm1176 (as in bcm2835) in a normal armhf kernel and
have that boot on armv6k, armv7 and armv8 hardware.
Our armhf is armv7. Does armv6k fullfil the requirements as well?
The armv8 hardware can just use our arm64 kernel.
I actually want to change that in the kernel though:
Now that we dropped SMP support in armv6, as it now
makes more sense to have armv6k grouped with armv5
and instead have a generic kernel for armel that
works on bcm2835, versatilepb, at91, kirkwood and
all the others that one might use.
Send patches?
Bastian
--
Virtue is a relative term.
-- Spock, "Friday's Child", stardate 3499.1
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)