After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.
This is probably a mix of platforms that are completely unused and
those that just work, but I have no good way of knowing which one
it is. Without hearing back about these, I'd propose removing all of
these:
* asm9260 -- added in 2014, no notable changes after 2015
* axxia -- added in 2014, no notable changes after 2015
* bcm/kona -- added in 2013, no notable changes after 2014
* digicolor -- added in 2014, no notable changes after 2015
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
* efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
* nspire -- added in 2013, no notable changes after 2015
* picoxcell -- added in 2011, already queued for removal
* prima2 -- added in 20111, no notable changes since 2015
* spear -- added in 2010, no notable changes since 2015
* tango -- added in 2015, sporadic changes until 2017, but abandoned
* u300 -- added in 2009, no notable changes since 2013
* vt8500 -- added in 2010, no notable changes since 2014
* zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
If any of the above are not dead yet[2], please let me know,
and we'll keep them.
Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:
* clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
changes since
* cns3xxx -- added in 2010, last fixed in 2019, probably no users left
* ep93xx -- added in 2006, LinusW still working on it, any users left?
* footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have one
* gemini -- added in 2009, LinusW still working on it
* hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
* highbank -- added in 2011, no changes after 2015, but Andre still uses it
* iop32x -- added in 2006, no notable changes other than my cleanup, but
I think there are still users
* ixp4xx -- prehistoric, but LinusW and I are still working on it
* lpc18xx -- added in 2015, new dts in 2018, but few other changes
* lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
* mmp -- added in 2009, DT support is active, but board files might go
* moxart -- added in 2013, last Tested-by in 2017
* mv78xx0 -- added in 2008, mostly stale but still users
(https://github.com/1000001101000/Debian_on_Buffalo)
* nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
* oxnas -- added in 2016, but already old then, few changes later
* pxa -- prehistoric, but a few boards may still have users
* rpc -- prehistoric, but I think Russell still uses his machine
* sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
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
* 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
* 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
* 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)
* 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.
* 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.
* 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.
Arnd
[1] https://lwn.net/Articles/838807/
[2] https://www.youtube.com/watch?v=Jdf5EXo6I68
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Steven Rostedt <rostedt@goodmis.org> Date: 2021-01-08 23:33:57
On Fri, 8 Jan 2021 23:55:06 +0100
Arnd Bergmann [off-list ref] wrote:
* 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
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Date: 2021-01-08 23:45:41
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
* mips/jazz: last updated in 2007
* mips/cobalt: last updated in 2010
missing updates aren't exactly an indicator for being dead. I'm
regulary booting Cobalt and Jazz. And there are no updates needed
for Cobalt since every piece of hardware is supported and working.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann [off-list ref] wrote:
* u300 -- added in 2009, no notable changes since 2013
We can delete this, I don't see any use for it moving forward.
I'll send patches to drop it.
* ep93xx -- added in 2006, LinusW still working on it, any users left?
I was contacted by a user of this platform, using it with mainline and
fixing bugs in the GPIO driver for this kernel cycle. So it has users.
* gemini -- added in 2009, LinusW still working on it
This has active support and users through OpenWrt on the
D-Link DNS-313 and DIR-685.
* ixp4xx -- prehistoric, but LinusW and I are still working on it
One more developer has contacted me showing strong interest
in the platform.
* nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
I use this for various subsystem testing actually (for the hardware that
is on the board, not necessarily Nomadik per se). So it is in pretty
active use.
* sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
There were some users from OpenEmbedded some years back
and active patches from Andrea Adami beside RMK and me. Paging
Andrea to see if he still has interest in the platform. (I don't.)
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
* 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.
These also are the last generation of fanless x86 boards with 100% compatible
controllers, that some people have probably kept around because these don't
age much and have plenty of connectivity. I've used an old one a few times
to plug in an old floppy drive, ISA SCSI controllers to access an old tape
drive and a few such things. That doesn't mean that it's a good justification
not to remove them, what I rather mean is that *if* there is no benefit
in dropping them maybe we can keep them. On the other hand, good luck for
running a modern OS on these, when 16MB-32MB RAM was about the maximum that
was commonly found by then (though if people kept them around that's probably
because they were well equipped, like that 64MB 386DX I'm having :-)).
Willy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
* ep93xx -- added in 2006, LinusW still working on it, any users left?
I was contacted by a user of this platform, using it with mainline and
fixing bugs in the GPIO driver for this kernel cycle. So it has users.
You can count me as one of the users, I still use my TS7300 system,
however because of the amount of RAM I don't regularly update it.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.
This is probably a mix of platforms that are completely unused and
those that just work, but I have no good way of knowing which one
it is. Without hearing back about these, I'd propose removing all of
these:
* asm9260 -- added in 2014, no notable changes after 2015
* axxia -- added in 2014, no notable changes after 2015
* bcm/kona -- added in 2013, no notable changes after 2014
I have a development board that I occasionally turn on for testing
upstream kernels, it has not broken in a while which is why it did not
get much updates. I don't feel strongly with respect to keep it or
dropping it though.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-09 17:45:17
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
May be obsoleted, but I still use this for my dove cubox with
additional patches.
* footbridge -- added in prehistory, stable since ~2013, rmk and LinusW
have one
Yes, and still running:
Linux flint 5.6.12+ #94 Sat Oct 17 23:44:28 BST 2020 armv4l armv4l armv4l GNU/Linux
* iop32x -- added in 2006, no notable changes other than my cleanup, but
I think there are still users
I have two TheCUS N2100s here, one still powered up and running and
one is currently available if anyone wants the machine. Both may
become available if anyone wants them later in 2021. I notice
Heiner Kallweit has been patching some of this code recently.
* rpc -- prehistoric, but I think Russell still uses his machine
Yes, and I have sent some patches in the 5.x timeframe, and I do
have some further ones I could send, mostly around SCSI stuff.
It is my only machine that gives me access to some old tape backups
and syquest cartridges (not that any of that contains "modern" data.)
* sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
Hi Arnd,
On Sat, Jan 09 2021, Arnd Bergmann wrote:
* digicolor -- added in 2014, no notable changes after 2015
I have access to the hardware and I'm still interested in maintaining
mainline kernel support for it.
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Jan 9, 2021 at 6:34 PM Florian Fainelli [off-list ref] wrote:
On 1/8/2021 2:55 PM, Arnd Bergmann wrote:
quoted
* bcm/kona -- added in 2013, no notable changes after 2014
I have a development board that I occasionally turn on for testing
upstream kernels, it has not broken in a while which is why it did not
get much updates. I don't feel strongly with respect to keep it or
dropping it though.
Does that include all Kona-family SoCs or just one of them?
I see Kconfig listing bcm23550, bcm2166x and five variants of
bcm281xx.
We've seen a bit of a comeback of older phones making it into
mainline, so it's possible this platform might see a revival as well.
I now found a list of phones with partial postmarketos support [1]
and ongoing work as of last year.
Let's leave it untouched for now and see if any of those make
it upstream. If only the reference boards are supported and
nobody wants to use new kernels on commercial hardware in a
few years, we can then remove it.
Arnd
[1] https://wiki.postmarketos.org/wiki/Broadcom_chipsets
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Jan 9, 2021 at 6:43 PM Russell King - ARM Linux admin
[off-list ref] wrote:
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
quoted
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
May be obsoleted, but I still use this for my dove cubox with
additional patches.
What is the status of these patches? I also still have a set of patches
to integrate it with the other ARMv7 machines into multiplatform,
and a series to change some of the PCI handling in all plat-orion
platforms, that I was hoping to either upstream or drop once the
platform itself gets removed.
Did you give up on moving the Cubox to DT, or is this something you
still want to get back?
quoted
* footbridge -- added in prehistory, stable since ~2013, rmk and LinusW
have one
Yes, and still running:
Linux flint 5.6.12+ #94 Sat Oct 17 23:44:28 BST 2020 armv4l armv4l armv4l GNU/Linux
quoted
* iop32x -- added in 2006, no notable changes other than my cleanup, but
I think there are still users
I have two TheCUS N2100s here, one still powered up and running and
one is currently available if anyone wants the machine. Both may
become available if anyone wants them later in 2021. I notice
Heiner Kallweit has been patching some of this code recently.
quoted
* rpc -- prehistoric, but I think Russell still uses his machine
Yes, and I have sent some patches in the 5.x timeframe, and I do
have some further ones I could send, mostly around SCSI stuff.
It is my only machine that gives me access to some old tape backups
and syquest cartridges (not that any of that contains "modern" data.)
quoted
* sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
I also have some further patches that have been hanging around for
some time to modernise sa1100 a bit.
Ok, that roughly all matches what I was guessing. As I wrote, I
saw most of them have been getting updates and assumed we want
to keep them, but I was not sure if any of them have come to the point
where it's no longer worth updating kernels past v5.10.y for any
reason.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau [off-list ref] wrote:
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
quoted
* 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.
These also are the last generation of fanless x86 boards with 100% compatible
controllers, that some people have probably kept around because these don't
age much and have plenty of connectivity. I've used an old one a few times
to plug in an old floppy drive, ISA SCSI controllers to access an old tape
drive and a few such things. That doesn't mean that it's a good justification
not to remove them, what I rather mean is that *if* there is no benefit
in dropping them maybe we can keep them. On the other hand, good luck for
running a modern OS on these, when 16MB-32MB RAM was about the maximum that
was commonly found by then (though if people kept them around that's probably
because they were well equipped, like that 64MB 386DX I'm having :-)).
I think there were 486s with up to 256MB, which would still qualify as barely
usable for a minimal desktop, or as comfortable for a deeply embedded
system. The main limit was apparently the cacheable RAM, which is limited
by the amount of L2 cache -- you needed a rare 1MB of external L2-cache to
have 256MB of cached RAM, while more common 256KB of cache would
be good for 64MB. Vortex86SX has no FPU or L2 cache at all, but supports
256MB of DDR2.
I checked some distros and found that aside from Debian inadvertently
dropping i486 a long time ago, Slackware 14.2 (from 2016) also requires
an i586 or higher now. Slackware 14.1 (from 2013) is still supported
on i486 but ships with a Linux-3.10 kernel. archlinux32 is the only
binary distro I could find that still officially supports i486, which in their
case means anything below an i686 (cmov+mmx+sse). If it gets
dropped, it might require some users to stay on LTS kernels
after the distro moves to i586-only kernel, but as there are no
long-term supported releases, there is also no need to coordinate
the timing.
As with the other older platforms, the main question to ask is:
Are there users that are better off running a future LTS kernel on this
hardware than the v5.10.y version or something older?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Jan 9, 2021 at 1:18 AM Linus Walleij [off-list ref] wrote:
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann [off-list ref] wrote:
quoted
* u300 -- added in 2009, no notable changes since 2013
We can delete this, I don't see any use for it moving forward.
I'll send patches to drop it.
Ok, thanks for confirming.
quoted
* ep93xx -- added in 2006, LinusW still working on it, any users left?
I was contacted by a user of this platform, using it with mainline and
fixing bugs in the GPIO driver for this kernel cycle. So it has users.
quoted
* gemini -- added in 2009, LinusW still working on it
This has active support and users through OpenWrt on the
D-Link DNS-313 and DIR-685.
quoted
* ixp4xx -- prehistoric, but LinusW and I are still working on it
One more developer has contacted me showing strong interest
in the platform.
quoted
* nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
I use this for various subsystem testing actually (for the hardware that
is on the board, not necessarily Nomadik per se). So it is in pretty
active use.
quoted
* sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
There were some users from OpenEmbedded some years back
and active patches from Andrea Adami beside RMK and me. Paging
Andrea to see if he still has interest in the platform. (I don't.)
And thanks for confirming that we still want to keep all of these.
One thing I'd really like to see for the ep93xx is to have it
use the COMMON_CLK interfaces. I have patches for OMAP1
that I need to finalize, and then this one will be the last ARM
platform without it. I also still hope we can eventually get ep93xx
into multiplatform build.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Jan 9, 2021 at 12:32 AM Steven Rostedt [off-list ref] wrote:
On Fri, 8 Jan 2021 23:55:06 +0100
Arnd Bergmann [off-list ref] wrote:
quoted
* 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
"I'm not dead yet!", "You're not fooling anyone!"
The patch that I sent that fixes a critical bug in the architecture
(irq disabling does no compiler barriers!), has been ignored since
September 18th.
https://lore.kernel.org/lkml/20200918152507.711865ce@gandalf.local.home/
I'm thinking to kill it and see if that causes any complaints.
I'm happy to queue the patches in my asm-generic tree if you send them
my way. Then they can spend some more time in linux-next and give
possible users one last chance to speak up.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-09 23:13:22
Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:
Hi Arnd
I notice orion5x is not on this list. Is that because of Debian still
building for it?
I just blew the dust out of my orion5x RDK and booted 5.11-rc2 on it.
orion5x_defconfig needs a few updates, but otherwise it seems to work
O.K.
But i have no idea if there are any real users out there running
modern kernels.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sat, Jan 09, 2021 at 10:52:53PM +0100, Arnd Bergmann wrote:
(... i486 ...)
As with the other older platforms, the main question to ask is:
Are there users that are better off running a future LTS kernel on this
hardware than the v5.10.y version or something older?
I think this is the most important part of the question. Because the
possible use case I've described actually doesn't correspond to a
"prod" machine but to a machine that's powered on every 5 years for
some old data recovery. In such a case users just start with an old
system (possibly the one that's still on them if present), and this
doesn't warrant an up-to-date OS.
Moreover, just as I experienced when maintaining 2.4, there's a point
where support for old stuff starts to break again by lack of testing.
And just because of this, users shouldn't always expect to see their
old machines boot fine on a recent kernel. Sometimes there may even be
difficulties setting up a compatible toolchain.
So actually the question shouldn't be "does anyone want such old
machines to still be supported" but "does anyone *need* them to be
supported". And I suspect that for most of them the response is "no",
it's just a convenience.
Just my two cents,
Willy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sun, Jan 10, 2021 at 12:12 AM Andrew Lunn [off-list ref] wrote:
quoted
Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:
Hi Arnd
I notice orion5x is not on this list. Is that because of Debian still
building for it?
No, it was a mistake on my end, it should have been in the
second list of platforms that are fairly old but still updated
and possibly have users.
I just blew the dust out of my orion5x RDK and booted 5.11-rc2 on it.
orion5x_defconfig needs a few updates, but otherwise it seems to work
O.K.
But i have no idea if there are any real users out there running
modern kernels.
For this platform, I'm most interested in whether there are still users
that rely on board files instead of DT. AFAIU we could just fold
the DT variant into arch-mvebu like kirkwood was, right?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-10 10:46:52
On Sun, Jan 10, 2021 at 07:21:13AM +0100, Willy Tarreau wrote:
On Sat, Jan 09, 2021 at 10:52:53PM +0100, Arnd Bergmann wrote:
(... i486 ...)
quoted
As with the other older platforms, the main question to ask is:
Are there users that are better off running a future LTS kernel on this
hardware than the v5.10.y version or something older?
I think this is the most important part of the question. Because the
possible use case I've described actually doesn't correspond to a
"prod" machine but to a machine that's powered on every 5 years for
some old data recovery. In such a case users just start with an old
system (possibly the one that's still on them if present), and this
doesn't warrant an up-to-date OS.
Moreover, just as I experienced when maintaining 2.4, there's a point
where support for old stuff starts to break again by lack of testing.
And just because of this, users shouldn't always expect to see their
old machines boot fine on a recent kernel. Sometimes there may even be
difficulties setting up a compatible toolchain.
So actually the question shouldn't be "does anyone want such old
machines to still be supported" but "does anyone *need* them to be
supported". And I suspect that for most of them the response is "no",
it's just a convenience.
What about feature obsolescence?
Consider that old ssh (supporting only the v1 protocol) will no longer
connect to new sshd (supporting only the v2 protocol) or older NFS
supporting UDP only trying to connect to new NFS supporting only TCP.
Or older NFS that does buggily support TCP and won't talk to newer
machines.
At one time, the suggestion would've been to use a DOS formatted
floppy to transfer the data... but modern machines tend not to have
floppy drives. USB pendrive? Maybe the older machine doesn't have USB.
I suppose you'd have to resort to FTP at that point to move data off
the old machine, or via email if you have email setup on it.
Having a machine that's able to boot an old installation just means
it can run, but it doesn't guarantee that it will be useful once
booted to move old data onto newer machines.
Over Christmas, I booted my Acorn A5000 (the very first machine to run
Linux on ARM) to retrieve some old data off it - thankfully I still
have an Acorn Ether1 card with an AUI interface and a 10baseT MAU to
connect to my network. Sadly, support for running Linux on it has
long since passed - with only 8MB and 32KiB pages, modern Linux would
struggle with it, which is really the reason why support was dropped.
Linux outgrew the hardware.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Neil Armstrong <hidden> Date: 2021-01-10 15:52:53
Hi Arnd,
Le 08/01/2021 à 23:55, Arnd Bergmann a écrit :
After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.
...
* oxnas -- added in 2016, but already old then, few changes later
There is still active users in the openwrt community, so it would be goods to keep it for now.
And we have an OX820 board in KerneCI so it's still maintained & boot-tested.
Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sun, Jan 10, 2021 at 4:51 PM Neil Armstrong [off-list ref] wrote:
Hi Arnd,
Le 08/01/2021 à 23:55, Arnd Bergmann a écrit :
quoted
After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.
...
quoted
* oxnas -- added in 2016, but already old then, few changes later
There is still active users in the openwrt community, so it would be goods to keep it for now.
And we have an OX820 board in KerneCI so it's still maintained & boot-tested.
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 16:47:35
For this platform, I'm most interested in whether there are still users
that rely on board files instead of DT. AFAIU we could just fold
the DT variant into arch-mvebu like kirkwood was, right?
Hi Arnd
I'm actually booting my device using a board file. But Debian
flash-kernel is pretty unhappy about that. The bootloader i have on
this machine is too old to passed DT blob. I will test appended DT
blob still works. And see if we have any board files which also don't
have a DT representation.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Sun, Jan 10, 2021 at 5:48 PM Andrew Lunn [off-list ref] wrote:
quoted
For this platform, I'm most interested in whether there are still users
that rely on board files instead of DT. AFAIU we could just fold
the DT variant into arch-mvebu like kirkwood was, right?
Hi Arnd
I'm actually booting my device using a board file. But Debian
flash-kernel is pretty unhappy about that. The bootloader i have on
this machine is too old to passed DT blob. I will test appended DT
blob still works. And see if we have any board files which also don't
have a DT representation.
It may help to ask for these at
https://github.com/1000001101000/Debian_on_Buffalo/,
I already contacted them about mv78xx0. I tried to find
out how the Linkstation/Terastation board files map to the
dts files, but couldn't figure it out either. It seems they
want to keep supporting all those machines and can probably
help out ensure that there are dts files for each one.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-01-10 19:52:51
On Sun, Jan 10, 2021 at 06:27:12PM +0100, Arnd Bergmann wrote:
On Sun, Jan 10, 2021 at 5:48 PM Andrew Lunn [off-list ref] wrote:
quoted
quoted
For this platform, I'm most interested in whether there are still users
that rely on board files instead of DT. AFAIU we could just fold
the DT variant into arch-mvebu like kirkwood was, right?
Hi Arnd
I'm actually booting my device using a board file. But Debian
flash-kernel is pretty unhappy about that. The bootloader i have on
this machine is too old to passed DT blob. I will test appended DT
blob still works. And see if we have any board files which also don't
have a DT representation.
Thanks for the link.
I looked at the remaining board files and i'm cooking up a set of
patches. I don't see any reason to keep the Marvell reference designs
around, especially since one has been converted to DT and gives a good
example how the others could be converted.
The two WiFi devices have been dropped by OpenWRT, too little
RAM/FLASH. OpenWRT seems like the most likely downstream user, so if
they have given up supporting them, i think it is safe for mainline to
drop them.
I checked with the ts78xx Maintainer and he says we can drop that.
Kurobox Pro has a DTS file, so i've dropped to board file.
What is left are NAS boxes. The low FLASH is not really an issue for
them, they can run with the OS on the disk. And they are the sort of
device which does have a long life.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Daniel Palmer <hidden> Date: 2021-01-11 01:39:53
Hi Arnd,
On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann [off-list ref] wrote:
* 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.
I have some patches for the DragonBall series to enable SPI etc there,
some patches to support the SuperVZ variant, some tools to upload
Linux via the integrated serial bootloader.
The DragonBall is probably what anyone that wants to build a 68K retro
computer should use as the DRAM controller is integrated and it can
access 32MB of SDRAM.
I haven't tested it recently but it should still work and I have
hardware and I'm willing to look after it if no one else wants to.
Thanks,
Daniel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Arnd,
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann [off-list ref] wrote:
* 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.
I have a (32-bit) RBTX4927 development board in my board farm, boot-test
every bi-weekly renesas-drivers release on it, and fix kernel issues
when they appear.
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Alexander Sverdlin <hidden> Date: 2021-01-11 08:51:01
Hello Arnd!
On 08/01/2021 23:55, Arnd Bergmann wrote:
This is probably a mix of platforms that are completely unused and
those that just work, but I have no good way of knowing which one
it is. Without hearing back about these, I'd propose removing all of
these:
[...]
* axxia -- added in 2014, no notable changes after 2015
This one is still widely used there is a chance you are using it too when
traveling in Asia or USA :)
I can take the official maintainership, if there is no existing one currently,
or you can count on me to test the patches.
--
Best regards,
Alexander Sverdlin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Alexander Sverdlin <hidden> Date: 2021-01-11 08:55:21
Hello Arnd!
On 08/01/2021 23:55, Arnd Bergmann wrote:
Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:
[...]
* ep93xx -- added in 2006, LinusW still working on it, any users left?
These devices are still in service, and I'm still here to test any patches
(in my private time).
--
Best regards,
Alexander Sverdlin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven [off-list ref] wrote:
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have a (32-bit) RBTX4927 development board in my board farm, boot-test
every bi-weekly renesas-drivers release on it, and fix kernel issues
when they appear.
Right, I was specifically thinking of the MIPS-II/R3000 ones here, I know
there are users on multiple actively maintained MIPS-III platforms.
Regarding 32-bit vs 64-bit kernels, can you clarify what makes this one
a 32-bit board? Is this just your preference for which kernel you install,
or are there dependencies on firmware or hardware that require running
this machine in 32-bit mode?
(MIPS is not my area anyway, I'm just curious)
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Date: 2021-01-11 09:16:46
Hi Daniel!
On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have some patches for the DragonBall series to enable SPI etc there,
some patches to support the SuperVZ variant, some tools to upload
Linux via the integrated serial bootloader.
The DragonBall is probably what anyone that wants to build a 68K retro
computer should use as the DRAM controller is integrated and it can
access 32MB of SDRAM.
Sounds interesting. Do these SoCs come with an MMU? And do they use the
ColdFire instruction set or do they run plain 68k code?
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Arnd,
On Mon, Jan 11, 2021 at 9:59 AM Arnd Bergmann [off-list ref] wrote:
On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven [off-list ref] wrote:
quoted
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have a (32-bit) RBTX4927 development board in my board farm, boot-test
every bi-weekly renesas-drivers release on it, and fix kernel issues
when they appear.
Right, I was specifically thinking of the MIPS-II/R3000 ones here, I know
there are users on multiple actively maintained MIPS-III platforms.
Regarding 32-bit vs 64-bit kernels, can you clarify what makes this one
a 32-bit board? Is this just your preference for which kernel you install,
or are there dependencies on firmware or hardware that require running
this machine in 32-bit mode?
TX492x is 32-bit (/proc/cpuinfo says mips1/mips2/mips3), TX493x is 64-bit.
As Debian dropped support for mips3 and older, I'm stuck at a Jessie nfsroot.
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Adrian,
On Mon, Jan 11, 2021 at 10:16 AM John Paul Adrian Glaubitz
[off-list ref] wrote:
quoted
On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have some patches for the DragonBall series to enable SPI etc there,
some patches to support the SuperVZ variant, some tools to upload
Linux via the integrated serial bootloader.
The DragonBall is probably what anyone that wants to build a 68K retro
computer should use as the DRAM controller is integrated and it can
access 32MB of SDRAM.
Sounds interesting. Do these SoCs come with an MMU? And do they use the
ColdFire instruction set or do they run plain 68k code?
No MMU, plain m68k code.
68328 Soc = 68000 core + some peripherals,
68360 SoC = CPU32 core (based on 68020 + some peripherals.
Anyone working on integrating m68k (and SPARC and MIPS?) softcores in
LiteX? ;-)
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jan 11, 2021 at 9:49 AM Alexander Sverdlin
[off-list ref] wrote:
On 08/01/2021 23:55, Arnd Bergmann wrote:
quoted
This is probably a mix of platforms that are completely unused and
those that just work, but I have no good way of knowing which one
it is. Without hearing back about these, I'd propose removing all of
these:
[...]
quoted
* axxia -- added in 2014, no notable changes after 2015
This one is still widely used there is a chance you are using it too when
traveling in Asia or USA :)
I know this one has a large installed base, and that Intel were at
least working on it for a while after upstream contributions stopped.
However, my impression was that the port was never completed
upstream before the acquisition, and that the new owners had no
interest in working with us. In particular, none of the later Axxia
SoCs (ppc32/axe3500, arm64/axm5600, arm64/axc6700) ever got
submitted for inclusion as far as I can tell.
The latest public source code I found is at https://github.com/axxia/,
but this is a heavily patched linux-4.9, see
https://github.com/axxia/axxia_yocto_linux_4.9/commits/fa03c456641
My interpretation of this was that whoever is using Axxia chips
is no longer interested in upgrading to newer kernels or using
anything remotely resembling the code we have uptream.
I can take the official maintainership, if there is no existing one currently,
or you can count on me to test the patches.
Hi Adrian,
On Mon, Jan 11, 2021 at 10:26 AM John Paul Adrian Glaubitz
[off-list ref] wrote:
On 1/11/21 10:20 AM, Geert Uytterhoeven wrote:
quoted
quoted
Sounds interesting. Do these SoCs come with an MMU? And do they use the
ColdFire instruction set or do they run plain 68k code?
No MMU, plain m68k code.
68328 Soc = 68000 core + some peripherals,
68360 SoC = CPU32 core (based on 68020 + some peripherals.
OK, I guess that would be useful for the NoMMU Linux port.
Note that 68360 support was removed from the kernel in 2016, as
Arnd said.
quoted
Anyone working on integrating m68k (and SPARC and MIPS?) softcores in
LiteX? ;-)
I'm personally waiting for the Vampire to gain support for the real 68851
as the hardware in general looks very attractive [1].
The 68851 is way too complex for what's needed (who needs support for
256 byte pages (https://lwn.net/Articles/839746/)?).
They'd be better off implementing something simpler, like 68040 MMU
support, or perhaps even a software-controlled TLB like most RISC
architectures (incl. ColdFire?). The latter would require more changes
to Linux, 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Daniel Palmer <hidden> Date: 2021-01-11 09:43:29
Hi Adrian,
On Mon, 11 Jan 2021 at 18:17, John Paul Adrian Glaubitz
[off-list ref] wrote:
Hi Daniel!
quoted
On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have some patches for the DragonBall series to enable SPI etc there,
some patches to support the SuperVZ variant, some tools to upload
Linux via the integrated serial bootloader.
The DragonBall is probably what anyone that wants to build a 68K retro
computer should use as the DRAM controller is integrated and it can
access 32MB of SDRAM.
Sounds interesting. Do these SoCs come with an MMU? And do they use the
ColdFire instruction set or do they run plain 68k code?
I can't remember if they have a simple memory protection controller or
not but I'm sure there isn't a proper mmu so they are limited to
nommu.
The instruction set is exactly the same as the original 68000 except I
think they have the one slightly different instruction like the
MC68SEC000 has.
The standard MC68000 only has 24 bits worth of address lines though so
you have to get everything into 16MB which is a bit painful if you
have 8MB of flash and 8MB of RAM.
The DragonBall must have more address lines internally however as I
managed to get 32MB of SDRAM and 16MB of flash working on my board.
It's still a toy at the end of the day though. :)
Cheers,
Daniel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Adrian,
On Mon, Jan 11, 2021 at 10:26 AM John Paul Adrian Glaubitz
[off-list ref] wrote:
quoted
On 1/11/21 10:20 AM, Geert Uytterhoeven wrote:
quoted
quoted
Sounds interesting. Do these SoCs come with an MMU? And do they use the
ColdFire instruction set or do they run plain 68k code?
No MMU, plain m68k code.
68328 Soc = 68000 core + some peripherals,
68360 SoC = CPU32 core (based on 68020 + some peripherals.
OK, I guess that would be useful for the NoMMU Linux port.
Note that 68360 support was removed from the kernel in 2016, as
Arnd said.
And that 68360 was bit rotten for a very long time before that.
Nobody ever seemed to show much interest in it.
Keep in mind that the 68328 family of parts are pretty slow too...
quoted
quoted
Anyone working on integrating m68k (and SPARC and MIPS?) softcores in
LiteX? ;-)
I'm personally waiting for the Vampire to gain support for the real 68851
as the hardware in general looks very attractive [1].
The 68851 is way too complex for what's needed (who needs support for
256 byte pages (https://lwn.net/Articles/839746/)?).
They'd be better off implementing something simpler, like 68040 MMU
support, or perhaps even a software-controlled TLB like most RISC
architectures (incl. ColdFire?). The latter would require more changes
to Linux, though.
Yep, the ColdFire MMU is a software controlled TLB.
Regards
Greg
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: David Laight <hidden> Date: 2021-01-11 09:52:24
From: Arnd Bergmann
Sent: 09 January 2021 21:53
On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau [off-list ref] wrote:
quoted
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
quoted
* 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.
These also are the last generation of fanless x86 boards with 100% compatible
controllers, that some people have probably kept around because these don't
age much and have plenty of connectivity. I've used an old one a few times
to plug in an old floppy drive, ISA SCSI controllers to access an old tape
drive and a few such things. That doesn't mean that it's a good justification
not to remove them, what I rather mean is that *if* there is no benefit
in dropping them maybe we can keep them. On the other hand, good luck for
running a modern OS on these, when 16MB-32MB RAM was about the maximum that
was commonly found by then (though if people kept them around that's probably
because they were well equipped, like that 64MB 386DX I'm having :-)).
I think there were 486s with up to 256MB, which would still qualify as barely
usable for a minimal desktop, or as comfortable for a deeply embedded
system. The main limit was apparently the cacheable RAM, which is limited
by the amount of L2 cache -- you needed a rare 1MB of external L2-cache to
have 256MB of cached RAM, while more common 256KB of cache would
be good for 64MB. Vortex86SX has no FPU or L2 cache at all, but supports
256MB of DDR2.
There are also some newer (well less than 30 year old) cpus that are
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Date: 2021-01-11 10:00:03
On Mon, Jan 11, 2021 at 09:59:23AM +0100, Arnd Bergmann wrote:
On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven [off-list ref] wrote:
quoted
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have a (32-bit) RBTX4927 development board in my board farm, boot-test
every bi-weekly renesas-drivers release on it, and fix kernel issues
when they appear.
Right, I was specifically thinking of the MIPS-II/R3000 ones here, I know
there are users on multiple actively maintained MIPS-III platforms.
Maciej still runs R3k based machines.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jan 11, 2021 at 2:40 AM Daniel Palmer [off-list ref] wrote:
Hi Arnd,
On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have some patches for the DragonBall series to enable SPI etc there,
some patches to support the SuperVZ variant, some tools to upload
Linux via the integrated serial bootloader.
Ah, good to know. Note that I recently did some cleanups for dragonball,
which were Greg merged into 5.10, but I don't think that he or anyone
else tested them on real hardware.
The DragonBall is probably what anyone that wants to build a 68K retro
computer should use as the DRAM controller is integrated and it can
access 32MB of SDRAM.
I generally wouldn't recommend MMU-less hardware for new projects
any more, when your primary goal is to run the latest Linux kernel.
As recently as 2017, there was a lot of work going into a bunch of
platforms (J2, STM32, SAMV7, pre-v4e Coldfire, ...) in both user space
and kernel, but that seems have significantly slowed down in the
past years (K210 being the notable exception). The fewer users there
are on other NOMMU targets, the harder I expect it to get for the
remaining ones to keep it from breaking.
Of course, for a retro computer, that may not be relevant. If you
just want to run Vintage operating systems (including older
Linux kernels) and you just do it for fun, then this sounds like a
good choice.
I haven't tested it recently but it should still work and I have
hardware and I'm willing to look after it if no one else wants to.
For the purpose of documenting the current state, it would be
great if you could just do a minimal test on linux-5.10 to see if
anything broke since you last ran it.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Alexander Sverdlin <hidden> Date: 2021-01-11 10:28:55
Hello Arnd,
On 11/01/2021 10:31, Arnd Bergmann wrote:
quoted
quoted
* axxia -- added in 2014, no notable changes after 2015
This one is still widely used there is a chance you are using it too when
traveling in Asia or USA :)
I know this one has a large installed base, and that Intel were at
least working on it for a while after upstream contributions stopped.
However, my impression was that the port was never completed
upstream before the acquisition, and that the new owners had no
interest in working with us. In particular, none of the later Axxia
SoCs (ppc32/axe3500, arm64/axm5600, arm64/axc6700) ever got
submitted for inclusion as far as I can tell.
The latest public source code I found is at https://github.com/axxia/,
but this is a heavily patched linux-4.9, see
https://github.com/axxia/axxia_yocto_linux_4.9/commits/fa03c456641
My interpretation of this was that whoever is using Axxia chips
is no longer interested in upgrading to newer kernels or using
anything remotely resembling the code we have uptream.
we indeed upgrade to the latest kernels but yes, we have to forward-port
LSI/Intel's code again and again.
And while AXM55xx is ugly hardware in itself where we need to patch a lot,
64-bit variants are working out of the box with vanilla kernel actually.
We by no means want this platform to be thrown away, so let us work a
road map out.
I'll assess what the situation is with AXM55xx, AXM56xx and AXC67 (which from my PoV
is no different from AXM56xx) and share my ideas.
I'm of course not in the position to submit patches you found in their
github account, but maybe there is another solution.
--
Best regards,
Alexander Sverdlin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Arnd,
On Mon, Jan 11, 2021 at 10:16 AM Geert Uytterhoeven
[off-list ref] wrote:
On Mon, Jan 11, 2021 at 9:59 AM Arnd Bergmann [off-list ref] wrote:
quoted
On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven [off-list ref] wrote:
quoted
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have a (32-bit) RBTX4927 development board in my board farm, boot-test
every bi-weekly renesas-drivers release on it, and fix kernel issues
when they appear.
Right, I was specifically thinking of the MIPS-II/R3000 ones here, I know
there are users on multiple actively maintained MIPS-III platforms.
Regarding 32-bit vs 64-bit kernels, can you clarify what makes this one
a 32-bit board? Is this just your preference for which kernel you install,
or are there dependencies on firmware or hardware that require running
this machine in 32-bit mode?
TX492x is 32-bit (/proc/cpuinfo says mips1/mips2/mips3), TX493x is 64-bit.
As Debian dropped support for mips3 and older, I'm stuck at a Jessie nfsroot.
Upon closer look, all TX49xx are 64-bit, but the VxWorks boot loader
refuses to boot 64-bit kernels ("Size is incorrect"), hence I settled
for a 32-bit kernel config a long time ago.
Probably I need to write a 32-bit bootwrapper first. which would allow
me to upgrade the Debian userland beyond jessie using mips64el?
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jan 11, 2021 at 10:40 AM Thomas Bogendoerfer
[off-list ref] wrote:
On Mon, Jan 11, 2021 at 09:59:23AM +0100, Arnd Bergmann wrote:
quoted
On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven [off-list ref] wrote:
quoted
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann [off-list ref] wrote:
quoted
* 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.
I have a (32-bit) RBTX4927 development board in my board farm, boot-test
every bi-weekly renesas-drivers release on it, and fix kernel issues
when they appear.
Right, I was specifically thinking of the MIPS-II/R3000 ones here, I know
there are users on multiple actively maintained MIPS-III platforms.
On Mon, Jan 11, 2021 at 11:28 AM Geert Uytterhoeven
[off-list ref] wrote:
quoted
quoted
Regarding 32-bit vs 64-bit kernels, can you clarify what makes this one
a 32-bit board? Is this just your preference for which kernel you install,
or are there dependencies on firmware or hardware that require running
this machine in 32-bit mode?
TX492x is 32-bit (/proc/cpuinfo says mips1/mips2/mips3), TX493x is 64-bit.
As Debian dropped support for mips3 and older, I'm stuck at a Jessie nfsroot.
Upon closer look, all TX49xx are 64-bit, but the VxWorks boot loader
refuses to boot 64-bit kernels ("Size is incorrect"), hence I settled
for a 32-bit kernel config a long time ago.
Ah, that makes sense.
Probably I need to write a 32-bit bootwrapper first. which would allow
me to upgrade the Debian userland beyond jessie using mips64el?
No, I don't think it would help you here, as Debian Stretch requires
either MIPS32r2 or MIPS64r2 processors, so neither MIPS-II nor
MIPS-III work any more.
Not sure what others are running on their pre-r2 hardware these days.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jan 11, 2021 at 11:27 AM Alexander Sverdlin
[off-list ref] wrote:
On 11/01/2021 10:31, Arnd Bergmann wrote:
quoted
quoted
quoted
* axxia -- added in 2014, no notable changes after 2015
This one is still widely used there is a chance you are using it too when
traveling in Asia or USA :)
I know this one has a large installed base, and that Intel were at
least working on it for a while after upstream contributions stopped.
However, my impression was that the port was never completed
upstream before the acquisition, and that the new owners had no
interest in working with us. In particular, none of the later Axxia
SoCs (ppc32/axe3500, arm64/axm5600, arm64/axc6700) ever got
submitted for inclusion as far as I can tell.
The latest public source code I found is at https://github.com/axxia/,
but this is a heavily patched linux-4.9, see
https://github.com/axxia/axxia_yocto_linux_4.9/commits/fa03c456641
My interpretation of this was that whoever is using Axxia chips
is no longer interested in upgrading to newer kernels or using
anything remotely resembling the code we have uptream.
we indeed upgrade to the latest kernels but yes, we have to forward-port
LSI/Intel's code again and again.
And while AXM55xx is ugly hardware in itself where we need to patch a lot,
64-bit variants are working out of the box with vanilla kernel actually.
We by no means want this platform to be thrown away, so let us work a
road map out.
I'll assess what the situation is with AXM55xx, AXM56xx and AXC67
(which from my PoV
is no different from AXM56xx) and share my ideas.
Sure, sounds good. Great to head the 64-bit parts actually work.
It would be great to have a Kconfig.platforms entry for it and
maybe one .dts file either for a reference machine, or one of the
products you work with.
I'm of course not in the position to submit patches you found in their
github account, but maybe there is another solution.
Why not? As long as the code looks reasonable and has a GPLv2
compatible license, you should be able to take any small or large
subset of their work and send it our way.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
* spear -- added in 2010, no notable changes since 2015
I started an email chain with the ST folks to see if there are any
concerns with this getting removed and it was confirmed by Mattias
(Cc'd) from Schneider Electric (one of SPEAr's customers) that they
indeed use mainline on spear320s and the spear1380 boards, while they
also have access to spear1310 board which they don't use that often.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marc Gonzalez <hidden> Date: 2021-01-11 13:15:04
[ Dropping maintainers of other platforms ]
On 08/01/2021 23:55, Arnd Bergmann wrote:
After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.
This is probably a mix of platforms that are completely unused and
those that just work, but I have no good way of knowing which one
it is. Without hearing back about these, I'd propose removing all of
these:
* asm9260 -- added in 2014, no notable changes after 2015
* axxia -- added in 2014, no notable changes after 2015
* bcm/kona -- added in 2013, no notable changes after 2014
* digicolor -- added in 2014, no notable changes after 2015
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
* efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
* nspire -- added in 2013, no notable changes after 2015
* picoxcell -- added in 2011, already queued for removal
* prima2 -- added in 20111, no notable changes since 2015
* spear -- added in 2010, no notable changes since 2015
* tango -- added in 2015, sporadic changes until 2017, but abandoned
* u300 -- added in 2009, no notable changes since 2013
* vt8500 -- added in 2010, no notable changes since 2014
* zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
If any of the above are not dead yet[2], please let me know,
and we'll keep them.
Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:
* clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
changes since
* cns3xxx -- added in 2010, last fixed in 2019, probably no users left
* ep93xx -- added in 2006, LinusW still working on it, any users left?
* footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have one
* gemini -- added in 2009, LinusW still working on it
* hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
* highbank -- added in 2011, no changes after 2015, but Andre still uses it
* iop32x -- added in 2006, no notable changes other than my cleanup, but
I think there are still users
* ixp4xx -- prehistoric, but LinusW and I are still working on it
* lpc18xx -- added in 2015, new dts in 2018, but few other changes
* lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
* mmp -- added in 2009, DT support is active, but board files might go
* moxart -- added in 2013, last Tested-by in 2017
* mv78xx0 -- added in 2008, mostly stale but still users
(https://github.com/1000001101000/Debian_on_Buffalo)
* nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
* oxnas -- added in 2016, but already old then, few changes later
* pxa -- prehistoric, but a few boards may still have users
* rpc -- prehistoric, but I think Russell still uses his machine
* sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
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
* 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
* 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
* 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)
* 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.
* 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.
* 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.
Arnd
[1] https://lwn.net/Articles/838807/
[2] https://www.youtube.com/watch?v=Jdf5EXo6I68
I didn't see Mans in the CC list. Not sure he's seen this message.
As far as tango is concerned, I didn't keep any boards.
Mans might have some tango3 and tango4 boards.
Waiting for his take on the matter.
I can point out some device-specific drivers that would become
useless if tango support were dropped.
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Salter <hidden> Date: 2021-01-11 14:24:18
On Fri, 2021-01-08 at 23:55 +0100, Arnd Bergmann wrote:
* 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.
Hi Arnd,
So this has been on my mind for a while now. I no longer have working hw
for c6x and TI hasn't been forthcoming with replacements. I'm totally fine
with removing it from mainline. In any case, I'm not really in a position
to go forward as maintainer.
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Alexander Shiyan <hidden> Date: 2021-01-11 14:46:38
On Fri, 8 Jan 2021 23:55:06 +0100
Arnd Bergmann [off-list ref] wrote:
Hello.
...
Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:
* clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
changes since
I still keep this architecture up and running (currently at 5.9.0).
--
Alexander Shiyan [off-list ref]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jan 11, 2021 at 3:48 PM Alexander Shiyan [off-list ref] wrote:
On Fri, 8 Jan 2021 23:55:06 +0100 Arnd Bergmann [off-list ref] wrote:
quoted
Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:
* clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
changes since
I still keep this architecture up and running (currently at 5.9.0).
On Mon, Jan 11, 2021 at 3:22 PM Mark Salter [off-list ref] wrote:
On Fri, 2021-01-08 at 23:55 +0100, Arnd Bergmann wrote:
quoted
* 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.
Hi Arnd,
So this has been on my mind for a while now. I no longer have working hw
for c6x and TI hasn't been forthcoming with replacements. I'm totally fine
with removing it from mainline. In any case, I'm not really in a position
to go forward as maintainer.
Ok, let's remove it then. I'm happy to take patches through my
asm-generic tree. If someone shows up later that does have an
interest in the platform for future kernels, I'll drop the branch or
revert it after it gets merged.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Arnd,
According to NXP
(https://www.nxp.com/products/product-information/product-longevity:PRDCT_LONGEVITY_HM),
the LPC32xx is still an active product (although it was listed for 10
years in 2009).
We still have active products in the field with this MCU and we are
still shipping products with the LPC3250.
I think this platform should remain in the kernel for now.
Regards,
Sylvain Lemieux
On Fri, Jan 8, 2021 at 5:58 PM Arnd Bergmann [off-list ref] wrote:
After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.
This is probably a mix of platforms that are completely unused and
those that just work, but I have no good way of knowing which one
it is. Without hearing back about these, I'd propose removing all of
these:
* asm9260 -- added in 2014, no notable changes after 2015
* axxia -- added in 2014, no notable changes after 2015
* bcm/kona -- added in 2013, no notable changes after 2014
* digicolor -- added in 2014, no notable changes after 2015
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
* efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
* nspire -- added in 2013, no notable changes after 2015
* picoxcell -- added in 2011, already queued for removal
* prima2 -- added in 20111, no notable changes since 2015
* spear -- added in 2010, no notable changes since 2015
* tango -- added in 2015, sporadic changes until 2017, but abandoned
* u300 -- added in 2009, no notable changes since 2013
* vt8500 -- added in 2010, no notable changes since 2014
* zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
If any of the above are not dead yet[2], please let me know,
and we'll keep them.
Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:
* clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
changes since
* cns3xxx -- added in 2010, last fixed in 2019, probably no users left
* ep93xx -- added in 2006, LinusW still working on it, any users left?
* footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have one
* gemini -- added in 2009, LinusW still working on it
* hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
* highbank -- added in 2011, no changes after 2015, but Andre still uses it
* iop32x -- added in 2006, no notable changes other than my cleanup, but
I think there are still users
* ixp4xx -- prehistoric, but LinusW and I are still working on it
* lpc18xx -- added in 2015, new dts in 2018, but few other changes
* lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
* mmp -- added in 2009, DT support is active, but board files might go
* moxart -- added in 2013, last Tested-by in 2017
* mv78xx0 -- added in 2008, mostly stale but still users
(https://github.com/1000001101000/Debian_on_Buffalo)
* nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
* oxnas -- added in 2016, but already old then, few changes later
* pxa -- prehistoric, but a few boards may still have users
* rpc -- prehistoric, but I think Russell still uses his machine
* sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
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
* 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
* 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
* 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)
* 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.
* 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.
* 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.
Arnd
[1] https://lwn.net/Articles/838807/
[2] https://www.youtube.com/watch?v=Jdf5EXo6I68
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Date: 2021-01-11 19:59:38
Hello,
I haven't gone through the full thread, so sorry if some of the below
information duplicates stuff that was already said.
On Fri, 8 Jan 2021 23:55:06 +0100
Arnd Bergmann [off-list ref] wrote:
* asm9260 -- added in 2014, no notable changes after 2015
* axxia -- added in 2014, no notable changes after 2015
* bcm/kona -- added in 2013, no notable changes after 2014
* digicolor -- added in 2014, no notable changes after 2015
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
arch/arm/mach-dove has two remaining board files, cm-a510.c and
dove-db-setup.c. The former is covered by the
dove-cm-a510.dtsi/dove-sbc-a510.dts DTs and the latter by
dove-dove-db.dts.
However, dove-dove-db.dts doesn't seem to have all the features of
dove-db-setup.c. The DT only enables UART, SDIO, SATA, SPI and I2C0.
The board file has PCIe, Ethernet, USB.
The dove-sbc-a510.dts seems much more complete, as it includes
Ethernet, PCIe, USB in addition to SATA, SDIO, I2C, SPI, UART, etc.
So overall, I'd say that yes we could probably drop arch/arm/mach-dove/.
* spear -- added in 2010, no notable changes since 2015
Well, I did quite a few improvements in spear DTs in 2017, some
improvements to the NAND FSMC driver for Spear, and my colleague Miquèl
Raynal fixed an issue in the Spear NOR driver in 2019.
We have one customer running a 4.14 upstream kernel on a Spear600
product, and this was a fairly "recent" port, in the sense that the
product was originally running WinCE, and we ported Linux to it many
years later after the product was first shipped.
* lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
As late as early 2020, we were finishing the migration of one of our
customer LPC32xx platform to a recent mainline kernel.
So in fact for us at Bootlin, it happens pretty regularly to see users
of "legacy" platforms having a need for an updated kernel. From the
above, you can see that even legacy SoCs such as Spear600 and LPC32xx
are still used in products were kernel are being updated.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar [off-list ref] wrote:
On 08-01-21, 23:55, Arnd Bergmann wrote:
quoted
* spear -- added in 2010, no notable changes since 2015
I started an email chain with the ST folks to see if there are any
concerns with this getting removed and it was confirmed by Mattias
(Cc'd) from Schneider Electric (one of SPEAr's customers) that they
indeed use mainline on spear320s and the spear1380 boards, while they
also have access to spear1310 board which they don't use that often.
Thank you for reaching out to them!
Do we actually support spear1380 with the mainline kernel? I've
never seen anything other than 1310 and 1340 models mentioned.
If Schneider have additional patches on top of mainline for this,
it would be good to get those merged as well. Is there a kernel
source tree available somewhere?
Rob Herring had mentioned that it would be nice to see SPEAr
get removed eventually because it was only partially converted
to devicetree, with some AUXDATA() (on 300/310/320/6xx) and
some dmaengine channel data still in source format. These need
to be finished before we can kill off AUXDATA.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Russell King - ARM Linux admin <linux@armlinux.org.uk> Date: 2021-01-11 20:10:19
On Sat, Jan 09, 2021 at 10:34:57PM +0100, Arnd Bergmann wrote:
On Sat, Jan 9, 2021 at 6:43 PM Russell King - ARM Linux admin
[off-list ref] wrote:
quoted
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
quoted
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
May be obsoleted, but I still use this for my dove cubox with
additional patches.
What is the status of these patches? I also still have a set of patches
to integrate it with the other ARMv7 machines into multiplatform,
and a series to change some of the PCI handling in all plat-orion
platforms, that I was hoping to either upstream or drop once the
platform itself gets removed.
I really couldn't say - I have over 200 patches in my kernel tree for
the Dove Cubox that give me a fully featured kernel - and I mean
everything, including the vMeta video decoder. I haven't updated the
tree since last Summer, partly because other things have taken
precedence. I couldn't say what the status is right now without
going through an update to 5.10.
However, some bits can't go into mainline - I was totally shafted over
the audio support. There is no way to add flexible support to the
kirkwood audio driver without breaking the DT descriptions for every
board using that - and by flexible, I mean the ability to output DTS
via the SPDIF connector or HDMI on the Dove Cubox. I wasn't listened
to at the time, and it _still_ hurts to this day that there is no way
back from the crippling bad choices that mainline kernel developers
and others made. There was no need for this, other than a desire to
merge something that worked for everyone else but was totally
unsuitable to be able to provide the full features.
Did you give up on moving the Cubox to DT, or is this something you
still want to get back?
On Mon, Jan 11, 2021 at 8:58 PM Thomas Petazzoni
[off-list ref] wrote:
quoted
On Fri, 8 Jan 2021 23:55:06 +0100 Arnd Bergmann [off-list ref] wrote:
So overall, I'd say that yes we could probably drop arch/arm/mach-dove/.
Russell mentioned that he still uses a cubox with an out-of-tree
board file for dove.
quoted
* spear -- added in 2010, no notable changes since 2015
Well, I did quite a few improvements in spear DTs in 2017, some
improvements to the NAND FSMC driver for Spear, and my colleague Miquèl
Raynal fixed an issue in the Spear NOR driver in 2019.
We have one customer running a 4.14 upstream kernel on a Spear600
product, and this was a fairly "recent" port, in the sense that the
product was originally running WinCE, and we ported Linux to it many
years later after the product was first shipped.
Ok, thanks for the list, very helpful. Sorry I missed your DT changes
when I went through the logs there.
Viresh already pointed out Schneider Electric as a user of multiple
SPEAr SoCs.
quoted
* lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
As late as early 2020, we were finishing the migration of one of our
customer LPC32xx platform to a recent mainline kernel.
So in fact for us at Bootlin, it happens pretty regularly to see users
of "legacy" platforms having a need for an updated kernel. From the
above, you can see that even legacy SoCs such as Spear600 and LPC32xx
are still used in products were kernel are being updated.
I had put the lpc32xx in the list of code that is still updated and
should not get removed unless the maintainers think it is near
its end of useful life (which I did not really expect in this case).
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Song Bao Hua (Barry Song) <hidden> Date: 2021-01-11 20:26:32
-----Original Message-----
From: Arnd Bergmann [mailto:arnd@kernel.org]
Sent: Saturday, January 9, 2021 11:55 AM
To: Linux ARM <redacted>; Linux Kernel Mailing
List [off-list ref]
Cc: Krzysztof Adamski <redacted>; Oleksij Rempel
[off-list ref]; Baruch Siach [off-list ref]; Russell King -
ARM Linux [off-list ref]; Daniel Tang [off-list ref]; Uwe
Kleine-König [off-list ref]; Jamie Iles
[off-list ref]; Song Bao Hua (Barry Song) [off-list ref];
Viresh Kumar [off-list ref]; Linus Walleij
[off-list ref]; Jonas Jensen [off-list ref]; Marc
Gonzalez [off-list ref]; Hartley Sweeten
[off-list ref]; Lubomir Rintel [off-list ref]; Neil
Armstrong [off-list ref]; Shawn Guo [off-list ref]; Alex
Elder [off-list ref]; Alexander Shiyan [off-list ref]; Koen Vandeputte
[off-list ref]; Hans Ulli Kroll [off-list ref];
Vladimir Zapolskiy [off-list ref]; xuwei (O) [off-list ref]; Steven
Rostedt [off-list ref]; Yoshinori Sato [off-list ref];
Mark Salter [off-list ref]; Michael Ellerman [off-list ref]; Geert
Uytterhoeven [off-list ref]; Thomas Bogendoerfer
[off-list ref]
Subject: Old platforms: bring out your dead
After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.
This is probably a mix of platforms that are completely unused and
those that just work, but I have no good way of knowing which one
it is. Without hearing back about these, I'd propose removing all of
these:
* asm9260 -- added in 2014, no notable changes after 2015
* axxia -- added in 2014, no notable changes after 2015
* bcm/kona -- added in 2013, no notable changes after 2014
* digicolor -- added in 2014, no notable changes after 2015
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
* efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
* nspire -- added in 2013, no notable changes after 2015
* picoxcell -- added in 2011, already queued for removal
* prima2 -- added in 20111, no notable changes since 2015
Hi Arnd,
I got confirmation from Qualcomm guys that there is no plan
to maintain prima2 in mainline any more.
Please feel free to remove the code. If you need my help,
Please let me know.
* spear -- added in 2010, no notable changes since 2015
* tango -- added in 2015, sporadic changes until 2017, but abandoned
* u300 -- added in 2009, no notable changes since 2013
* vt8500 -- added in 2010, no notable changes since 2014
* zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar [off-list ref] wrote:
quoted
On 08-01-21, 23:55, Arnd Bergmann wrote:
quoted
* spear -- added in 2010, no notable changes since 2015
I started an email chain with the ST folks to see if there are any
concerns with this getting removed and it was confirmed by Mattias
(Cc'd) from Schneider Electric (one of SPEAr's customers) that they
indeed use mainline on spear320s and the spear1380 boards, while they
also have access to spear1310 board which they don't use that often.
Thank you for reaching out to them!
Do we actually support spear1380 with the mainline kernel? I've
never seen anything other than 1310 and 1340 models mentioned.
If Schneider have additional patches on top of mainline for this,
it would be good to get those merged as well. Is there a kernel
source tree available somewhere?
Rob Herring had mentioned that it would be nice to see SPEAr
get removed eventually because it was only partially converted
to devicetree, with some AUXDATA() (on 300/310/320/6xx) and
some dmaengine channel data still in source format. These need
to be finished before we can kill off AUXDATA.
Thanks for taking the time Arnd and Viresh
The spear1380 is not supported in mainline but it's quite similar to 1310 and 1340.
The spear13xx comes in a few flavors. 1310 and 1340 are the standard ones sold by ST and the 1380 are the customized version for Schneider Electric needs. One part of the chip is customizable but the base is the same in all 13xx. So a few IP blocks differ between the flavors. I can try to send you the 1380 stuff as well.
There is currently no external source tree for our kernel easy available.
If the AUXDATA on 3xx is a problem I can try to start focus on sending for patches in that area. We have patches that move some more parts over to devicetree (compared to mainline) but we haven't converted all. I will investigate if we have something that helps in that area.
Thanks,
Mattias Wallin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jan 11, 2021 at 10:15 PM Mattias Wallin [off-list ref] wrote:
quoted
On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar [off-list ref] wrote:
quoted
On 08-01-21, 23:55, Arnd Bergmann wrote:
quoted
* spear -- added in 2010, no notable changes since 2015
I started an email chain with the ST folks to see if there are any
concerns with this getting removed and it was confirmed by Mattias
(Cc'd) from Schneider Electric (one of SPEAr's customers) that they
indeed use mainline on spear320s and the spear1380 boards, while they
also have access to spear1310 board which they don't use that often.
quoted
Thank you for reaching out to them!
quoted
Do we actually support spear1380 with the mainline kernel? I've
never seen anything other than 1310 and 1340 models mentioned.
If Schneider have additional patches on top of mainline for this,
it would be good to get those merged as well. Is there a kernel
source tree available somewhere?
quoted
Rob Herring had mentioned that it would be nice to see SPEAr
get removed eventually because it was only partially converted
to devicetree, with some AUXDATA() (on 300/310/320/6xx) and
some dmaengine channel data still in source format. These need
to be finished before we can kill off AUXDATA.
Thanks for taking the time Arnd and Viresh
The spear1380 is not supported in mainline but it's quite similar to 1310 and 1340.
The spear13xx comes in a few flavors. 1310 and 1340 are the standard ones sold by ST and the 1380 are the customized version for Schneider Electric needs. One part of the chip is customizable but the base is the same in all 13xx. So a few IP blocks differ between the flavors. I can try to send you the 1380 stuff as well.
There is currently no external source tree for our kernel easy available.
If the AUXDATA on 3xx is a problem I can try to start focus on sending for patches in that area. We have patches that move some more parts over to devicetree (compared to mainline) but we haven't converted all. I will investigate if we have something that helps in that area.
This sounds great, thanks! I think the main work that needs to
be done here is to convert the DT over to use the regular
dma-controller binding (as used on spear13xx) for the pl080.
Please contact Vinod Koul, Linus Walleij and me in a separate
email thread if you have questions about that.
Looking forward to getting those patches,
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hello,
On 11/01/2021 11:23:40-0500, Sylvain Lemieux wrote:
According to NXP
(https://www.nxp.com/products/product-information/product-longevity:PRDCT_LONGEVITY_HM),
the LPC32xx is still an active product (although it was listed for 10
years in 2009).
We still have active products in the field with this MCU and we are
still shipping products with the LPC3250.
I think this platform should remain in the kernel for now.
From: Marc Gonzalez <hidden> Date: 2021-01-12 08:43:23
On 11/01/2021 21:25, Song Bao Hua (Barry Song) wrote:
I got confirmation from Qualcomm guys that there is no plan
to maintain prima2 in mainline any more.
Please feel free to remove the code. If you need my help,
Please let me know.
Hello Barry,
I didn't know that qualcomm worked on mainline kernels, except through
the Code Aurora and Linaro arrangement.
Was the mainline work done by CSR plc /before/ it was swallowed by qcom?
https://en.wikipedia.org/wiki/CSR_(company)
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andy Shevchenko <hidden> Date: 2021-01-13 10:28:26
On Mon, Jan 11, 2021 at 11:55 AM David Laight [off-list ref] wrote:
From: Arnd Bergmann
quoted
Sent: 09 January 2021 21:53
On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau [off-list ref] wrote:
quoted
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
quoted
* 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.
These also are the last generation of fanless x86 boards with 100% compatible
controllers, that some people have probably kept around because these don't
age much and have plenty of connectivity. I've used an old one a few times
to plug in an old floppy drive, ISA SCSI controllers to access an old tape
drive and a few such things. That doesn't mean that it's a good justification
not to remove them, what I rather mean is that *if* there is no benefit
in dropping them maybe we can keep them. On the other hand, good luck for
running a modern OS on these, when 16MB-32MB RAM was about the maximum that
was commonly found by then (though if people kept them around that's probably
because they were well equipped, like that 64MB 386DX I'm having :-)).
I think there were 486s with up to 256MB, which would still qualify as barely
usable for a minimal desktop, or as comfortable for a deeply embedded
system. The main limit was apparently the cacheable RAM, which is limited
by the amount of L2 cache -- you needed a rare 1MB of external L2-cache to
have 256MB of cached RAM, while more common 256KB of cache would
be good for 64MB. Vortex86SX has no FPU or L2 cache at all, but supports
256MB of DDR2.
There are also some newer (well less than 30 year old) cpus that are
(less than 10 years actually)
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
Right, we have "last of mohicans" (to date) Intel Quark family of CPUs
(486 core + few i586 features).
This is for the embedded world and probably not for powerful use.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andy Shevchenko <hidden> Date: 2021-01-13 10:31:25
On Sat, Jan 9, 2021 at 12:58 AM Arnd Bergmann [off-list ref] wrote:
After v5.10 was officially declared an LTS kernel,
I have a question here. Maybe I have missed something, but how LTS
helps in this case? LTS AFAIR has a rule "upstream first". How can you
provide a patch to be backported if there is no upstream for it
anymore?
* 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.
We still have Intel Quark available. I run vanilla from time to time
on it due to the presence of peripherals I can't find elsewhere on x86
boards.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jan 13, 2021 at 11:31 AM Andy Shevchenko
[off-list ref] wrote:
On Sat, Jan 9, 2021 at 12:58 AM Arnd Bergmann [off-list ref] wrote:
quoted
After v5.10 was officially declared an LTS kernel,
I have a question here. Maybe I have missed something, but how LTS
helps in this case? LTS AFAIR has a rule "upstream first". How can you
provide a patch to be backported if there is no upstream for it
anymore?
Platform specific bugs are usually not the problem here, and if something
does happen on deleted code, I would expect you can get an exception
to the "upstream first" rule.
What I was getting at here were the things in the second category, the
stuff that is is still maintained and working, but so old that it becomes a
burden for maintainers. If a maintainer knows who all the users are
and what they do with their machines, removing the platform from mainline
would be a chance to get everyone to use the same LTS version so they
can get bugfixes to common kernel code for a few more years and
benefit from everyone else testing the same codebase.
quoted
* 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.
We still have Intel Quark available. I run vanilla from time to time
on it due to the presence of peripherals I can't find elsewhere on x86
boards.
While Quark is derived from a i486 pipeline, the kernel treats it as
CONFIG_M586TSC, as it contains fpu, rdtsc, cpuid and cmpxchg8b
instructions but no cmov or mmx. More importantly, you wouldn't find the
vintage i486 peripherals (drivers/ide, drivers/video/fbdev, VLB, ISA,
floppy) but instead have modern stuff like USB, PCIe, and eMMC.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
[off-list ref] wrote:
On Mon, Jan 11, 2021 at 11:55 AM David Laight [off-list ref] wrote:
quoted
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
Right, we have "last of mohicans" (to date) Intel Quark family of CPUs
(486 core + few i586 features).
This is for the embedded world and probably not for powerful use.
What is the status of PC/104?
https://en.wikipedia.org/wiki/PC/104
I have three GPIO drivers for PC/104 machines and these are for
embedded industrial usecases. I am curious about what CPUs these
beasts run on in practice? Are they getting upgraded?
Paging William, I think he work on these daily.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andy Shevchenko <hidden> Date: 2021-01-13 12:19:11
On Wed, Jan 13, 2021 at 2:02 PM Linus Walleij [off-list ref] wrote:
On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
[off-list ref] wrote:
quoted
On Mon, Jan 11, 2021 at 11:55 AM David Laight [off-list ref] wrote:
quoted
quoted
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
Right, we have "last of mohicans" (to date) Intel Quark family of CPUs
(486 core + few i586 features).
This is for the embedded world and probably not for powerful use.
From: Andy Shevchenko <hidden> Date: 2021-01-13 12:22:49
On Wed, Jan 13, 2021 at 2:17 PM Andy Shevchenko
[off-list ref] wrote:
On Wed, Jan 13, 2021 at 2:02 PM Linus Walleij [off-list ref] wrote:
quoted
On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
[off-list ref] wrote:
quoted
On Mon, Jan 11, 2021 at 11:55 AM David Laight [off-list ref] wrote:
quoted
quoted
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
Right, we have "last of mohicans" (to date) Intel Quark family of CPUs
(486 core + few i586 features).
This is for the embedded world and probably not for powerful use.
From: William Breathitt Gray <hidden> Date: 2021-01-13 12:31:32
On Wed, Jan 13, 2021 at 01:02:20PM +0100, Linus Walleij wrote:
On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
[off-list ref] wrote:
quoted
On Mon, Jan 11, 2021 at 11:55 AM David Laight [off-list ref] wrote:
quoted
quoted
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
Right, we have "last of mohicans" (to date) Intel Quark family of CPUs
(486 core + few i586 features).
This is for the embedded world and probably not for powerful use.
What is the status of PC/104?
https://en.wikipedia.org/wiki/PC/104
I have three GPIO drivers for PC/104 machines and these are for
embedded industrial usecases. I am curious about what CPUs these
beasts run on in practice? Are they getting upgraded?
Paging William, I think he work on these daily.
Yours,
Linus Walleij
From: William Breathitt Gray <hidden> Date: 2021-01-13 12:57:18
On Wed, Jan 13, 2021 at 09:30:28PM +0900, William Breathitt Gray wrote:
On Wed, Jan 13, 2021 at 01:02:20PM +0100, Linus Walleij wrote:
quoted
On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
[off-list ref] wrote:
quoted
On Mon, Jan 11, 2021 at 11:55 AM David Laight [off-list ref] wrote:
quoted
quoted
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
Right, we have "last of mohicans" (to date) Intel Quark family of CPUs
(486 core + few i586 features).
This is for the embedded world and probably not for powerful use.
What is the status of PC/104?
https://en.wikipedia.org/wiki/PC/104
I have three GPIO drivers for PC/104 machines and these are for
embedded industrial usecases. I am curious about what CPUs these
beasts run on in practice? Are they getting upgraded?
Paging William, I think he work on these daily.
Yours,
Linus Walleij
Oops, I misread what you were asking. If you mean, are the systems that
run these PC/104 stackable devices running older processor series, then
yes that's typically the case.
It seems like newer systems have migrated to the PCIe/104 form factor,
which although having the same dimensions as the PC/104 form factor
lacks compatibility with PC/104 devices; for example:
https://www.rtd.com/i7/default.htm
I suspect the general trend in the market is moving towards these PCIe
modules because PC/104 ISA communication just lacks the bandwidth
necessary for many applications.
William Breathitt Gray
On Wed, Jan 13, 2021 at 1:02 PM Linus Walleij [off-list ref] wrote:
On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko [off-list ref] wrote:
quoted
On Mon, Jan 11, 2021 at 11:55 AM David Laight [off-list ref] wrote:
quoted
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
Right, we have "last of mohicans" (to date) Intel Quark family of CPUs
(486 core + few i586 features).
This is for the embedded world and probably not for powerful use.
What is the status of PC/104?
https://en.wikipedia.org/wiki/PC/104
I have three GPIO drivers for PC/104 machines and these are for
embedded industrial usecases. I am curious about what CPUs these
beasts run on in practice? Are they getting upgraded?
I had a look at those earlier when trying to find out what the remaining
users of CONFIG_ISA are. It turns out that you can still easily get new
x86 hardware with PC/104+ (combined ISA and PCI, not PCIe)
connectors, see e.g. https://www.versalogic.com/product/SandCat/.
Like the older VMEbus based systems, these would have at least 10
years of hardware availability (sometimes much more) and are indeed
designed for use over decades after that.
On the other hand, the set of ISA-style peripherals that you would
connect here has little overlap with the those you'd find on a 1990's
PC or Unix workstation, and I would expect that a lot of device
drivers for them were never submitted for mainline because they are
application specific.
We have a couple of ARMv5-generation systems with PC/104
support, added before the start of the git history:
* s3c2410/bast
* s3c2410/vr1000
* pxa25x/viper
* pxa27x/zeus
I would assume that some of those are still operational somewhere
in the world (along with similar machines without mainline support),
but none have seen in field kernel updates for years.
There is also ep93xx/ts72xx, which has a PC/104 connector
but no Linux support for it. A new version of the board was
added in 2017, so there are clearly still users, but they would
need add-on patches to use PC/104.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Richard Z <hidden> Date: 2021-01-14 02:07:19
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.
* 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)
me and a few other guys are still running m68k/q40. I did not compile
a new kernel for some time but will try.
Regards
Richard
There are some real/true PC104 boards left -
still in production - with boards (though
they tend to loose features like
"memory-mapping over the ISA-bus").
One is a - according to /proc/cpuinfo - a
"Intel(R) Atom(TM) CPU E3825 @ 1.33GHz".
Sry, I cannot get the product name.
MfG,
BErnd
--
Bernd Petrovitsch Email : bernd@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
There are some real/true PC104 boards left -
still in production - with boards (though
they tend to loose features like
"memory-mapping over the ISA-bus").
One is a - according to /proc/cpuinfo - a
"Intel(R) Atom(TM) CPU E3825 @ 1.33GHz".
Sry, I cannot get the product name.
MfG,
BErnd
--
Bernd Petrovitsch Email : bernd@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
That's part of the Bay Trail generation isn't it? Are those processors
still manufactured? My worry is that although there are boards still in
production, they might be simply using up an old stock of parts. The
question becomes whether these will still be produced in the near
future, or whether the companies are just using up the rest of their
supply.
William Breathitt Gray
From: David Laight <hidden> Date: 2021-01-15 09:01:00
From: William Breathitt Gray
Sent: 15 January 2021 00:24
...
That's part of the Bay Trail generation isn't it? Are those processors
still manufactured? My worry is that although there are boards still in
production, they might be simply using up an old stock of parts. The
question becomes whether these will still be produced in the near
future, or whether the companies are just using up the rest of their
supply.
The 'stock of parts' might go back as far as etched wafers that
haven't been cut up....
Even then it may take a moderate demand to get them processed.
We're have to redesign a board to use a completely different
part because the one we were using has gone end-of-life.
Hopefully the replacement will be made for a while.
The datasheet for that part is 12 years old.
The designs for both are probably over 20 years old.
The TDM E1/T1 interface is about 50.
But it is still used.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Pavel Machek <hidden> Date: 2021-02-04 21:03:13
Hi!
quoted
quoted
I think there were 486s with up to 256MB, which would still qualify as barely
usable for a minimal desktop, or as comfortable for a deeply embedded
system. The main limit was apparently the cacheable RAM, which is limited
by the amount of L2 cache -- you needed a rare 1MB of external L2-cache to
have 256MB of cached RAM, while more common 256KB of cache would
be good for 64MB. Vortex86SX has no FPU or L2 cache at all, but supports
256MB of DDR2.
There are also some newer (well less than 30 year old) cpus that are
(less than 10 years actually)
quoted
basically 486 but have a few extra instructions - probably just cpuid
and (IIRC) rdtsc.
Designed for low power embedded use they won't ever have been suitable
for a desktop - but are probably fast enough for some uses.
I'm not sure how much keeping 486 support actually costs, 386 was a
PITA - but the 486 fixed most of those issues.
Right, we have "last of mohicans" (to date) Intel Quark family of CPUs
(486 core + few i586 features).
This is for the embedded world and probably not for powerful use.
We have open-hardware implementation for 486, AFAICT, thanks to MISTer
project. I'm not aware of open 586 core.
Being able to run recent Linux on open hardware sounds fun.
Pavel
--
http://www.livejournal.com/~pavelmachek