Old platforms: bring out your dead

Old platforms: bring out your dead

[Arnd Bergmann]

After v5.10 was officially declared an LTS kernel, I had a look around
the Arm platforms that look like they have not seen any patches from
their maintainers or users that are actually running the hardware for
at least five years (2015 or earlier). I made some statistics and lists
for my lwn.net article last year [1], so I'd thought I'd share a summary
here for discussion about what we should remove. As I found three
years ago when I removed several CPU architectures, it makes sense
to do this in bulk, to simplify a scripted search for device drivers, header
files and Kconfig options that become unused in the process.

This is probably a mix of platforms that are completely unused and
those that just work, but I have no good way of knowing which one
it is. Without hearing back about these, I'd propose removing all of
these:

* asm9260 -- added in 2014, no notable changes after 2015
* axxia -- added in 2014, no notable changes after 2015
* bcm/kona -- added in 2013, no notable changes after 2014
* digicolor -- added in 2014, no notable changes after 2015
* dove -- added in 2009, obsoleted by mach-mvebu in 2015
* efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
* nspire -- added in 2013, no notable changes after 2015
* picoxcell -- added in 2011, already queued for removal
* prima2 -- added in 20111, no notable changes since 2015
* spear -- added in 2010, no notable changes since 2015
* tango -- added in 2015, sporadic changes until 2017, but abandoned
* u300 -- added in 2009, no notable changes since 2013
* vt8500 -- added in 2010, no notable changes since 2014
* zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes

If any of the above are not dead yet[2], please let me know,
and we'll keep them.

Then there are ARM platforms that are old but have still seen some work
in the past years. If I hear nothing, these will all stay, but if maintainers
may want to drop them anyway, I can help with that:

* clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
changes since
* cns3xxx -- added in 2010, last fixed in 2019, probably no users left
* ep93xx -- added in 2006, LinusW still working on it, any users left?
* footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have one
* gemini -- added in 2009, LinusW still working on it
* hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
* highbank -- added in 2011, no changes after 2015, but Andre still uses it
* iop32x -- added in 2006, no notable changes other than my cleanup, but
  I think there are still users
* ixp4xx -- prehistoric, but LinusW and I are still working on it
* lpc18xx -- added in 2015, new dts in 2018, but few other changes
* lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
* mmp -- added in 2009, DT support is active, but board files might go
* moxart -- added in 2013, last Tested-by in 2017
* mv78xx0 -- added in 2008, mostly stale but still users
  (https://github.com/1000001101000/Debian_on_Buffalo)
* nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
* oxnas -- added in 2016, but already old then, few changes later
* pxa -- prehistoric, but a few boards may still have users
* rpc -- prehistoric, but I think Russell still uses his machine
* sa1100 -- prehistoric, but rmk and LinusW sporadically working in it

I also looked at non-ARM platforms while preparing for my article. Some of
these look like they are no longer actively maintained or used, but I'm not
doing anything about those unless the maintainers would like me to:

* h8300: Steven Rostedt has repeatedly asked about it to be removed
   or fixed in 2020 with no reply. This was killed before in 2013, added back
   in 2015 but has been mostly stale again since 2016
* c6x: Added in 2011, this has seen very few updates since, but
    Mark still Acks patches when they come. Like most other DSP platforms,
    the model of running Linux on a DSP appears to have been obsoleted
    by using Linux on ARM with on-chip DSP cores running bare-metal code.
* sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
   is currently under review
* powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
   it's in my backlog but I will get to it. This is separate from PS3,
which is actively
   maintained and used; spufs will move to ps3
* powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
* powerpc/amigaone: last updated in 2009
* powerpc/maple: last updated in 2011
* m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
   seen updates in many years (atari/amiga/mac and coldfire are very much
   alive)
* mips/jazz: last updated in 2007
* mips/cobalt: last updated in 2010

There might be some value in dropping old CPU support on architectures
and platforms that are almost exclusively used with more modern CPUs.
If there are only few users, those can still keep using v5.10 or v5.4 stable
kernels for a few more years. Again, I'm not doing anything about them,
except mention them since I did the research.
These are the oldest one by architecture, and they may have reached
their best-served-by-date:

* 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
  indications that 486 have no users either on recent kernels.
  There is still the Vortex86 family of SoCs, and the oldest of those were
  486SX-class, but all the modern ones are 586-class.
* Alpha 2106x: First generation that lacks some of the later features.
  Since all Alphas are ancient by now, it's hard to tell whether these have
  any fewer users.
* IA64 Merced: first generation Itanium (2001) was quickly replaced by
  Itanium II in 2002.
* MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
  64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
  supports these in DECstation and Toshiba Txx9, but it appears that most
  of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
  later are rather different and widely used.
* PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
  are apparently all still used.
* SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
  support in the past, I don't think there were any objections, but
  nobody submitted a patch.
* 68000/68328 (Dragonball): these are less capable than the
  68020+ or the Coldfire MCF5xxx line and similar to the 68360
  that was removed in 2016.

        Arnd

[1] https://lwn.net/Articles/838807/
[2] https://www.youtube.com/watch?v=Jdf5EXo6I68

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Steven Rostedt]

On Fri, 8 Jan 2021 23:55:06 +0100
Arnd Bergmann <arnd@kernel.org> 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/20200918152507.711865ce@gandalf.local.home/

I'm thinking to kill it and see if that causes any complaints.

-- Steve

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Thomas Bogendoerfer]

On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> * mips/jazz: last updated in 2007
> * mips/cobalt: last updated in 2010

missing updates aren't exactly an indicator for being dead. I'm
regulary booting Cobalt and Jazz. And there are no updates needed
for Cobalt since every piece of hardware is supported and working.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Linus Walleij]

On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> wrote:

> * u300 -- added in 2009, no notable changes since 2013

We can delete this, I don't see any use for it moving forward.
I'll send patches to drop it.

> * ep93xx -- added in 2006, LinusW still working on it, any users left?

I was contacted by a user of this platform, using it with mainline and
fixing bugs in the GPIO driver for this kernel cycle. So it has users.

> * gemini -- added in 2009, LinusW still working on it

This has active support and users through OpenWrt on the
D-Link DNS-313 and DIR-685.

> * ixp4xx -- prehistoric, but LinusW and I are still working on it

One more developer has contacted me showing strong interest
in the platform.

> * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users

I use this for various subsystem testing actually (for the hardware that
is on the board, not necessarily Nomadik per se). So it is in pretty
active use.

> * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it

There were some users from OpenEmbedded some years back
and active patches from Andrea Adami beside RMK and me. Paging
Andrea to see if he still has interest in the platform. (I don't.)

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Willy Tarreau]

On Fri, Jan 08, 2021 at 11:55:06PM +0100, Arnd Bergmann wrote:
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>   indications that 486 have no users either on recent kernels.
>   There is still the Vortex86 family of SoCs, and the oldest of those were
>   486SX-class, but all the modern ones are 586-class.

