Re: Old platforms: bring out your dead

Re: Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hi Arnd!

(Please let's have this cross-posted for more visibility. I only learned about this
 while reading Phoronix news)

> I also looked at non-ARM platforms while preparing for my article. Some of
> these look like they are no longer actively maintained or used, but I'm not
> doing anything about those unless the maintainers would like me to:
> 
> * h8300: Steven Rostedt has repeatedly asked about it to be removed
>    or fixed in 2020 with no reply. This was killed before in 2013, added back
>    in 2015 but has been mostly stale again since 2016

As far as I know, Yoshinori Sato is actively maintaining H8300 support, see:

> https://osdn.net/projects/uclinux-h8/

> * c6x: Added in 2011, this has seen very few updates since, but
>     Mark still Acks patches when they come. Like most other DSP platforms,
>     the model of running Linux on a DSP appears to have been obsoleted
>     by using Linux on ARM with on-chip DSP cores running bare-metal code.
> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>    is currently under review

I don't think this has reached any agreement yet. Multiple people want it to stay.

> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
>    it's in my backlog but I will get to it. This is separate from PS3,
> which is actively
>    maintained and used; spufs will move to ps3
> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009

I'm still using this. Please keep it.

> * powerpc/amigaone: last updated in 2009
> * powerpc/maple: last updated in 2011
> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
>    seen updates in many years (atari/amiga/mac and coldfire are very much
>    alive)

Dito. I have both sun3 and hp300 machines.

> * mips/jazz: last updated in 2007
> * mips/cobalt: last updated in 2010
> 
> There might be some value in dropping old CPU support on architectures
> and platforms that are almost exclusively used with more modern CPUs.
> If there are only few users, those can still keep using v5.10 or v5.4 stable
> kernels for a few more years. Again, I'm not doing anything about them,
> except mention them since I did the research.
> These are the oldest one by architecture, and they may have reached
> their best-served-by-date:
> 
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>   indications that 486 have no users either on recent kernels.
>   There is still the Vortex86 family of SoCs, and the oldest of those were
>   486SX-class, but all the modern ones are 586-class.
> * Alpha 2106x: First generation that lacks some of the later features.
>   Since all Alphas are ancient by now, it's hard to tell whether these have
>   any fewer users.

I don't see the point in crippling Alpha support. Does this achieve anything?

> * IA64 Merced: first generation Itanium (2001) was quickly replaced by
>   Itanium II in 2002.
> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
>   64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
>   supports these in DECstation and Toshiba Txx9, but it appears that most
>   of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
>   later are rather different and widely used.
> * PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
>   are apparently all still used.
> * SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
>   support in the past, I don't think there were any objections, but
>   nobody submitted a patch.

Isn't SH-2 basically J-2? I'm not sure what we would gain here.

> * 68000/68328 (Dragonball): these are less capable than the
>   68020+ or the Coldfire MCF5xxx line and similar to the 68360
>   that was removed in 2016.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Old platforms: bring out your dead

[Sam Ravnborg]

Hi all,
> Hi Arnd!
> 
> (Please let's have this cross-posted for more visibility. I only learned about this
>  while reading Phoronix news)
> 
> > I also looked at non-ARM platforms while preparing for my article. Some of
> > these look like they are no longer actively maintained or used, but I'm not
> > doing anything about those unless the maintainers would like me to:
> > 

> > * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
> >    is currently under review
> 
> I don't think this has reached any agreement yet. Multiple people want it to stay.

None of the people that replied have any real use of the sun4m port,
they only wanted it to stay because they had some machines or such.
In other words - people will be sad if we sunset sun4m, but it will not
hurt anyone as there are no users left.

I will include the above summary when I post v2 of the patch to sunset
sun4m and sun4d. Then we will see what we conclude in the end.

Right now in am in demolition mode as I have a new house that requires a
total refactoring. So linux stuff is lower on the priority list so v2
will wait until I have time to do any necessary follow-up.

	Sam

Re: Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hello!

On 1/10/21 10:46 PM, Sam Ravnborg wrote:
>> I don't think this has reached any agreement yet. Multiple people want it to stay.
> 
> None of the people that replied have any real use of the sun4m port,
> they only wanted it to stay because they had some machines or such.
> In other words - people will be sad if we sunset sun4m, but it will not
> hurt anyone as there are no users left.
> 
> I will include the above summary when I post v2 of the patch to sunset
> sun4m and sun4d. Then we will see what we conclude in the end.

I'm not sure I understand the reasoning for doing this. The SPARC architecture
isn't going to see any new hardware developments in the future after Oracle
let go of most of the SPARC developers. So it's not that we need to make room
for new hardware.

And I also disagree with Arnd's stance that a port seems broken because it
doesn't see frequent or recent changes. As pointed out by Thomas Bogendoerfer
in this thread [1], missing updates don't necessarily mean that something
is broken but it can also just mean the hardware is fully supported and
working, so why fix something that isn't broken?

On the other hand, there are really serious bugs in the kernel that easily
allow crashing the whole machine (here on POWER [2] or here on SPARC [3])
that never get addressed.

We have a $10k IBM POWER server in Debian Ports which hosts a big-endian
PowerKVM build server instance and regularly hard-crashes because of the
bug in [2]. This bug has remained unfixed for almost a year now.

On top of that, some of the tree-wide conversions like [4] have completely
broken the Linux kernel on certain machines so that any larger ia64 servers
are stuck on the 4.14 kernel with no fix in sight. Before that, the kernel
worked perfectly fine on these machines.

I understand that cleaning up code and modernizing things is important, but
I think that the top priority should be to deliver something that is stable
and usable by the enduser.

But kernel development shouldn't be about scratching an itch which I sometimes
have the impression is the main driver behind some changes in the kernel.

I have personally invested a lot of time and effort in the past years to get
Debian into shape on exotic and older architectures and I feel all this effort
goes to waste when upstream projects just decide to kill of a certain platform
in the kernel or toolchain like it already happened with PowerPCSPE in GCC.

Adrian

> [1] https://lore.kernel.org/lkml/20210108234430.GA17487@alpha.franken.de/
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=206669
> [3] https://marc.info/?l=linux-sparc&m=160967865029609&w=2
> [4] https://marc.info/?l=linux-ia64&m=156144480821712&w=2

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Old platforms: bring out your dead

[chase rayfield]

On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:

>
> I'm not sure I understand the reasoning for doing this. The SPARC architecture
> isn't going to see any new hardware developments in the future after Oracle
> let go of most of the SPARC developers. So it's not that we need to make room
> for new hardware.
>
My take is that there *would* be more interest in Sparc sun4m / Sun4d
from enthusiasts at the very least if it was possible to actually boot
the bloat hog that is Linux these days in a fully usable configuration
that probably means some modifications to SILO and Linux required.

