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

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: [patch 09/14] tmpfs: disallow CONFIG_TMPFS_INODE64 on alpha

[Arnd Bergmann]

On Wed, Feb 10, 2021 at 8:17 PM Linus Torvalds
 wrote:
>
> On Wed, Feb 10, 2021 at 5:39 AM Heiko Carstens  wrote:
> >
> > I couldn't spot any and also gave the patch below a try and my system
> > still boots without any errors.
> > So, as far as I can tell it _should_ be ok to change this.
>
> So your patch (with the fix on top) looks sane to me.
>
> I'm not entirely sure it is worth it, but the fact that we've had bugs
> wrt this before does seem to imply that we should do this.
>
> I'd remove the __kernel_ino_t type entirely, but I wonder if user
> space might depend on it. I do find
>
>#ifndef __kernel_ino_t
>typedef __kernel_ulong_t __kernel_ino_t;
>#endif
>
> in the GNU libc headers I have, but then I don't find any actual use
> of that, so it looks like it may be jyst a "we copied things for other
> reasons".

I checked debian codesearch to see if there are any users in
distro source code and found exactly one instance that will
definitely break at compile time:

https://sources.debian.org/src/nfs-utils/1:1.3.4-4/support/include/nfs/nfs.h/?hl=99#L99

This is a copy of a kernel header that was removed ten years ago
with commit c152292f9ee7 ("nfsd: remove include/linux/nfsd/syscall.h").

The mainline version of that package removed the contents in 2016 in
the following release (2.1.1), but debian is still on the previous
version (1.3.4)
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fc1127d754578cd1

Someone will have to update the package for Debian, but it seems
that would be a good idea anyway.

  Arnd

Re: bullseye-installer fails on Cubox-i due to networking issue

[Arnd Bergmann]

On Thu, Dec 24, 2020 at 3:38 PM Rainer Dorsch  wrote:
>
> Hi,
>
> I tried to run the bullseye installer from
>
> http://ftp2.de.debian.org/debian/dists/bullseye/main/installer-armhf/current/
> images/netboot/SD-card-images/
>
> on a cubox-i using a serial console today.
>
> It seems the network interface does not come up properly:
>
> ~ # dmesg |grep eth
> [5.009246] fec 2188000.ethernet: Invalid MAC address: 00:00:00:00:00:00
> [5.015982] fec 2188000.ethernet: Using random MAC address: 4a:
> 0d:a7:66:c1:e6
> [5.028381] mdio_bus 2188000.ethernet-1: MDIO device at address 0 is
> missing.
> [  138.479638] fec 2188000.ethernet eth0: Unable to connect to phy
> [  139.674014] fec 2188000.ethernet eth0: Unable to connect to phy
> [  141.218830] fec 2188000.ethernet eth0: Unable to connect to phy
> [  147.400881] fec 2188000.ethernet eth0: Unable to connect to phy
> [  199.375688] fec 2188000.ethernet eth0: Unable to connect to phy
> [  736.031852] fec 2188000.ethernet eth0: Unable to connect to phy
> [  906.069383] fec 2188000.ethernet eth0: Unable to connect to phy
> [ 1156.891662] fec 2188000.ethernet eth0: Unable to connect to phy
> [ 1266.982998] fec 2188000.ethernet eth0: Unable to connect to phy

Which was the last kernel version on which it worked correctly?

There were a couple of regressions based on incorrect phy-mode
settings after a phy driver changed its behavior in an incompatible
way.

This should be the relevant hunk in your board, it was merged into
linux-5.2:

0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")

diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
index 4ccb7afc4b35..6d7f6b9035bc 100644
--- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
@@ -53,7 +53,7 @@ vcc_3v3: regulator-vcc-3v3 {
  {
pinctrl-names = "default";
pinctrl-0 = <_microsom_enet_ar8035>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-reset-duration = <2>;
phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>;
status = "okay";

If you have a dtb file from before that change and want to run it
on a newer kernel, at least this change is needed.

> ~ #
>
> Not sure if this backtrace is related or even expected:
>
> [5.626874] Freeing unused kernel memory: 2048K
> [5.632309] [ cut here ]
> [5.636982] WARNING: CPU: 0 PID: 1 at arch/arm/mm/dump.c:248
> note_page+0x3d0/0x3dc
> [5.644576] arm/mm: Found insecure W+X mapping at address 0xf0879000
> [5.650947] Modules linked in:
> [5.654033] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-4-armmp #1
> Debian 5.9.11-1
> [5.661953] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)

I see the current kernel version here, which is helpful in figuring out the
problem, but I don't think the warning is relevant here.

I do see two code changes that may be relevant

0da1ccbbefb6 ("net: fec: Fix PHY init after phy_reset_after_clk_enable()")
1e6114f51f9d ("net: fec: fix MDIO probing for some FEC hardware blocks")

both of them are backported into linux-5.9.y and are part of 5.9.7 or newer,
so you probably have them already, but there is a chance that one of
these patches caused a regression, so maybe try a v5.9.0 for comparison.

  Arnd

Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

[Arnd Bergmann]

On Saturday, December 3, 2016 4:36:37 AM CET Ben Hutchings wrote:
> On Fri, 2016-12-02 at 13:40 +0100, Arnd Bergmann wrote:
> > With binutils-2.16 and before, a weak missing symbol was kept during the
> > final link, and a missing CRC for an export would lead to that CRC
> > being treated as zero implicitly. With binutils-2.17, the crc
> > symbol gets dropped, and any module trying to use it will fail to
> > load.
> > 
> > This sets the weak CRC symbol to zero explicitly, making it defined
> > in vmlinux, which in turn lets us load the modules referring to
> > that CRC.
> > 
> > The comment above the __CRC_SYMBOL macro suggests that this was
> > always the intention, although it also seems that all symbols
> > defined in C have a correct CRC these days, and only the exports
> > that are now done in assembly need this.
> > 
> > > Signed-off-by: Arnd Bergmann <a...@arndb.de>
> > ---
> > Not sure if this is the correct way of doing it, but this seems trivial
> > enough and lets me build the kernel with missing CRCs with any binutils
> > version.
> 
> I tried this along with Adam's patch on x86_64, with Debian's binutils
> 2.27.51.20161127.  The result was that the kernel's __kcrctab held 0
> for several symbols, even though there was type information in asm-
> prototypes.h and Module.symvers and the modules had a non-zero CRC for
> those symbols.  With just Adam's patch, the kernel and modules agreed.

Can you be more specific? Which symbols are those? I would have expected
modpost to generate Module.symvers from the vmlinux file, so I wonder
where that difference comes from.

Arnd

Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

[Arnd Bergmann]

On Friday, December 2, 2016 1:59:15 PM CET Geert Uytterhoeven wrote:
> On Fri, Dec 2, 2016 at 1:40 PM, Arnd Bergmann <a...@arndb.de> wrote:
> > With binutils-2.16 and before, a weak missing symbol was kept during the
> 
> 2.26?
> 
> > final link, and a missing CRC for an export would lead to that CRC
> > being treated as zero implicitly. With binutils-2.17, the crc
> 
> 2.27?'

Yes, serious version number deficiency on my end. Also 4.9 instead of 3.9
in the subject...

Arnd

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Arnd Bergmann]

On Tuesday, November 29, 2016 9:14:46 AM CET Linus Torvalds wrote:
> On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds
>  wrote:
> >
> > So quite frankly, I don't want to make our kernel sources worse due to
> > broken shit tools getting something wrong that we shouldn't even care
> > about.
> 
> And yes, I'm on binutils 2.26 (with no issues), so it could be that
> it's 2.27 that triggers this.
> 
> We could make the pr_warn_once() mention "broken binutils?" so that
> people know why the warning happens.

I've tried to get to the bottom of this, but couldn't find anything
related to the toolchain version. I've tried binutils 2.23, 2.24, 2.26
and 2.27, and also gcc-7.0, gcc-5.4.1 and gcc-4.9.3, but with today's
linux-next, I always get

WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version generation 
failed, symbol will not be versioned.
WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation 
failed, symbol will not be versioned.
WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, 
symbol will not be versioned.
WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, 
symbol will not be versioned.
WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol 
will not be versioned.
WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, 
symbol will not be versioned.
WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, 
symbol will not be versioned.
WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol 
will not be versioned.

Out of 12 randconfig builds that had CONFIG_MODVERSIONS enabled, all 12
had this problem, though not always with all the symbols.

Arnd

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Friday 21 February 2014 01:47:31 Ben Hutchings wrote:
 On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote:
  On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:

  For all I know, the only interesting ixp4xx platforms are the consumer
  products listed on http://www.nslu2-linux.org/, the other ones you support
  are development boards that tend to exist only in very small quantities.
  
  The main limitation would be the amount of installed RAM, which is
  either 32MB or 64MB depending on the machine for these. Running a
  modern Debian with these constraints is probably possible but
  doesn't sound like fun. 
 
 Our most pressing constraint has actually been the size of the kernel
 partition in flash, which is only ~1.4 MB on some of the iop32x and
 ixp4xx machines (and ~1.5 MB on one of the orion5x machines).  We've
 modularised as much as possible and turned off some of the features that
 are otherwise standard across all Debian architectures.

Makes sense. I'm impressed you actually manage to get a modern kernel
in 1.5MB and have it boot up a (mostly) full distro. I think we have
in the past dropped a subarchitecture from the kernel when it turned
out its defconfig could no longer fit within the 2MB of flash it
has.

 But I got fed up with trying to make it fit, and no-one else stepped up
 to maintain the reduced configurations, so the last time iop32x went
 over the limit I removed it.  As Ian hinted, ixp4xx might follow.

Ok. As I mentioned, I believe OpenWRT is really the playground for
the remaining ixp4xx users that are doing new installs.

Arnd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1725547.sbei6Aef3A@wuerfel

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Friday 21 February 2014 02:00:27 Ben Hutchings wrote:
 On Thu, 2014-02-20 at 14:24 +, Ian Campbell wrote:
  On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote:
 [...]
   What i suspect we will end up doing it dropping the last patch for the
   moment and ensuring ARCH_KIRKWOOD still supports all the DT machines.
   I think that just needs care with arch/arm/boot/dts/Makefile.
   
   Once we have the last four converted over to DT, you can then do a
   straight swap, mach-kirkwood for mach-mvebu.
  
  That sounds like a good plan, thanks!
  
  If we are going to do a straight swap I suppose it might as go for a v5
  multiplatform flavour instead of a mvebu specific one.
 [...]
 
 I would love it if we could do that.
 
 By the way, we still have the problem that at least one supported
 orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition.
 So we would probably have to keep a reduced orion5x config for those
 machines, alongside the mvebu or multiplatform kernel.

orion5x is still some time away from being included in mvebu, 3.16 at
the earliest, so it will have to stay separate anyway.

My hope is really that we get very little overhead in enabling
multiplatform on mvebu compared to a orion5x or kirkwood standalone
configuration, so depending on what the platforms have you could
end up with e.g. a 1.5MB mini multiplatform kernel that includes
all machines that have 2MB or less for their kernel partitions and
a everything included multiplatform kernel for the machines with
larger partititons. For instance kirkwood-rd88f6281 has a 2MB
uImage partition and everything else seems to have at least 4MB.

Arnd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1438274.4sq9OA90up@wuerfel

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Thursday 20 February 2014 13:18:21 Andrew Lunn wrote:
 
 What this patchset does is also make mach-mvebu part of the multi v5
 kernel. So you just need one kernel for all ARM v5 machines which are
 part of multi v5. The long term goal is that you need just two 32 ARM
 kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
 yet part of theses, so we are not there yet.

BTW, if converting enough of orion5x to DT takes too long to
deprecate that platform any time soon, I'd prefer moving it
over to multiplatform while keeping the legacy board files
in there. That should get substantially easier once
mv78xx0, kirkwood and dove have been dealt with and we can
collapse plat-orion and mach-orion5x into one directory.

  IOW that all of the platforms currently supported by the
  Debian kirkwood flavour remain supportable in the same binary after this
  change. It looks like it should be to me, but I'm not 100% sure.
 
 If you don't support LaCie 2Big and 5Big, HP t5325 thin client and
 Marvell OpenRD then yes, you have one binary. That binary could
 potentially support over v5 machines, but i have no idea what ARM
 machines Debian actually supports. Is there a list somewhere?

http://anonscm.debian.org/viewvc/kernel/releases/linux/3.12.9-1/debian/config/armel/config.kirkwood?view=markup

just lists all kirkwood machines as enabled, but that of course
doesn't meant they are actually working or supported.

Arnd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/11515265.X2qOAjvHY6@wuerfel

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Thursday 20 February 2014 12:51:04 Ian Campbell wrote:
 On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote:
  On Thu, Feb 20, 2014 at 11:34:36AM +, Ian Campbell wrote:
 Debian has a single v7 flavour, armmp which uses the multi platform
 stuff. (actually there is a second armmp-lpae, but lets ignore that)
 
 I'm only really concerned about the v5 stuff here. Debian has multiple
 v5 flavours: ixp4xx, kirkwood, mv78xx0, orion5x and versatile.

Unfortunately, this selection include multiple platforms that
we don't plan to (ever) support in a multiplatform kernel, while
a lot of platforms you don't currently support are already enabled
or will be at some point.

* ixp4xx is too different from the others and I don't think it's
  possible to turn it over to multiplatform.
* I see a iop32x_defconfig in svn that you didn't mention here,
  but it's basically the same problem as ixp4xx.
* kirkwood/mv78xx0/orion5x are essentially one platform and work
  in progress.
* versatile is easy to do as multiplatform, I just haven't gotten
  around to do it.

ARMv5 platforms that are already working with ARCH_MULTIPLATFORM:
* freescale mxc (i.mx21 and i.mx25)
* freescale mxs (i.mx23 and i.mx28)
* st-ericsson Nomadik
* st-ericsson u300
* st spear3xx
* st spear6xx
* TI NSpire
* VIA/Wondermedia vt85xx/wm85xx/wm86xx

The embedded mxs family is probably most interesting among these,
but there is also a community around the wondermedia stuff, which is
used in cheap tablets and laptops.

  What this patchset does is also make mach-mvebu part of the multi v5
  kernel. So you just need one kernel for all ARM v5 machines which are
  part of multi v5. The long term goal is that you need just two 32 ARM
  kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not
  yet part of theses, so we are not there yet.
 
 So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot*
 coexist in the same binary?

That has been the plan for the kirkwood migration for the last few
years, yes. The idea is that every kirkwood machine that anyone is
interested in should be supported by ARCH_MVEBU, and we can keep
ARCH_KIRKWOOD for the ones we don't care about until it is just
dropped.

Same for orion5x, dove and mv78xx0, just a different schedule
for moving them over.

Now in theory, we could have them supported in a multiplatform kernel,
but that would mean extra work that we planned to avoid by converting
them to DT first.

As I said, it may be useful to do multiplatform support for MACH_ORION5x,
but for MACH_KIRKWOOD, we have come too far now to turn back.

Arnd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2127012.W6WnQnXmRo@wuerfel

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

[Arnd Bergmann]

On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:
 On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote:
  On Thursday 20 February 2014 12:51:04 Ian Campbell wrote:
  * ixp4xx is too different from the others and I don't think it's
possible to turn it over to multiplatform.
  * I see a iop32x_defconfig in svn that you didn't mention here,
but it's basically the same problem as ixp4xx.
 
 This is only in Wheezy and not in trunk (which will become Jessie). AIUI
 support for these has been dropped for the next version of Debian so
 Wheezy is the last one and we don't need to worry about upgrade for
 these.

Ok, I see.

 TBH I'm not sure that ixp4xx isn't in the same boat, I suppose we'll
 see.

For all I know, the only interesting ixp4xx platforms are the consumer
products listed on http://www.nslu2-linux.org/, the other ones you support
are development boards that tend to exist only in very small quantities.

The main limitation would be the amount of installed RAM, which is
either 32MB or 64MB depending on the machine for these. Running a
modern Debian with these constraints is probably possible but
doesn't sound like fun. ;-)

Also, the upstream kernel port isn't that well maintained, a lot
the development seems to have happened in OpenWRT and not mainlined,
including a dozen new machines that were already ported in 2009.

Then again, Martin Michlmayr has instructions for running Wheezy
on the 32MB nslu2, and I guess as long as he's interested in the
hardware, new versions of Debian will keep running on it.

  The embedded mxs family is probably most interesting among these,
  but there is also a community around the wondermedia stuff, which is
  used in cheap tablets and laptops.
 
 Interesting. I don't know how many of these are supported by Debian --
 mostly these things get added when someone acquires one and scratches
 that itch.
 
 I suppose if we could remove at least one existing flavour in favour of
 a v5 multiplatform config then there probably wouldn't be many
 objections to doing that.

That will probably come as a natural progression after kirkwood
gets replaced with mvebu.

  As I said, it may be useful to do multiplatform support for MACH_ORION5x,
  but for MACH_KIRKWOOD, we have come too far now to turn back.
 
 Understood. It sounds like mach-kirkwood is very close to being
 removable altogether though (by migrating the last few boards to
 mach-mvebu), which would make distro upgrades much simpler, since we can
 just do a straight swap rather than trying to figure out which one we
 need.

Yes, makes sense.

Arnd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/35719313.JyFlzSVKnx@wuerfel

Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

[Arnd Bergmann]

On Thursday 06 June 2013, Maxime Ripard wrote:
 So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
 inferior (because not generic enough) to the device tree, but they show
 interest on going down the mainline road.

Right, and of course there is nothing special about that, everybody starts
out with they own even vendor tree (c), and as hardware support gets merged
upstream, the diff gets smaller, even though the code in the mainline
kernel is normally very different from what they started out with.

Chances are actually that the Allwinner (A10/A13/A20, not A31) platform may
end up being the first modern one that is fully supported upstream including
a GPU driver, since it is one of the obvious targets for the
reverse-engineering efforts. Ironically (given NVIDIA's reputation), the
Tegra platform is the strongest competitor I see in that race at the moment.

For all I can tell, things are progressing nicely, given that it's currently
a volunteer effort. If anyone needs things to move faster, I'd recommend
them to send money to free-electrons.com.

Arnd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130606.53780.a...@arndb.de

Re: trying to use virtio with the wheezy installer on arm versatile oops

[Arnd Bergmann]

On Wednesday 26 September 2012, Arnaud Patard wrote:
 Torben Hohn torb...@linutronix.de writes:

  i tried to use virtio inside qemu-system-arm emulating versatile.
 
  getting this kernel oops:
 
  [  341.274760] pgd = cd818000   
  x
  [  341.274940] [44000412] 
  *pgd=qj
  [  341.275424] Internal error: Oops: 805 [#1]
  [  341.275756] Modules linked in: virtio_pci(+) virtio_ring virtio ohci_hcd 
  ehci_hcd usbcore smc91x mii usb_common
  [  341.276703] CPU: 0Not tainted  (3.2.0-3-versatile #1)
  [  341.277479] PC is at vp_reset+0xc/0x5c [virtio_pci]
  [  341.277834] LR is at register_virtio_device+0x44/0x8c [virtio]
 
 ok, easy to reproduce. Will look at that.
 
 Can you please open a bug report to keep track of this bug ?
 

Sorry, It's really my fault for not updating the patches I did back
then. The basic problem of course is missing I/O space support in
the versatile platform. The implementation would be done slightly
differently today, but basically my patches are still needed.

Arnd


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201209271421.53817.a...@arndb.de

Bug#340508: missing modules on s390/s390x (mkinitramfs for 2.6.14)

[Arnd Bergmann]

Am Sonntag 04 Dezember 2005 16:31 schrieb Frans Pop:
 Reason is that dasd_mod needs an option to tell it which dasd devices
 should be used. I've written a script that creates a config file for
 modprobe in /etc/modprobe.d/.
 The script is a first approximation and probably needs cleaning up.
 Background info and some possible issues are documented in the script.

Note that it is not required to pass the list of dasd devices when loading
the module. You also have the option of enabling devices through sysfs
or with one of the tools from s390tools (I forgot the name of the binary),
which is probably easier to do from initramfs.

Arnd 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]