These also are the last generation of fanless x86 boards with 100% compatible
controllers, that some people have probably kept around because these don't
age much and have plenty of connectivity. I've used an old one a few times
to plug in an old floppy drive, ISA SCSI controllers to access an old tape
drive and a few such things. That doesn't mean that it's a good justification
not to remove them, what I rather mean is that *if* there is no benefit
in dropping them maybe we can keep them. On the other hand, good luck for
running a modern OS on these, when 16MB-32MB RAM was about the maximum that
was commonly found by then (though if people kept them around that's probably
because they were well equipped, like that 64MB 386DX I'm having :-)).

Willy

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Florian Fainelli]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Florian Fainelli]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Russell King - ARM Linux admin]

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!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Baruch Siach]

Hi Arnd,

On Sat, Jan 09 2021, Arnd Bergmann wrote:
> * digicolor -- added in 2014, no notable changes after 2015

I have access to the hardware and I'm still interested in maintaining
mainline kernel support for it.

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 6:34 PM Florian Fainelli <f.fainelli@gmail.com> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 9:21 PM Baruch Siach <baruch@tkos.co.il> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 6:43 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau <w@1wt.eu> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 1:18 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 12:32 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 8 Jan 2021 23:55:06 +0100
> Arnd Bergmann <arnd@kernel.org> 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/20200918152507.711865ce@gandalf.local.home/
>
> I'm thinking to kill it and see if that causes any complaints.

I'm happy to queue the patches in my asm-generic tree if you send them
my way. Then they can spend some more time in linux-next and give
possible users one last chance to speak up.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <dt.tangr@gmail.com> wrote:
>
> Hi Arnd,
>
> On 9 Jan 2021, at 9:55 am, Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Andrew Lunn]

> Then there are ARM platforms that are old but have still seen some work
> in the past years. If I hear nothing, these will all stay, but if maintainers
> may want to drop them anyway, I can help with that:

Hi Arnd

I notice orion5x is not on this list. Is that because of Debian still
building for it?

I just blew the dust out of my orion5x RDK and booted 5.11-rc2 on it.
orion5x_defconfig needs a few updates, but otherwise it seems to work
O.K.

But i have no idea if there are any real users out there running
modern kernels.

       Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Willy Tarreau]

On Sat, Jan 09, 2021 at 10:52:53PM +0100, Arnd Bergmann wrote:
(... i486 ...)
> As with the other older platforms, the main question to ask is:
> Are there users that are better off running a future LTS kernel on this
> hardware than the v5.10.y version or something older?

I think this is the most important part of the question. Because the
possible use case I've described actually doesn't correspond to a
"prod" machine but to a machine that's powered on every 5 years for
some old data recovery. In such a case users just start with an old
system (possibly the one that's still on them if present), and this
doesn't warrant an up-to-date OS.

Moreover, just as I experienced when maintaining 2.4, there's a point
where support for old stuff starts to break again by lack of testing.
And just because of this, users shouldn't always expect to see their
old machines boot fine on a recent kernel. Sometimes there may even be
difficulties setting up a compatible toolchain.

So actually the question shouldn't be "does anyone want such old
machines to still be supported" but "does anyone *need* them to be
supported". And I suspect that for most of them the response is "no",
it's just a convenience.

Just my two cents,
Willy

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sun, Jan 10, 2021 at 12:12 AM Andrew Lunn <andrew@lunn.ch> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Russell King - ARM Linux admin]

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!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Neil Armstrong]

Hi Arnd,

Le 08/01/2021 à 23:55, Arnd Bergmann a écrit :
> After v5.10 was officially declared an LTS kernel, I had a look around
> the Arm platforms that look like they have not seen any patches from
> their maintainers or users that are actually running the hardware for
> at least five years (2015 or earlier). I made some statistics and lists
> for my lwn.net article last year [1], so I'd thought I'd share a summary
> here for discussion about what we should remove. As I found three
> years ago when I removed several CPU architectures, it makes sense
> to do this in bulk, to simplify a scripted search for device drivers, header
> files and Kconfig options that become unused in the process.

...

> * oxnas -- added in 2016, but already old then, few changes later

There is still active users in the openwrt community, so it would be goods to keep it for now.
And we have an OX820 board in KerneCI so it's still maintained & boot-tested.

Neil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sun, Jan 10, 2021 at 4:51 PM Neil Armstrong <narmstrong@baylibre.com> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Andrew Lunn]

> For this platform, I'm most interested in whether there are still users
> that rely on board files instead of DT. AFAIU we could just fold
> the DT variant into arch-mvebu like kirkwood was, right?

Hi Arnd

I'm actually booting my device using a board file. But Debian
flash-kernel is pretty unhappy about that. The bootloader i have on
this machine is too old to passed DT blob. I will test appended DT
blob still works. And see if we have any board files which also don't
have a DT representation.

     Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sun, Jan 10, 2021 at 5:48 PM Andrew Lunn <andrew@lunn.ch> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Fabian Vogt]

Hi,

Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <dt.tangr@gmail.com> wrote:
> >
> > Hi Arnd,
> >
> > On 9 Jan 2021, at 9:55 am, Arnd Bergmann <arnd@kernel.org> 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/20190805085847.25554-1-linus.walleij@linaro.org)
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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Sun, Jan 10, 2021 at 7:12 PM Fabian Vogt <fabian@ritter-vogt.de> wrote:
> Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <dt.tangr@gmail.com> wrote:
> > >
> > > Hi Arnd,
> > >
> > > On 9 Jan 2021, at 9:55 am, Arnd Bergmann <arnd@kernel.org> 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/20190805085847.25554-1-linus.walleij@linaro.org)
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Andrew Lunn]

On Sun, Jan 10, 2021 at 06:27:12PM +0100, Arnd Bergmann wrote:
> On Sun, Jan 10, 2021 at 5:48 PM Andrew Lunn <andrew@lunn.ch> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Linus Walleij]

On Sun, Jan 10, 2021 at 7:16 PM Fabian Vogt <fabian@ritter-vogt.de> wrote:
> Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <dt.tangr@gmail.com> 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/20190805085847.25554-1-linus.walleij@linaro.org)
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Russell King - ARM Linux admin]

On Sun, Jan 10, 2021 at 10:33:56PM +0100, Linus Walleij wrote:
> On Sun, Jan 10, 2021 at 7:16 PM Fabian Vogt <fabian@ritter-vogt.de> wrote:
> > Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > > On Sat, Jan 9, 2021 at 1:06 AM Daniel Tang <dt.tangr@gmail.com> 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/20190805085847.25554-1-linus.walleij@linaro.org)
> > 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!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Daniel Palmer]

Hi Arnd,

On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <arnd@kernel.org> wrote:
> * 68000/68328 (Dragonball): these are less capable than the
>   68020+ or the Coldfire MCF5xxx line and similar to the 68360
>   that was removed in 2016.

I have some patches for the DragonBall series to enable SPI etc there,
some patches to support the SuperVZ variant, some tools to upload
Linux via the integrated serial bootloader.
The DragonBall is probably what anyone that wants to build a 68K retro
computer should use as the DRAM controller is integrated and it can
access 32MB of SDRAM.
I haven't tested it recently but it should still work and I have
hardware and I'm willing to look after it if no one else wants to.

Thanks,

Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Geert Uytterhoeven]

Hi Arnd,

On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> wrote:
> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
>   64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
>   supports these in DECstation and Toshiba Txx9, but it appears that most
>   of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
>   later are rather different and widely used.

I have a (32-bit) RBTX4927 development board in my board farm, boot-test
every bi-weekly renesas-drivers release on it, and fix kernel issues
when they appear.

Gr{oetje,eeting}s,

                        Geert

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

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Alexander Sverdlin]

Hello Arnd!

On 08/01/2021 23:55, Arnd Bergmann wrote:
> This is probably a mix of platforms that are completely unused and
> those that just work, but I have no good way of knowing which one
> it is. Without hearing back about these, I'd propose removing all of
> these:

[...]

> * axxia -- added in 2014, no notable changes after 2015

This one is still widely used there is a chance you are using it too when
traveling in Asia or USA :)

I can take the official maintainership, if there is no existing one currently,
or you can count on me to test the patches.

-- 
Best regards,
Alexander Sverdlin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Alexander Sverdlin]

Hello Arnd!

On 08/01/2021 23:55, Arnd Bergmann wrote:
> Then there are ARM platforms that are old but have still seen some work
> in the past years. If I hear nothing, these will all stay, but if maintainers
> may want to drop them anyway, I can help with that:

[...]

> * ep93xx -- added in 2006, LinusW still working on it, any users left?

These devices are still in service, and I'm still here to test any patches
(in my private time).

-- 
Best regards,
Alexander Sverdlin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hi Daniel!
> On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <arnd@kernel.org> 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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Geert Uytterhoeven]

Hi Arnd,

On Mon, Jan 11, 2021 at 9:59 AM Arnd Bergmann <arnd@kernel.org> wrote:
> On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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 -- geert@linux-m68k.org

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Geert Uytterhoeven]

Hi Adrian,

On Mon, Jan 11, 2021 at 10:16 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> > On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <arnd@kernel.org> 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 -- geert@linux-m68k.org

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 9:49 AM Alexander Sverdlin
<alexander.sverdlin@nokia.com> wrote:
> On 08/01/2021 23:55, Arnd Bergmann wrote:
> > This is probably a mix of platforms that are completely unused and
> > those that just work, but I have no good way of knowing which one
> > it is. Without hearing back about these, I'd propose removing all of
> > these:
>
> [...]
>
> > * axxia -- added in 2014, no notable changes after 2015
>
> This one is still widely used there is a chance you are using it too when
> traveling in Asia or USA :)

I know this one has a large installed base, and that Intel were at
least working on it for a while after upstream contributions stopped.

However, my impression was that the port was never completed
upstream before the acquisition, and that the new owners had no
interest in working with us. In particular, none of the later Axxia
SoCs (ppc32/axe3500, arm64/axm5600, arm64/axc6700) ever got
submitted for inclusion as far as I can tell.

The latest public source code I found is at https://github.com/axxia/,
but this is a heavily patched linux-4.9, see
https://github.com/axxia/axxia_yocto_linux_4.9/commits/fa03c456641

My interpretation of this was that whoever is using Axxia chips
is no longer interested in upgrading to newer kernels or using
anything remotely resembling the code we have uptream.

> I can take the official maintainership, if there is no existing one currently,
> or you can count on me to test the patches.

That would be great, thanks for the offer.

         Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Geert Uytterhoeven]

Hi Adrian,

On Mon, Jan 11, 2021 at 10:26 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> 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 -- geert@linux-m68k.org

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Thomas Bogendoerfer]

On Mon, Jan 11, 2021 at 09:59:23AM +0100, Arnd Bergmann wrote:
> On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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 ]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Daniel Palmer]

Hi Adrian,

On Mon, 11 Jan 2021 at 18:17, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
> Hi Daniel!
> > On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Greg Ungerer]

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
> <glaubitz@physik.fu-berlin.de> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: Old platforms: bring out your dead

[David Laight]

From: Arnd Bergmann
> Sent: 09 January 2021 21:53
> 
> On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau <w@1wt.eu> 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)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 2:40 AM Daniel Palmer <daniel@0x0f.com> wrote:
>
> Hi Arnd,
>
> On Sat, 9 Jan 2021 at 07:56, Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Alexander Sverdlin]

Hello Arnd,

On 11/01/2021 10:31, Arnd Bergmann wrote:
>>> * axxia -- added in 2014, no notable changes after 2015
>> This one is still widely used there is a chance you are using it too when
>> traveling in Asia or USA :)
> I know this one has a large installed base, and that Intel were at
> least working on it for a while after upstream contributions stopped.
> 
> However, my impression was that the port was never completed
> upstream before the acquisition, and that the new owners had no
> interest in working with us. In particular, none of the later Axxia
> SoCs (ppc32/axe3500, arm64/axm5600, arm64/axc6700) ever got
> submitted for inclusion as far as I can tell.
> 
> The latest public source code I found is at https://github.com/axxia/,
> but this is a heavily patched linux-4.9, see
> https://github.com/axxia/axxia_yocto_linux_4.9/commits/fa03c456641
> 
> My interpretation of this was that whoever is using Axxia chips
> is no longer interested in upgrading to newer kernels or using
> anything remotely resembling the code we have uptream.

we indeed upgrade to the latest kernels but yes, we have to forward-port
LSI/Intel's code again and again.

And while AXM55xx is ugly hardware in itself where we need to patch a lot,
64-bit variants are working out of the box with vanilla kernel actually.

We by no means want this platform to be thrown away, so let us work a
road map out.

I'll assess what the situation is with AXM55xx, AXM56xx and AXC67 (which from my PoV
is no different from AXM56xx) and share my ideas.

I'm of course not in the position to submit patches you found in their
github account, but maybe there is another solution. 

-- 
Best regards,
Alexander Sverdlin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Geert Uytterhoeven]

Hi Arnd,

On Mon, Jan 11, 2021 at 10:16 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Jan 11, 2021 at 9:59 AM Arnd Bergmann <arnd@kernel.org> wrote:
> > On Mon, Jan 11, 2021 at 9:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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 -- geert@linux-m68k.org

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 10:40 AM Thomas Bogendoerfer
<tsbogend@alpha.franken.de> 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 <geert@linux-m68k.org> wrote:
> > > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 11:28 AM Geert Uytterhoeven
<geert@linux-m68k.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 11:27 AM Alexander Sverdlin
<alexander.sverdlin@nokia.com> wrote:
> On 11/01/2021 10:31, Arnd Bergmann wrote:
> >>> * axxia -- added in 2014, no notable changes after 2015
> >> This one is still widely used there is a chance you are using it too when
> >> traveling in Asia or USA :)
> > I know this one has a large installed base, and that Intel were at
> > least working on it for a while after upstream contributions stopped.
> >
> > However, my impression was that the port was never completed
> > upstream before the acquisition, and that the new owners had no
> > interest in working with us. In particular, none of the later Axxia
> > SoCs (ppc32/axe3500, arm64/axm5600, arm64/axc6700) ever got
> > submitted for inclusion as far as I can tell.
> >
> > The latest public source code I found is at https://github.com/axxia/,
> > but this is a heavily patched linux-4.9, see
> > https://github.com/axxia/axxia_yocto_linux_4.9/commits/fa03c456641
> >
> > My interpretation of this was that whoever is using Axxia chips
> > is no longer interested in upgrading to newer kernels or using
> > anything remotely resembling the code we have uptream.
>
> we indeed upgrade to the latest kernels but yes, we have to forward-port
> LSI/Intel's code again and again.
>
> And while AXM55xx is ugly hardware in itself where we need to patch a lot,
> 64-bit variants are working out of the box with vanilla kernel actually.
>
> We by no means want this platform to be thrown away, so let us work a
> road map out.
>
> I'll assess what the situation is with AXM55xx, AXM56xx and AXC67
> (which from my PoV
> is no different from AXM56xx) and share my ideas.

