Future for armel? (was: Re: What to do with d-i on armel?)
[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
Reply to: