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
On Fri, 8 Jan 2021 23:55:06 +0100
Arnd Bergmann <[email protected]> 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
"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/[email protected]/
I'm thinking to kill it and see if that causes any complaints.
-- Steve
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 ]
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> 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
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
On 1/8/2021 4:16 PM, Linus Walleij wrote:
>> * 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
On 1/8/2021 2:55 PM, 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
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
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
I also have some further patches that have been hanging around for
some time to modernise sa1100 a bit.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
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------------{=
- [email protected] - tel: +972.52.368.4656, http://www.tkos.co.il -
On Sat, Jan 9, 2021 at 6:34 PM Florian Fainelli <[email protected]> wrote:
> On 1/8/2021 2:55 PM, Arnd Bergmann wrote:
> > * 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
On Sat, Jan 9, 2021 at 9:21 PM Baruch Siach <[email protected]> wrote:
>
> 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.
Ok, dropping it from the list, thanks for your reply!
Arnd
On Sat, Jan 9, 2021 at 6:43 PM Russell King - ARM Linux admin
<[email protected]> wrote:
>
> 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.
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?
> > * 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
>
> 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
On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau <[email protected]> wrote:
>
> 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 :-)).
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
On Sat, Jan 9, 2021 at 1:18 AM Linus Walleij <[email protected]> wrote:
>
> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> 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.
Ok, thanks for confirming.
> > * 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.)
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
On Sat, Jan 9, 2021 at 12:32 AM Steven Rostedt <[email protected]> wrote:
>
> On Fri, 8 Jan 2021 23:55:06 +0100
> Arnd Bergmann <[email protected]> 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
>
> "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/[email protected]/
>
> 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
On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <[email protected]> wrote:
>
> Hi Arnd,
>
> On 9 Jan 2021, at 9:55 am, Arnd Bergmann <[email protected]> wrote:
>
> * nspire -- added in 2013, no notable changes after 2015
>
>
> I believe this is still in active use. I’ve CC’d Fabian into this thread who’s
> probably in a better position to respond to this.
Ok, moving it to the "keep around for now list" as well, to be on the
safe side. Would either of you already have a guess for how long it makes
sense to update kernels on it?
I see that this is one of the more limited platforms with just 32MB
of RAM (64MB in case of CX), and kernels only get more bloated over
time, so I expect at some point you will be stuck with running old
software.
Wikipedia tells me that new models came out recently. Are you
planning to add support for those as well?
Arnd
> 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
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
On Sun, Jan 10, 2021 at 12:12 AM Andrew Lunn <[email protected]> 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:
>
> 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
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 ...)
> > 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!
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
On Sun, Jan 10, 2021 at 4:51 PM Neil Armstrong <[email protected]> wrote:
>
> 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.
Ok, taken off the list now.
Thanks for the clarification,
Arnd
> 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
On Sun, Jan 10, 2021 at 5:48 PM Andrew Lunn <[email protected]> wrote:
>
> > 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
Hi Arnd!
(Please let's have this cross-posted for more visibility. I only learned about this
while reading Phoronix news)
> I also looked at non-ARM platforms while preparing for my article. Some of
> these look like they are no longer actively maintained or used, but I'm not
> doing anything about those unless the maintainers would like me to:
>
> * h8300: Steven Rostedt has repeatedly asked about it to be removed
> or fixed in 2020 with no reply. This was killed before in 2013, added back
> in 2015 but has been mostly stale again since 2016
As far as I know, Yoshinori Sato is actively maintaining H8300 support, see:
> https://osdn.net/projects/uclinux-h8/
> * c6x: Added in 2011, this has seen very few updates since, but
> Mark still Acks patches when they come. Like most other DSP platforms,
> the model of running Linux on a DSP appears to have been obsoleted
> by using Linux on ARM with on-chip DSP cores running bare-metal code.
> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
> is currently under review
I don't think this has reached any agreement yet. Multiple people want it to stay.
> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
> it's in my backlog but I will get to it. This is separate from PS3,
> which is actively
> maintained and used; spufs will move to ps3
> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
I'm still using this. Please keep it.
> * powerpc/amigaone: last updated in 2009
> * powerpc/maple: last updated in 2011
> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
> seen updates in many years (atari/amiga/mac and coldfire are very much
> alive)
Dito. I have both sun3 and hp300 machines.
> * mips/jazz: last updated in 2007
> * mips/cobalt: last updated in 2010
>
> There might be some value in dropping old CPU support on architectures
> and platforms that are almost exclusively used with more modern CPUs.
> If there are only few users, those can still keep using v5.10 or v5.4 stable
> kernels for a few more years. Again, I'm not doing anything about them,
> except mention them since I did the research.
> These are the oldest one by architecture, and they may have reached
> their best-served-by-date:
>
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
> indications that 486 have no users either on recent kernels.
> There is still the Vortex86 family of SoCs, and the oldest of those were
> 486SX-class, but all the modern ones are 586-class.
> * Alpha 2106x: First generation that lacks some of the later features.
> Since all Alphas are ancient by now, it's hard to tell whether these have
> any fewer users.
I don't see the point in crippling Alpha support. Does this achieve anything?
> * IA64 Merced: first generation Itanium (2001) was quickly replaced by
> Itanium II in 2002.
> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
> 64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
> supports these in DECstation and Toshiba Txx9, but it appears that most
> of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
> later are rather different and widely used.
> * PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
> are apparently all still used.
> * SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
> support in the past, I don't think there were any objections, but
> nobody submitted a patch.
Isn't SH-2 basically J-2? I'm not sure what we would gain here.
> * 68000/68328 (Dragonball): these are less capable than the
> 68020+ or the Coldfire MCF5xxx line and similar to the 68360
> that was removed in 2016.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi,
Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <[email protected]> wrote:
> >
> > Hi Arnd,
> >
> > On 9 Jan 2021, at 9:55 am, Arnd Bergmann <[email protected]> wrote:
> >
> > * nspire -- added in 2013, no notable changes after 2015
Most of the platform is just the DT sources and some small drivers around it,
so it's actually fairly low maintenance. So far the migration away from
panel-simple in 2019
(https://lore.kernel.org/linux-arm-kernel/[email protected])
was the biggest required change so far.
> > I believe this is still in active use. I’ve CC’d Fabian into this thread who’s
> > probably in a better position to respond to this.
>
> Ok, moving it to the "keep around for now list" as well, to be on the
> safe side.
Thanks!
> Would either of you already have a guess for how long it makes
> sense to update kernels on it?
>
> I see that this is one of the more limited platforms with just 32MB
> of RAM (64MB in case of CX), and kernels only get more bloated over
> time, so I expect at some point you will be stuck with running old
> software.
The kernel overhead isn't actually that bad. I just built today's 2ff90100ace8
and booted it with a busybox-based initrd. free -m reports:
total used free shared buffers
58 12 46 0 0
Relatively speaking, still mostly unused ;-) The stock OS actually uses more!
With 32MiB, the situation is definitely worse, but still manageable. Should
that change in the future, dropping just the Classic/CM variants would be a
possible option, but that still seems far enough away.
> Wikipedia tells me that new models came out recently. Are you
> planning to add support for those as well?
Yes, someone from the community actually managed to boot Linux on a CX II-T,
and I'm hoping to get that upstreamed soon. Most of the hardware changes are
supported by drivers already and so this is mainly just another device tree.
Cheers,
Fabian
> Arnd
On Sun, Jan 10, 2021 at 7:12 PM Fabian Vogt <[email protected]> wrote:
> Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <[email protected]> wrote:
> > >
> > > Hi Arnd,
> > >
> > > On 9 Jan 2021, at 9:55 am, Arnd Bergmann <[email protected]> wrote:
> > >
> > > * nspire -- added in 2013, no notable changes after 2015
>
> Most of the platform is just the DT sources and some small drivers around it,
> so it's actually fairly low maintenance. So far the migration away from
> panel-simple in 2019
> (https://lore.kernel.org/linux-arm-kernel/[email protected])
> was the biggest required change so far.
Sure, there is no problem in keeping it around as long as it is used.
There were a couple of platforms that had not seen a lot of changes
in the past five years but that are still in active use, I just used it as
an indication that I should ask about the status. A lot of the other
platforms that list only ever had an incomplete port and were
abandoned before they were fully supported in upstream kernels.
> > Would either of you already have a guess for how long it makes
> > sense to update kernels on it?
> >
> > I see that this is one of the more limited platforms with just 32MB
> > of RAM (64MB in case of CX), and kernels only get more bloated over
> > time, so I expect at some point you will be stuck with running old
> > software.
>
> The kernel overhead isn't actually that bad. I just built today's 2ff90100ace8
> and booted it with a busybox-based initrd. free -m reports:
> total used free shared buffers
> 58 12 46 0 0
>
> Relatively speaking, still mostly unused ;-) The stock OS actually uses more!
> With 32MiB, the situation is definitely worse, but still manageable. Should
> that change in the future, dropping just the Classic/CM variants would be a
> possible option, but that still seems far enough away.
Ok, makes sense.
> > Wikipedia tells me that new models came out recently. Are you
> > planning to add support for those as well?
>
> Yes, someone from the community actually managed to boot Linux on a CX II-T,
> and I'm hoping to get that upstreamed soon. Most of the hardware changes are
> supported by drivers already and so this is mainly just another device tree.
Nice!
Arnd
On Sun, Jan 10, 2021 at 06:27:12PM +0100, Arnd Bergmann wrote:
> On Sun, Jan 10, 2021 at 5:48 PM Andrew Lunn <[email protected]> wrote:
> >
> > > 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.
Hi Arnd
Appended DT works fine for my device.
> It may help to ask for these at
> https://github.com/1000001101000/Debian_on_Buffalo/,
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
On Sun, Jan 10, 2021 at 7:16 PM Fabian Vogt <[email protected]> wrote:
> Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <[email protected]> wrote:
> > > * nspire -- added in 2013, no notable changes after 2015
>
> Most of the platform is just the DT sources and some small drivers around it,
> so it's actually fairly low maintenance. So far the migration away from
> panel-simple in 2019
> (https://lore.kernel.org/linux-arm-kernel/[email protected])
> was the biggest required change so far.
What we're seeing here is actually a port that is:
- Finished
- Has a complete set of working drivers
- Supported
- Just works
I.e. it doesn't see much patches because it is pretty much perfect.
We are so unused to this situation that it can be mistaken for
the device being abandoned.
I think it was Russell who first pointed out that this is actually
the case for a few machines.
> > Would either of you already have a guess for how long it makes
> > sense to update kernels on it?
> >
> > I see that this is one of the more limited platforms with just 32MB
> > of RAM (64MB in case of CX), and kernels only get more bloated over
> > time, so I expect at some point you will be stuck with running old
> > software.
>
> The kernel overhead isn't actually that bad. I just built today's 2ff90100ace8
> and booted it with a busybox-based initrd. free -m reports:
> total used free shared buffers
> 58 12 46 0 0
>
> Relatively speaking, still mostly unused ;-) The stock OS actually uses more!
> With 32MiB, the situation is definitely worse, but still manageable. Should
> that change in the future, dropping just the Classic/CM variants would be a
> possible option, but that still seems far enough away.
64 MB is perfectly fine to run Linux. OpenWrt-type distributions (also
OpenEmbedded/YOCTO) run just fine with that. 32 MB certainly works.
For example this is the Gemini D-Link DNS-313 which is my NAS
and works perfectly on 64MB:
root@DNS-313:~# free -m
total used free shared buff/cache available
Mem: 56136 21032 28612 0 6492 23812
Swap: 131128 1280 129848
Not even using the fallback swap.
I can add that at the time it is syncing a backup AND playing back
a 1080p movie over SMB. The trick is using ksmbd rather than
Samba. ksmbd is much less memory-intensive.
I like to use this device for NAS since it is good at I/O, stable,
maintained by myself and JustWorks(TM).
Yours,
Linus Walleij
Hi all,
> Hi Arnd!
>
> (Please let's have this cross-posted for more visibility. I only learned about this
> while reading Phoronix news)
>
> > I also looked at non-ARM platforms while preparing for my article. Some of
> > these look like they are no longer actively maintained or used, but I'm not
> > doing anything about those unless the maintainers would like me to:
> >
> > * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
> > is currently under review
>
> I don't think this has reached any agreement yet. Multiple people want it to stay.
None of the people that replied have any real use of the sun4m port,
they only wanted it to stay because they had some machines or such.
In other words - people will be sad if we sunset sun4m, but it will not
hurt anyone as there are no users left.
I will include the above summary when I post v2 of the patch to sunset
sun4m and sun4d. Then we will see what we conclude in the end.
Right now in am in demolition mode as I have a new house that requires a
total refactoring. So linux stuff is lower on the priority list so v2
will wait until I have time to do any necessary follow-up.
Sam
On Sun, Jan 10, 2021 at 10:33:56PM +0100, Linus Walleij wrote:
> On Sun, Jan 10, 2021 at 7:16 PM Fabian Vogt <[email protected]> wrote:
> > Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > > On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <[email protected]> wrote:
>
> > > > * nspire -- added in 2013, no notable changes after 2015
> >
> > Most of the platform is just the DT sources and some small drivers around it,
> > so it's actually fairly low maintenance. So far the migration away from
> > panel-simple in 2019
> > (https://lore.kernel.org/linux-arm-kernel/[email protected])
> > was the biggest required change so far.
>
> What we're seeing here is actually a port that is:
> - Finished
> - Has a complete set of working drivers
> - Supported
> - Just works
>
> I.e. it doesn't see much patches because it is pretty much perfect.
>
> We are so unused to this situation that it can be mistaken for
> the device being abandoned.
>
> I think it was Russell who first pointed out that this is actually
> the case for a few machines.
Yes indeed. I find it utterly rediculous that there is a perception
that you constantly need to be patching a bit of software for it to
not be seen as abandoned. If a piece of software works and does what
it needs to do, why does it need to be continually patched? It makes
no sense to me.
I have my xf86-video-armada which I use on the Dove Cubox and iMX6
platforms. It does what I need it to, and I haven't updated the
userspace on these platforms for a while. Therefore, I've no reason
to patch that code, and no one has sent me patches. Does that mean
it's abandoned? Absolutely not.
Some people are just weird and think that unless stuff is constantly
worked on, no one cares about it.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Hi Arnd,
On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <[email protected]> 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
Hello!
On 1/10/21 10:46 PM, Sam Ravnborg wrote:
>> I don't think this has reached any agreement yet. Multiple people want it to stay.
>
> None of the people that replied have any real use of the sun4m port,
> they only wanted it to stay because they had some machines or such.
> In other words - people will be sad if we sunset sun4m, but it will not
> hurt anyone as there are no users left.
>
> I will include the above summary when I post v2 of the patch to sunset
> sun4m and sun4d. Then we will see what we conclude in the end.
I'm not sure I understand the reasoning for doing this. The SPARC architecture
isn't going to see any new hardware developments in the future after Oracle
let go of most of the SPARC developers. So it's not that we need to make room
for new hardware.
And I also disagree with Arnd's stance that a port seems broken because it
doesn't see frequent or recent changes. As pointed out by Thomas Bogendoerfer
in this thread [1], missing updates don't necessarily mean that something
is broken but it can also just mean the hardware is fully supported and
working, so why fix something that isn't broken?
On the other hand, there are really serious bugs in the kernel that easily
allow crashing the whole machine (here on POWER [2] or here on SPARC [3])
that never get addressed.
We have a $10k IBM POWER server in Debian Ports which hosts a big-endian
PowerKVM build server instance and regularly hard-crashes because of the
bug in [2]. This bug has remained unfixed for almost a year now.
On top of that, some of the tree-wide conversions like [4] have completely
broken the Linux kernel on certain machines so that any larger ia64 servers
are stuck on the 4.14 kernel with no fix in sight. Before that, the kernel
worked perfectly fine on these machines.
I understand that cleaning up code and modernizing things is important, but
I think that the top priority should be to deliver something that is stable
and usable by the enduser.
But kernel development shouldn't be about scratching an itch which I sometimes
have the impression is the main driver behind some changes in the kernel.
I have personally invested a lot of time and effort in the past years to get
Debian into shape on exotic and older architectures and I feel all this effort
goes to waste when upstream projects just decide to kill of a certain platform
in the kernel or toolchain like it already happened with PowerPCSPE in GCC.
Adrian
> [1] https://lore.kernel.org/lkml/[email protected]/
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=206669
> [3] https://marc.info/?l=linux-sparc&m=160967865029609&w=2
> [4] https://marc.info/?l=linux-ia64&m=156144480821712&w=2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Arnd,
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> 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 -- [email protected]
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
Hello Arnd,
On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
It was quite fun to work on Cortex-M and cooperate with Energymicro and
ARM. But apart from the nice memorys there is I think little gain in
keeping efm32.
I understood your mail as offer to care for removing? If so, please
go on with efm32. If it helps you I can prepare patches to remove the
platform, too.
Best regards and thanks for you taking care,
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <[email protected]> wrote:
> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> 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.
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
Hi Daniel!
> On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <[email protected]> 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.
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 - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Arnd,
On Mon, Jan 11, 2021 at 9:59 AM Arnd Bergmann <[email protected]> wrote:
> On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <[email protected]> wrote:
> > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> 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.
>
> 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 -- [email protected]
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
Hi Adrian,
On Mon, Jan 11, 2021 at 10:16 AM John Paul Adrian Glaubitz
<[email protected]> wrote:
> > On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <[email protected]> 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.
>
> 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 -- [email protected]
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
Hi Geert!
On 1/11/21 10:20 AM, Geert Uytterhoeven wrote:
>> 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.
> 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].
Adrian
> {1] https://retromodsblog.wordpress.com/2020/01/28/a-look-at-the-vampire-v4-stand-alone-fpga-first-impressions/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian,
On Mon, 11 Jan 2021 at 18:17, John Paul Adrian Glaubitz
<[email protected]> wrote:
>
> Hi Daniel!
> > On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <[email protected]> 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.
>
> 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
On 11/1/21 7:36 pm, Geert Uytterhoeven wrote:
> Hi Adrian,
>
> On Mon, Jan 11, 2021 at 10:26 AM John Paul Adrian Glaubitz
> <[email protected]> wrote:
>> On 1/11/21 10:20 AM, Geert Uytterhoeven wrote:
>>>> 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...
>>> 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
From: Arnd Bergmann
> Sent: 09 January 2021 21:53
>
> On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau <[email protected]> wrote:
> >
> > 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 :-)).
>
> 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)
On Mon, Jan 11, 2021 at 09:59:23AM +0100, Arnd Bergmann wrote:
> On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <[email protected]> wrote:
> > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> 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.
>
> 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 ]
On Mon, Jan 11, 2021 at 2:40 AM Daniel Palmer <[email protected]> wrote:
>
> Hi Arnd,
>
> On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <[email protected]> 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.
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
Hi Arnd,
On Mon, Jan 11, 2021 at 10:16 AM Geert Uytterhoeven
<[email protected]> wrote:
> On Mon, Jan 11, 2021 at 9:59 AM Arnd Bergmann <[email protected]> wrote:
> > On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <[email protected]> wrote:
> > > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> 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.
> >
> > 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 -- [email protected]
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
On Mon, Jan 11, 2021 at 10:40 AM Thomas Bogendoerfer
<[email protected]> wrote:
>
> On Mon, Jan 11, 2021 at 09:59:23AM +0100, Arnd Bergmann wrote:
> > On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <[email protected]> wrote:
> > > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> 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.
> >
> > 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.
Ok, got it.
Arnd
On 08-01-21, 23:55, Arnd Bergmann wrote:
> * 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
Hi Adrian,
On Mon, Jan 11, 2021 at 10:26 AM John Paul Adrian Glaubitz
<[email protected]> wrote:
> On 1/11/21 10:20 AM, Geert Uytterhoeven wrote:
> >> 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.
> > 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 -- [email protected]
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
On Mon, Jan 11, 2021 at 11:28 AM Geert Uytterhoeven
<[email protected]> wrote:
> > > 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
On Mon, Jan 11, 2021 at 1:33 AM Russell King - ARM Linux admin
<[email protected]> wrote:
> On Sun, Jan 10, 2021 at 10:33:56PM +0100, Linus Walleij wrote:
> > On Sun, Jan 10, 2021 at 7:16 PM Fabian Vogt <[email protected]> wrote:
> > > Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > > (https://lore.kernel.org/linux-arm-kernel/[email protected])
> > > was the biggest required change so far.
> >
> > What we're seeing here is actually a port that is:
> > - Finished
> > - Has a complete set of working drivers
> > - Supported
> > - Just works
> >
> > I.e. it doesn't see much patches because it is pretty much perfect.
> >
> > We are so unused to this situation that it can be mistaken for
> > the device being abandoned.
> >
> > I think it was Russell who first pointed out that this is actually
> > the case for a few machines.
>
> Yes indeed. I find it utterly rediculous that there is a perception
> that you constantly need to be patching a bit of software for it to
> not be seen as abandoned. If a piece of software works and does what
> it needs to do, why does it need to be continually patched? It makes
> no sense to me.
I don't know where you got the impression that this is what I
want to do. I used this as a first approximation because it reduced
the number of platforms to look at from 71 to under 20, just by
looking at what patches went into the kernel. I could further get the
number down to the 14 platforms listed in this email by knowing
some of the users of platforms that did not see a lot of updates but
are well supported, like highbank or dove.
We have already confirmed axxia, digicolor, kona and nspire
as platforms that we want to keep for now, and a new volunteer
to maintain axxia, and I did not get the impression that any of
the maintainers were overly stressed out by being sent an
email inquiry five years after the last contact. I would prefer
an occasional Tested-by tag for the cleanup patches that did make
it in (yes, I counted those as activity), but I understand that
everyone is busy and these are low-maintenance platforms.
> I have my xf86-video-armada which I use on the Dove Cubox and iMX6
> platforms. It does what I need it to, and I haven't updated the
> userspace on these platforms for a while. Therefore, I've no reason
> to patch that code, and no one has sent me patches. Does that mean
> it's abandoned? Absolutely not.
I listed the dove platform in the first table specifically because the
plan back in 2014 was to completely remove the platform once that
hardware is working with the modern mach-mvebu platform, and
I hoped that the transition had finished by now.
Arnd
[ 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.
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
On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz
<[email protected]> wrote:
>
> I'm not sure I understand the reasoning for doing this. The SPARC architecture
> isn't going to see any new hardware developments in the future after Oracle
> let go of most of the SPARC developers. So it's not that we need to make room
> for new hardware.
>
My take is that there *would* be more interest in Sparc sun4m / Sun4d
from enthusiasts at the very least if it was possible to actually boot
the bloat hog that is Linux these days in a fully usable configuration
that probably means some modifications to SILO and Linux required.
The problem is as I understand it, SILO only sets up a 16Mb mapping
(either due to having to assume 4MB minimum dram stick size or due to
mapping limitations not sure, most of these machines have at least
16MB in slot one...these days though that wasn't the case for sun4c),
loads Linux into it and says good Luck. This isn't enough for a modern
kernel with any hardware support built in. So you might for instance
get a kernel to fit but only if you dropped all of networking support
etc... I'm guessing the fix for this would be to modify silo to map a
larger amount in a way that Linux expects so it can remap it as it
likes, or just have SILO map the full memory as Linux would. Anyway
that is THE main demotivation for these architectures.... otherwise
they have plenty of ram and performance to do basic router/server
tasks sans SSL.
This has been the status quo for since the last of the 2.6 series of
kernels which it was still possible to just barely squeeze a usable
kernel out of... If someone wanted to take a few hours and fix this
issue, and keep these architectures around I'd be happy to "buy them a
round of pizza", though I recognize that many people that work on this
already have nice jobs, and just don't have time.
Also Sparc would probably be a good project for someone to extend/test
Andi Keen's Linux LTO patch set so we could reduce the kernel binary
size that way also even if sun4 architectures are dropped, it would
still be useful for embedded sparc. Also there is a port of Temlib to
the Mister hardware now, 3 cores roughly equivalent to a mid 90s
machine, at least 128MB ram is possible ( more if a way to map the ARM
system memory also 1GB is available there, it would have higher
latency though).
It is perfectly viable to build Sparc v7 or v8 32bit binaries in a
chroot on a fast machine also, and I would recommend this if you wish
to retain sanity rather than attempting cross compiler voodoo, unless
that is your thing.
Anyways it could be that people that want this get around to fixing
SILO eventually and just sit on this last kernel version... *shrugs*
Chase
On Mon, Jan 11, 2021 at 3:48 PM Alexander Shiyan <[email protected]> wrote:
> On Fri, 8 Jan 2021 23:55:06 +0100 Arnd Bergmann <[email protected]> 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:
> >
> > * clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
> > changes since
> I still keep this architecture up and running (currently at 5.9.0).
Ok, great. Thanks for letting us know.
Arnd
On Mon, Jan 11, 2021 at 3:22 PM Mark Salter <[email protected]> wrote:
>
> 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.
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
Am 10.01.21 um 18:35 schrieb John Paul Adrian Glaubitz:
> Hi Arnd!
>
> (Please let's have this cross-posted for more visibility. I only learned about this
> while reading Phoronix news)
Same for me!
>> I also looked at non-ARM platforms while preparing for my article. Some of
>> these look like they are no longer actively maintained or used, but I'm not
>> doing anything about those unless the maintainers would like me to:
>>
>> * h8300: Steven Rostedt has repeatedly asked about it to be removed
>> or fixed in 2020 with no reply. This was killed before in 2013, added back
>> in 2015 but has been mostly stale again since 2016
>
> As far as I know, Yoshinori Sato is actively maintaining H8300 support, see:
>
>> https://osdn.net/projects/uclinux-h8/
>
>> * c6x: Added in 2011, this has seen very few updates since, but
>> Mark still Acks patches when they come. Like most other DSP platforms,
>> the model of running Linux on a DSP appears to have been obsoleted
>> by using Linux on ARM with on-chip DSP cores running bare-metal code.
>> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>> is currently under review
>
> I don't think this has reached any agreement yet. Multiple people want it to stay.
>
>> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
>> it's in my backlog but I will get to it. This is separate from PS3,
>> which is actively maintained and used; spufs will move to ps3
>> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
>
> I'm still using this. Please keep it.
I can also confirm that Pegasos2 users in the Amiga scene are running Linux
(Debian) on these machines.
>> * powerpc/amigaone: last updated in 2009
I still have 2 of the 3 types of the first generation AmigaOne machines (not
to be confused with the newer AmigaOne X1000 and X5000 machines based on
PASemi and P5020 CPUs) working here. A third machine needs a repair of the
G4 CPU module (replacement parts already available).
I have to admit however that I yet have to setup an environment that allows
me to regularly test new Linux kernel versions on these machines. Especially
because there are not many Linux users for these machines - which is likely
due to the fact that no distribution officially supports these machines out
of the box (the Pegasos2 platform had more luck here). Inputs on how to
automate tests would therefore be very welcome!
Given however that the Debian PowerPC port has a proper maintainer again
(kudos to Adrian!) and there is also another new PowerPC distro (Void Linux),
I would like to ask for a period of grace. After all this is just a hobby
project for me, so keeping up with the pace of the Linux development isn't
always that easy (and no, work on this did not stop in 2009, but shifted more
towards distro support since then).
>> * powerpc/maple: last updated in 2011
>> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
>> seen updates in many years (atari/amiga/mac and coldfire are very much
>> alive)
>
> Dito. I have both sun3 and hp300 machines.
>
>> * mips/jazz: last updated in 2007
>> * mips/cobalt: last updated in 2010
>>
>> There might be some value in dropping old CPU support on architectures
>> and platforms that are almost exclusively used with more modern CPUs.
>> If there are only few users, those can still keep using v5.10 or v5.4 stable
>> kernels for a few more years. Again, I'm not doing anything about them,
>> except mention them since I did the research.
>> These are the oldest one by architecture, and they may have reached
>> their best-served-by-date:
>>
>> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>> indications that 486 have no users either on recent kernels.
>> There is still the Vortex86 family of SoCs, and the oldest of those were
>> 486SX-class, but all the modern ones are 586-class.
>> * Alpha 2106x: First generation that lacks some of the later features.
>> Since all Alphas are ancient by now, it's hard to tell whether these have
>> any fewer users.
>
> I don't see the point in crippling Alpha support. Does this achieve anything?
>
>> * IA64 Merced: first generation Itanium (2001) was quickly replaced by
>> Itanium II in 2002.
>> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
>> 64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
>> supports these in DECstation and Toshiba Txx9, but it appears that most
>> of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
>> later are rather different and widely used.
>> * PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
>> are apparently all still used.
>> * SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
>> support in the past, I don't think there were any objections, but
>> nobody submitted a patch.
>
> Isn't SH-2 basically J-2? I'm not sure what we would gain here.
>
>> * 68000/68328 (Dragonball): these are less capable than the
>> 68020+ or the Coldfire MCF5xxx line and similar to the 68360
>> that was removed in 2016.
>
> Adrian
>
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 <[email protected]> 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Marc Gonzalez <[email protected]> writes:
> [ 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.
>>
>
> 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.
I have tango3 and tango4 boards. Can't say I'm using them for anything,
though. With the entire platform dead at the vendor level, removal
seems like a reasonable choice.
--
M?ns Rullg?rd
On 1/10/21 3:46 PM, Sam Ravnborg wrote:
> Hi all,
>> Hi Arnd!
>>
>> (Please let's have this cross-posted for more visibility. I only learned about this
>> while reading Phoronix news)
>>
>>> I also looked at non-ARM platforms while preparing for my article. Some of
>>> these look like they are no longer actively maintained or used, but I'm not
>>> doing anything about those unless the maintainers would like me to:
>>>
>
>>> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>>> is currently under review
>>
>> I don't think this has reached any agreement yet. Multiple people want it to stay.
>
> None of the people that replied have any real use of the sun4m port,
> they only wanted it to stay because they had some machines or such.
> In other words - people will be sad if we sunset sun4m, but it will not
> hurt anyone as there are no users left.
>
> I will include the above summary when I post v2 of the patch to sunset
> sun4m and sun4d. Then we will see what we conclude in the end.
I used to regression test it in my cross builds but I switched my
toolchains/userspace from uClibc to musl-libc a couple years back, and musl
never added sparc support.
Rob
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 <[email protected]> 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
On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar <[email protected]> wrote:
> On 08-01-21, 23:55, Arnd Bergmann wrote:
> > * 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
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
> <[email protected]> wrote:
> > 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.
>
> 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?
Yes, because it is the only fully featured platform I have.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> -----Original Message-----
> From: Arnd Bergmann [mailto:[email protected]]
> Sent: Saturday, January 9, 2021 11:55 AM
> To: Linux ARM <[email protected]>; Linux Kernel Mailing
> List <[email protected]>
> Cc: Krzysztof Adamski <[email protected]>; Oleksij Rempel
> <[email protected]>; Baruch Siach <[email protected]>; Russell King -
> ARM Linux <[email protected]>; Daniel Tang <[email protected]>; Uwe
> Kleine-König <[email protected]>; Jamie Iles
> <[email protected]>; Song Bao Hua (Barry Song) <[email protected]>;
> Viresh Kumar <[email protected]>; Linus Walleij
> <[email protected]>; Jonas Jensen <[email protected]>; Marc
> Gonzalez <[email protected]>; Hartley Sweeten
> <[email protected]>; Lubomir Rintel <[email protected]>; Neil
> Armstrong <[email protected]>; Shawn Guo <[email protected]>; Alex
> Elder <[email protected]>; Alexander Shiyan <[email protected]>; Koen Vandeputte
> <[email protected]>; Hans Ulli Kroll <[email protected]>;
> Vladimir Zapolskiy <[email protected]>; xuwei (O) <[email protected]>; Steven
> Rostedt <[email protected]>; Yoshinori Sato <[email protected]>;
> Mark Salter <[email protected]>; Michael Ellerman <[email protected]>; Geert
> Uytterhoeven <[email protected]>; Thomas Bogendoerfer
> <[email protected]>
> 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
>
Thanks
Barry
>On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar <[email protected]> wrote:
>> On 08-01-21, 23:55, Arnd Bergmann wrote:
>> > * 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
On Mon, Jan 11, 2021 at 10:15 PM Mattias Wallin <[email protected]> wrote:
> >On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar <[email protected]> wrote:
> >> On 08-01-21, 23:55, Arnd Bergmann wrote:
> >> > * 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.
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
On Mon, Jan 11, 2021 at 01:32:57PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 11, 2021 at 1:33 AM Russell King - ARM Linux admin
> <[email protected]> wrote:
> > On Sun, Jan 10, 2021 at 10:33:56PM +0100, Linus Walleij wrote:
> > > On Sun, Jan 10, 2021 at 7:16 PM Fabian Vogt <[email protected]> wrote:
> > > > Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > > > (https://lore.kernel.org/linux-arm-kernel/[email protected])
> > > > was the biggest required change so far.
> > >
> > > What we're seeing here is actually a port that is:
> > > - Finished
> > > - Has a complete set of working drivers
> > > - Supported
> > > - Just works
> > >
> > > I.e. it doesn't see much patches because it is pretty much perfect.
> > >
> > > We are so unused to this situation that it can be mistaken for
> > > the device being abandoned.
> > >
> > > I think it was Russell who first pointed out that this is actually
> > > the case for a few machines.
> >
> > Yes indeed. I find it utterly rediculous that there is a perception
> > that you constantly need to be patching a bit of software for it to
> > not be seen as abandoned. If a piece of software works and does what
> > it needs to do, why does it need to be continually patched? It makes
> > no sense to me.
>
> I don't know where you got the impression that this is what I
> want to do. I used this as a first approximation because it reduced
> the number of platforms to look at from 71 to under 20, just by
> looking at what patches went into the kernel. I could further get the
> number down to the 14 platforms listed in this email by knowing
> some of the users of platforms that did not see a lot of updates but
> are well supported, like highbank or dove.
>
> We have already confirmed axxia, digicolor, kona and nspire
> as platforms that we want to keep for now, and a new volunteer
> to maintain axxia, and I did not get the impression that any of
> the maintainers were overly stressed out by being sent an
> email inquiry five years after the last contact. I would prefer
> an occasional Tested-by tag for the cleanup patches that did make
> it in (yes, I counted those as activity), but I understand that
> everyone is busy and these are low-maintenance platforms.
>
> > I have my xf86-video-armada which I use on the Dove Cubox and iMX6
> > platforms. It does what I need it to, and I haven't updated the
> > userspace on these platforms for a while. Therefore, I've no reason
> > to patch that code, and no one has sent me patches. Does that mean
> > it's abandoned? Absolutely not.
>
> I listed the dove platform in the first table specifically because the
> plan back in 2014 was to completely remove the platform once that
> hardware is working with the modern mach-mvebu platform, and
> I hoped that the transition had finished by now.
I was talking in general terms about the whole idea that any piece of
software needs to be constantly changed in order not to be seen as
abandoned, and not specific to the kernel either.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Fri, 8 Jan 2021 23:55:06 +0100
Arnd Bergmann <[email protected]> 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 <[email protected]>
On Mon, Jan 11, 2021 at 8:58 PM Thomas Petazzoni
<[email protected]> wrote:
> > On Fri, 8 Jan 2021 23:55:06 +0100 Arnd Bergmann <[email protected]> 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.
> > * 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.
> > * 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
On Mon, Jan 11, 2021 at 6:29 PM Måns Rullgård <[email protected]> wrote:
> Marc Gonzalez <[email protected]> writes:
> >
> > Waiting for his take on the matter.
> >
> > I can point out some device-specific drivers that would become
> > useless if tango support were dropped.
>
> I have tango3 and tango4 boards. Can't say I'm using them for anything,
> though. With the entire platform dead at the vendor level, removal
> seems like a reasonable choice.
Ok, thanks for confirming.
Arnd
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.
>
However, I would love to see it actually maintained as upstream is still
broken for most of the platforms, see:
https://lore.kernel.org/linux-arm-kernel/[email protected]/
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 1/11/21 8:55 AM, chase rayfield wrote:
> On Mon, Jan 11, 2021 at 3:09 AM John Paul Adrian Glaubitz
> <[email protected]> wrote:
>
>>
>> I'm not sure I understand the reasoning for doing this. The SPARC architecture
>> isn't going to see any new hardware developments in the future after Oracle
>> let go of most of the SPARC developers. So it's not that we need to make room
>> for new hardware.
>>
> My take is that there *would* be more interest in Sparc sun4m / Sun4d
> from enthusiasts at the very least if it was possible to actually boot
> the bloat hog that is Linux these days in a fully usable configuration
> that probably means some modifications to SILO and Linux required.
You can trim current linux down a bit, it's just non-obvious how. Unfortunately
there's an "expert" menu and CONFIG_EMBEDDED and if you touch anything there's
suddenly a hundred extra options in your config with no explanation of what they do.
At least 50% of what you want is probably disabling the printk strings that
aren't visible at your default verbosity level, but alas you must open pandora's
box to access those options...
> The problem is as I understand it, SILO only sets up a 16Mb mapping
> (either due to having to assume 4MB minimum dram stick size or due to
> mapping limitations not sure, most of these machines have at least
> 16MB in slot one...these days though that wasn't the case for sun4c),
> loads Linux into it and says good Luck. This isn't enough for a modern
> kernel with any hardware support built in. So you might for instance
> get a kernel to fit but only if you dropped all of networking support
> etc... I'm guessing the fix for this would be to modify silo to map a
> larger amount in a way that Linux expects so it can remap it as it
> likes, or just have SILO map the full memory as Linux would. Anyway
> that is THE main demotivation for these architectures.... otherwise
> they have plenty of ram and performance to do basic router/server
> tasks sans SSL.
A lot of people with hardware like this haven't stopped using it, they've just
stopped fighting with kernel upgrades. (Common issue in the embedded world. Not
really a fun thing for security, but )
> This has been the status quo for since the last of the 2.6 series of
> kernels which it was still possible to just barely squeeze a usable
> kernel out of... If someone wanted to take a few hours and fix this
> issue, and keep these architectures around I'd be happy to "buy them a
> round of pizza", though I recognize that many people that work on this
> already have nice jobs, and just don't have time.
My https://github.com/landley/toybox/blob/master/scripts/mkroot.sh ~250 line
bash script generates the simplest kernel configs for a bunch of platforms to
boot qemu to a shell prompt, but you then have to open the "expert" menu and
_disable_ stuff in order to get the size down from there.
> Also Sparc would probably be a good project for someone to extend/test
Sparc has a runtime relocation I've never understood but did manage to break
once, resulting in a long thread to fix:
http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html
Between that and the weird save half the stack register thing with function
calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk
Rich into adding support for it to musl.
> Andi Keen's Linux LTO patch set so we could reduce the kernel binary
> size that way also even if sun4 architectures are dropped, it would
> still be useful for embedded sparc. Also there is a port of Temlib to
> the Mister hardware now, 3 cores roughly equivalent to a mid 90s
> machine, at least 128MB ram is possible ( more if a way to map the ARM
> system memory also 1GB is available there, it would have higher
> latency though).
>
> It is perfectly viable to build Sparc v7 or v8 32bit binaries in a
> chroot on a fast machine also, and I would recommend this if you wish
> to retain sanity rather than attempting cross compiler voodoo, unless
> that is your thing.
It is, sadly, my thing. The above 250 line bash script builds:
aarch64 armv7l i686 mips powerpc s390x x86_64
armv4l armv7m m68k mips64 powerpc64 sh2eb
armv5l i486 microblaze mipsel powerpc64le sh4
That's toybox booting to a shell prompt and a linux kernel configured for qemu
for each target. Adding new targets looks something like:
elif [ "$TARGET" == m68k ]; then
QEMU="m68k -M q800" KARCH=m68k KARGS=ttyS0 VMLINUX=vmlinux
KCONF=MMU,M68040,M68KFPU_EMU,MAC,SCSI_MAC_ESP,MACINTOSH_DRIVERS,ADB,ADB_MACII,NET_CORE,MACSONIC,SERIAL_PMACZILOG,SERIAL_PMACZILOG_TTYS,SERIAL_PMACZILOG_CONSOLE
elif [ "$TARGET" = s390x ]; then
QEMU="s390x" KARCH=s390 VMLINUX=arch/s390/boot/bzImage
KCONF=MARCH_Z900,PACK_STACK,NET_CORE,VIRTIO_NET,VIRTIO_BLK,SCLP_TTY,SCLP_CONSOLE,SCLP_VT220_TTY,SCLP_VT220_CONSOLE,S390_GUEST
(Well, modulo thunderbird being unable to an indent a line that goes off the
right edge of the screen. The mozilla foundation somehow managed to spend half a
billion dollars in 2019 but it wasn't on thunderbird, I can tell you that.)
Anyway, I wrote a couple FAQ entries trying to explain the worst of it:
https://landley.net/toybox/faq.html#cross
https://landley.net/toybox/faq.html#mkroot
> Anyways it could be that people that want this get around to fixing
> SILO eventually and just sit on this last kernel version... *shrugs*
They're never sitting on the _last_ kernel version. They're generally way back
from there. Been true forever off of x86 (and now arm):
https://lore.kernel.org/lkml/[email protected]/T/
> Chase
Rob
> Sparc has a runtime relocation I've never understood but did manage to break
> once, resulting in a long thread to fix:
>
> http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html
>
> Between that and the weird save half the stack register thing with function
> calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk
> Rich into adding support for it to musl.
>
Register windowing, with parts of each window overlapping for function
arguments etc... you can kind of think of it as a ring buffer of
overlapping register files that's an oversimplification but it was
originally intended to accelerate and improve register file usage.
MIPS and the rest of the industry abandoned this for improved compile
time allocation. I think you might be more likely on MIPS to incur
more interrupt latency though since you have to spill to memory (at
least on MIPS contemporary to Sparc V8) instead of just switching
register windows mileage varies greatly.... From what I remember
overflowing the register file is implemented with hardware traps that
spill to memory etc... since you don't know that information at
compile time. on Sparc so yeah it's quite involved to understand and I
certainly don't grasp it fully. So on MIPS you spill the register file
to memory, on Sparc you spill register windows to memory... if you
have exceeded the supported call depth (which is rather expensive
since all the register windows go at once). Note spilling a single
variable within a register window is a separate issue.
Amazing, a link that actually works and is informative:
https://blogs.oracle.com/d/flush-register-windows
Chase
On 11/01/2021 22:50, Arnd Bergmann wrote:
> On Mon, Jan 11, 2021 at 6:29 PM Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> Waiting for his take on the matter.
>>>
>>> I can point out some device-specific drivers that would become
>>> useless if tango support were dropped.
>>
>> I have tango3 and tango4 boards. Can't say I'm using them for anything,
>> though. With the entire platform dead at the vendor level, removal
>> seems like a reasonable choice.
>
> Ok, thanks for confirming.
It's not just the platform that's dead.
The whole company has been liquidated :(
(The Z-Wave stuff lives on inside Silicon Labs)
https://www.prnewswire.com/news-releases/sigma-designs-announces-plan-for-final-distribution-of-0-285-per-share-to-shareholders-in-connection-with-its-voluntary-plan-of-liquidation-and-dissolution-301099186.html
The following drivers are tango-specific, and it might make sense
to remove them along with the platform?
drivers/watchdog/tangox_wdt.c
drivers/media/rc/tango-ir.c
drivers/media/rc/keymaps/rc-tango.c
drivers/irqchip/irq-tango.c
drivers/clk/clk-tango4.c
drivers/pci/controller/pcie-tango.c
drivers/thermal/tango_thermal.c
drivers/mtd/nand/raw/tango_nand.c
drivers/cpufreq/tango-cpufreq.c
drivers/clocksource/timer-tango-xtal.c
Mans, do you agree?
Regards.
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.
Hello!
On 1/11/21 3:55 PM, chase rayfield wrote:
> My take is that there *would* be more interest in Sparc sun4m / Sun4d
> from enthusiasts at the very least if it was possible to actually boot
> the bloat hog that is Linux these days in a fully usable configuration
> that probably means some modifications to SILO and Linux required.
The Linux kernel is configurable. If you want a small kernel, then just
configure one. No one expects you to boot a fully-fledged distribution
kernel on these machines.
> The problem is as I understand it, SILO only sets up a 16Mb mapping
> (either due to having to assume 4MB minimum dram stick size or due to
> mapping limitations not sure, most of these machines have at least
> 16MB in slot one...these days though that wasn't the case for sun4c),
> loads Linux into it and says good Luck. This isn't enough for a modern
> kernel with any hardware support built in. So you might for instance
> get a kernel to fit but only if you dropped all of networking support
> etc...
That makes no sense. It worked in the past, why shouldn't it work nowadays?
As I said, you disable everything you don't need. I'm booting my SH-7785LCR
SuperH board with a kernel that is less than 4 MB in size and which includes
everything I need.
> I'm guessing the fix for this would be to modify silo to map a
> larger amount in a way that Linux expects so it can remap it as it
> likes, or just have SILO map the full memory as Linux would. Anyway
> that is THE main demotivation for these architectures.... otherwise
> they have plenty of ram and performance to do basic router/server
> tasks sans SSL.
Or just configure a smaller kernel.
> This has been the status quo for since the last of the 2.6 series of
> kernels which it was still possible to just barely squeeze a usable
> kernel out of... If someone wanted to take a few hours and fix this
> issue, and keep these architectures around I'd be happy to "buy them a
> round of pizza", though I recognize that many people that work on this
> already have nice jobs, and just don't have time.
I haven't gotten around to setup my SPARCstation 5 yet, but I will certainly
going to do that later this year to give it a try.
> Also Sparc would probably be a good project for someone to extend/test
> Andi Keen's Linux LTO patch set so we could reduce the kernel binary
> size that way also even if sun4 architectures are dropped, it would
> still be useful for embedded sparc. Also there is a port of Temlib to
> the Mister hardware now, 3 cores roughly equivalent to a mid 90s
> machine, at least 128MB ram is possible ( more if a way to map the ARM
> system memory also 1GB is available there, it would have higher
> latency though).
>
> It is perfectly viable to build Sparc v7 or v8 32bit binaries in a
> chroot on a fast machine also, and I would recommend this if you wish
> to retain sanity rather than attempting cross compiler voodoo, unless
> that is your thing.
We build anything SPARC on a SPARC T5 that we have for Debian, no need
for cross-compilation and that machine is actually quite fast.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hello Gerhard!
On 1/11/21 4:04 PM, Gerhard Pircher wrote:
>>> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
>>> it's in my backlog but I will get to it. This is separate from PS3,
>>> which is actively maintained and used; spufs will move to ps3
>>> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
>>
>> I'm still using this. Please keep it.
>
> I can also confirm that Pegasos2 users in the Amiga scene are running Linux
> (Debian) on these machines.
Thanks for raising your voice. It's nice and reliable hardware after all and
still fast enough to run a recent version of Debian unstable with a lean
desktop such as XFCE or MATE.
>>> * powerpc/amigaone: last updated in 2009
>
> I still have 2 of the 3 types of the first generation AmigaOne machines (not
> to be confused with the newer AmigaOne X1000 and X5000 machines based on
> PASemi and P5020 CPUs) working here. A third machine needs a repair of the
> G4 CPU module (replacement parts already available).
Cool.
> I have to admit however that I yet have to setup an environment that allows
> me to regularly test new Linux kernel versions on these machines. Especially
> because there are not many Linux users for these machines - which is likely
> due to the fact that no distribution officially supports these machines out
> of the box (the Pegasos2 platform had more luck here). Inputs on how to
> automate tests would therefore be very welcome!
Are you on the debian-powerpc mailing list? If not, please subscribe and post
your issues there:
> https://lists.debian.org/debian-powerpc/
> Given however that the Debian PowerPC port has a proper maintainer again
> (kudos to Adrian!) and there is also another new PowerPC distro (Void Linux),
> I would like to ask for a period of grace. After all this is just a hobby
> project for me, so keeping up with the pace of the Linux development isn't
> always that easy (and no, work on this did not stop in 2009, but shifted more
> towards distro support since then).
Yeah, I have the same impression that's the strong commercial interest pushes
hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
they're motivated by corporate decisions.
There has to be a healthy balance between hobbyist and commercial use. I understand
that from a commercial point of view, it doesn't make much sense to run Linux
on a 30-year-old computer. But it's a hobbyist project for many people and hacking
Linux stuff for these old machines has a very entertaining and educational factor.
Plus, as Thomas Bogendoerfer already mentioned in this thread, most of the old ports
run just fine. I have an Alpha XP-1000 building Debian packages for the Debian
Alpha port and it runs 24/7 without a hick and is regularly kept up-to-date with
dist-upgrades.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Arnd,
> * 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.
I actively use the i486DX systems for regression testing and they have
proven useful for detecting bugs in both the kernel and GCC (see
below).
I am also about to use them as testing systems for kernel programming
students. I would hate to lose this platform as a student learning
opportunity.
Here are just some of the patches that I have worked on myself:
Kernel patches i486 testing uncovered:
x86/boot: Fix another __read_cr4() case on 486
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=192d1dccbfc5b901b66527df9df80304693cf06e
x86/CPU: Change query logic so CPUID is enabled before testing
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2893cc8ff892fa74972d8dc0e1d0dc65116daaa3
GCC patches i486 contributed to:
ibgcc calls __get_cpuid with 0 level breaks on early 486
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a6c78ea30381cc28ea0b2cf8f0bd584a91dda948
ICE in gen_lowpart_general, at rtlhooks.c:63
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=980c8afc0961da4b4567a5abe85b6048d501a1ad
So, these systems are _quietly_ being used, and helping to contribute,
it's just not glamorous, eye-catching work.
- Matthew Whitehead
On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
<[email protected]> wrote:
> Yeah, I have the same impression that's the strong commercial interest pushes
> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
> they're motivated by corporate decisions.
>
> There has to be a healthy balance between hobbyist and commercial use. I understand
> that from a commercial point of view, it doesn't make much sense to run Linux
> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
> Linux stuff for these old machines has a very entertaining and educational factor.
This is actually one of the most interesting things written in this discussion.
I have both revamped and deleted subarchitectures in the ARM tree. We
never deleted anyone's pet project *unless* they were clearly unwilling to
work on it (such as simply testning new patches) and agreed that it will
not go on.
At multiple occasions I actually found it easier to fix stuff than
delete it, both because it is a nicer thing to do and because it
simply creates less social problems, often to the point that the time
(man hours) spent trying to solve the resulting social problems from
deleting a platform would be longer than the time spent actually acquiring
the physical platform and fixing it.
Corporate entities can be a bit deletionist (using Wikipedia terminology)
and as in this thread there is always a strong inclusionist stance pushing
back to that.
The explanation is in my mind very simply that running Linux
on a 35-yo or so Amiga, Atari or Apollo Workstation is pretty impressive and
fun. And I think that fits Mr. Torvalds own sociological-or-something
explanation in the autobiographical "Just for fun" as to why to write it
in the first place. And we are very protective of that quality of the
kernel. (At least I am.)
That said there are a three things that people should really be doing if they
want to keep their pet archs/subarchs around as good community
members, and they are in essence to:
1. Test and review/ack patches that others make
2. Migrate existing drivers to newly appeared and
appropriate subsystems (I think there are some hacky heartbeat LED
drivers down in arch/* for example) there is also the feature matrix
core maintainers like and which appears if you type
Documentation/features/list-arch.sh <archname>
would be nice if you work on them if you can support them!
Or at least take a look.
3. Migrate old systems to use the
contemporary hardware descriptions (such as device tree or ACPI)
because it makes things so much easier to maintain. Some
upfront work, but a great win for everyone. Especially for
subsystem maintainers.
And if your arch uses highmem then please get rid of highmem. I'm
trying to do this a bit right now for ARM let's see how it goes.
I understand that for some maintainers time is a factor and this list
feels stressful. I'd say relax, but it'd be nice if you have a TODO that
you cross items off of.
Just my €0.01
Linus Walleij
On Tue, 12 Jan 2021, John Paul Adrian Glaubitz wrote:
>
> There has to be a healthy balance between hobbyist and commercial use.
>
Yes, both of those, and everything in-between, including for-profit
businesses that serve mostly hobbyists. Also start-up companies that may
never be commercially viable (which is most of them).
And don't forget government and non-government organisations,
not-for-profit organisations, charities, etc.
> I understand that from a commercial point of view, it doesn't make much
> sense to run Linux on a 30-year-old computer.
It ain't necessarily so. I would be surprised if there are no Linux VMs
running on old corporate mainframes right now. But the age of the hardware
is largely irrelevant.
If you're a museum interested in cultural artifacts from decades past, or
if you're a business doing data recovery, you're going to need to operate
those platforms.
Once removed from mainline Linux, a port becomes basically frozen, and may
not be compatible with future emulators, which are a moving target. I say
that because last year I fixed bugs in Linux/m68k that made it incomatible
with recent QEMU releases (it was only compatible with old QEMU releases).
On 1/12/21 4:46 PM, Linus Walleij wrote:
> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> <[email protected]> wrote:
>
>> Yeah, I have the same impression that's the strong commercial interest pushes
>> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
>> they're motivated by corporate decisions.
>>
>> There has to be a healthy balance between hobbyist and commercial use. I understand
>> that from a commercial point of view, it doesn't make much sense to run Linux
>> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
>> Linux stuff for these old machines has a very entertaining and educational factor.
>
> This is actually one of the most interesting things written in this discussion.
>
> I have both revamped and deleted subarchitectures in the ARM tree. We
> never deleted anyone's pet project *unless* they were clearly unwilling to
> work on it (such as simply testning new patches) and agreed that it will
> not go on.
Another fun aspect of old hardware is it serves as prior art for patents. The
j-core hardware implementation schedule has in part been driven by specific
patents expiring, as in "we can't do $FEATURE until $DATE".
It's much easier to nip a patent suit in the bud if you can go "here is
functionally equivalent hardware from the past, dates the specifications were
published, and the specific patents on the technology which have now expired".
We're a little overscheduled and not always _prompt_ about it, but for example
the reason we couldn't do full 6-wire sd 1.0 in the first j-core SOC release
(and had to implement a painfully slow mmc bus instead) is the patents hadn't
expired yet.
> That said there are a three things that people should really be doing if they
> want to keep their pet archs/subarchs around as good community
> members, and they are in essence to:
>
> 1. Test and review/ack patches that others make
I'm trying. :)
> 2. Migrate existing drivers to newly appeared and
> appropriate subsystems (I think there are some hacky heartbeat LED
> drivers down in arch/* for example) there is also the feature matrix
> core maintainers like and which appears if you type
> Documentation/features/list-arch.sh <archname>
> would be nice if you work on them if you can support them!
> Or at least take a look.
For 3 years in the 1990's SuperH was the best-selling processor in the world,
and that's left the architecture with a bunch of legacy boards that aren't
easily available to us. I regression test a current kernel build under qemu
every month or two, and have portable USB-powered boards for the j-core stuff.
When I did an sh4 porting contract in 2018 I got that board updated to a
current-ish kernel (3 versions back from then-current it hit some intermittent
nor flash filesystem corruption that only occurred intermittently under
sustained load; had to ship so I backed off one version and never tracked it
down). But these days I'm not always on the same continent as my two actual sh4
hardware boards, have never gotten my physical sh2 board to boot, and $DAYJOB is
all j-core stuff not sh4.
Testing that a basic superh system still builds and boots under qemu and j-core
I can commit to doing regularly. Testing specific hardware devices on boards I
don't regularly use is a lot harder.
> 3. Migrate old systems to use the
> contemporary hardware descriptions (such as device tree or ACPI)
> because it makes things so much easier to maintain. Some
> upfront work, but a great win for everyone. Especially for
> subsystem maintainers.
We did that one for our SOC. We haven't ported a lot of legacy boards because we
can't easily test most of them.
> And if your arch uses highmem then please get rid of highmem. I'm
> trying to do this a bit right now for ARM let's see how it goes.
I don't believe it does? (We haven't got any configs using it, anyway...)
> I understand that for some maintainers time is a factor and this list
> feels stressful. I'd say relax, but it'd be nice if you have a TODO that
> you cross items off of.
My todo list runneth over. One of our perpetual todo list items is "collate todo
lists"...
> Just my €0.01
> Linus Walleij
Rob
Hi Linus,
On Wed, Jan 13, 2021 at 4:20 AM Linus Walleij <[email protected]> wrote:
> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> <[email protected]> wrote:
> That said there are a three things that people should really be doing if they
> want to keep their pet archs/subarchs around as good community
> members, and they are in essence to:
> 2. Migrate existing drivers to newly appeared and
> appropriate subsystems (I think there are some hacky heartbeat LED
> drivers down in arch/* for example) there is also the feature matrix
> core maintainers like and which appears if you type
> Documentation/features/list-arch.sh <archname>
> would be nice if you work on them if you can support them!
> Or at least take a look.
The choir is listening ;-)
For Amiga, that would require writing a real GPIO driver (modifying
gpio-mmio?) for the CIAs, and converting its users (amiflop, amijoy,
amimouse, parport_amiga, amiserial, and dmasound_paula) from direct CIA
register access to GPIO access (mctrl_gpio for amiserial)).
Note that the heartbeat LED is shared by heartbeat and audio.
An interim solution might be to just write a simple gpio driver for the
single CIA pin driving the heartbeat LED, allowing the user to set up
ledtrig-heartbeat.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
Hi Rob,
On Wed, Jan 13, 2021 at 8:58 AM Rob Landley <[email protected]> wrote:
> On 1/12/21 4:46 PM, Linus Walleij wrote:
> > On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> > <[email protected]> wrote:
> >> Yeah, I have the same impression that's the strong commercial interest pushes
> >> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
> >> they're motivated by corporate decisions.
> >>
> >> There has to be a healthy balance between hobbyist and commercial use. I understand
> >> that from a commercial point of view, it doesn't make much sense to run Linux
> >> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
> >> Linux stuff for these old machines has a very entertaining and educational factor.
> >
> > This is actually one of the most interesting things written in this discussion.
> >
> > I have both revamped and deleted subarchitectures in the ARM tree. We
> > never deleted anyone's pet project *unless* they were clearly unwilling to
> > work on it (such as simply testning new patches) and agreed that it will
> > not go on.
>
> Another fun aspect of old hardware is it serves as prior art for patents. The
> j-core hardware implementation schedule has in part been driven by specific
> patents expiring, as in "we can't do $FEATURE until $DATE".
Indeed, so that's why the release of j4 is postponed to 2016...
/me runs date (again).
> When I did an sh4 porting contract in 2018 I got that board updated to a
> current-ish kernel (3 versions back from then-current it hit some intermittent
> nor flash filesystem corruption that only occurred intermittently under
> sustained load; had to ship so I backed off one version and never tracked it
> down). But these days I'm not always on the same continent as my two actual sh4
> hardware boards, have never gotten my physical sh2 board to boot, and $DAYJOB is
> all j-core stuff not sh4.
Which is not upstream, investing in the future?
> Testing that a basic superh system still builds and boots under qemu and j-core
> I can commit to doing regularly. Testing specific hardware devices on boards I
> don't regularly use is a lot harder.
I have the sh7751-based landisk in my board farm, so it's receiving
regular boot testing. That's one of the simpler SH-based platforms,
though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Mon, Jan 11, 2021 at 11:55 AM David Laight <[email protected]> wrote:
> From: Arnd Bergmann
> > Sent: 09 January 2021 21:53
> >
> > On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau <[email protected]> wrote:
> > >
> > > 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 :-)).
> >
> > 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
On Sat, Jan 9, 2021 at 12:58 AM Arnd Bergmann <[email protected]> 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
On Tue, Jan 12, 2021 at 11:46 PM Linus Walleij <[email protected]> wrote:
>
> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> <[email protected]> wrote:
>
> > Yeah, I have the same impression that's the strong commercial interest pushes
> > hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
> > they're motivated by corporate decisions.
> >
> > There has to be a healthy balance between hobbyist and commercial use. I understand
> > that from a commercial point of view, it doesn't make much sense to run Linux
> > on a 30-year-old computer. But it's a hobbyist project for many people and hacking
> > Linux stuff for these old machines has a very entertaining and educational factor.
>
> This is actually one of the most interesting things written in this discussion.
>
> I have both revamped and deleted subarchitectures in the ARM tree. We
> never deleted anyone's pet project *unless* they were clearly unwilling to
> work on it (such as simply testning new patches) and agreed that it will
> not go on.
>
> At multiple occasions I actually found it easier to fix stuff than
> delete it, both because it is a nicer thing to do and because it
> simply creates less social problems, often to the point that the time
> (man hours) spent trying to solve the resulting social problems from
> deleting a platform would be longer than the time spent actually acquiring
> the physical platform and fixing it.
>
> Corporate entities can be a bit deletionist (using Wikipedia terminology)
> and as in this thread there is always a strong inclusionist stance pushing
> back to that.
It's usually one of two things that happened before a platform gets
deleted for good:
* The platform port was (almost) exclusively done by one company
with a commercial interest in it, and the company shifts its priorities
for some reason (acquisition, bankruptcy, product cancellation,
accidentally laying off all competent developers, ...) that causes it to
stop working on it. Sometimes the previously paid maintainers
keep up their upstream position, but without someone pushing the
last missing bits into an official release, users are stuck on an old
BSP kernel.
* A platform port is done in the open and actually works for upstream
users, but over time the last active maintainers move on in their
lives. Complex platforms inevitably break when a treewide change
goes wrong, so we rely on users that are able to bisect and report
bugs when they happen. After a platform has been broken for
too long, even competent users may decide to just give up and
stay on their last working kernel. Some of these platforms eventually
recover when a new maintainer steps up or someone discovers they
depend on newer kernels for products, but after a few years it's
usually beyond repair.
Arnd
On Wed, Jan 13, 2021 at 11:31 AM Andy Shevchenko
<[email protected]> wrote:
>
> On Sat, Jan 9, 2021 at 12:58 AM Arnd Bergmann <[email protected]> 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?
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.
> > * 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
On Tue, Jan 12, 2021 at 4:47 PM John Paul Adrian Glaubitz
<[email protected]> wrote:
> On 1/11/21 4:04 PM, Gerhard Pircher wrote:
> There has to be a healthy balance between hobbyist and commercial use. I understand
> that from a commercial point of view, it doesn't make much sense to run Linux
> on a 30-year-old computer.
I have another impression (depending on what you put under "commercial use").
Industrial requirements are to support for 15+ (in some cases 30+)
years for hardware. I'm quite sure they don't want to have completely
outdated software there either.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
<[email protected]> wrote:
> On Mon, Jan 11, 2021 at 11:55 AM David Laight <[email protected]> wrote:
> > 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
On Wed, Jan 13, 2021 at 9:58 AM Rob Landley <[email protected]> wrote:
> On 1/12/21 4:46 PM, Linus Walleij wrote:
...
> Testing that a basic superh system still builds and boots under qemu and j-core
> I can commit to doing regularly. Testing specific hardware devices on boards I
> don't regularly use is a lot harder.
In our lab we have different hardware connected (including non-x86,
mostly due to maintenance and testing drivers) and it allows us to run
more or less fresh kernels on it. Setup is pretty simple: server with
connected USB 2 serial, network, etc, power cutters, relays to emulate
power button presses for the hardware that can't be turned off and on
by cutting the main power (usual case for tablets / phones) and so on.
From a software point of view we use a netboot image [1][2] which
allows us to kexec kernel downloaded via net.
Now to the point, perhaps organizations like LF can set up something
like this with one technician to support this and pay electricity /
internet bills?
[1]: https://github.com/andy-shev/linux/tree/netboot (just a set of
kernel configuration options on top of defaults)
[2]: https://github.com/andy-shev/buildroot/tree/intel/board/intel/common
(see README in the folder)
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 13, 2021 at 2:02 PM Linus Walleij <[email protected]> wrote:
>
> On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
> <[email protected]> wrote:
> > On Mon, Jan 11, 2021 at 11:55 AM David Laight <[email protected]> wrote:
>
> > > 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?
Personally I have no idea, but...
> https://en.wikipedia.org/wiki/PC/104
...from this we learn about PC/104 consortium on site of which we may
learn about new products:
https://pc104.org/products/vcs-1-pc-104-system-for-precision-robotics-applications/
One and a half years ago, not dead to me.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 13, 2021 at 2:17 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Wed, Jan 13, 2021 at 2:02 PM Linus Walleij <[email protected]> wrote:
> >
> > On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
> > <[email protected]> wrote:
> > > On Mon, Jan 11, 2021 at 11:55 AM David Laight <[email protected]> wrote:
> >
> > > > 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?
>
> Personally I have no idea, but...
>
> > https://en.wikipedia.org/wiki/PC/104
>
> ...from this we learn about PC/104 consortium on site of which we may
> learn about new products:
> https://pc104.org/products/vcs-1-pc-104-system-for-precision-robotics-applications/
It's ARM based for which Wiki says:
"Non-x86 PC/104 CPU boards based on ARM or PowerPC are also
commercially available. However, such boards are not capable of
running off-the-shelf PC software. In these cases, a Board Support
Package is usually provided by the manufacturer for the supported
operating system(s)."
WRT x86 I run the search
https://pc104.org/product-search-results/?kw=x86&post_tag=&product_type=&specifications=&pc-bus-technology=&user=Filter+by+Member+Company
seems like all of them are based on Vortex86DX.
> One and a half years ago, not dead to me.
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 13, 2021 at 01:02:20PM +0100, Linus Walleij wrote:
> On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
> <[email protected]> wrote:
> > On Mon, Jan 11, 2021 at 11:55 AM David Laight <[email protected]> wrote:
>
> > > 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
I don't really see pure PC/104 systems around that much anymore, but
there are still plenty of PC/104-Plus and PCI-104 setups in production.
The PC/104 form factor is popular because users can stack PC/104
compatible modules easily together to build custom solutions; see for
example the diagram on this page:
https://www.advantech.com/embedded-boards-design-in-services/embedded-single-board-computers/pc104-and-pc104-plus
As far as the CPU is concerned, these systems are typically for
industrial applications and run CPUs geared for low-power consumption --
you're looking at processor series such as the Intel Bay trail
(https://www.winsystems.com/product/epx-c414/), DMP Vortex86DX
(http://www.diamondsystems.com/products/helios), and AMD G-series
(https://www.advantech.com/products/1-2jkltu/pcm-3356/mod_0706f4d5-2e44-473a-a7b7-53bd1a7bd1a0).
TLDR; PC/104 is certainly a niche market focused on industrial
consumers, but the form factor and devices are still popular and
upgraded reguarly.
William Breathitt Gray
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:
> > On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
> > <[email protected]> wrote:
> > > On Mon, Jan 11, 2021 at 11:55 AM David Laight <[email protected]> wrote:
> >
> > > > 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
>
> I don't really see pure PC/104 systems around that much anymore, but
> there are still plenty of PC/104-Plus and PCI-104 setups in production.
> The PC/104 form factor is popular because users can stack PC/104
> compatible modules easily together to build custom solutions; see for
> example the diagram on this page:
> https://www.advantech.com/embedded-boards-design-in-services/embedded-single-board-computers/pc104-and-pc104-plus
>
> As far as the CPU is concerned, these systems are typically for
> industrial applications and run CPUs geared for low-power consumption --
> you're looking at processor series such as the Intel Bay trail
> (https://www.winsystems.com/product/epx-c414/), DMP Vortex86DX
> (http://www.diamondsystems.com/products/helios), and AMD G-series
> (https://www.advantech.com/products/1-2jkltu/pcm-3356/mod_0706f4d5-2e44-473a-a7b7-53bd1a7bd1a0).
>
> TLDR; PC/104 is certainly a niche market focused on industrial
> consumers, but the form factor and devices are still popular and
> upgraded reguarly.
>
> William Breathitt Gray
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 1/13/21 2:21 AM, Geert Uytterhoeven wrote:
> Hi Rob,
>
> On Wed, Jan 13, 2021 at 8:58 AM Rob Landley <[email protected]> wrote:
>> On 1/12/21 4:46 PM, Linus Walleij wrote:
>>> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
>>> <[email protected]> wrote:
>>>> Yeah, I have the same impression that's the strong commercial interest pushes
>>>> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
>>>> they're motivated by corporate decisions.
>>>>
>>>> There has to be a healthy balance between hobbyist and commercial use. I understand
>>>> that from a commercial point of view, it doesn't make much sense to run Linux
>>>> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
>>>> Linux stuff for these old machines has a very entertaining and educational factor.
>>>
>>> This is actually one of the most interesting things written in this discussion.
>>>
>>> I have both revamped and deleted subarchitectures in the ARM tree. We
>>> never deleted anyone's pet project *unless* they were clearly unwilling to
>>> work on it (such as simply testning new patches) and agreed that it will
>>> not go on.
>>
>> Another fun aspect of old hardware is it serves as prior art for patents. The
>> j-core hardware implementation schedule has in part been driven by specific
>> patents expiring, as in "we can't do $FEATURE until $DATE".
>
> Indeed, so that's why the release of j4 is postponed to 2016...
> /me runs date (again).
We renamed it J32 because although the patents have expired the trademarks have
not, and provoking Renesas' lawyers more than necessary seemed gratuitous.
It's actually been feature complete for years now, but we've never ported the
kernel to it. (Rich has been working on a kernel port since new year's though.
Jeff Garzik sponsored some engineering time in our 2021 budget to finally get
that done, which has been our blocker for publishing because the lab tests don't
guarantee we won't have to change bits of the API in response to real world loads.)
>> When I did an sh4 porting contract in 2018 I got that board updated to a
>> current-ish kernel (3 versions back from then-current it hit some intermittent
>> nor flash filesystem corruption that only occurred intermittently under
>> sustained load; had to ship so I backed off one version and never tracked it
>> down). But these days I'm not always on the same continent as my two actual sh4
>> hardware boards, have never gotten my physical sh2 board to boot, and $DAYJOB is
>> all j-core stuff not sh4.
>
> Which is not upstream, investing in the future?
Alas I'm not in charge of what is cleared for public release. (I complain about
it on the weekly calls from time to time.) We have actual marketing people now
(Mike and Bunga) so I'm not supposed to do the website in raw stylesheet-less
html with vi anymore.
Unpublished stuff we _mean_ to publish is a form of technical debt. It
_shouldn't_ be (release early release often) but Jeff insists on doing
everything in Mercurial which makes dogfooding our github repos as part of our
normal process darn awkward, and once there a little out of sync with the rest
of the build it becomes a todo item...
Rob
On Wed, Jan 13, 2021 at 1:02 PM Linus Walleij <[email protected]> wrote:
> On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko <[email protected]> wrote:
> > On Mon, Jan 11, 2021 at 11:55 AM David Laight <[email protected]> wrote:
> > > 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
On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> wrote:
Just to catch up on the replies I received on my initial email, here
is the updated status of all the Arm platforms I listed earlier, thanks
for everyone that contributed information on these platforms!
These platforms were listed as likely unused and are now going to
be kept around, as we wait for work on them to resume:
* axxia -- added in 2014, no notable changes after 2015
(Alexander Sverdlin has patches and volunteered as a maintainer)
* bcm/kona -- added in 2013, no notable changes after 2014
(Found activity in PostmarketOS, waiting for usptreaming)
* digicolor -- added in 2014, no notable changes after 2015
(Baruch still uses it, no changes needed)
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
(Russell still has patches for cubox, we might remove the other
boards that are converted to DT though)
* nspire -- added in 2013, no notable changes after 2015
(Fabian and Daniel confirmed this is alive and well, more
hardware support is planned)
* spear -- added in 2010, no notable changes since 2015
(My mistake in reading the changelog, should have been
on the second list. The platform is still active, and Mattias
Wallin plans to send more hardware support and cleanup
patches)
These platforms are confirmed to be dead upstream, and are going to
be removed:
* efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
* picoxcell -- added in 2011, already queued for removal
* prima2 -- added in 20111, no notable changes since 2015
* tango -- added in 2015, sporadic changes until 2017, but abandoned
* u300 -- added in 2009, no notable changes since 2013
* zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
No reply yet, still planning for removal. Oleksij and Tony, please
confirm this is ok or let us know if we should keep them:
* asm9260 -- added in 2014, no notable changes after 2015
* vt8500 -- added in 2010, no notable changes since 2014
These were on the original list of platforms that are likely still
maintained and used despite their age, and I received a
confirmation that this is true (some of them off-list)
* clps711x -- prehistoric, converted to multiplatform+DT in 2016
* 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
* highbank -- added in 2011, no changes after 2015, but Andre still uses it
* iop32x -- added in 2006, no notable changes other than my cleanup, still used
* ixp4xx -- prehistoric, but LinusW and I are still working on it
* lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
* nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
* orion5x -- DT support still active, board files support to get reviewed
for removal and conversion to DT individually
* 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
For these I received no reply yet. Again, these will stay for the moment
unless I get a reply, but if anyone has more information, please reply
here to document the status (adding a few more people to Cc):
* mmp -- added in 2009, DT support is active, but board files might go
* cns3xxx -- added in 2010, last fixed in 2019, probably no users left
* hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
* lpc18xx -- added in 2015, new dts in 2018, but few other changes
* 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)
For the non-Arm platforms I listed, little has changed:
* Thomas Bogendoerfer confirms that he all the MIPS platforms and
the R3000 CPU are still in active use
* Mark Salter steps down as the maintainer for C6x and the architecture
will be removed
* No objection to removing arch/powerpc/platforms/cell that I
had mentioned I plan to do.
* For the other architectures, a couple of users replied, but no
architecture maintainer added any information, so I won't take
any action.
Arnd
Arnd,
Arnd Bergmann <[email protected]> writes:
> For these I received no reply yet. Again, these will stay for the moment
> unless I get a reply, but if anyone has more information, please reply
> here to document the status (adding a few more people to Cc):
>
> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
The following is what I sent to you a week ago. I don't say whether
CNS3xxx support should stay or not, of course.
Subject: Re: cns3xxx PCIe domain support
Arnd Bergmann <[email protected]> writes:
> For the cns3xxx case, I wonder if anyone actually cares. If
> there are still users, the treewide change would make it trivial
> to set it up right, while backporting would be harder. I noticed
> that openwrt removed cns3xxx support in August with the
> explanation that the platform is not used much anymore,
> and I suspect that any users outside of openwrt stopped updating
> their kernels long ago.
I'm still using CNS3xxx-based Gateworks' boards (Laguna), with some
custom patch set, but the last kernels are over 2 years old. I have some
plan to update, but the probability it will happen very soon is rather
low. I guess I will test and, if needed, fix it when the time comes.
I'm not using them with OpenWrt, though.
They are basically a platform for (the old, parallel, not express)
mini-PCI cards and similar stuff. Nothing connected to the Internet etc.
--
Krzysztof Halasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
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
On Wed, 13 Jan 2021, Arnd Bergmann wrote:
>
> It's usually one of two things that happened before a platform gets
> deleted for good:
>
> * The platform port was (almost) exclusively done by one company
> with a commercial interest in it, and the company shifts its priorities
> for some reason (acquisition, bankruptcy, product cancellation,
> accidentally laying off all competent developers, ...) that causes it to
> stop working on it. Sometimes the previously paid maintainers
> keep up their upstream position, but without someone pushing the
> last missing bits into an official release, users are stuck on an old
> BSP kernel.
>
Yes, that's the typical product life cycle. It presumes a short window of
opportunity for sales (suggesting that demand is not organic).
Most vendors like to avoid having to compete with their own prior product
lines. Hence the constrained lifespan that we get from devices with
out-of-tree Linux ports.
AFAICS open source licenses cannot really prevent this (no matter how many
freedoms the FSF would like to confer on people). However, consumer law
could do it, if it were to disallow products which were not servicable.
> * A platform port is done in the open and actually works for upstream
> users, but over time the last active maintainers move on in their
> lives. Complex platforms inevitably break when a treewide change
> goes wrong, so we rely on users that are able to bisect and report
> bugs when they happen.
And without bug reports, breakage gets leveraged into deletion, using the
bogus argument that "broken" code is proof of zero potential users.
> After a platform has been broken for too long, even competent users
> may decide to just give up and stay on their last working kernel. Some
> of these platforms eventually recover when a new maintainer steps up
> or someone discovers they depend on newer kernels for products, but
> after a few years it's usually beyond repair.
>
So all a vendor has to do is make maintenance a bit too difficult for
competent users e.g. by depriving them of access to existing
documentation.
It was only a few decades ago that every applicance you bought came with a
printed circuit schematic. These days, every device you buy comes with
built-in obsolescence and a customer lock-in strategy.
> Arnd
>
On Wed, Jan 13, 2021 at 8:00 PM Krzysztof Hałasa <[email protected]> wrote:
> Arnd Bergmann <[email protected]> writes:
>
> > For these I received no reply yet. Again, these will stay for the moment
> > unless I get a reply, but if anyone has more information, please reply
> > here to document the status (adding a few more people to Cc):
> >
> > * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
>
> The following is what I sent to you a week ago. I don't say whether
> CNS3xxx support should stay or not, of course.
>
> Subject: Re: cns3xxx PCIe domain support
>
> Arnd Bergmann <[email protected]> writes:
>
> > For the cns3xxx case, I wonder if anyone actually cares. If
> > there are still users, the treewide change would make it trivial
> > to set it up right, while backporting would be harder. I noticed
> > that openwrt removed cns3xxx support in August with the
> > explanation that the platform is not used much anymore,
> > and I suspect that any users outside of openwrt stopped updating
> > their kernels long ago.
>
> I'm still using CNS3xxx-based Gateworks' boards (Laguna), with some
> custom patch set, but the last kernels are over 2 years old. I have some
> plan to update, but the probability it will happen very soon is rather
> low. I guess I will test and, if needed, fix it when the time comes.
>
> I'm not using them with OpenWrt, though.
> They are basically a platform for (the old, parallel, not express)
> mini-PCI cards and similar stuff. Nothing connected to the Internet etc.
Hi Krzysztof,
Thanks for your reply. I think I misremembered it from when you
originally said this in the other thread and thought you meant
you were unlikely to ever do it, not just for doing it soon.
No need to rush things then by removing it prematurely then, but it
might help if you could point to a git tree with your last working patches
in case someone else has a Laguna and wants to update it to a more
recent kernel before you do.
Arnd
Hello Linus!
On 1/12/21 11:46 PM, Linus Walleij wrote:
> On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz
> <[email protected]> wrote:
>
>> Yeah, I have the same impression that's the strong commercial interest pushes
>> hobbyist use of the Linux kernel a bit down. A lot of these changes feel like
>> they're motivated by corporate decisions.
>>
>> There has to be a healthy balance between hobbyist and commercial use. I understand
>> that from a commercial point of view, it doesn't make much sense to run Linux
>> on a 30-year-old computer. But it's a hobbyist project for many people and hacking
>> Linux stuff for these old machines has a very entertaining and educational factor.
>
> This is actually one of the most interesting things written in this discussion.
>
> I have both revamped and deleted subarchitectures in the ARM tree. We
> never deleted anyone's pet project *unless* they were clearly unwilling to
> work on it (such as simply testning new patches) and agreed that it will
> not go on.
I'm not arguing this. This was more about killing (sub-)architectures because they
haven't seen git activity for a long time which I think is poor metric to determine
whether a port is dead or not. And reading through the other answers in this thread,
it seems I'm not alone with this stance.
> At multiple occasions I actually found it easier to fix stuff than
> delete it, both because it is a nicer thing to do and because it
> simply creates less social problems, often to the point that the time
> (man hours) spent trying to solve the resulting social problems from
> deleting a platform would be longer than the time spent actually acquiring
> the physical platform and fixing it.
Good to hear.
> Corporate entities can be a bit deletionist (using Wikipedia terminology)
> and as in this thread there is always a strong inclusionist stance pushing
> back to that.
It's an obvious conflict.
> The explanation is in my mind very simply that running Linux
> on a 35-yo or so Amiga, Atari or Apollo Workstation is pretty impressive and
> fun. And I think that fits Mr. Torvalds own sociological-or-something
> explanation in the autobiographical "Just for fun" as to why to write it
> in the first place. And we are very protective of that quality of the
> kernel. (At least I am.)
I'm happy to hear that. For me personally, it also has a very educational value
as the non-mainstream platforms such as m68k offer more places of code to hack
on for adding features such as SECCOMP which are still missing there.
There are usually enough people working on architectures such as x86 and ARM,
so there is not much room for hobbyist activities. Also, you risk making much
more people upset if you break something.
> That said there are a three things that people should really be doing if they
> want to keep their pet archs/subarchs around as good community
> members, and they are in essence to:
>
> 1. Test and review/ack patches that others make
I am already doing that as much as I can for various architectures such as ia64,
m68k, SH and POWER, SPARC although I need to ramp up my activity a bit more. I have
also now added myself for the linux-alpha mailing list to test and ack patches for
the Alpha architecture as well.
I have to admit I have quite a number of pet architectures but that's because I'm
co-maintaining these architectures in Debian Ports with regular releases of Debian
installation images for these targets:
> https://cdimage.debian.org/cdimage/ports/snapshots/
> 2. Migrate existing drivers to newly appeared and
> appropriate subsystems (I think there are some hacky heartbeat LED
> drivers down in arch/* for example) there is also the feature matrix
> core maintainers like and which appears if you type
> Documentation/features/list-arch.sh <archname>
> would be nice if you work on them if you can support them!
> Or at least take a look.
Thanks for the pointer. I'm not so much active in kernel development itself yet, but
I'm also trying to be more active. Although the kernel is not the only project that
sometimes needs attention for these pet architectures. We're also confronted with
deprecation problem in problems such as GCC although we recently saved the m68k
(and VAX) backends in GCC with the help of a Bountysource campaign. The AVR backend
is also backed by such a campaign and currently being worked on.
We are even getting an m68k backend for LLVM hopefully soonish, so we will even be able
to build the Linux kernel for m68k with clang :-).
> 3. Migrate old systems to use the
> contemporary hardware descriptions (such as device tree or ACPI)
> because it makes things so much easier to maintain. Some
> upfront work, but a great win for everyone. Especially for
> subsystem maintainers.
There is such a patch set for arch/sh to add device tree support, but so far it has not
been merged yet, unfortunately. Apparently, it causes some regression on LANDISK devices
according to Rich Felker.
Maybe we can finally get it merged this year:
> https://lore.kernel.org/patchwork/cover/693910/
Since Geert also has a LANDISK SH device now for testing, he might be able to help.
Oh, and if anyone else is interested in helping with the SH port, I'm happy to send
them a free LANDISK or NextVoD SuperH device - the latter has a 450 MHz ST-40
CPU and 256 MB RAM.
> And if your arch uses highmem then please get rid of highmem. I'm
> trying to do this a bit right now for ARM let's see how it goes.
Is there a list of architectures which still need highmem?
> I understand that for some maintainers time is a factor and this list
> feels stressful. I'd say relax, but it'd be nice if you have a TODO that
> you cross items off of.
Thanks for the kind words. I appreciate the input.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian,
On Thu, Jan 14, 2021 at 10:42 AM John Paul Adrian Glaubitz
<[email protected]> wrote:
> Oh, and if anyone else is interested in helping with the SH port, I'm happy to send
> them a free LANDISK or NextVoD SuperH device - the latter has a 450 MHz ST-40
> CPU and 256 MB RAM.
Wasn't ST-40 support removed in 2007[1]?
However, that didn't stop people from submitting ST-40 fixes to the core
SH code three years later[2] ;-)
[1] f96691872439ab20 ("sh: Kill off the remaining ST40 cruft.")
[2] a086536858ad0eb5 ("sh: Ensure ST40-300 BogoMIPS value is consistent")
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Thu, Jan 14, 2021 at 10:43 AM John Paul Adrian Glaubitz
<[email protected]> wrote:
> On 1/12/21 11:46 PM, Linus Walleij wrote:
> > On Tue, Jan 12, 2021 at 3:45 PM John Paul Adrian Glaubitz > <[email protected]> wrote:
> > This is actually one of the most interesting things written in this discussion.
> >
> > I have both revamped and deleted subarchitectures in the ARM tree. We
> > never deleted anyone's pet project *unless* they were clearly unwilling to
> > work on it (such as simply testning new patches) and agreed that it will
> > not go on.
>
> I'm not arguing this. This was more about killing (sub-)architectures because they
> haven't seen git activity for a long time which I think is poor metric to determine
> whether a port is dead or not. And reading through the other answers in this thread,
> it seems I'm not alone with this stance.
I think it's mainly a misunderstanding of what I am trying to do
in finding the platforms that have been completely abandoned.
There are now eight platforms on the list that are unmaintained
and have no known users. All of them were actively getting patched
and tested in the past as can be easily seen from the changelog,
but then the maintainers stopped sending patches five years or
longer ago, which indicates that something changed: either the platform
port was now perfect and has been working fine ever since
(e.g. highbank, digicolor, nspire, ...), or the maintainers (or rather
their employers) gave up and never continued the job (picoxcell,
prima2, efm32, ...).
I can usually guess which one is the case, but the only way to be
sure is to ask, which is what I did in that email.
> > 3. Migrate old systems to use the
> > contemporary hardware descriptions (such as device tree or ACPI)
> > because it makes things so much easier to maintain. Some
> > upfront work, but a great win for everyone. Especially for
> > subsystem maintainers.
>
> There is such a patch set for arch/sh to add device tree support, but so far it has not
> been merged yet, unfortunately. Apparently, it causes some regression on LANDISK devices
> according to Rich Felker.
>
> Maybe we can finally get it merged this year:
>
> > https://lore.kernel.org/patchwork/cover/693910/
>
> Since Geert also has a LANDISK SH device now for testing, he might be able to help.
Doing a proper device tree conversion for arch/sh/ is a huge task,
so unless someone is going to work on that full-time for a while,
I don't see this going anywhere. If nobody has even rebased that
patch series in the past five years, it's fairly unlikely that they will
do it soon.
One of the bigger problems is converting to CONFIG_COMMON_CLK,
as was done for one of the simpler chips in the patch series you
reference above.
> > And if your arch uses highmem then please get rid of highmem. I'm
> > trying to do this a bit right now for ARM let's see how it goes.
>
> Is there a list of architectures which still need highmem?
These are the architectures that currently allow highmem:
| arch/arm/Kconfig:config HIGHMEM
We're working on CONFIG_VMSPLIT_4G_4G as a replacement
to keep ARMv7VE based platforms working after highmem gets
removed, and possibly use ZSWAP to help platforms for
which this is not enough. There are a few users on ARMV7VE
with more than 4GB (keystone2, highbank, armadaxp, some
broadcom STB SoCs) or ARMv7-A with more than 2GB (imx6q,
tegra3), but those memory configurations were shipped in
minute quantities compared to smaller memory versions of the
same boards, so the plan is to wait until the known users have
all stopped needing kernel updates, possibly around 2025.
| arch/arc/Kconfig:config HIGHMEM
| arch/microblaze/Kconfig:config HIGHMEM
I don't think we have upstream support for platforms with a need for
highmem, but these are both used in deeply embedded systems
that tend to not follow mainline kernels. Also, both have hardware
support for 64-bit cores, which I guess will be used in the future
on systems that have more than a gigabyte of RAM.
| arch/csky/Kconfig:config HIGHMEM
| arch/nds32/Kconfig.cpu:config HIGHMEM
These were only merged fairly recently, and as far as I can
tell, highmem support was mainly added for the purpose of
completeness, not because of actual user requirements.
Both architectures are getting replaced with RV64 cores from
the respective companies (Andes and C-Sky/T-Head).
| arch/powerpc/Kconfig:config HIGHMEM
| arch/sparc/Kconfig:config HIGHMEM
| arch/x86/Kconfig:config HIGHMEM
Highmem was used extensively on these in the past, but mainly
on older machines. Most o the x86 users here would already
be on 64-bit hardware and can just change their kernels to
x86-64, but 32-bit machines from around 2004 to 2006
on both powerpc and x86, as well as some older servers, are
likely to lose some of their memory or may have to use ZSWAP
instead.
| arch/mips/Kconfig:config HIGHMEM
| arch/xtensa/Kconfig:config HIGHMEM
AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at
most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G
tricks won't work. OTOH, most mips platforms that support
highmem are on older 64-bit cores and can probably move to
64-bit kernels as well, but some can not (ingenic xburst,
loongson1, bmips, ...)
P5600 (Baikal-T1) is often used with 4GB or at most 8GB on
desktops, this will be interesting to migrate. Since it's MIPS32r5,
this may use more than 512MB of lowmem with some tricks that
need to be implemented.
Most of the embedded MIPS32 ones support less than those 512MB
of RAM and are not affected.
I have no idea who uses xtensa systems with lots of memory on
modern kernels.
Arnd
On Thu, 14 Jan 2021, Arnd Bergmann wrote:
> I think it's mainly a misunderstanding of what I am trying to do
> in finding the platforms that have been completely abandoned.
Have you tried to identify those drivers and Kconfig symbols in mainline
that are used only by devices that don't function with mainline kernels?
Hi Arnd,
On Thu, Jan 14, 2021 at 1:25 PM Arnd Bergmann <[email protected]> wrote:
> | arch/mips/Kconfig:config HIGHMEM
> | arch/xtensa/Kconfig:config HIGHMEM
>
> AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at
> most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G
> tricks won't work.
Regarding xtensa this was done to minimize difference between
MMUv2 and MMUv3 virtual memory layouts. MMUv2 has been
obsoleted more than 10 years ago, and MMUv3 is much more
flexible and can do e.g. 4GB linear map. The only piece of xtensa
MMUv2 hardware that I have has 96MB of DRAM which fits into
its linear mapping. So maybe it's time to do a cleanup and
rearrange virtual memory layout to eliminate the need of highmem.
> I have no idea who uses xtensa systems with lots of memory on
> modern kernels.
We definitely use it for development internally at Cadence/Tensilica,
mainly on simulators, but also on FPGA boards (e.g. on KC705 we
can use all of the 1GB onboard DRAM).
In the last few years we've had a few support requests for linux on
xtensa cores with MMU, but AFAICT none of them had to deal with
more than 512MB of onboard memory.
--
Thanks.
-- Max
On Wed, 2021-01-13 at 14:21 +0200, Andy Shevchenko wrote:
[...]
> WRT x86 I run the search
> https://pc104.org/product-search-results/?kw=x86&post_tag=&product_type=&specifications=&pc-bus-technology=&user=Filter+by+Member+Company
> seems like all of them are based on Vortex86DX.
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 : [email protected]
There is no cloud, just other people computers. - FSFE
LUGA : http://www.luga.at
On Fri, Jan 15, 2021 at 01:03:14AM +0100, Bernd Petrovitsch wrote:
> On Wed, 2021-01-13 at 14:21 +0200, Andy Shevchenko wrote:
> [...]
> > WRT x86 I run the search
> > https://pc104.org/product-search-results/?kw=x86&post_tag=&product_type=&specifications=&pc-bus-technology=&user=Filter+by+Member+Company
> > seems like all of them are based on Vortex86DX.
>
> 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 : [email protected]
> 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
Hi Arnd,
On 2021/1/14 0:14, Arnd Bergmann wrote:
> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> wrote:
>
> Just to catch up on the replies I received on my initial email, here
> is the updated status of all the Arm platforms I listed earlier, thanks
> for everyone that contributed information on these platforms!
>
> These platforms were listed as likely unused and are now going to
> be kept around, as we wait for work on them to resume:
>
> * axxia -- added in 2014, no notable changes after 2015
> (Alexander Sverdlin has patches and volunteered as a maintainer)
> * bcm/kona -- added in 2013, no notable changes after 2014
> (Found activity in PostmarketOS, waiting for usptreaming)
> * digicolor -- added in 2014, no notable changes after 2015
> (Baruch still uses it, no changes needed)
> * dove -- added in 2009, obsoleted by mach-mvebu in 2015
> (Russell still has patches for cubox, we might remove the other
> boards that are converted to DT though)
> * nspire -- added in 2013, no notable changes after 2015
> (Fabian and Daniel confirmed this is alive and well, more
> hardware support is planned)
> * spear -- added in 2010, no notable changes since 2015
> (My mistake in reading the changelog, should have been
> on the second list. The platform is still active, and Mattias
> Wallin plans to send more hardware support and cleanup
> patches)
>
> These platforms are confirmed to be dead upstream, and are going to
> be removed:
>
> * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
> * picoxcell -- added in 2011, already queued for removal
> * prima2 -- added in 20111, no notable changes since 2015
> * tango -- added in 2015, sporadic changes until 2017, but abandoned
> * u300 -- added in 2009, no notable changes since 2013
> * zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
>
> No reply yet, still planning for removal. Oleksij and Tony, please
> confirm this is ok or let us know if we should keep them:
>
> * asm9260 -- added in 2014, no notable changes after 2015
> * vt8500 -- added in 2010, no notable changes since 2014
>
> These were on the original list of platforms that are likely still
> maintained and used despite their age, and I received a
> confirmation that this is true (some of them off-list)
>
> * clps711x -- prehistoric, converted to multiplatform+DT in 2016
> * 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
> * highbank -- added in 2011, no changes after 2015, but Andre still uses it
> * iop32x -- added in 2006, no notable changes other than my cleanup, still used
> * ixp4xx -- prehistoric, but LinusW and I are still working on it
> * lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
> * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
> * orion5x -- DT support still active, board files support to get reviewed
> for removal and conversion to DT individually
> * 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
>
> For these I received no reply yet. Again, these will stay for the moment
> unless I get a reply, but if anyone has more information, please reply
> here to document the status (adding a few more people to Cc):
>
> * mmp -- added in 2009, DT support is active, but board files might go
> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
I think it is OK to drop the support of the hip01(arm32) and hip05(arm64).
Could you also help to drop the support of the hip04(arm32) which I think nobody use as well?
Thanks!
Best Regards,
Wei
On Fri, Jan 15, 2021 at 12:09 AM Max Filippov <[email protected]> wrote:
> On Thu, Jan 14, 2021 at 1:25 PM Arnd Bergmann <[email protected]> wrote:
> > | arch/mips/Kconfig:config HIGHMEM
> > | arch/xtensa/Kconfig:config HIGHMEM
> >
> > AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at
> > most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G
> > tricks won't work.
>
> Regarding xtensa this was done to minimize difference between
> MMUv2 and MMUv3 virtual memory layouts. MMUv2 has been
> obsoleted more than 10 years ago, and MMUv3 is much more
> flexible and can do e.g. 4GB linear map. The only piece of xtensa
> MMUv2 hardware that I have has 96MB of DRAM which fits into
> its linear mapping. So maybe it's time to do a cleanup and
> rearrange virtual memory layout to eliminate the need of highmem.
Yes, I think that sounds like a useful preparation for the future.
> > I have no idea who uses xtensa systems with lots of memory on
> > modern kernels.
>
> We definitely use it for development internally at Cadence/Tensilica,
> mainly on simulators, but also on FPGA boards (e.g. on KC705 we
> can use all of the 1GB onboard DRAM).
> In the last few years we've had a few support requests for linux on
> xtensa cores with MMU, but AFAICT none of them had to deal with
> more than 512MB of onboard memory.
If 1GB of RAM is a useful upper bound on MMUv3, the easiest way is
probably to hardcode the CONFIG_VMSPLIT_3G_OPT behavior
from x86 and ARM, using 2.75GB of user addresses (TASK_SIZE),
and 1.25 GB that gets split between linear map and vmalloc space,
but no uncached linear map and ioremap() pointing into vmalloc
instead. If you want to be prepared for machines with 2GB of linear
lowmem, you could do the same with VMSPLIT_2G_OPT
(TASK_SIZE == 0x70000000).
Arnd
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)
On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <[email protected]> wrote:
> On 2021/1/14 0:14, Arnd Bergmann wrote:
> > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> wrote:
> > * mmp -- added in 2009, DT support is active, but board files might go
> > * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
> > * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
>
> I think it is OK to drop the support of the hip01(arm32) and hip05(arm64).
> Could you also help to drop the support of the hip04(arm32) which I think nobody use as well?
Thank you for your reply! I actually meant to write hip04 instead of hip05,
so I was only asking about the two 32-bit targets. I would expect that
hip05 still has a few users, but wouldn't mind removing that as well if you
are sure there are none.
Since Zhen Lei is starting to upstream Kunpeng506 and Kunpeng509
support, can you clarify how much reuse of IP blocks there is between
hip04 and those? In particular, hip04 has custom code for (at least)
platmcpm, clk, irqchip, ethernet, and hw_rng, probably more as those
were only the ones I see on a quick grep.
If we remove hip04, should we remove all these drivers right away,
or keep some of them around?
Arnd
On 2021/1/15 17:26, Arnd Bergmann wrote:
> On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <[email protected]> wrote:
>> On 2021/1/14 0:14, Arnd Bergmann wrote:
>>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> wrote:
>>> * mmp -- added in 2009, DT support is active, but board files might go
>>> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
>>> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
>>
>> I think it is OK to drop the support of the hip01(arm32) and hip05(arm64).
>> Could you also help to drop the support of the hip04(arm32) which I think nobody use as well?
>
> Thank you for your reply! I actually meant to write hip04 instead of hip05,
> so I was only asking about the two 32-bit targets. I would expect that
> hip05 still has a few users, but wouldn't mind removing that as well if you
> are sure there are none.
>
> Since Zhen Lei is starting to upstream Kunpeng506 and Kunpeng509
> support, can you clarify how much reuse of IP blocks there is between
> hip04 and those? In particular, hip04 has custom code for (at least)
> platmcpm, clk, irqchip, ethernet, and hw_rng, probably more as those
> were only the ones I see on a quick grep.
>
> If we remove hip04, should we remove all these drivers right away,
> or keep some of them around?
I think the drivers should be kept. Currently, at least hip04_eth.c and
irq-hip04.c are used. These drivers were originally written for Hip04, but
the drivers used by other boards maybe similar to them. Therefore, these
drivers are extended without adding new drivers.
>
> Arnd
>
> .
>
On Fri, Jan 15, 2021 at 12:09 PM Leizhen (ThunderTown)
<[email protected]> wrote:
> On 2021/1/15 17:26, Arnd Bergmann wrote:
> > On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <[email protected]> wrote:
> >> On 2021/1/14 0:14, Arnd Bergmann wrote:
> >>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> wrote:
> >>> * mmp -- added in 2009, DT support is active, but board files might go
> >>> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
> >>> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
> >>
> >> I think it is OK to drop the support of the hip01(arm32) and hip05(arm64).
> >> Could you also help to drop the support of the hip04(arm32) which I think nobody use as well?
> >
> > Thank you for your reply! I actually meant to write hip04 instead of hip05,
> > so I was only asking about the two 32-bit targets. I would expect that
> > hip05 still has a few users, but wouldn't mind removing that as well if you
> > are sure there are none.
> >
> > Since Zhen Lei is starting to upstream Kunpeng506 and Kunpeng509
> > support, can you clarify how much reuse of IP blocks there is between
> > hip04 and those? In particular, hip04 has custom code for (at least)
> > platmcpm, clk, irqchip, ethernet, and hw_rng, probably more as those
> > were only the ones I see on a quick grep.
> >
> > If we remove hip04, should we remove all these drivers right away,
> > or keep some of them around?
>
> I think the drivers should be kept.
Ok, will do.
> Currently, at least hip04_eth.c and irq-hip04.c are used. These drivers
> were originally written for Hip04, but the drivers used by other boards
> maybe similar to them. Therefore, these drivers are extended without
> adding new drivers.
Right, so the other chips just use compatible="hisilicon,hip04-intc"
etc. in their device trees? Is there a public copy of the dts files
somewhere that I can use for cross-referencing? Sorry if I'm
messing up the timeline for your upstreaming plans.
It might actually be easier to leave hip01 and hip04 in the
tree for the moment until you have upstreamed the other SoC
support, and then we clean up by removing the unused bits
afterwards. I'll leave it to you both to tell me which way is easier
for you.
Arnd
On 1/12/21 6:12 PM, Finn Thain wrote:
> If you're a museum interested in cultural artifacts from decades past, or
> if you're a business doing data recovery, you're going to need to operate
> those platforms.
Or if you're camping patent expirations and want to be able to point at prior
art for new hardware development WITHOUT a legal team big enough to have its own
office building.
> Once removed from mainline Linux, a port becomes basically frozen, and may
> not be compatible with future emulators, which are a moving target. I say
> that because last year I fixed bugs in Linux/m68k that made it incomatible
> with recent QEMU releases (it was only compatible with old QEMU releases).
Speaking of which, my qemu m68k system has failed to boot ever since commit:
commit f93bfeb55255bddaa16597e187a99ae6131b964a
Author: Finn Thain <[email protected]>
Date: Sun Jun 28 14:23:12 2020 +1000
macintosh/via-macii: Poll the device most likely to respond
Poll the most recently polled device by default, rather than the lowest
device address that happens to be enabled in autopoll_devs. This improves
input latency. Re-use macii_queue_poll() rather than duplicate that logic.
This eliminates a static struct and function.
It hangs in a cpu-eating loop after "random: crng init done". Miniconfig
attached, the qemu invocation is:
qemu-system-m68k -M q800 -nographic -no-reboot -m 256 -kernel vmlinux \
-initrd cpio.gz -append "panic=1 HOST=m68k console=ttyS0
Rob
P.S. This is the toybox "make root" m68k target from
https://github.com/landley/toybox/blob/master/scripts/mkroot.sh#L171 if that's
useful to know. It doesn't get to the root filesystem and the build just creates
that miniconfig and runs it as the comments say...
On Sat, 16 Jan 2021, Rob Landley wrote:
> Speaking of which, my qemu m68k system has failed to boot ever since commit:
>
> commit f93bfeb55255bddaa16597e187a99ae6131b964a
> Author: Finn Thain <[email protected]>
> Date: Sun Jun 28 14:23:12 2020 +1000
>
> macintosh/via-macii: Poll the device most likely to respond
>
Yes, that patch series broke your emulator by fixing kernel bugs. Please
refer to this message for some background and some solutions--
https://lore.kernel.org/linux-m68k/[email protected]/
Hi Arnd,
On 2021/1/15 20:04, Arnd Bergmann wrote:
> On Fri, Jan 15, 2021 at 12:09 PM Leizhen (ThunderTown)
> <[email protected]> wrote:
>> On 2021/1/15 17:26, Arnd Bergmann wrote:
>>> On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <[email protected]> wrote:
>>>> On 2021/1/14 0:14, Arnd Bergmann wrote:
>>>>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <[email protected]> wrote:
>>>>> * mmp -- added in 2009, DT support is active, but board files might go
>>>>> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
>>>>> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
>>>>
>>>> I think it is OK to drop the support of the hip01(arm32) and hip05(arm64).
>>>> Could you also help to drop the support of the hip04(arm32) which I think nobody use as well?
>>>
>>> Thank you for your reply! I actually meant to write hip04 instead of hip05,
>>> so I was only asking about the two 32-bit targets. I would expect that
>>> hip05 still has a few users, but wouldn't mind removing that as well if you
>>> are sure there are none.
>>>
>>> Since Zhen Lei is starting to upstream Kunpeng506 and Kunpeng509
>>> support, can you clarify how much reuse of IP blocks there is between
>>> hip04 and those? In particular, hip04 has custom code for (at least)
>>> platmcpm, clk, irqchip, ethernet, and hw_rng, probably more as those
>>> were only the ones I see on a quick grep.
>>>
>>> If we remove hip04, should we remove all these drivers right away,
>>> or keep some of them around?
>>
>> I think the drivers should be kept.
>
> Ok, will do.
>
>> Currently, at least hip04_eth.c and irq-hip04.c are used. These drivers
>> were originally written for Hip04, but the drivers used by other boards
>> maybe similar to them. Therefore, these drivers are extended without
>> adding new drivers.
>
> Right, so the other chips just use compatible="hisilicon,hip04-intc"
> etc. in their device trees? Is there a public copy of the dts files
> somewhere that I can use for cross-referencing? Sorry if I'm
> messing up the timeline for your upstreaming plans.
>
> It might actually be easier to leave hip01 and hip04 in the
> tree for the moment until you have upstreamed the other SoC
> support, and then we clean up by removing the unused bits
> afterwards. I'll leave it to you both to tell me which way is easier
> for you.
I have aligned with Leizhen and as you suggested it is better to keep them
for the moment.
Thanks!
Best Regards,
Wei
>
> Arnd
> .
>
Hi!
> > > 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.
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
> 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.
Putting a 486 on an fpga might be 'interesting'.
But it has a lot of 'cruft' (like 286 protected mode) that
you really don't need.
I'd bet RISCV comes out smaller.
Most x86 ports are actually IBM-PC ports - so you'd also have
to sort out all the peripherals.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
On Fri 2021-02-05 09:13:03, David Laight wrote:
> > 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.
>
> Putting a 486 on an fpga might be 'interesting'.
> But it has a lot of 'cruft' (like 286 protected mode) that
> you really don't need.
> I'd bet RISCV comes out smaller.
Well.. RISCV may be smaller, and there are open-hardware RISCV
_cores_, but not complete systems.
> Most x86 ports are actually IBM-PC ports - so you'd also have
> to sort out all the peripherals.
And that's exactly what they are doing, and what makes the project
important:
https://github.com/MiSTer-devel/ao486_MiSTer
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
From: Arnd Bergmann <[email protected]>
Date: Fri, 8 Jan 2021 23:55:06 +0100
> 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.
I still have some devboards with a 32-bit R3000-like CPU :S
v5.11-rc6 works well on them.
> * 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
Thanks,
Al
Hi Arnd,
Old discussion, but I lost it in the mid-Jan linux-mips.org crash and
only got my unread mailbox from that time restored recently and got at
wading through it now. I think an update on a couple of platforms of
interest to me is going to be valuable anyway.
On Fri, 8 Jan 2021, Arnd Bergmann wrote:
> 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.
I continue using my 486DX2 box for defxx driver maintenance, as it's my
only EISA machine. A few years ago it suffered from a PSU failure, but
that has been fixed now (I now have a spare PSU too, as it's an unusual
industrial unit needed by the box due to its form factor). Also its 16MiB
of RAM it came with has indeed become insufficient recently, but I now
have a 128MiB upgrade in the post, and will add another 128MiB to max it
out once I get at suitable modules (the system requires 72-pin parity FPM
SIMMs with gold fingers, which are uncommon at 64MiB).
In any case I last booted 5.11.0 on it just fine and will get back at it
once I have installed the RAM upgrade (scheduled second half of Nov; the
box is in my remote lab, so I need to actually get there).
FTR I also have a dual Pentium MMX box with 512MiB of RAM now installed
and PCIe expansion. It feels so fast after the RAM upgrade!
There are some corner-case issues with both systems though and I have
been posting patches to get them gradually addressed. Expect more to
come.
> * Alpha 2106x: First generation that lacks some of the later features.
> Since all Alphas are ancient by now, it's hard to tell whether these have
> any fewer users.
I have a pair of Alpha 21064A (EV45) boxes, one of which is ready to run;
I just need to schedule some time to get an OS installed on it. The other
box will require some porting to get Linux run on it. I have both of them
locally here, so I can fiddle with them at any time. Both have reasonable
amounts of RAM, but I can't remember how much offhand. Either or both my
end up in my remote lab eventually.
> * 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 numerous boxes built around the R3000 and the R2000 CPU even. All
have booted recent Linux kernels just fine. The R2000 box has its maximum
of 24MiB of RAM installed, which has become a bit of a problem. OTOH the
R3000 boxes support up to 480MiB of RAM, and I reckon I have an odd amount
of like 352MiB installed in one of them, which makes it work quite nicely
even without swap. There has been some outstanding work in the driver
area for these; I know.
NB I have some of these boxes wired in my remote lab and scheduled to run
GCC CI for legacy MIPS support once I get the test harness sorted. Based
on my experience they should be fast enough for that purpose.
FAOD I can boot and control, including any software changes, any machine
in my remote lab at any time as it's been the whole point of the lab. Of
course any hardware change requires an actual visit.
FWIW,
Maciej