The problem is as I understand it, SILO only sets up a 16Mb mapping
(either due to having to assume 4MB minimum dram stick size or due to
mapping limitations not sure, most of these machines have at least
16MB in slot one...these days though that wasn't the case for sun4c),
loads Linux into it and says good Luck. This isn't enough for a modern
kernel with any  hardware support built in. So you might for instance
get a kernel to fit but only if you dropped all of networking support
etc... I'm guessing the fix for this would be to modify silo to map a
larger amount in a way that Linux expects so it can remap it as it
likes, or just have SILO map the full memory as Linux would. Anyway
that is THE main demotivation for these architectures.... otherwise
they have plenty of ram and performance to do basic router/server
tasks sans SSL.

This has been the status quo for since the last of the 2.6 series of
kernels which it was still possible to just barely squeeze a usable
kernel out of... If someone wanted to take a few hours and fix this
issue, and keep these architectures around I'd be happy to "buy them a
round of pizza", though I recognize that many people that work on this
already have nice jobs, and just don't have time.

Also Sparc would probably be a good project for someone to extend/test
Andi Keen's Linux LTO patch set so we could reduce the kernel binary
size that way also even if sun4 architectures are dropped, it would
still be useful for embedded sparc. Also there is a port of Temlib to
the Mister hardware now, 3 cores roughly equivalent to a mid 90s
machine, at least 128MB ram is possible ( more if a way to map the ARM
system memory also 1GB is available there, it would have higher
latency though).

It is perfectly viable to build Sparc v7 or v8 32bit binaries in a
chroot on a fast machine also, and I would recommend this if you wish
to retain sanity rather than attempting cross compiler voodoo, unless
that is your thing.

Anyways it could be that people that want this get around to fixing
SILO eventually and just sit on this last kernel version... *shrugs*

Chase

Re: Old platforms: bring out your dead

[Rob Landley]

On 1/11/21 8:55 AM, chase rayfield wrote:
> On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> 
>>
>> I'm not sure I understand the reasoning for doing this. The SPARC architecture
>> isn't going to see any new hardware developments in the future after Oracle
>> let go of most of the SPARC developers. So it's not that we need to make room
>> for new hardware.
>>
> My take is that there *would* be more interest in Sparc sun4m / Sun4d
> from enthusiasts at the very least if it was possible to actually boot
> the bloat hog that is Linux these days in a fully usable configuration
> that probably means some modifications to SILO and Linux required.

You can trim current linux down a bit, it's just non-obvious how. Unfortunately
there's an "expert" menu and CONFIG_EMBEDDED and if you touch anything there's
suddenly a hundred extra options in your config with no explanation of what they do.

At least 50% of what you want is probably disabling the printk strings that
aren't visible at your default verbosity level, but alas you must open pandora's
box to access those options...

> The problem is as I understand it, SILO only sets up a 16Mb mapping
> (either due to having to assume 4MB minimum dram stick size or due to
> mapping limitations not sure, most of these machines have at least
> 16MB in slot one...these days though that wasn't the case for sun4c),
> loads Linux into it and says good Luck. This isn't enough for a modern
> kernel with any  hardware support built in. So you might for instance
> get a kernel to fit but only if you dropped all of networking support
> etc... I'm guessing the fix for this would be to modify silo to map a
> larger amount in a way that Linux expects so it can remap it as it
> likes, or just have SILO map the full memory as Linux would. Anyway
> that is THE main demotivation for these architectures.... otherwise
> they have plenty of ram and performance to do basic router/server
> tasks sans SSL.

A lot of people with hardware like this haven't stopped using it, they've just
stopped fighting with kernel upgrades. (Common issue in the embedded world. Not
really a fun thing for security, but )

> This has been the status quo for since the last of the 2.6 series of
> kernels which it was still possible to just barely squeeze a usable
> kernel out of... If someone wanted to take a few hours and fix this
> issue, and keep these architectures around I'd be happy to "buy them a
> round of pizza", though I recognize that many people that work on this
> already have nice jobs, and just don't have time.

My https://github.com/landley/toybox/blob/master/scripts/mkroot.sh ~250 line
bash script generates the simplest kernel configs for a bunch of platforms to
boot qemu to a shell prompt, but you then have to open the "expert" menu and
_disable_ stuff in order to get the size down from there.

> Also Sparc would probably be a good project for someone to extend/test

Sparc has a runtime relocation I've never understood but did manage to break
once, resulting in a long thread to fix:

http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html

Between that and the weird save half the stack register thing with function
calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk
Rich into adding support for it to musl.

> Andi Keen's Linux LTO patch set so we could reduce the kernel binary
> size that way also even if sun4 architectures are dropped, it would
> still be useful for embedded sparc. Also there is a port of Temlib to
> the Mister hardware now, 3 cores roughly equivalent to a mid 90s
> machine, at least 128MB ram is possible ( more if a way to map the ARM
> system memory also 1GB is available there, it would have higher
> latency though).
> 
> It is perfectly viable to build Sparc v7 or v8 32bit binaries in a
> chroot on a fast machine also, and I would recommend this if you wish
> to retain sanity rather than attempting cross compiler voodoo, unless
> that is your thing.

It is, sadly, my thing. The above 250 line bash script builds:

aarch64  armv7l  i686        mips    powerpc      s390x  x86_64
armv4l   armv7m  m68k        mips64  powerpc64    sh2eb
armv5l   i486    microblaze  mipsel  powerpc64le  sh4

That's toybox booting to a shell prompt and a linux kernel configured for qemu
for each target. Adding new targets looks something like:

elif [ "$TARGET" == m68k ]; then
  QEMU="m68k -M q800" KARCH=m68k KARGS=ttyS0 VMLINUX=vmlinux
KCONF=MMU,M68040,M68KFPU_EMU,MAC,SCSI_MAC_ESP,MACINTOSH_DRIVERS,ADB,ADB_MACII,NET_CORE,MACSONIC,SERIAL_PMACZILOG,SERIAL_PMACZILOG_TTYS,SERIAL_PMACZILOG_CONSOLE
elif [ "$TARGET" = s390x ]; then
  QEMU="s390x" KARCH=s390 VMLINUX=arch/s390/boot/bzImage
KCONF=MARCH_Z900,PACK_STACK,NET_CORE,VIRTIO_NET,VIRTIO_BLK,SCLP_TTY,SCLP_CONSOLE,SCLP_VT220_TTY,SCLP_VT220_CONSOLE,S390_GUEST

(Well, modulo thunderbird being unable to an indent a line that goes off the
right edge of the screen. The mozilla foundation somehow managed to spend half a
billion dollars in 2019 but it wasn't on thunderbird, I can tell you that.)

Anyway, I wrote a couple FAQ entries trying to explain the worst of it:

  https://landley.net/toybox/faq.html#cross
  https://landley.net/toybox/faq.html#mkroot

> Anyways it could be that people that want this get around to fixing
> SILO eventually and just sit on this last kernel version... *shrugs*

They're never sitting on the _last_ kernel version. They're generally way back
from there. Been true forever off of x86 (and now arm):

https://lore.kernel.org/lkml/201002211025.11588.rob@landley.net/T/

> Chase

Rob

Re: Old platforms: bring out your dead

[chase rayfield]

> Sparc has a runtime relocation I've never understood but did manage to break
> once, resulting in a long thread to fix:
>
> http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html
>
> Between that and the weird save half the stack register thing with function
> calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk
> Rich into adding support for it to musl.
>
Register windowing, with parts of each window overlapping for function
arguments etc... you can kind of think of it as a ring buffer of
overlapping register files that's an oversimplification but it was
originally intended to accelerate and improve register file usage.
MIPS and the rest of the industry abandoned this for improved compile
time allocation. I think you might be more likely on MIPS to incur
more interrupt latency though since you have to spill to memory (at
least on MIPS contemporary to Sparc V8) instead of just switching
register windows mileage varies greatly.... From what I remember
overflowing the register file is implemented with hardware traps that
spill to memory etc... since you don't know that information at
compile time. on Sparc so yeah it's quite involved to understand and I
certainly don't grasp it fully. So on MIPS you spill the register file
to memory, on Sparc you spill register windows to memory... if you
have exceeded the supported call depth (which is rather expensive
since all the register windows go at once). Note spilling a single
variable within a register window is a separate issue.

Amazing, a link that actually works and is informative:
https://blogs.oracle.com/d/flush-register-windows


Chase

Re: Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hello!

On 1/11/21 3:55 PM, chase rayfield wrote:
> My take is that there *would* be more interest in Sparc sun4m / Sun4d
> from enthusiasts at the very least if it was possible to actually boot
> the bloat hog that is Linux these days in a fully usable configuration
> that probably means some modifications to SILO and Linux required.

The Linux kernel is configurable. If you want a small kernel, then just
configure one. No one expects you to boot a fully-fledged distribution
kernel on these machines.

> The problem is as I understand it, SILO only sets up a 16Mb mapping
> (either due to having to assume 4MB minimum dram stick size or due to
> mapping limitations not sure, most of these machines have at least
> 16MB in slot one...these days though that wasn't the case for sun4c),
> loads Linux into it and says good Luck. This isn't enough for a modern
> kernel with any  hardware support built in. So you might for instance
> get a kernel to fit but only if you dropped all of networking support
> etc...

That makes no sense. It worked in the past, why shouldn't it work nowadays?

As I said, you disable everything you don't need. I'm booting my SH-7785LCR
SuperH board with a kernel that is less than 4 MB in size and which includes
everything I need.

> I'm guessing the fix for this would be to modify silo to map a
> larger amount in a way that Linux expects so it can remap it as it
> likes, or just have SILO map the full memory as Linux would. Anyway
> that is THE main demotivation for these architectures.... otherwise
> they have plenty of ram and performance to do basic router/server
> tasks sans SSL.

Or just configure a smaller kernel.

> This has been the status quo for since the last of the 2.6 series of
> kernels which it was still possible to just barely squeeze a usable
> kernel out of... If someone wanted to take a few hours and fix this
> issue, and keep these architectures around I'd be happy to "buy them a
> round of pizza", though I recognize that many people that work on this
> already have nice jobs, and just don't have time.

I haven't gotten around to setup my SPARCstation 5 yet, but I will certainly
going to do that later this year to give it a try.

> Also Sparc would probably be a good project for someone to extend/test
> Andi Keen's Linux LTO patch set so we could reduce the kernel binary
> size that way also even if sun4 architectures are dropped, it would
> still be useful for embedded sparc. Also there is a port of Temlib to
> the Mister hardware now, 3 cores roughly equivalent to a mid 90s
> machine, at least 128MB ram is possible ( more if a way to map the ARM
> system memory also 1GB is available there, it would have higher
> latency though).
> 
> It is perfectly viable to build Sparc v7 or v8 32bit binaries in a
> chroot on a fast machine also, and I would recommend this if you wish
> to retain sanity rather than attempting cross compiler voodoo, unless
> that is your thing.

We build anything SPARC on a SPARC T5 that we have for Debian, no need
for cross-compilation and that machine is actually quite fast.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Old platforms: bring out your dead

[Rob Landley]

On 1/10/21 3:46 PM, Sam Ravnborg wrote:
> Hi all,
>> Hi Arnd!
>>
>> (Please let's have this cross-posted for more visibility. I only learned about this
>>  while reading Phoronix news)
>>
>>> I also looked at non-ARM platforms while preparing for my article. Some of
>>> these look like they are no longer actively maintained or used, but I'm not
>>> doing anything about those unless the maintainers would like me to:
>>>
> 
>>> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>>>    is currently under review
>>
>> I don't think this has reached any agreement yet. Multiple people want it to stay.
> 
> None of the people that replied have any real use of the sun4m port,
> they only wanted it to stay because they had some machines or such.
> In other words - people will be sad if we sunset sun4m, but it will not
> hurt anyone as there are no users left.
> 
> I will include the above summary when I post v2 of the patch to sunset
> sun4m and sun4d. Then we will see what we conclude in the end.

I used to regression test it in my cross builds but I switched my
toolchains/userspace from uClibc to musl-libc a couple years back, and musl
never added sparc support.

Rob

Re: Old platforms: bring out your dead

[Gerhard Pircher]

Am 10.01.21 um 18:35 schrieb John Paul Adrian Glaubitz:
> Hi Arnd!
>
> (Please let's have this cross-posted for more visibility. I only learned about this
>  while reading Phoronix news)
Same for me!

>> I also looked at non-ARM platforms while preparing for my article. Some of
>> these look like they are no longer actively maintained or used, but I'm not
>> doing anything about those unless the maintainers would like me to:
>>
>> * h8300: Steven Rostedt has repeatedly asked about it to be removed
>>    or fixed in 2020 with no reply. This was killed before in 2013, added back
>>    in 2015 but has been mostly stale again since 2016
>
> As far as I know, Yoshinori Sato is actively maintaining H8300 support, see:
>
>> https://osdn.net/projects/uclinux-h8/
>
>> * c6x: Added in 2011, this has seen very few updates since, but
>>     Mark still Acks patches when they come. Like most other DSP platforms,
>>     the model of running Linux on a DSP appears to have been obsoleted
>>     by using Linux on ARM with on-chip DSP cores running bare-metal code.
>> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>>    is currently under review
>
> I don't think this has reached any agreement yet. Multiple people want it to stay.
>
>> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
>>    it's in my backlog but I will get to it. This is separate from PS3,
>>    which is actively maintained and used; spufs will move to ps3
>> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
>
> I'm still using this. Please keep it.
I can also confirm that Pegasos2 users in the Amiga scene are running Linux
(Debian) on these machines.

>> * powerpc/amigaone: last updated in 2009
I still have 2 of the 3 types of the first generation AmigaOne machines (not
to be confused with the newer AmigaOne X1000 and X5000 machines based on
PASemi and P5020 CPUs) working here. A third machine needs a repair of the
G4 CPU module (replacement parts already available).
I have to admit however that I yet have to setup an environment that allows
me to regularly test new Linux kernel versions on these machines. Especially
because there are not many Linux users for these machines - which is likely
due to the fact that no distribution officially supports these machines out
of the box (the Pegasos2 platform had more luck here). Inputs on how to
automate tests would therefore be very welcome!
Given however that the Debian PowerPC port has a proper maintainer again
(kudos to Adrian!) and there is also another new PowerPC distro (Void Linux),
I would like to ask for a period of grace. After all this is just a hobby
project for me, so keeping up with the pace of the Linux development isn't
always that easy (and no, work on this did not stop in 2009, but shifted more
towards distro support since then).

>> * powerpc/maple: last updated in 2011
>> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
>>    seen updates in many years (atari/amiga/mac and coldfire are very much
>>    alive)
>
> Dito. I have both sun3 and hp300 machines.
>
>> * mips/jazz: last updated in 2007
>> * mips/cobalt: last updated in 2010
>>
>> There might be some value in dropping old CPU support on architectures
>> and platforms that are almost exclusively used with more modern CPUs.
>> If there are only few users, those can still keep using v5.10 or v5.4 stable
>> kernels for a few more years. Again, I'm not doing anything about them,
>> except mention them since I did the research.
>> These are the oldest one by architecture, and they may have reached
>> their best-served-by-date:
>>
>> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>>   indications that 486 have no users either on recent kernels.
>>   There is still the Vortex86 family of SoCs, and the oldest of those were
>>   486SX-class, but all the modern ones are 586-class.
>> * Alpha 2106x: First generation that lacks some of the later features.
>>   Since all Alphas are ancient by now, it's hard to tell whether these have
>>   any fewer users.
>
> I don't see the point in crippling Alpha support. Does this achieve anything?
>
>> * IA64 Merced: first generation Itanium (2001) was quickly replaced by
>>   Itanium II in 2002.
>> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
>>   64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
>>   supports these in DECstation and Toshiba Txx9, but it appears that most
>>   of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
>>   later are rather different and widely used.
>> * PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
>>   are apparently all still used.
>> * SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
>>   support in the past, I don't think there were any objections, but
>>   nobody submitted a patch.
>
> Isn't SH-2 basically J-2? I'm not sure what we would gain here.
>
>> * 68000/68328 (Dragonball): these are less capable than the
>>   68020+ or the Coldfire MCF5xxx line and similar to the 68360
>>   that was removed in 2016.
>
> Adrian
>

Re: Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hello Gerhard!

On 1/11/21 4:04 PM, Gerhard Pircher wrote:
>>> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
>>>    it's in my backlog but I will get to it. This is separate from PS3,
>>>    which is actively maintained and used; spufs will move to ps3
>>> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
>>
>> I'm still using this. Please keep it.
>
> I can also confirm that Pegasos2 users in the Amiga scene are running Linux
> (Debian) on these machines.

Thanks for raising your voice. It's nice and reliable hardware after all and
still fast enough to run a recent version of Debian unstable with a lean
desktop such as XFCE or MATE.
 
>>> * powerpc/amigaone: last updated in 2009
>
> I still have 2 of the 3 types of the first generation AmigaOne machines (not
> to be confused with the newer AmigaOne X1000 and X5000 machines based on
> PASemi and P5020 CPUs) working here. A third machine needs a repair of the
> G4 CPU module (replacement parts already available).

Cool.

> I have to admit however that I yet have to setup an environment that allows
> me to regularly test new Linux kernel versions on these machines. Especially
> because there are not many Linux users for these machines - which is likely
> due to the fact that no distribution officially supports these machines out
> of the box (the Pegasos2 platform had more luck here). Inputs on how to
> automate tests would therefore be very welcome!

Are you on the debian-powerpc mailing list? If not, please subscribe and post
your issues there:

> https://lists.debian.org/debian-powerpc/

> Given however that the Debian PowerPC port has a proper maintainer again
> (kudos to Adrian!) and there is also another new PowerPC distro (Void Linux),
> I would like to ask for a period of grace. After all this is just a hobby
> project for me, so keeping up with the pace of the Linux development isn't
> always that easy (and no, work on this did not stop in 2009, but shifted more
> towards distro support since then).

Yeah, I have the same impression that's the strong commercial interest pushes
hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
they're motivated by corporate decisions.

There has to be a healthy balance between hobbyist and commercial use. I understand
that from a commercial point of view, it doesn't make much sense to run Linux
on a 30-year-old computer. But it's a hobbyist project for many people and hacking
Linux stuff for these old machines has a very entertaining and educational factor.

Plus, as Thomas Bogendoerfer already mentioned in this thread, most of the old ports
run just fine. I have an Alpha XP-1000 building Debian packages for the Debian
Alpha port and it runs 24/7 without a hick and is regularly kept up-to-date with
dist-upgrades.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Old platforms: bring out your dead

[Linus Walleij]

On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:

> Yeah, I have the same impression that's the strong commercial interest pushes
> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
> they're motivated by corporate decisions.
>
> There has to be a healthy balance between hobbyist and commercial use. I understand
> that from a commercial point of view, it doesn't make much sense to run Linux
> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
> Linux stuff for these old machines has a very entertaining and educational factor.

This is actually one of the most interesting things written in this discussion.

I have both revamped and deleted subarchitectures in the ARM tree. We
never deleted anyone's pet project *unless* they were clearly unwilling to
work on it (such as simply testning new patches) and agreed that it will
not go on.

At multiple occasions I actually found it easier to fix stuff than
delete it, both because it is a nicer thing to do and because it
simply creates less social problems, often to the point that the time
(man hours) spent trying to solve the resulting social problems from
deleting a platform would be longer than the time spent actually acquiring
the physical platform and fixing it.

Corporate entities can be a bit deletionist (using Wikipedia terminology)
and as in this thread there is always a strong inclusionist stance pushing
back to that.

The explanation is in my mind very simply that running Linux
on a 35-yo or so Amiga, Atari or Apollo Workstation is pretty impressive and
fun. And I think that fits Mr. Torvalds own sociological-or-something
explanation in the autobiographical "Just for fun" as to why to write it
in the first place. And we are very protective of that quality of the
kernel. (At least I am.)

That said there are a three things that people should really be doing if they
want to keep their pet archs/subarchs around as good community
members, and they are in essence to:

1. Test and review/ack patches that others make

2. Migrate existing drivers to newly appeared and
    appropriate subsystems (I think there are some hacky heartbeat LED
    drivers down in arch/* for example) there is also the feature matrix
    core maintainers like and which appears if you type
    Documentation/features/list-arch.sh <archname>
    would be nice if you work on them if you can support them!
    Or at least take a look.

3. Migrate old systems to use the
   contemporary hardware descriptions (such as device tree or ACPI)
   because it makes things so much easier to maintain. Some
   upfront work, but a great win for everyone. Especially for
   subsystem maintainers.

And if your arch uses highmem then please get rid of highmem. I'm
trying to do this a bit right now for ARM let's see how it goes.

I understand that for some maintainers time is a factor and this list
feels stressful. I'd say relax, but it'd be nice if you have a TODO that
you cross items off of.

Just my €0.01
Linus Walleij

Re: Old platforms: bring out your dead

[Rob Landley]

On 1/12/21 4:46 PM, Linus Walleij wrote:
> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> 
>> Yeah, I have the same impression that's the strong commercial interest pushes
>> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
>> they're motivated by corporate decisions.
>>
>> There has to be a healthy balance between hobbyist and commercial use. I understand
>> that from a commercial point of view, it doesn't make much sense to run Linux
>> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
>> Linux stuff for these old machines has a very entertaining and educational factor.
> 
> This is actually one of the most interesting things written in this discussion.
> 
> I have both revamped and deleted subarchitectures in the ARM tree. We
> never deleted anyone's pet project *unless* they were clearly unwilling to
> work on it (such as simply testning new patches) and agreed that it will
> not go on.

Another fun aspect of old hardware is it serves as prior art for patents. The
j-core hardware implementation schedule has in part been driven by specific
patents expiring, as in "we can't do $FEATURE until $DATE".

It's much easier to nip a patent suit in the bud if you can go "here is
functionally equivalent hardware from the past, dates the specifications were
published, and the specific patents on the technology which have now expired".

We're a little overscheduled and not always _prompt_ about it, but for example
the reason we couldn't do full 6-wire sd 1.0 in the first j-core SOC release
(and had to implement a painfully slow mmc bus instead) is the patents hadn't
expired yet.

> That said there are a three things that people should really be doing if they
> want to keep their pet archs/subarchs around as good community
> members, and they are in essence to:
> 
> 1. Test and review/ack patches that others make

I'm trying. :)

> 2. Migrate existing drivers to newly appeared and
>     appropriate subsystems (I think there are some hacky heartbeat LED
>     drivers down in arch/* for example) there is also the feature matrix
>     core maintainers like and which appears if you type
>     Documentation/features/list-arch.sh <archname>
>     would be nice if you work on them if you can support them!
>     Or at least take a look.

For 3 years in the 1990's SuperH was the best-selling processor in the world,
and that's left the architecture with a bunch of legacy boards that aren't
easily available to us. I regression test a current kernel build under qemu
every month or two, and have portable USB-powered boards for the j-core stuff.

When I did an sh4 porting contract in 2018 I got that board updated to a
current-ish kernel (3 versions back from then-current it hit some intermittent
nor flash filesystem corruption that only occurred intermittently under
sustained load; had to ship so I backed off one version and never tracked it
down). But these days I'm not always on the same continent as my two actual sh4
hardware boards, have never gotten my physical sh2 board to boot, and $DAYJOB is
all j-core stuff not sh4.

Testing that a basic superh system still builds and boots under qemu and j-core
I can commit to doing regularly. Testing specific hardware devices on boards I
don't regularly use is a lot harder.

> 3. Migrate old systems to use the
>    contemporary hardware descriptions (such as device tree or ACPI)
>    because it makes things so much easier to maintain. Some
>    upfront work, but a great win for everyone. Especially for
>    subsystem maintainers.

We did that one for our SOC. We haven't ported a lot of legacy boards because we
can't easily test most of them.

> And if your arch uses highmem then please get rid of highmem. I'm
> trying to do this a bit right now for ARM let's see how it goes.

I don't believe it does? (We haven't got any configs using it, anyway...)

> I understand that for some maintainers time is a factor and this list
> feels stressful. I'd say relax, but it'd be nice if you have a TODO that
> you cross items off of.

My todo list runneth over. One of our perpetual todo list items is "collate todo
lists"...

> Just my €0.01
> Linus Walleij

Rob

Re: Old platforms: bring out your dead

[Geert Uytterhoeven]

Hi Rob,

On Wed, Jan 13, 2021 at 8:58 AM Rob Landley <rob@landley.net> wrote:
> On 1/12/21 4:46 PM, Linus Walleij wrote:
> > On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> > <glaubitz@physik.fu-berlin.de> wrote:
> >> Yeah, I have the same impression that's the strong commercial interest pushes
> >> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
> >> they're motivated by corporate decisions.
> >>
> >> There has to be a healthy balance between hobbyist and commercial use. I understand
> >> that from a commercial point of view, it doesn't make much sense to run Linux
> >> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
> >> Linux stuff for these old machines has a very entertaining and educational factor.
> >
> > This is actually one of the most interesting things written in this discussion.
> >
> > I have both revamped and deleted subarchitectures in the ARM tree. We
> > never deleted anyone's pet project *unless* they were clearly unwilling to
> > work on it (such as simply testning new patches) and agreed that it will
> > not go on.
>
> Another fun aspect of old hardware is it serves as prior art for patents. The
> j-core hardware implementation schedule has in part been driven by specific
> patents expiring, as in "we can't do $FEATURE until $DATE".

Indeed, so that's why the release of j4 is postponed to 2016...
/me runs date (again).

> When I did an sh4 porting contract in 2018 I got that board updated to a
> current-ish kernel (3 versions back from then-current it hit some intermittent
> nor flash filesystem corruption that only occurred intermittently under
> sustained load; had to ship so I backed off one version and never tracked it
> down). But these days I'm not always on the same continent as my two actual sh4
> hardware boards, have never gotten my physical sh2 board to boot, and $DAYJOB is
> all j-core stuff not sh4.

Which is not upstream, investing in the future?

> Testing that a basic superh system still builds and boots under qemu and j-core
> I can commit to doing regularly. Testing specific hardware devices on boards I
> don't regularly use is a lot harder.

I have the sh7751-based landisk in my board farm, so it's receiving
regular boot testing.  That's one of the simpler SH-based platforms,
though.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Old platforms: bring out your dead

[Rob Landley]

On 1/13/21 2:21 AM, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Wed, Jan 13, 2021 at 8:58 AM Rob Landley <rob@landley.net> wrote:
>> On 1/12/21 4:46 PM, Linus Walleij wrote:
>>> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
>>> <glaubitz@physik.fu-berlin.de> wrote:
>>>> Yeah, I have the same impression that's the strong commercial interest pushes
>>>> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
>>>> they're motivated by corporate decisions.
>>>>
>>>> There has to be a healthy balance between hobbyist and commercial use. I understand
>>>> that from a commercial point of view, it doesn't make much sense to run Linux
>>>> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
>>>> Linux stuff for these old machines has a very entertaining and educational factor.
>>>
>>> This is actually one of the most interesting things written in this discussion.
>>>
>>> I have both revamped and deleted subarchitectures in the ARM tree. We
>>> never deleted anyone's pet project *unless* they were clearly unwilling to
>>> work on it (such as simply testning new patches) and agreed that it will
>>> not go on.
>>
>> Another fun aspect of old hardware is it serves as prior art for patents. The
>> j-core hardware implementation schedule has in part been driven by specific
>> patents expiring, as in "we can't do $FEATURE until $DATE".
> 
> Indeed, so that's why the release of j4 is postponed to 2016...
> /me runs date (again).

We renamed it J32 because although the patents have expired the trademarks have
not, and provoking Renesas' lawyers more than necessary seemed gratuitous.

It's actually been feature complete for years now, but we've never ported the
kernel to it. (Rich has been working on a kernel port since new year's though.
Jeff Garzik sponsored some engineering time in our 2021 budget to finally get
that done, which has been our blocker for publishing because the lab tests don't
guarantee we won't have to change bits of the API in response to real world loads.)

>> When I did an sh4 porting contract in 2018 I got that board updated to a
>> current-ish kernel (3 versions back from then-current it hit some intermittent
>> nor flash filesystem corruption that only occurred intermittently under
>> sustained load; had to ship so I backed off one version and never tracked it
>> down). But these days I'm not always on the same continent as my two actual sh4
>> hardware boards, have never gotten my physical sh2 board to boot, and $DAYJOB is
>> all j-core stuff not sh4.
> 
> Which is not upstream, investing in the future?

Alas I'm not in charge of what is cleared for public release. (I complain about
it on the weekly calls from time to time.) We have actual marketing people now
(Mike and Bunga) so I'm not supposed to do the website in raw stylesheet-less
html with vi anymore.

Unpublished stuff we _mean_ to publish is a form of technical debt. It
_shouldn't_ be (release early release often) but Jeff insists on doing
everything in Mercurial which makes dogfooding our github repos as part of our
normal process darn awkward, and once there a little out of sync with the rest
of the build it becomes a todo item...

Rob

Re: Old platforms: bring out your dead

[Andy Shevchenko]

On Wed, Jan 13, 2021 at 9:58 AM Rob Landley <rob@landley.net> wrote:
> On 1/12/21 4:46 PM, Linus Walleij wrote:

...

> Testing that a basic superh system still builds and boots under qemu and j-core
> I can commit to doing regularly. Testing specific hardware devices on boards I
> don't regularly use is a lot harder.

In our lab we have different hardware connected (including non-x86,
mostly due to maintenance and testing drivers) and it allows us to run
more or less fresh kernels on it. Setup is pretty simple: server with
connected USB 2 serial, network, etc, power cutters, relays to emulate
power button presses for the hardware that can't be turned off and on
by cutting the main power (usual case for tablets / phones) and so on.
From a software point of view we use a netboot image [1][2] which
allows us to kexec kernel downloaded via net.

Now to the point, perhaps organizations like LF can set up something
like this with one technician to support this and pay electricity /
internet bills?

[1]: https://github.com/andy-shev/linux/tree/netboot (just a set of
kernel configuration options on top of defaults)
[2]: https://github.com/andy-shev/buildroot/tree/intel/board/intel/common
(see README in the folder)

-- 
With Best Regards,
Andy Shevchenko

Re: Old platforms: bring out your dead

[Geert Uytterhoeven]

Hi Linus,

On Wed, Jan 13, 2021 at 4:20 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> That said there are a three things that people should really be doing if they
> want to keep their pet archs/subarchs around as good community
> members, and they are in essence to:

> 2. Migrate existing drivers to newly appeared and
>     appropriate subsystems (I think there are some hacky heartbeat LED
>     drivers down in arch/* for example) there is also the feature matrix
>     core maintainers like and which appears if you type
>     Documentation/features/list-arch.sh <archname>
>     would be nice if you work on them if you can support them!
>     Or at least take a look.

The choir is listening ;-)

For Amiga, that would require writing a real GPIO driver (modifying
gpio-mmio?) for the CIAs, and converting its users (amiflop, amijoy,
amimouse, parport_amiga, amiserial, and dmasound_paula) from direct CIA
register access to GPIO access (mctrl_gpio for amiserial)).
Note that the heartbeat LED is shared by heartbeat and audio.

An interim solution might be to just write a simple gpio driver for the
single CIA pin driving the heartbeat LED, allowing the user to set up
ledtrig-heartbeat.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Tue, Jan 12, 2021 at 11:46 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
>
> > Yeah, I have the same impression that's the strong commercial interest pushes
> > hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
> > they're motivated by corporate decisions.
> >
> > There has to be a healthy balance between hobbyist and commercial use. I understand
> > that from a commercial point of view, it doesn't make much sense to run Linux
> > on a 30-year-old computer. But it's a hobbyist project for many people and hacking
> > Linux stuff for these old machines has a very entertaining and educational factor.
>
> This is actually one of the most interesting things written in this discussion.
>
> I have both revamped and deleted subarchitectures in the ARM tree. We
> never deleted anyone's pet project *unless* they were clearly unwilling to
> work on it (such as simply testning new patches) and agreed that it will
> not go on.
>
> At multiple occasions I actually found it easier to fix stuff than
> delete it, both because it is a nicer thing to do and because it
> simply creates less social problems, often to the point that the time
> (man hours) spent trying to solve the resulting social problems from
> deleting a platform would be longer than the time spent actually acquiring
> the physical platform and fixing it.
>
> Corporate entities can be a bit deletionist (using Wikipedia terminology)
> and as in this thread there is always a strong inclusionist stance pushing
> back to that.

It's usually one of two things that happened before a platform gets
deleted for good:

* The platform port was (almost) exclusively done by one company
   with a commercial interest in it, and the company shifts its priorities
   for some reason (acquisition, bankruptcy, product cancellation,
   accidentally laying off all competent developers, ...) that causes it to
   stop working on it. Sometimes the previously paid maintainers
   keep up their upstream position, but without someone pushing the
   last missing bits into an official release, users are stuck on an old
   BSP kernel.

* A platform port is done in the open and actually works for upstream
  users, but over time the last active maintainers move on in their
  lives. Complex platforms inevitably break when a treewide change
  goes wrong, so we rely on users that are able to bisect and report
  bugs when they happen. After a platform has been broken for
  too long, even competent users may decide to just give up and
  stay on their last working kernel. Some of these platforms eventually
  recover when a new maintainer steps up or someone discovers they
  depend on newer kernels for products, but after a few years it's
  usually beyond repair.

      Arnd

New platforms: bring out your dead, was Re: Old platforms: bring out your dead

[Finn Thain]

On Wed, 13 Jan 2021, Arnd Bergmann wrote:

> 
> It's usually one of two things that happened before a platform gets
> deleted for good:
> 
> * The platform port was (almost) exclusively done by one company
>    with a commercial interest in it, and the company shifts its priorities
>    for some reason (acquisition, bankruptcy, product cancellation,
>    accidentally laying off all competent developers, ...) that causes it to
>    stop working on it. Sometimes the previously paid maintainers
>    keep up their upstream position, but without someone pushing the
>    last missing bits into an official release, users are stuck on an old
>    BSP kernel.
> 

Yes, that's the typical product life cycle. It presumes a short window of 
opportunity for sales (suggesting that demand is not organic).

Most vendors like to avoid having to compete with their own prior product 
lines. Hence the constrained lifespan that we get from devices with 
out-of-tree Linux ports.

AFAICS open source licenses cannot really prevent this (no matter how many 
freedoms the FSF would like to confer on people). However, consumer law 
could do it, if it were to disallow products which were not servicable.

> * A platform port is done in the open and actually works for upstream
>   users, but over time the last active maintainers move on in their
>   lives. Complex platforms inevitably break when a treewide change
>   goes wrong, so we rely on users that are able to bisect and report
>   bugs when they happen. 

And without bug reports, breakage gets leveraged into deletion, using the 
bogus argument that "broken" code is proof of zero potential users.

>   After a platform has been broken for too long, even competent users 
>   may decide to just give up and stay on their last working kernel. Some 
>   of these platforms eventually recover when a new maintainer steps up 
>   or someone discovers they depend on newer kernels for products, but 
>   after a few years it's usually beyond repair.
> 

So all a vendor has to do is make maintenance a bit too difficult for 
competent users e.g. by depriving them of access to existing 
documentation.

It was only a few decades ago that every applicance you bought came with a 
printed circuit schematic. These days, every device you buy comes with 
built-in obsolescence and a customer lock-in strategy.

>       Arnd
> 

Re: Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hello Linus!

On 1/12/21 11:46 PM, Linus Walleij wrote:
> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> 
>> Yeah, I have the same impression that's the strong commercial interest pushes
>> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
>> they're motivated by corporate decisions.
>>
>> There has to be a healthy balance between hobbyist and commercial use. I understand
>> that from a commercial point of view, it doesn't make much sense to run Linux
>> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
>> Linux stuff for these old machines has a very entertaining and educational factor.
> 
> This is actually one of the most interesting things written in this discussion.
> 
> I have both revamped and deleted subarchitectures in the ARM tree. We
> never deleted anyone's pet project *unless* they were clearly unwilling to
> work on it (such as simply testning new patches) and agreed that it will
> not go on.

I'm not arguing this. This was more about killing (sub-)architectures because they
haven't seen git activity for a long time which I think is poor metric to determine
whether a port is dead or not. And reading through the other answers in this thread,
it seems I'm not alone with this stance.

> At multiple occasions I actually found it easier to fix stuff than
> delete it, both because it is a nicer thing to do and because it
> simply creates less social problems, often to the point that the time
> (man hours) spent trying to solve the resulting social problems from
> deleting a platform would be longer than the time spent actually acquiring
> the physical platform and fixing it.

Good to hear.

> Corporate entities can be a bit deletionist (using Wikipedia terminology)
> and as in this thread there is always a strong inclusionist stance pushing
> back to that.

It's an obvious conflict.

> The explanation is in my mind very simply that running Linux
> on a 35-yo or so Amiga, Atari or Apollo Workstation is pretty impressive and
> fun. And I think that fits Mr. Torvalds own sociological-or-something
> explanation in the autobiographical "Just for fun" as to why to write it
> in the first place. And we are very protective of that quality of the
> kernel. (At least I am.)

I'm happy to hear that. For me personally, it also has a very educational value
as the non-mainstream platforms such as m68k offer more places of code to hack
on for adding features such as SECCOMP which are still missing there.

There are usually enough people working on architectures such as x86 and ARM,
so there is not much room for hobbyist activities. Also, you risk making much
more people upset if you break something.

> That said there are a three things that people should really be doing if they
> want to keep their pet archs/subarchs around as good community
> members, and they are in essence to:
> 
> 1. Test and review/ack patches that others make

I am already doing that as much as I can for various architectures such as ia64,
m68k, SH and POWER, SPARC although I need to ramp up my activity a bit more. I have
also now added myself for the linux-alpha mailing list to test and ack patches for
the Alpha architecture as well.

I have to admit I have quite a number of pet architectures but that's because I'm
co-maintaining these architectures in Debian Ports with regular releases of Debian
installation images for these targets:

> https://cdimage.debian.org/cdimage/ports/snapshots/

> 2. Migrate existing drivers to newly appeared and
>     appropriate subsystems (I think there are some hacky heartbeat LED
>     drivers down in arch/* for example) there is also the feature matrix
>     core maintainers like and which appears if you type
>     Documentation/features/list-arch.sh <archname>
>     would be nice if you work on them if you can support them!
>     Or at least take a look.

Thanks for the pointer. I'm not so much active in kernel development itself yet, but
I'm also trying to be more active. Although the kernel is not the only project that
sometimes needs attention for these pet architectures. We're also confronted with
deprecation problem in problems such as GCC although we recently saved the m68k
(and VAX) backends in GCC with the help of a Bountysource campaign. The AVR backend
is also backed by such a campaign and currently being worked on.

We are even getting an m68k backend for LLVM hopefully soonish, so we will even be able
to build the Linux kernel for m68k with clang :-).

> 3. Migrate old systems to use the
>    contemporary hardware descriptions (such as device tree or ACPI)
>    because it makes things so much easier to maintain. Some
>    upfront work, but a great win for everyone. Especially for
>    subsystem maintainers.

There is such a patch set for arch/sh to add device tree support, but so far it has not
been merged yet, unfortunately. Apparently, it causes some regression on LANDISK devices
according to Rich Felker.

Maybe we can finally get it merged this year:

> https://lore.kernel.org/patchwork/cover/693910/

Since Geert also has a LANDISK SH device now for testing, he might be able to help.

Oh, and if anyone else is interested in helping with the SH port, I'm happy to send
them a free LANDISK or NextVoD SuperH device - the latter has a 450 MHz ST-40
CPU and 256 MB RAM.

> And if your arch uses highmem then please get rid of highmem. I'm
> trying to do this a bit right now for ARM let's see how it goes.

Is there a list of architectures which still need highmem?

> I understand that for some maintainers time is a factor and this list
> feels stressful. I'd say relax, but it'd be nice if you have a TODO that
> you cross items off of.

Thanks for the kind words. I appreciate the input.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Old platforms: bring out your dead

[Geert Uytterhoeven]

Hi Adrian,

On Thu, Jan 14, 2021 at 10:42 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> Oh, and if anyone else is interested in helping with the SH port, I'm happy to send
> them a free LANDISK or NextVoD SuperH device - the latter has a 450 MHz ST-40
> CPU and 256 MB RAM.

Wasn't ST-40 support removed in 2007[1]?
However, that didn't stop people from submitting ST-40 fixes to the core
SH code three years later[2] ;-)

[1] f96691872439ab20 ("sh: Kill off the remaining ST40 cruft.")
[2] a086536858ad0eb5 ("sh: Ensure ST40-300 BogoMIPS value is consistent")

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Thu, Jan 14, 2021 at 10:43 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On 1/12/21 11:46 PM, Linus Walleij wrote:
> > On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz > <glaubitz@physik.fu-berlin.de> wrote:
> > This is actually one of the most interesting things written in this discussion.
> >
> > I have both revamped and deleted subarchitectures in the ARM tree. We
> > never deleted anyone's pet project *unless* they were clearly unwilling to
> > work on it (such as simply testning new patches) and agreed that it will
> > not go on.
>
> I'm not arguing this. This was more about killing (sub-)architectures because they
> haven't seen git activity for a long time which I think is poor metric to determine
> whether a port is dead or not. And reading through the other answers in this thread,
> it seems I'm not alone with this stance.

I think it's mainly a misunderstanding of what I am trying to do
in finding the platforms that have been completely abandoned.
There are now eight platforms on the list that are unmaintained
and have no known users. All of them were actively getting patched
and tested in the past as can be easily seen from the changelog,
but then the maintainers stopped sending patches five years or
longer ago, which indicates that something changed: either the platform
port was now perfect and has been working fine ever since
(e.g. highbank, digicolor, nspire, ...), or the maintainers (or rather
their employers) gave up and never continued the job (picoxcell,
prima2, efm32, ...).

I can usually guess which one is the case, but the only way to be
sure is to ask, which is what I did in that email.

> > 3. Migrate old systems to use the
> >    contemporary hardware descriptions (such as device tree or ACPI)
> >    because it makes things so much easier to maintain. Some
> >    upfront work, but a great win for everyone. Especially for
> >    subsystem maintainers.
>
> There is such a patch set for arch/sh to add device tree support, but so far it has not
> been merged yet, unfortunately. Apparently, it causes some regression on LANDISK devices
> according to Rich Felker.
>
> Maybe we can finally get it merged this year:
>
> > https://lore.kernel.org/patchwork/cover/693910/
>
> Since Geert also has a LANDISK SH device now for testing, he might be able to help.

Doing a proper device tree conversion for arch/sh/ is a huge task,
so unless someone is going to work on that full-time for a while,
I don't see this going anywhere. If nobody has even rebased that
patch series in the past five years, it's fairly unlikely that they will
do it soon.

One of the bigger problems is converting to CONFIG_COMMON_CLK,
as was done for one of the simpler chips in the patch series you
reference above.

> > And if your arch uses highmem then please get rid of highmem. I'm
> > trying to do this a bit right now for ARM let's see how it goes.
>
> Is there a list of architectures which still need highmem?

These are the architectures that currently allow highmem:

| arch/arm/Kconfig:config HIGHMEM

We're working on CONFIG_VMSPLIT_4G_4G as a replacement
to keep ARMv7VE based platforms working after highmem gets
removed, and possibly use ZSWAP to help platforms for
which this is not enough. There are a few users on ARMV7VE
with more than 4GB (keystone2, highbank, armadaxp, some
broadcom STB SoCs) or ARMv7-A with more than 2GB (imx6q,
tegra3), but those memory configurations were shipped in
minute quantities compared to smaller memory versions of the
same boards, so the plan is to wait until the known users have
all stopped needing kernel updates, possibly around 2025.

| arch/arc/Kconfig:config HIGHMEM
| arch/microblaze/Kconfig:config HIGHMEM

I don't think we have upstream support for platforms with a need for
highmem, but these are both used in deeply embedded systems
that tend to not follow mainline kernels. Also, both have hardware
support for 64-bit cores, which I guess will be used in the future
on systems that have more than a gigabyte of RAM.

| arch/csky/Kconfig:config HIGHMEM
| arch/nds32/Kconfig.cpu:config HIGHMEM

These were only merged fairly recently, and as far as I can
tell, highmem support was mainly added for the purpose of
completeness, not because of actual user requirements.
Both architectures are getting replaced with RV64 cores from
the respective companies (Andes and C-Sky/T-Head).

| arch/powerpc/Kconfig:config HIGHMEM
| arch/sparc/Kconfig:config HIGHMEM
| arch/x86/Kconfig:config HIGHMEM

Highmem was used extensively on these in the past, but mainly
on older machines. Most o the x86 users here would already
be on 64-bit hardware and can just change their kernels to
x86-64, but 32-bit machines from around 2004 to 2006
on both powerpc and x86, as well as some older servers, are
likely to lose some of their memory or may have to use ZSWAP
instead.

| arch/mips/Kconfig:config HIGHMEM
| arch/xtensa/Kconfig:config HIGHMEM

AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at
most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G
tricks won't work. OTOH, most mips platforms that support
highmem are on older 64-bit cores and can probably move to
64-bit kernels as well, but some can not (ingenic xburst,
loongson1, bmips, ...)

P5600 (Baikal-T1) is often used with 4GB or at most 8GB on
desktops, this will be interesting to migrate. Since it's MIPS32r5,
this may use more than 512MB of lowmem with some tricks that
need to be implemented.

Most of the embedded MIPS32 ones support less than those 512MB
of RAM and are not affected.

I have no idea who uses xtensa systems with lots of memory on
modern kernels.




      Arnd

Undesirable code, was Re: Old platforms etc.

[Finn Thain]

On Thu, 14 Jan 2021, Arnd Bergmann wrote:

> I think it's mainly a misunderstanding of what I am trying to do
> in finding the platforms that have been completely abandoned.

Have you tried to identify those drivers and Kconfig symbols in mainline 
that are used only by devices that don't function with mainline kernels?

Re: Old platforms: bring out your dead

[Max Filippov]

Hi Arnd,

On Thu, Jan 14, 2021 at 1:25 PM Arnd Bergmann <arnd@kernel.org> wrote:
> | arch/mips/Kconfig:config HIGHMEM
> | arch/xtensa/Kconfig:config HIGHMEM
>
> AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at
> most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G
> tricks won't work.

Regarding xtensa this was done to minimize difference between
MMUv2 and MMUv3 virtual memory layouts. MMUv2 has been
obsoleted more than 10 years ago, and MMUv3 is much more
flexible and can do e.g. 4GB linear map. The only piece of xtensa
MMUv2 hardware that I have has 96MB of DRAM which fits into
its linear mapping. So maybe it's time to do a cleanup and
rearrange virtual memory layout to eliminate the need of highmem.

> I have no idea who uses xtensa systems with lots of memory on
> modern kernels.

We definitely use it for development internally at Cadence/Tensilica,
mainly on simulators, but also on FPGA boards (e.g. on KC705 we
can use all of the 1GB onboard DRAM).
In the last few years we've had a few support requests for linux on
xtensa cores with MMU, but AFAICT none of them had to deal with
more than 512MB of onboard memory.

-- 
Thanks.
-- Max

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Fri, Jan 15, 2021 at 12:09 AM Max Filippov <jcmvbkbc@gmail.com> wrote:
> On Thu, Jan 14, 2021 at 1:25 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > | arch/mips/Kconfig:config HIGHMEM
> > | arch/xtensa/Kconfig:config HIGHMEM
> >
> > AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at
> > most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G
> > tricks won't work.
>
> Regarding xtensa this was done to minimize difference between
> MMUv2 and MMUv3 virtual memory layouts. MMUv2 has been
> obsoleted more than 10 years ago, and MMUv3 is much more
> flexible and can do e.g. 4GB linear map. The only piece of xtensa
> MMUv2 hardware that I have has 96MB of DRAM which fits into
> its linear mapping. So maybe it's time to do a cleanup and
> rearrange virtual memory layout to eliminate the need of highmem.

Yes, I think that sounds like a useful preparation for the future.

> > I have no idea who uses xtensa systems with lots of memory on
> > modern kernels.
>
> We definitely use it for development internally at Cadence/Tensilica,
> mainly on simulators, but also on FPGA boards (e.g. on KC705 we
> can use all of the 1GB onboard DRAM).
> In the last few years we've had a few support requests for linux on
> xtensa cores with MMU, but AFAICT none of them had to deal with
> more than 512MB of onboard memory.

If 1GB of RAM is a useful upper bound on MMUv3, the easiest way is
probably to hardcode the CONFIG_VMSPLIT_3G_OPT behavior
from x86 and ARM, using 2.75GB of user addresses (TASK_SIZE),
and 1.25 GB that gets split between linear map and vmalloc space,
but no uncached linear map and ioremap() pointing into vmalloc
instead. If you want to be prepared for machines with 2GB of linear
lowmem, you could do the same with VMSPLIT_2G_OPT
(TASK_SIZE == 0x70000000).

      Arnd

Old platforms never die, was Re: Old platforms: bring out your dead

[Finn Thain]

On Tue, 12 Jan 2021, John Paul Adrian Glaubitz wrote:

> 
> There has to be a healthy balance between hobbyist and commercial use.
> 

Yes, both of those, and everything in-between, including for-profit 
businesses that serve mostly hobbyists. Also start-up companies that may 
never be commercially viable (which is most of them).

And don't forget government and non-government organisations, 
not-for-profit organisations, charities, etc.

> I understand that from a commercial point of view, it doesn't make much 
> sense to run Linux on a 30-year-old computer.

It ain't necessarily so. I would be surprised if there are no Linux VMs 
running on old corporate mainframes right now. But the age of the hardware 
is largely irrelevant.

If you're a museum interested in cultural artifacts from decades past, or 
if you're a business doing data recovery, you're going to need to operate 
those platforms.

Once removed from mainline Linux, a port becomes basically frozen, and may 
not be compatible with future emulators, which are a moving target. I say 
that because last year I fixed bugs in Linux/m68k that made it incomatible 
with recent QEMU releases (it was only compatible with old QEMU releases).

Re: Old platforms never die, was Re: Old platforms: bring out your dead

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On 1/12/21 6:12 PM, Finn Thain wrote:
> If you're a museum interested in cultural artifacts from decades past, or 
> if you're a business doing data recovery, you're going to need to operate 
> those platforms.

Or if you're camping patent expirations and want to be able to point at prior
art for new hardware development WITHOUT a legal team big enough to have its own
office building.

> Once removed from mainline Linux, a port becomes basically frozen, and may 
> not be compatible with future emulators, which are a moving target. I say 
> that because last year I fixed bugs in Linux/m68k that made it incomatible 
> with recent QEMU releases (it was only compatible with old QEMU releases).

Speaking of which, my qemu m68k system has failed to boot ever since commit:

commit f93bfeb55255bddaa16597e187a99ae6131b964a
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Sun Jun 28 14:23:12 2020 +1000

    macintosh/via-macii: Poll the device most likely to respond

    Poll the most recently polled device by default, rather than the lowest
    device address that happens to be enabled in autopoll_devs. This improves
    input latency. Re-use macii_queue_poll() rather than duplicate that logic.
    This eliminates a static struct and function.

It hangs in a cpu-eating loop after "random: crng init done". Miniconfig
attached, the qemu invocation is:

qemu-system-m68k -M q800 -nographic -no-reboot -m 256 -kernel vmlinux \
  -initrd cpio.gz -append "panic=1 HOST=m68k console=ttyS0

Rob

P.S. This is the toybox "make root" m68k target from
https://github.com/landley/toybox/blob/master/scripts/mkroot.sh#L171 if that's
useful to know. It doesn't get to the root filesystem and the build just creates
that miniconfig and runs it as the comments say...

[-- Attachment #2: miniconfig-m68k --]
[-- Type: text/plain, Size: 1121 bytes --]

# make ARCH=m68k allnoconfig KCONFIG_ALLCONFIG=m68k.miniconf
# make ARCH=m68k -j $(nproc)
# boot vmlinux


# CONFIG_EMBEDDED is not set
# architecture independent
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_UTF8=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=y
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_NETCONSOLE=y
CONFIG_ETHERNET=y
CONFIG_COMPAT_32BIT_TIME=y
CONFIG_EARLY_PRINTK=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

# architecture specific
CONFIG_MMU=y
CONFIG_M68040=y
CONFIG_M68KFPU_EMU=y
CONFIG_MAC=y
CONFIG_SCSI_MAC_ESP=y
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_ADB=y
CONFIG_ADB_MACII=y
CONFIG_NET_CORE=y
CONFIG_MACSONIC=y
CONFIG_SERIAL_PMACZILOG=y
CONFIG_SERIAL_PMACZILOG_TTYS=y
CONFIG_SERIAL_PMACZILOG_CONSOLE=y

Re: Old platforms never die, was Re: Old platforms: bring out your dead

[Finn Thain]

On Sat, 16 Jan 2021, Rob Landley wrote:

> Speaking of which, my qemu m68k system has failed to boot ever since commit:
> 
> commit f93bfeb55255bddaa16597e187a99ae6131b964a
> Author: Finn Thain <fthain@telegraphics.com.au>
> Date:   Sun Jun 28 14:23:12 2020 +1000
> 
>     macintosh/via-macii: Poll the device most likely to respond
> 

Yes, that patch series broke your emulator by fixing kernel bugs. Please 
refer to this message for some background and some solutions--
https://lore.kernel.org/linux-m68k/alpine.LNX.2.23.453.2008100844450.8@nippy.intranet/

Re: Old platforms: bring out your dead

[Andy Shevchenko]

On Tue, Jan 12, 2021 at 4:47 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On 1/11/21 4:04 PM, Gerhard Pircher wrote:

> There has to be a healthy balance between hobbyist and commercial use. I understand
> that from a commercial point of view, it doesn't make much sense to run Linux
> on a 30-year-old computer.

I have another impression (depending on what you put under "commercial use").
Industrial requirements are to support for 15+ (in some cases 30+)
years for hardware. I'm quite sure they don't want to have completely
outdated software there either.

-- 
With Best Regards,
Andy Shevchenko