Sure, sounds good. Great to head the 64-bit parts actually work.
It would be great to have a Kconfig.platforms entry for it and
maybe one .dts file either for a reference machine, or one of the
products you work with.

> I'm of course not in the position to submit patches you found in their
> github account, but maybe there is another solution.

Why not? As long as the code looks reasonable and has a GPLv2
compatible license, you should be able to take any small or large
subset of their work and send it our way.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Viresh Kumar]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 1:33 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> 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 <fabian@ritter-vogt.de> wrote:
> > > Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > > (https://lore.kernel.org/linux-arm-kernel/20190805085847.25554-1-linus.walleij@linaro.org)
> > > 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Russell King - ARM Linux admin]

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
> <linux@armlinux.org.uk> 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 <fabian@ritter-vogt.de> wrote:
> > > > Am Samstag, 9. Januar 2021, 23:20:48 CET schrieb Arnd Bergmann:
> > > > (https://lore.kernel.org/linux-arm-kernel/20190805085847.25554-1-linus.walleij@linaro.org)
> > > > 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!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Marc Gonzalez]

[ Dropping maintainers of other platforms ]

On 08/01/2021 23:55, Arnd Bergmann wrote:

> After v5.10 was officially declared an LTS kernel, I had a look around
> the Arm platforms that look like they have not seen any patches from
> their maintainers or users that are actually running the hardware for
> at least five years (2015 or earlier). I made some statistics and lists
> for my lwn.net article last year [1], so I'd thought I'd share a summary
> here for discussion about what we should remove. As I found three
> years ago when I removed several CPU architectures, it makes sense
> to do this in bulk, to simplify a scripted search for device drivers, header
> files and Kconfig options that become unused in the process.
> 
> This is probably a mix of platforms that are completely unused and
> those that just work, but I have no good way of knowing which one
> it is. Without hearing back about these, I'd propose removing all of
> these:
> 
> * asm9260 -- added in 2014, no notable changes after 2015
> * axxia -- added in 2014, no notable changes after 2015
> * bcm/kona -- added in 2013, no notable changes after 2014
> * digicolor -- added in 2014, no notable changes after 2015
> * dove -- added in 2009, obsoleted by mach-mvebu in 2015
> * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
> * nspire -- added in 2013, no notable changes after 2015
> * picoxcell -- added in 2011, already queued for removal
> * prima2 -- added in 20111, no notable changes since 2015
> * spear -- added in 2010, no notable changes since 2015
> * tango -- added in 2015, sporadic changes until 2017, but abandoned
> * u300 -- added in 2009, no notable changes since 2013
> * vt8500 -- added in 2010, no notable changes since 2014
> * zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
> 
> If any of the above are not dead yet[2], please let me know,
> and we'll keep them.
> 
> Then there are ARM platforms that are old but have still seen some work
> in the past years. If I hear nothing, these will all stay, but if maintainers
> may want to drop them anyway, I can help with that:
> 
> * clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
> changes since
> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
> * ep93xx -- added in 2006, LinusW still working on it, any users left?
> * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have one
> * gemini -- added in 2009, LinusW still working on it
> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
> * highbank -- added in 2011, no changes after 2015, but Andre still uses it
> * iop32x -- added in 2006, no notable changes other than my cleanup, but
>   I think there are still users
> * ixp4xx -- prehistoric, but LinusW and I are still working on it
> * lpc18xx -- added in 2015, new dts in 2018, but few other changes
> * lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
> * mmp -- added in 2009, DT support is active, but board files might go
> * moxart -- added in 2013, last Tested-by in 2017
> * mv78xx0 -- added in 2008, mostly stale but still users
>   (https://github.com/1000001101000/Debian_on_Buffalo)
> * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
> * oxnas -- added in 2016, but already old then, few changes later
> * pxa -- prehistoric, but a few boards may still have users
> * rpc -- prehistoric, but I think Russell still uses his machine
> * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
> 
> I also looked at non-ARM platforms while preparing for my article. Some of
> these look like they are no longer actively maintained or used, but I'm not
> doing anything about those unless the maintainers would like me to:
> 
> * h8300: Steven Rostedt has repeatedly asked about it to be removed
>    or fixed in 2020 with no reply. This was killed before in 2013, added back
>    in 2015 but has been mostly stale again since 2016
> * c6x: Added in 2011, this has seen very few updates since, but
>     Mark still Acks patches when they come. Like most other DSP platforms,
>     the model of running Linux on a DSP appears to have been obsoleted
>     by using Linux on ARM with on-chip DSP cores running bare-metal code.
> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>    is currently under review
> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
>    it's in my backlog but I will get to it. This is separate from PS3,
> which is actively
>    maintained and used; spufs will move to ps3
> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
> * powerpc/amigaone: last updated in 2009
> * powerpc/maple: last updated in 2011
> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
>    seen updates in many years (atari/amiga/mac and coldfire are very much
>    alive)
> * mips/jazz: last updated in 2007
> * mips/cobalt: last updated in 2010
> 
> There might be some value in dropping old CPU support on architectures
> and platforms that are almost exclusively used with more modern CPUs.
> If there are only few users, those can still keep using v5.10 or v5.4 stable
> kernels for a few more years. Again, I'm not doing anything about them,
> except mention them since I did the research.
> These are the oldest one by architecture, and they may have reached
> their best-served-by-date:
> 
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>   indications that 486 have no users either on recent kernels.
>   There is still the Vortex86 family of SoCs, and the oldest of those were
>   486SX-class, but all the modern ones are 586-class.
> * Alpha 2106x: First generation that lacks some of the later features.
>   Since all Alphas are ancient by now, it's hard to tell whether these have
>   any fewer users.
> * IA64 Merced: first generation Itanium (2001) was quickly replaced by
>   Itanium II in 2002.
> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
>   64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
>   supports these in DECstation and Toshiba Txx9, but it appears that most
>   of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
>   later are rather different and widely used.
> * PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
>   are apparently all still used.
> * SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
>   support in the past, I don't think there were any objections, but
>   nobody submitted a patch.
> * 68000/68328 (Dragonball): these are less capable than the
>   68020+ or the Coldfire MCF5xxx line and similar to the 68360
>   that was removed in 2016.
> 
>         Arnd
> 
> [1] https://lwn.net/Articles/838807/
> [2] https://www.youtube.com/watch?v=Jdf5EXo6I68

I didn't see Mans in the CC list. Not sure he's seen this message.

As far as tango is concerned, I didn't keep any boards.

Mans might have some tango3 and tango4 boards.

Waiting for his take on the matter.

I can point out some device-specific drivers that would become
useless if tango support were dropped.

Regards.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Mark Salter]

On Fri, 2021-01-08 at 23:55 +0100, Arnd Bergmann wrote:
> * c6x: Added in 2011, this has seen very few updates since, but
>     Mark still Acks patches when they come. Like most other DSP platforms,
>     the model of running Linux on a DSP appears to have been obsoleted
>     by using Linux on ARM with on-chip DSP cores running bare-metal code.

Hi Arnd,

So this has been on my mind for a while now. I no longer have working hw
for c6x and TI hasn't been forthcoming with replacements. I'm totally fine
with removing it from mainline. In any case, I'm not really in a position
to go forward as maintainer.

Mark



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Alexander Shiyan]

On Fri, 8 Jan 2021 23:55:06 +0100
Arnd Bergmann <arnd@kernel.org> 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 <shc_work@mail.ru>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 3:48 PM Alexander Shiyan <shc_work@mail.ru> wrote:
> On Fri, 8 Jan 2021 23:55:06 +0100 Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 3:22 PM Mark Salter <msalter@redhat.com> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Sylvain Lemieux]

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 <arnd@kernel.org> wrote:
>
> After v5.10 was officially declared an LTS kernel, I had a look around
> the Arm platforms that look like they have not seen any patches from
> their maintainers or users that are actually running the hardware for
> at least five years (2015 or earlier). I made some statistics and lists
> for my lwn.net article last year [1], so I'd thought I'd share a summary
> here for discussion about what we should remove. As I found three
> years ago when I removed several CPU architectures, it makes sense
> to do this in bulk, to simplify a scripted search for device drivers, header
> files and Kconfig options that become unused in the process.
>
> This is probably a mix of platforms that are completely unused and
> those that just work, but I have no good way of knowing which one
> it is. Without hearing back about these, I'd propose removing all of
> these:
>
> * asm9260 -- added in 2014, no notable changes after 2015
> * axxia -- added in 2014, no notable changes after 2015
> * bcm/kona -- added in 2013, no notable changes after 2014
> * digicolor -- added in 2014, no notable changes after 2015
> * dove -- added in 2009, obsoleted by mach-mvebu in 2015
> * efm32 -- added in 2011, first Cortex-M, no notable changes after 2013
> * nspire -- added in 2013, no notable changes after 2015
> * picoxcell -- added in 2011, already queued for removal
> * prima2 -- added in 20111, no notable changes since 2015
> * spear -- added in 2010, no notable changes since 2015
> * tango -- added in 2015, sporadic changes until 2017, but abandoned
> * u300 -- added in 2009, no notable changes since 2013
> * vt8500 -- added in 2010, no notable changes since 2014
> * zx --added in 2015 for both 32, 2017 for 64 bit, no notable changes
>
> If any of the above are not dead yet[2], please let me know,
> and we'll keep them.
>
> Then there are ARM platforms that are old but have still seen some work
> in the past years. If I hear nothing, these will all stay, but if maintainers
> may want to drop them anyway, I can help with that:
>
> * clps711x -- prehistoric, converted to multiplatform+DT in 2016, no
> changes since
> * cns3xxx -- added in 2010, last fixed in 2019, probably no users left
> * ep93xx -- added in 2006, LinusW still working on it, any users left?
> * footbridge -- added in prehistory, stable since ~2013, rmk and LinusW have one
> * gemini -- added in 2009, LinusW still working on it
> * hisi (hip01/hip05) -- servers added in 2013, replaced with arm64 in 2016
> * highbank -- added in 2011, no changes after 2015, but Andre still uses it
> * iop32x -- added in 2006, no notable changes other than my cleanup, but
>   I think there are still users
> * ixp4xx -- prehistoric, but LinusW and I are still working on it
> * lpc18xx -- added in 2015, new dts in 2018, but few other changes
> * lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL
> * mmp -- added in 2009, DT support is active, but board files might go
> * moxart -- added in 2013, last Tested-by in 2017
> * mv78xx0 -- added in 2008, mostly stale but still users
>   (https://github.com/1000001101000/Debian_on_Buffalo)
> * nomadik -- added in 2009, LinusW keeps fixing it, probably no other users
> * oxnas -- added in 2016, but already old then, few changes later
> * pxa -- prehistoric, but a few boards may still have users
> * rpc -- prehistoric, but I think Russell still uses his machine
> * sa1100 -- prehistoric, but rmk and LinusW sporadically working in it
>
> I also looked at non-ARM platforms while preparing for my article. Some of
> these look like they are no longer actively maintained or used, but I'm not
> doing anything about those unless the maintainers would like me to:
>
> * h8300: Steven Rostedt has repeatedly asked about it to be removed
>    or fixed in 2020 with no reply. This was killed before in 2013, added back
>    in 2015 but has been mostly stale again since 2016
> * c6x: Added in 2011, this has seen very few updates since, but
>     Mark still Acks patches when they come. Like most other DSP platforms,
>     the model of running Linux on a DSP appears to have been obsoleted
>     by using Linux on ARM with on-chip DSP cores running bare-metal code.
> * sparc/sun4m: A patch for removing 32-bit Sun sparc support (not LEON)
>    is currently under review
> * powerpc/cell: I'm the maintainer and I promised to send a patch to remove it.
>    it's in my backlog but I will get to it. This is separate from PS3,
> which is actively
>    maintained and used; spufs will move to ps3
> * powerpc/chrp (32-bit rs6000, pegasos2): last updated in 2009
> * powerpc/amigaone: last updated in 2009
> * powerpc/maple: last updated in 2011
> * m68k/{apollo,hp300,sun3,q40} these are all presumably dead and have not
>    seen updates in many years (atari/amiga/mac and coldfire are very much
>    alive)
> * mips/jazz: last updated in 2007
> * mips/cobalt: last updated in 2010
>
> There might be some value in dropping old CPU support on architectures
> and platforms that are almost exclusively used with more modern CPUs.
> If there are only few users, those can still keep using v5.10 or v5.4 stable
> kernels for a few more years. Again, I'm not doing anything about them,
> except mention them since I did the research.
> These are the oldest one by architecture, and they may have reached
> their best-served-by-date:
>
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>   indications that 486 have no users either on recent kernels.
>   There is still the Vortex86 family of SoCs, and the oldest of those were
>   486SX-class, but all the modern ones are 586-class.
> * Alpha 2106x: First generation that lacks some of the later features.
>   Since all Alphas are ancient by now, it's hard to tell whether these have
>   any fewer users.
> * IA64 Merced: first generation Itanium (2001) was quickly replaced by
>   Itanium II in 2002.
> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
>   64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
>   supports these in DECstation and Toshiba Txx9, but it appears that most
>   of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
>   later are rather different and widely used.
> * PowerPC 601 (from 1992) just got removed, later 60x, 4xx, 8xx etc
>   are apparently all still used.
> * SuperH SH-2: We discussed removing SH-2 (not J2 or SH-4)
>   support in the past, I don't think there were any objections, but
>   nobody submitted a patch.
> * 68000/68328 (Dragonball): these are less capable than the
>   68020+ or the Coldfire MCF5xxx line and similar to the 68360
>   that was removed in 2016.
>
>         Arnd
>
> [1] https://lwn.net/Articles/838807/
> [2] https://www.youtube.com/watch?v=Jdf5EXo6I68
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Måns Rullgård]

