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

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable

[Arno Lehmann]

Hi all,

I have now installed an early 6.1 kernel:

$ uname -a
Linux Zwerg 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 
(2023-01-07) x86_64 GNU/Linux


and not updated anything else. Also, still running with PCIe power 
management in non-default:


# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.1.0-1-amd64 root=/dev/mapper/Zwerg--vg-root ro 
pcie_aspm=off quiet



Let's see how long this works :-) Or, rather, how much patience I have. 
Failures were between few hours and up to four weeks apart...


Cheers,

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück