info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
What to do with d-i on armel?
21 views
Skip to first unread message
Bastian Blank
Jan 7, 2024, 5:30:05 PMJan 7
to
Hi
With Linux 6.6 we dropped the Marvell specific kernel image, as it
was not known to work on any of the available devices. We still have
another armel kernel left, the one of the Raspberry Pi 0 and 1, which
uses an ARMv6 CPU.
This also removed all the udebs from armel, which makes many d-i
components not longer have fullfiled dependencies and the release stuff
of course acting up.
Do we have any armel subarch that can be installed via d-i?
Bastian
--
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
With Linux 6.6 we dropped the Marvell specific kernel image, as it
was not known to work on any of the available devices. We still have
another armel kernel left, the one of the Raspberry Pi 0 and 1, which
uses an ARMv6 CPU.
This also removed all the udebs from armel, which makes many d-i
components not longer have fullfiled dependencies and the release stuff
of course acting up.
Do we have any armel subarch that can be installed via d-i?
Bastian
--
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Emanuele Rocca
Jan 9, 2024, 2:00:04 PMJan 9
to
Hi Bastian,
On Sun, Jan 07, 2024 at 11:07:48PM +0100, Bastian Blank wrote:
> Do we have any armel subarch that can be installed via d-i?
Not as far as I know, perhaps Sledge has more info on this? Also, I don't think
we've seen anyone mentioning armel in ages on debian-boot, both in terms of
installation reports and in general asking questions. Correct me if I'm wrong
though. Any armel users out there? :-)
On Sun, Jan 07, 2024 at 11:07:48PM +0100, Bastian Blank wrote:
> Do we have any armel subarch that can be installed via d-i?
we've seen anyone mentioning armel in ages on debian-boot, both in terms of
installation reports and in general asking questions. Correct me if I'm wrong
though. Any armel users out there? :-)
Martin
Jan 9, 2024, 5:30:05 PMJan 9
to
On 2024-01-09 19:56, Emanuele Rocca wrote:
> though. Any armel users out there? :-)
My employer uses Debian on armel, but not d-i :-)
> though. Any armel users out there? :-)
gene heskett
Jan 9, 2024, 7:00:05 PMJan 9
to
3d printing environment relies heavily on whatever runs the rp2040. A
whole industry has grown up around the combo of the adxl345 and an
rp2040 to measure resonances and tune them out, allowing the printer to
run several times faster with what is called "input shaping" The actual
device is about the size of a postage stamp on a teeny pcb. I do not
know which version of linux it is that the rp2040 is actually running.
For us, its one of those things that Just Works.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Peter Green
Jan 9, 2024, 8:40:05 PMJan 9
to
On 09/01/2024 23:33, gene heskett wrote:
> 3d printing environment relies heavily on whatever runs the rp2040. A whole industry has grown up around the combo of the adxl345 and an rp2040 to measure resonances and tune them out, allowing the printer to run several times faster with what is called "input shaping" The actual device is about the size of a postage stamp on a teeny pcb. I do not know which version of linux it is that the rp2040 is actually running. For us, its one of those things that Just Works.
The rp2040 does not run linux.
> 3d printing environment relies heavily on whatever runs the rp2040. A whole industry has grown up around the combo of the adxl345 and an rp2040 to measure resonances and tune them out, allowing the printer to run several times faster with what is called "input shaping" The actual device is about the size of a postage stamp on a teeny pcb. I do not know which version of linux it is that the rp2040 is actually running. For us, its one of those things that Just Works.
Arnd Bergmann
Jan 10, 2024, 3:00:04 AMJan 10
to
On Sun, Jan 7, 2024, at 23:07, Bastian Blank wrote:
> Hi
>
> With Linux 6.6 we dropped the Marvell specific kernel image, as it
> was not known to work on any of the available devices. We still have
> another armel kernel left, the one of the Raspberry Pi 0 and 1, which
> uses an ARMv6 CPU.
>
> This also removed all the udebs from armel, which makes many d-i
> components not longer have fullfiled dependencies and the release stuff
> of course acting up.
>
> Do we have any armel subarch that can be installed via d-i?
A few ideas from the kernel's point of view:
> Hi
>
> With Linux 6.6 we dropped the Marvell specific kernel image, as it
> was not known to work on any of the available devices. We still have
> another armel kernel left, the one of the Raspberry Pi 0 and 1, which
> uses an ARMv6 CPU.
>
> This also removed all the udebs from armel, which makes many d-i
> components not longer have fullfiled dependencies and the release stuff
> of course acting up.
>
> Do we have any armel subarch that can be installed via d-i?
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.
I would guess that the latest ones are not even that far off
the performance of the kirkwood/mv78xx0 or bcm2835 parts,
but I don't have numbers.
Qemu versatilepb is probably the most accessible arm926
platform, though there are a couple of other armv5/v6 (ast2400,
ast2500, pxa27x, raspi1ap) in qemu that one should be able
to get to work as well if anyone found the time.
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. [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.]
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.
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.
Arnd
[1] https://www.microchip.com/en-us/product/sam9x75
Bastian Blank
Jan 10, 2024, 4:00:04 AMJan 10
to
[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
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.
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.
> [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.]
> 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.
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.
Bastian
--
Virtue is a relative term.
-- Spock, "Friday's Child", stardate 3499.1
Martin
Jan 10, 2024, 4:50:04 AMJan 10
to
Quoting Bastian Blank <wa...@debian.org>:
> But why? What is provided by an armel userland that armhf can't?
My employer runs Debian on this armv5(?) hardware:
> But why? What is provided by an armel userland that armhf can't?
https://www.taskit.de/produkte/embedded-produkte/computer-on-module/132/stamp9g20-512f/128r
Sure, the kernel is not the Debian one, but something around 4.19.
Cheers
Dimitri John Ledkov
Jan 10, 2024, 5:50:04 AMJan 10
to
kernel nor debian d-i build for said arch. A sort of partial / rootfs
chroot-only arch.
--
Dimitri
Sent from Ubuntu Pro
https://ubuntu.com/pro
Arnd Bergmann
Jan 19, 2024, 12:00:03 PMJan 19
to
On Wed, Jan 17, 2024, at 23:54, Ben Hutchings wrote:
> accidentally; when I found out I removed it because no-one had
> complained in 9 months. (Maybe that was a bit quick!)
>
> We do have a configuration for RPi 0/1, which is supported with images
> at <https://raspi.debian.net/> rather than through d-i.
>
> I don't think anyone has proposed configurations to support the other
> platforms.
My guess is that the remaining armel users expect a bit of
manual work, and tend to have their own kernels. Setting up
qemu is rather tricky as well, so I would tend to assume I
made a mistake if I can't get the versatilepb kernel to work,
not a bug in the package.
I definitely put a lot of work into the kernel changes
myself that enabled us to have a multiplatform kernel
for all armv5 targets as of linux-6.1, and I think it's
a bit sad to see this not getting used in Debian at all.
>> 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. [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.]
>
> We used to do this for amd64 kernels on i386. Then Debian implemented
> multiarch and it became an unnecessary waste of build resources.
> Still, we are lacking support for adding a "foreign" architecture and
> kernel package at installation time.
mipsel (now discontinued) also does the same thing by
shipping only 64-bit kernels for loongson and octeon hardware,
plus a 32-bit kernel for the malta reference system.
The situation for mipsel and armhf is similar here, as
most modern SoCs really requires running a 64-bit kernel,
but you often don't have enough RAM to install the 64-bit
userland on small systems. On x86, this is usually not
an issue since all current 64-bit machines are still
able to boot a 32-bit installer and then get the 64-bit
kernel later.
Granted, this is much less important on armel today,
since there is really no reason to run armel userland
on armv7 or armv8 hardware other than for debugging.
It would be nice to have an easy way to run the armel
installer with an armhf kernel for setting up an armel
rootfs in qemu, but debvm probably fills this niche better
already. If armhf ever moves to requiring vfpv3-d32 and
neon, having an armel installer with an armv7 kernel
for the handful of non-neon machines would be helpful
though.
> (This specific combination would also be hard to support in the current
> linux packaging because arm64 and armhf have different kernel
> architectures and toolchains, unlike amd64 and i386.)
Right, though changing the kernel package to support this
sounds easier than changing the installer to use a
foreign architecture kernel package.
>> 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.
>> 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.
>
> If someone wants to make this work in Debian that would be great, but
> without a specific maintainer it's not going to happen.
Understood.
Arnd
> On Wed, 2024-01-10 at 08:34 +0100, Arnd Bergmann wrote:
>>
>> Qemu versatilepb is probably the most accessible arm926
>> platform, though there are a couple of other armv5/v6 (ast2400,
>> ast2500, pxa27x, raspi1ap) in qemu that one should be able
>> to get to work as well if anyone found the time.
>
> We used to have a configuration for Versatile, but it got broken
>>
>> Qemu versatilepb is probably the most accessible arm926
>> platform, though there are a couple of other armv5/v6 (ast2400,
>> ast2500, pxa27x, raspi1ap) in qemu that one should be able
>> to get to work as well if anyone found the time.
>
> accidentally; when I found out I removed it because no-one had
> complained in 9 months. (Maybe that was a bit quick!)
>
> We do have a configuration for RPi 0/1, which is supported with images
> at <https://raspi.debian.net/> rather than through d-i.
>
> I don't think anyone has proposed configurations to support the other
> platforms.
My guess is that the remaining armel users expect a bit of
manual work, and tend to have their own kernels. Setting up
qemu is rather tricky as well, so I would tend to assume I
made a mistake if I can't get the versatilepb kernel to work,
not a bug in the package.
I definitely put a lot of work into the kernel changes
myself that enabled us to have a multiplatform kernel
for all armv5 targets as of linux-6.1, and I think it's
a bit sad to see this not getting used in Debian at all.
>> 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. [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.]
>
> multiarch and it became an unnecessary waste of build resources.
> Still, we are lacking support for adding a "foreign" architecture and
> kernel package at installation time.
mipsel (now discontinued) also does the same thing by
shipping only 64-bit kernels for loongson and octeon hardware,
plus a 32-bit kernel for the malta reference system.
The situation for mipsel and armhf is similar here, as
most modern SoCs really requires running a 64-bit kernel,
but you often don't have enough RAM to install the 64-bit
userland on small systems. On x86, this is usually not
an issue since all current 64-bit machines are still
able to boot a 32-bit installer and then get the 64-bit
kernel later.
Granted, this is much less important on armel today,
since there is really no reason to run armel userland
on armv7 or armv8 hardware other than for debugging.
It would be nice to have an easy way to run the armel
installer with an armhf kernel for setting up an armel
rootfs in qemu, but debvm probably fills this niche better
already. If armhf ever moves to requiring vfpv3-d32 and
neon, having an armel installer with an armv7 kernel
for the handful of non-neon machines would be helpful
though.
> (This specific combination would also be hard to support in the current
> linux packaging because arm64 and armhf have different kernel
> architectures and toolchains, unlike amd64 and i386.)
Right, though changing the kernel package to support this
sounds easier than changing the installer to use a
foreign architecture kernel package.
>> 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.
>> 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.
>
> without a specific maintainer it's not going to happen.
Understood.
Arnd
Bastian Blank
Jan 19, 2024, 12:10:04 PMJan 19
to
On Fri, Jan 19, 2024 at 05:33:23PM +0100, Arnd Bergmann wrote:
> Right, though changing the kernel package to support this
> sounds easier than changing the installer to use a
> foreign architecture kernel package.
Well. It is a "dpkg --add-architecture" in the right spot of
> Right, though changing the kernel package to support this
> sounds easier than changing the installer to use a
> foreign architecture kernel package.
base-installer/debian/bootstrap-base.postinst.
Bastian
--
Yes, it is written. Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown
0 new messages