Marc Gonzalez <marc.w.gonzalez@free.fr> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Thomas Petazzoni]

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 <arnd@kernel.org> wrote:

> * asm9260 -- added in 2014, no notable changes after 2015
> * axxia -- added in 2014, no notable changes after 2015
> * bcm/kona -- added in 2013, no notable changes after 2014
> * digicolor -- added in 2014, no notable changes after 2015
> * dove -- added in 2009, obsoleted by mach-mvebu in 2015

arch/arm/mach-dove has two remaining board files, cm-a510.c and
dove-db-setup.c. The former is covered by the
dove-cm-a510.dtsi/dove-sbc-a510.dts DTs and the latter by
dove-dove-db.dts.

However, dove-dove-db.dts doesn't seem to have all the features of
dove-db-setup.c. The DT only enables UART, SDIO, SATA, SPI and I2C0.
The board file has PCIe, Ethernet, USB.

The dove-sbc-a510.dts seems much more complete, as it includes
Ethernet, PCIe, USB in addition to SATA, SDIO, I2C, SPI, UART, etc.

So overall, I'd say that yes we could probably drop arch/arm/mach-dove/.

> * spear -- added in 2010, no notable changes since 2015

Well, I did quite a few improvements in spear DTs in 2017, some
improvements to the NAND FSMC driver for Spear, and my colleague Miquèl
Raynal fixed an issue in the Spear NOR driver in 2019.

We have one customer running a 4.14 upstream kernel on a Spear600
product, and this was a fairly "recent" port, in the sense that the
product was originally running WinCE, and we ported Linux to it many
years later after the product was first shipped.

> * lpc32xx -- added in 2010, multiplatform 2019, hardware is EOL

As late as early 2020, we were finishing the migration of one of our
customer LPC32xx platform to a recent mainline kernel.

So in fact for us at Bootlin, it happens pretty regularly to see users
of "legacy" platforms having a need for an updated kernel. From the
above, you can see that even legacy SoCs such as Spear600 and LPC32xx
are still used in products were kernel are being updated.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar <viresh.kumar@linaro.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Russell King - ARM Linux admin]

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
> <linux@armlinux.org.uk> 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!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 8:58 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> > On Fri, 8 Jan 2021 23:55:06 +0100 Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: Old platforms: bring out your dead

[Song Bao Hua (Barry Song)]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@kernel.org]
> Sent: Saturday, January 9, 2021 11:55 AM
> To: Linux ARM <linux-arm-kernel@lists.infradead.org>; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>
> Cc: Krzysztof Adamski <krzysztof.adamski@nokia.com>; Oleksij Rempel
> <o.rempel@pengutronix.de>; Baruch Siach <baruch@tkos.co.il>; Russell King -
> ARM Linux <linux@armlinux.org.uk>; Daniel Tang <dt.tangr@gmail.com>; Uwe
> Kleine-König <u.kleine-koenig@pengutronix.de>; Jamie Iles
> <jamie@jamieiles.com>; Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>;
> Viresh Kumar <viresh.kumar@linaro.org>; Linus Walleij
> <linus.walleij@linaro.org>; Jonas Jensen <jonas.jensen@gmail.com>; Marc
> Gonzalez <marc.w.gonzalez@free.fr>; Hartley Sweeten
> <hsweeten@visionengravers.com>; Lubomir Rintel <lkundrak@v3.sk>; Neil
> Armstrong <narmstrong@baylibre.com>; Shawn Guo <shawnguo@kernel.org>; Alex
> Elder <elder@linaro.org>; Alexander Shiyan <shc_work@mail.ru>; Koen Vandeputte
> <koen.vandeputte@ncentric.com>; Hans Ulli Kroll <ulli.kroll@googlemail.com>;
> Vladimir Zapolskiy <vz@mleia.com>; xuwei (O) <xuwei5@huawei.com>; Steven
> Rostedt <rostedt@goodmis.org>; Yoshinori Sato <ysato@users.sourceforge.jp>;
> Mark Salter <msalter@redhat.com>; Michael Ellerman <mpe@ellerman.id.au>; Geert
> Uytterhoeven <geert+renesas@glider.be>; Thomas Bogendoerfer
> <tsbogend@alpha.franken.de>
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: Old platforms: bring out your dead

[Mattias Wallin]

>On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar <viresh.kumar@linaro.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 10:15 PM Mattias Wallin <mattias.wallin@se.com> wrote:
> >On Mon, Jan 11, 2021 at 12:10 PM Viresh Kumar <viresh.kumar@linaro.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Mon, Jan 11, 2021 at 6:29 PM Måns Rullgård <mans@mansr.com> wrote:
> Marc Gonzalez <marc.w.gonzalez@free.fr> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Alexandre Belloni]

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/20210104004313.1633622-1-alexandre.belloni@bootlin.com/


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Marc Gonzalez]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Marc Gonzalez]

On 11/01/2021 21:25, Song Bao Hua (Barry Song) wrote:

> I got confirmation from Qualcomm guys that there is no plan
> to maintain prima2 in mainline any more.
> Please feel free to remove the code. If you need my help,
> Please let me know.

Hello Barry,

I didn't know that qualcomm worked on mainline kernels, except through
the Code Aurora and Linaro arrangement.

Was the mainline work done by CSR plc /before/ it was swallowed by qcom?
https://en.wikipedia.org/wiki/CSR_(company)

Regards.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Andy Shevchenko]

On Mon, Jan 11, 2021 at 11:55 AM David Laight <David.Laight@aculab.com> wrote:
> From: Arnd Bergmann
> > Sent: 09 January 2021 21:53
> >
> > On Sat, Jan 9, 2021 at 6:56 AM Willy Tarreau <w@1wt.eu> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Andy Shevchenko]

On Sat, Jan 9, 2021 at 12:58 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> After v5.10 was officially declared an LTS kernel,

I have a question here. Maybe I have missed something, but how LTS
helps in this case? LTS AFAIR has a rule "upstream first". How can you
provide a patch to be backported if there is no upstream for it
anymore?

> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>   indications that 486 have no users either on recent kernels.
>   There is still the Vortex86 family of SoCs, and the oldest of those were
>   486SX-class, but all the modern ones are 586-class.
> * Alpha 2106x: First generation that lacks some of the later features.
>   Since all Alphas are ancient by now, it's hard to tell whether these have
>   any fewer users.

We still have Intel Quark available. I run vanilla from time to time
on it due to the presence of peripherals I can't find elsewhere on x86
boards.

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Wed, Jan 13, 2021 at 11:31 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Sat, Jan 9, 2021 at 12:58 AM Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Linus Walleij]

