Re: What to do with d-i on armel?

[Paul Gevers]

Hi,

On 03-03-2024 9:01 p.m., Cyril Brulebois wrote:

Maybe have it marked Not-For-Us on armel, also requesting the binary to
be dropped there? And maybe poke the ftp team to have installer-armel/
cleaned up?


Those actions sound appropriate to me, but I don't know the inner 
details well enough to see if there are traps set out.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: What to do with d-i on armel?

[Adrian Bunk]

On Mon, Mar 04, 2024 at 09:52:14AM +0100, Gerardo Ballabio wrote:
> Gianluca Renzi wrote:
> > The same here. We never used the d-i but we are using Debian systems 
> > (kernel and root file system) as daily bases of our line of products 
> > embedded systems. Hundred of thousands of boards are using Debian since 
> > Debian Lenny 5.0. From armel to armhf 32 bit systems.
> > So a drop of the armel and/or armhf will force us to a very complicated 
> > rearrangement of our build systems.
> > Please don't do that if you can.
> 
> Hi Gianluca,
> if that is so important for your business, you might consider
> sponsoring some work on this issue.
> The Debian Long Term Support project
>  is about keeping "old stuff"
> working so that might be the right place to ask.

That's not the right place, LTS is about keeping *old Debian versions*
security supported for 2 additional years (and has dropped armel since stretch).

LTS is not doing anything at all regarding keeping older/unusual 
hardware supported, such work has to be done directly in Debian
(and upstream).

> Gerardo

cu
Adrian

Re: What to do with d-i on armel?

[Gerardo Ballabio]

Gianluca Renzi wrote:
> The same here. We never used the d-i but we are using Debian systems (kernel 
> and root file system) as daily bases of our line of products embedded 
> systems. Hundred of thousands of boards are using Debian since Debian Lenny 
> 5.0. From armel to armhf 32 bit systems.
> So a drop of the armel and/or armhf will force us to a very complicated 
> rearrangement of our build systems.
> Please don't do that if you can.

Hi Gianluca,
if that is so important for your business, you might consider
sponsoring some work on this issue.
The Debian Long Term Support project
 is about keeping "old stuff"
working so that might be the right place to ask.

Gerardo

Re: What to do with d-i on armel?

[Gianluca Renzi]

The same here. We never used the d-i but we are using Debian systems
(kernel and root file system) as daily bases of our line of products
embedded systems. Hundred of thousands of boards are using Debian since
Debian Lenny 5.0. From armel to armhf 32 bit systems.
So a drop of the armel and/or armhf will force us to a very complicated
rearrangement of our build systems.
Please don't do that if you can.

Best regards


Il lun 4 mar 2024, 01:34 Martin  ha scritto:

> On 2024-01-09 22:19, Martin wrote:
> > 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 :-)
>
> I should add: We never used d-i on armel and have our own kernel.
> Most other stuff is plain Debian, though.
>
>

Re: What to do with d-i on armel?

[Martin]

On 2024-01-09 22:19, Martin wrote:
> 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 :-)

I should add: We never used d-i on armel and have our own kernel.
Most other stuff is plain Debian, though.

Re: What to do with d-i on armel?

[Ástor Ayllón Lázaro]

just another armel-debian user here, running in an old intel es4000 since
2006.

On Sun, 3 Mar 2024, 20:31 Christoph Biedl, 
wrote:

> Emanuele Rocca wrote...
>
> > Any armel users out there? :-)
>
> Fairly late, but just to avoid the impression there aren't any left:
> Yes, here.
>
> But that's not an objection against plans in Debian kernel and/or d-i,
> I'm using my own kernel, and should I ever have the need of a new
> installation, I know how to debootstrap and the rest.
>
> Besides, the hardware is a Seagate DockStar, so
>
> Architecture:   armv5tel
>   Byte Order:   Little Endian
> CPU(s): 1
>   On-line CPU(s) list:  0
> Vendor ID:  Marvell
>   Model name:   Feroceon-88FR131
>
> and 128 Mbytes of RAM. Running Debian stable already requires some hacks
> to not end up in thrashing, I might do a presentation "Running Debian on
> small systems" some day about it.
>
> In summary, I'm glad Debian keeps supporting this device - but I'm
> aware the good times are in the past and it will very likely become
> e-waste before the hardware dies. If not Debian ends the support, the
> Linux kernel will.
>
> Christoph
>

Re: What to do with d-i on armel?

[Cyril Brulebois]

Bastian Blank  (2024-01-07):
> 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?

Unless we get something to support in d-i, I'm wondering how to proceed
with dropping support for armel. Unsupported things tend to move to
ports while still being supported by porters, so we don't have much to
do there besides go with the flow. That'd be the first time (that I can
think of) that we have an FTBFS-ing d-i for an architecture that's in
unstable.

Maybe have it marked Not-For-Us on armel, also requesting the binary to
be dropped there? And maybe poke the ftp team to have installer-armel/
cleaned up? (The “disabling daily builds” part being trivial.)

I see no time pressure here, we have a big transition going on, so it
doesn't seem particularly fitting to try and get a d-i release out any
day soon.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: What to do with d-i on armel?

[Christoph Biedl]

Emanuele Rocca wrote...

> Any armel users out there? :-)

Fairly late, but just to avoid the impression there aren't any left:
Yes, here.

But that's not an objection against plans in Debian kernel and/or d-i,
I'm using my own kernel, and should I ever have the need of a new
installation, I know how to debootstrap and the rest.

Besides, the hardware is a Seagate DockStar, so

Architecture:   armv5tel
  Byte Order:   Little Endian
CPU(s): 1
  On-line CPU(s) list:  0
Vendor ID:  Marvell
  Model name:   Feroceon-88FR131

and 128 Mbytes of RAM. Running Debian stable already requires some hacks
to not end up in thrashing, I might do a presentation "Running Debian on
small systems" some day about it.

In summary, I'm glad Debian keeps supporting this device - but I'm
aware the good times are in the past and it will very likely become
e-waste before the hardware dies. If not Debian ends the support, the
Linux kernel will.

Christoph


signature.asc
Description: PGP signature

Re: What to do with d-i on armel?

[Bastian Blank]

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
base-installer/debian/bootstrap-base.postinst.

Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown

Re: What to do with d-i on armel?

[Arnd Bergmann]

On Wed, Jan 17, 2024, at 23:54, Ben Hutchings wrote:
> 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
> 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  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

Re: What to do with d-i on armel?

[Ben Hutchings]

On Wed, 2024-01-10 at 08:34 +0100, Arnd Bergmann wrote:
> 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:
> 
> 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.

We used to have a configuration for Versatile, but it got broken
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  rather than through d-i.

I don't think anyone has proposed configurations to support the other
platforms.

> 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.

(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.)

> 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.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.



signature.asc
Description: This is a digitally signed message part

Re: What to do with d-i on armel?

[Arnd Bergmann]

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:

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

Re: What to do with d-i on armel?

[Martin]

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 :-)

Re: What to do with d-i on armel?

[Emanuele Rocca]

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? :-)