On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Jan 11, 2021 at 11:55 AM David Laight <David.Laight@aculab.com> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Andy Shevchenko]

On Wed, Jan 13, 2021 at 2:02 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Mon, Jan 11, 2021 at 11:55 AM David Laight <David.Laight@aculab.com> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Andy Shevchenko]

On Wed, Jan 13, 2021 at 2:17 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Jan 13, 2021 at 2:02 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Mon, Jan 11, 2021 at 11:55 AM David Laight <David.Laight@aculab.com> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[William Breathitt Gray]

[-- Attachment #1.1: Type: text/plain, Size: 2210 bytes --]

On Wed, Jan 13, 2021 at 01:02:20PM +0100, Linus Walleij wrote:
> On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Mon, Jan 11, 2021 at 11:55 AM David Laight <David.Laight@aculab.com> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[William Breathitt Gray]

[-- Attachment #1.1: Type: text/plain, Size: 2992 bytes --]

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
> > <andy.shevchenko@gmail.com> wrote:
> > > On Mon, Jan 11, 2021 at 11:55 AM David Laight <David.Laight@aculab.com> 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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Arnd Bergmann]

On Wed, Jan 13, 2021 at 1:02 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Jan 13, 2021 at 11:27 AM Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Mon, Jan 11, 2021 at 11:55 AM David Laight <David.Laight@aculab.com> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Krzysztof Hałasa]

Arnd,

Arnd Bergmann <arnd@kernel.org> 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 <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Richard Z]

[-- Attachment #1.1: Type: text/plain, Size: 1025 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 811 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Arnd Bergmann]

On Wed, Jan 13, 2021 at 8:00 PM Krzysztof Hałasa <khalasa@piap.pl> wrote:
> Arnd Bergmann <arnd@kernel.org> 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 <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Bernd Petrovitsch]

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 : bernd@petrovitsch.priv.at
There is no cloud, just other people computers. - FSFE
                     LUGA : http://www.luga.at



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[William Breathitt Gray]

[-- Attachment #1.1: Type: text/plain, Size: 1272 bytes --]

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 : bernd@petrovitsch.priv.at
> There is no cloud, just other people computers. - FSFE
>                      LUGA : http://www.luga.at

That's part of the Bay Trail generation isn't it? Are those processors
still manufactured? My worry is that although there are boards still in
production, they might be simply using up an old stock of parts. The
question becomes whether these will still be produced in the near
future, or whether the companies are just using up the rest of their
supply.

William Breathitt Gray

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Wei Xu]

Hi Arnd,

On 2021/1/14 0:14, Arnd Bergmann wrote:
> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: Old platforms: bring out your dead

[David Laight]

From: William Breathitt Gray
> Sent: 15 January 2021 00:24
...
> That's part of the Bay Trail generation isn't it? Are those processors
> still manufactured? My worry is that although there are boards still in
> production, they might be simply using up an old stock of parts. The
> question becomes whether these will still be produced in the near
> future, or whether the companies are just using up the rest of their
> supply.

The 'stock of parts' might go back as far as etched wafers that
haven't been cut up....
Even then it may take a moderate demand to get them processed.

We're have to redesign a board to use a completely different
part because the one we were using has gone end-of-life.

Hopefully the replacement will be made for a while.
The datasheet for that part is 12 years old.

The designs for both are probably over 20 years old.
The TDM E1/T1 interface is about 50.
But it is still used.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Arnd Bergmann]

On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <xuwei5@hisilicon.com> wrote:
> On 2021/1/14 0:14, Arnd Bergmann wrote:
> > On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Leizhen (ThunderTown)]

On 2021/1/15 17:26, Arnd Bergmann wrote:
> On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <xuwei5@hisilicon.com> wrote:
>> On 2021/1/14 0:14, Arnd Bergmann wrote:
>>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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
> 
> .
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Arnd Bergmann]

On Fri, Jan 15, 2021 at 12:09 PM Leizhen (ThunderTown)
<thunder.leizhen@huawei.com> wrote:
> On 2021/1/15 17:26, Arnd Bergmann wrote:
> > On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <xuwei5@hisilicon.com> wrote:
> >> On 2021/1/14 0:14, Arnd Bergmann wrote:
> >>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Wei Xu]

Hi Arnd,

On 2021/1/15 20:04, Arnd Bergmann wrote:
> On Fri, Jan 15, 2021 at 12:09 PM Leizhen (ThunderTown)
> <thunder.leizhen@huawei.com> wrote:
>> On 2021/1/15 17:26, Arnd Bergmann wrote:
>>> On Fri, Jan 15, 2021 at 8:08 AM Wei Xu <xuwei5@hisilicon.com> wrote:
>>>> On 2021/1/14 0:14, Arnd Bergmann wrote:
>>>>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann <arnd@kernel.org> 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
> .
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 1413 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: Old platforms: bring out your dead

[David Laight]

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 835 bytes --]

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Alexander Lobakin]

From: Arnd Bergmann <arnd@kernel.org>
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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Old platforms: bring out your dead

[Maciej W. Rozycki]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Arnd Bergmann]

On Thu, Jan 21, 2021 at 12:58 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Arnd Bergmann <arnd@kernel.org> writes:
> > On Sun, Jan 17, 2021 at 11:33 AM Michael Ellerman <mpe@ellerman.id.au> wrote:

> > Right, I agree that there is little to gain from dropping QS20/21, the
> > only files that I see this would impact are
> >
> > arch/powerpc/platforms/cell/spider-pci.c
> > arch/powerpc/platforms/cell/spider-pic.c
> > drivers/net/ethernet/toshiba/spider_net*
> >
> > Dropping all of native (as opposed to PS3 hypervisor based) Cell support
> > would be a useful cleanup I think, but not as long as you still use it.
>
> I would still be happy to drop QS20/21, it's still a few thousand lines
> of code, and hasn't been tested for years.
>
> I think it might also let us clean up some of our IO_WORKAROUNDS stuff.
>
> But I agree it's much less of an obvious maintenance win than dropping
> all of the native code.

Good point about the IO_WORKAROUNDS! This is something that may
come up again if we manage to get arch/arm/mach-ixp4xx converted
to use a common kernel. This one also needs indirect MMIO, so at that
point, we could steal the code from powerpc and put it into common
code, but then drop the Cell version.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Michael Ellerman]

Arnd Bergmann <arnd@kernel.org> writes:
> On Sun, Jan 17, 2021 at 11:33 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Arnd Bergmann <arnd@kernel.org> writes:
>> > On Fri, Jan 15, 2021 at 9:37 PM John Paul Adrian Glaubitz
>> > <glaubitz@physik.fu-berlin.de> wrote:
>> >>
>> >> Hello Arnd!
>> >>
>> >> > * No objection to removing arch/powerpc/platforms/cell that I
>> >> >   had mentioned I plan to do.
>> >>
>> >> Does this affect the capability to run Linux on the PS3?
>> >>
>> >> If yes, it would be great if it could stay as the PS3 is a rather
>> >> widely used platform although you certainly won't find any PS3
>> >> users on the LKML.
>> >
>> > No, as I wrote in the initial email, I'm planning to move the things
>> > (like spufs) that are shared with PS3 into arch/powerpc/platforms/ps3
>> > and remove the parts that are only used on the IBM blades.
>>
>> As I said a while back, I'm not convinced that's a good idea.
>>
>> The only way I have of testing cell is using a QS22, I don't have a PS3
>> capable of running Linux these days. I worry that if I can't test cell
>> at all then the PS3 support will bit rot.
>
> Fair enough. I must have missed your previous reply and expected
> that your QS22 had stopped being operational years ago and that
> there were already zero machines getting kernel updates.

No worries, we all get lots of email :)

So far that QS22 is still going OK with no signs of imminent failure.

> Are you aware of any other users?

No.

I can think of one spufs patch ~year ago that came from someone I assume
is a real Cell user, but otherwise it's pretty much only Geoff that ever
sends Cell/PS3 patches.

>> I know Geoff tests PS3, but that seems sporadic, I don't think he tests
>> linux-next every day.
>>
>> I also don't think the cell blade support is really causing much in the
>> way of maintenance overhead. The thing that's causing work is spufs, and
>> that would remain either way.
>>
>> I'd be happy to drop any QS20/21 code we have, but I'm not convinced
>> dropping QS22 is a good trade off.
>
> Right, I agree that there is little to gain from dropping QS20/21, the
> only files that I see this would impact are
>
> arch/powerpc/platforms/cell/spider-pci.c
> arch/powerpc/platforms/cell/spider-pic.c
> drivers/net/ethernet/toshiba/spider_net*
>
> Dropping all of native (as opposed to PS3 hypervisor based) Cell support
> would be a useful cleanup I think, but not as long as you still use it.

I would still be happy to drop QS20/21, it's still a few thousand lines
of code, and hasn't been tested for years.

I think it might also let us clean up some of our IO_WORKAROUNDS stuff.

But I agree it's much less of an obvious maintenance win than dropping
all of the native code.

cheers

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hi Arnd!

On 1/17/21 11:56 AM, Arnd Bergmann wrote:
>> I'd be happy to drop any QS20/21 code we have, but I'm not convinced
>> dropping QS22 is a good trade off.
> 
> Right, I agree that there is little to gain from dropping QS20/21, the
> only files that I see this would impact are
> 
> arch/powerpc/platforms/cell/spider-pci.c
> arch/powerpc/platforms/cell/spider-pic.c
> drivers/net/ethernet/toshiba/spider_net*
> 
> Dropping all of native (as opposed to PS3 hypervisor based) Cell support
> would be a useful cleanup I think, but not as long as you still use it.

I'm very glad to hear that. Cell is such a unique and interesting architecture
that it would be a shame if it was no longer supported by the Linux kernel.

I would really like to try Debian on these machines one day.

Adrian

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Arnd Bergmann]

On Sun, Jan 17, 2021 at 11:33 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
> Arnd Bergmann <arnd@kernel.org> writes:
> > On Fri, Jan 15, 2021 at 9:37 PM John Paul Adrian Glaubitz
> > <glaubitz@physik.fu-berlin.de> wrote:
> >>
> >> Hello Arnd!
> >>
> >> > * No objection to removing arch/powerpc/platforms/cell that I
> >> >   had mentioned I plan to do.
> >>
> >> Does this affect the capability to run Linux on the PS3?
> >>
> >> If yes, it would be great if it could stay as the PS3 is a rather
> >> widely used platform although you certainly won't find any PS3
> >> users on the LKML.
> >
> > No, as I wrote in the initial email, I'm planning to move the things
> > (like spufs) that are shared with PS3 into arch/powerpc/platforms/ps3
> > and remove the parts that are only used on the IBM blades.
>
> As I said a while back, I'm not convinced that's a good idea.
>
> The only way I have of testing cell is using a QS22, I don't have a PS3
> capable of running Linux these days. I worry that if I can't test cell
> at all then the PS3 support will bit rot.

Fair enough. I must have missed your previous reply and expected
that your QS22 had stopped being operational years ago and that
there were already zero machines getting kernel updates.

Are you aware of any other users?

> I know Geoff tests PS3, but that seems sporadic, I don't think he tests
> linux-next every day.
>
> I also don't think the cell blade support is really causing much in the
> way of maintenance overhead. The thing that's causing work is spufs, and
> that would remain either way.
>
> I'd be happy to drop any QS20/21 code we have, but I'm not convinced
> dropping QS22 is a good trade off.

Right, I agree that there is little to gain from dropping QS20/21, the
only files that I see this would impact are

arch/powerpc/platforms/cell/spider-pci.c
arch/powerpc/platforms/cell/spider-pic.c
drivers/net/ethernet/toshiba/spider_net*

Dropping all of native (as opposed to PS3 hypervisor based) Cell support
would be a useful cleanup I think, but not as long as you still use it.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Michael Ellerman]

Arnd Bergmann <arnd@kernel.org> writes:
> On Fri, Jan 15, 2021 at 9:37 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
>>
>> Hello Arnd!
>>
>> > * No objection to removing arch/powerpc/platforms/cell that I
>> >   had mentioned I plan to do.
>>
>> Does this affect the capability to run Linux on the PS3?
>>
>> If yes, it would be great if it could stay as the PS3 is a rather
>> widely used platform although you certainly won't find any PS3
>> users on the LKML.
>
> No, as I wrote in the initial email, I'm planning to move the things
> (like spufs) that are shared with PS3 into arch/powerpc/platforms/ps3
> and remove the parts that are only used on the IBM blades.

As I said a while back, I'm not convinced that's a good idea.

The only way I have of testing cell is using a QS22, I don't have a PS3
capable of running Linux these days. I worry that if I can't test cell
at all then the PS3 support will bit rot.

I know Geoff tests PS3, but that seems sporadic, I don't think he tests
linux-next every day.

I also don't think the cell blade support is really causing much in the
way of maintenance overhead. The thing that's causing work is spufs, and
that would remain either way.

I'd be happy to drop any QS20/21 code we have, but I'm not convinced
dropping QS22 is a good trade off.

cheers

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[Arnd Bergmann]

On Fri, Jan 15, 2021 at 9:37 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
> Hello Arnd!
>
> > * No objection to removing arch/powerpc/platforms/cell that I
> >   had mentioned I plan to do.
>
> Does this affect the capability to run Linux on the PS3?
>
> If yes, it would be great if it could stay as the PS3 is a rather
> widely used platform although you certainly won't find any PS3
> users on the LKML.

No, as I wrote in the initial email, I'm planning to move the things
(like spufs) that are shared with PS3 into arch/powerpc/platforms/ps3
and remove the parts that are only used on the IBM blades.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [v2] Old platforms: bring out your dead

[John Paul Adrian Glaubitz]

Hello Arnd!

> * No objection to removing arch/powerpc/platforms/cell that I
>   had mentioned I plan to do.

Does this affect the capability to run Linux on the PS3?

If yes, it would be great if it could stay as the PS3 is a rather
widely used platform although you certainly won't find any PS3
users on the LKML.

Adrian

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel