Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Rick Leir]

I have some sparcstations too, and would like to be able to use them, but 
honestly it's unlikely that I ever will. What's more, a modern linux experience 
is not possible due to limited RAM and disk. Not to mention the problem of 
keeping the hardware working. 

The main Debian master has a KISS problem, we would do better to keep it simple 
stupid. I don't mean to insult anyone with this, maybe the phrase doesn't 
translate well. please don't take offense. Maybe the problem is all in my head. 
To keep it simple we should reduce the number of target architectures and maybe 
remove all but 64 bit.

For 32 bit Sparc we should freeze functionality, but keep fixing bugs. How can 
we choose the most reliable debian version as the basis for a bug fix branch?
Imho
Cheers
Rick

On December 20, 2020 11:07:08 a.m. EST, Stan Johnson  wrote:
>I also have a couple of SPARCstation 5 systems that I'd like to be able
>to keep using.
>
>-Stan Johnson
>
>On 12/19/20 2:57 PM, John Paul Adrian Glaubitz wrote:
>> On 12/19/20 10:40 PM, Sam Ravnborg wrote:
>>> Please keep the inputs coming independent if you are pro or not
>>> for the sunset of sun4m and sun4d.
>> I would personally be in favor of keeping it and I should finally get
>> my SPARCstation 5 up and running again.
>>
>> Adrian
>>

-- 
Sorry for being brief. Alternate email is rickleir at yahoo dot com 

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Romain Dolbeau]

Le dim. 20 déc. 2020 à 09:54, Julian Calaby  a écrit :
> If I want to run them, assuming the hardware still works, I need to
> netboot them as I cannot find working, compatible HDDs for them as
> everything has switched to SATA or SAS.

SCSI2SD ()
are a bit expensive, but solve that problem (I own both a V5 and a V6,
both work well in my SPARCstations, tried sun4c and sun4m).
As it takes micro-sd cards, it's quite easy to keep multiple OSes
on hand.

> Then there's the issue of finding a monitor as they're not
> electrically compatible with VGA

Huh? There is Sun's 13W3-to-vga adapters and cables, and many
monitors will sync to Sun's frequency (though not the most recent
LCDs whose analog circuitry is pathetic compared to old-school
CRTs). Some framebuffers will output 1280x1024 (rarer than for
1152x900), and some can be coerced to do almost anything with
some Forth knowledge (see e.g.
, again blowing my
own horn here sorry...).

> (...) booting one up for fun is simply impractical

An SCSI2SD and either a null-modem serial cable or a
Sun keyboard/13w3 cable/17"LCD combo and you're good to
go. You might need another unix-like box to netboot the system.

> I believe that Gentoo is architecture-neutral enough that it'd work,
> but I believe that you'll have to compile everything - there'll be no
> pre-built anything for sparc32

Trying gentoo is on my todo list... has been for a long time :-(

> and as it's fairly slow hardware by
> today's standards, that's going to take a long time, however you could
> probably use distcc and cross-compilers to speed it up.

Isn't that what Qemu is for ? :-) I've managed to recompile LLVM
and clang in NetBSD 9 for my SS20, one by cross-compiling
(LLVM requires too much memory), the other in QEmu.
Unfortunately, Qemu doesn't yet support mt-tcg (multithreaded
emulation) for sparc so single-core only - still faster than the HW,
mostly because of incomparably faster I/O.

> If there were more people using it or more testing, or more distros
> supporting it - not just (theoretically?) working on it - then I'd be
> fighting to keep it.

I wish I had some arguments for that point... I will just re-mention Qemu,
as it makes testing quite easy and reasonably not-too-slow.

Cordially,

-- 
Romain Dolbeau

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Julian Calaby]

Hi Romain, Sam,

On Sun, Dec 20, 2020 at 6:46 PM Romain Dolbeau  wrote:
>
> Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg  a écrit :
> > Another said that it would be a shame to sunset sun4m and sun4d because
> > there are so many machines around, and netbsd is also active on the
> > sparc32 area.
>
> Yes, those were plentiful back in the day and there's still quite a few 
> around.

I have three: two SparcStation 10s and a SparcStation LX.

If I want to run them, assuming the hardware still works, I need to
netboot them as I cannot find working, compatible HDDs for them as
everything has switched to SATA or SAS.

Then there's the issue of finding a monitor as they're not
electrically compatible with VGA and I'm pretty sure none of the VGA
compatible monitors I have or can lay hands on works with their
specific sync frequencies.

Ultimately it's one of those things where there's enough "stuff" in
the way that booting one up for fun is simply impractical and they're
old and slow enough that they're not useful for anything else.

Then we get to the not-so-significant issue of software...

> > The second mail also re-reminded me of an interesting project
> > implementing SPARC V8 and the sun4m platform in VHDL.
>
> There's also new hardware being developed for SBus systems :-)
> 
> (disclaimer: work-in-progress and shameless self-promotion here!).

Interesting project!

Amusingly enough you're not the first to hook an FPGA up to sBus. I
had a card that was some form of high-speed sampling thing which was
effectively some electrically isolated front-end hooked to a Xylinx
FPGA. I ended up trashing it as it had no markings and I couldn't find
out anything about it.

> If there's still a distribution willing to build for Sparc v8, then I
> believe the kernel
> should try to keep support of the relevant machine architectures if at all
> possible...

And here's where the problem lies. The last (official) version of
Debian to support Sparc32 was Etch and I believe it was one of the
last ones to drop support.

I believe that Gentoo is architecture-neutral enough that it'd work,
but I believe that you'll have to compile everything - there'll be no
pre-built anything for sparc32 - and as it's fairly slow hardware by
today's standards, that's going to take a long time, however you could
probably use distcc and cross-compilers to speed it up.

Long painful story short, it's difficult to get the hardware running,
there's practically no Linux distros that support it, and the kernel
code has probably bitrotted due to lack of testing.

As much as it pains me to say this, I think this code's time has come
and it's time to get rid of it.

If there were more people using it or more testing, or more distros
supporting it - not just (theoretically?) working on it - then I'd be
fighting to keep it.

But there isn't.

I think it's time for it to go.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

On Sun, Dec 20, 2020 at 6:46 PM Romain Dolbeau  wrote:
>
> Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg  a écrit :
> > Another said that it would be a shame to sunset sun4m and sun4d because
> > there are so many machines around, and netbsd is also active on the
> > sparc32 area.
>
> Yes, those were plentiful back in the day and there's still quite a few 
> around.
>
> > The second mail also re-reminded me of an interesting project
> > implementing SPARC V8 and the sun4m platform in VHDL.
>
> There's also new hardware being developed for SBus systems :-)
> 
> (disclaimer: work-in-progress and shameless self-promotion here!).
>
> If there's still a distribution willing to build for Sparc v8, then I
> believe the kernel
> should try to keep support of the relevant machine architectures if at all
> possible...
>
> Cordially,
>
> --
> Romain Dolbeau



-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Romain Dolbeau]

Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg  a écrit :
> Another said that it would be a shame to sunset sun4m and sun4d because
> there are so many machines around, and netbsd is also active on the
> sparc32 area.

Yes, those were plentiful back in the day and there's still quite a few around.

> The second mail also re-reminded me of an interesting project
> implementing SPARC V8 and the sun4m platform in VHDL.

There's also new hardware being developed for SBus systems :-)

(disclaimer: work-in-progress and shameless self-promotion here!).

If there's still a distribution willing to build for Sparc v8, then I
believe the kernel
should try to keep support of the relevant machine architectures if at all
possible...

Cordially,

-- 
Romain Dolbeau

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[John Paul Adrian Glaubitz]

On 12/19/20 10:40 PM, Sam Ravnborg wrote:
> Please keep the inputs coming independent if you are pro or not
> for the sunset of sun4m and sun4d.

I would personally be in favor of keeping it and I should finally get
my SPARCstation 5 up and running again.

Adrian

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

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Sam Ravnborg]

Hi all,

On Fri, Dec 18, 2020 at 07:43:34PM +0100, Sam Ravnborg wrote:
> The sun4m and sun4d based SPARC machines was very popular in the
> 90'ties and was then replaced by the more powerful sparc64
> class of machines.

I have received a couple of mails in private.
One said it was better to sunset now when it is actually working,
so there is a working state to return to.
Another said that it would be a shame to sunset sun4m and sun4d because
there are so many machines around, and netbsd is also active on the
sparc32 area.


The second mail also re-reminded me of an interesting project
implementing SPARC V8 and the sun4m platform in VHDL.
See https://temlib.org - the author posted a new blog post a
few months ago.

temlib is, to my best knowledge, an impressive one-man project.
And this is not enough to keep sun4m around as this would
require real users that cannot just stay at their current kernel
but who need to follow upstream.

Please keep the inputs coming independent if you are pro or not
for the sunset of sun4m and sun4d.

Sam

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Kjetil Oftedal]

On 18/12/2020, Sam Ravnborg  wrote:
> The sun4m and sun4d based SPARC machines was very popular in the
> 90'ties and was then replaced by the more powerful sparc64
> class of machines.
> Today there is only Gentoo that to my best knowledge supports
> sparc32 and people have moved on to more capable HW.
>
> Cobham Gaisler have variants of the LEON processer that
> runs sparc32 - and they are in production today.
>
> With this patchset I propose to sunset sun4m and sun4d and move
> focus to a more streamlined support for LEON.
>
> One downside is that qemu supports sun4m - and we may loose
> some testing possibilities when sun4m is dropped. qemu supports
> LEON to some degree - I have not yet tried it out.
>
> Andreas from Gaisler have indicated that they may be more active
> upstream on sparc32 - and this will only be easier with a kernel
> where the legacy stuff is dropped.
>

This makes me a bit sad. But I guess I haven't had any time to put
into the sparc32 port
for many years, so I guess it is time to let go.

But I do believe that by doing this we should make sure we are not
putting ourselves
in a position where the sparc kernel-developers don't have access to
any real sparc32
hardware.

SUN machines were at least plentiful. The LEON-family of processors
being targeted
towards the rad-hardened market are not so much available.

Maybe Gaisler can contribute some systems, or make some available remotely?

Best regards,
Kjetil Oftedal

Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Arnd Bergmann]

On Fri, Dec 18, 2020 at 7:43 PM Sam Ravnborg  wrote:
>
> The sun4m and sun4d based SPARC machines was very popular in the
> 90'ties and was then replaced by the more powerful sparc64
> class of machines.
> Today there is only Gentoo that to my best knowledge supports
> sparc32 and people have moved on to more capable HW.
>
> Cobham Gaisler have variants of the LEON processer that
> runs sparc32 - and they are in production today.
>
> With this patchset I propose to sunset sun4m and sun4d and move
> focus to a more streamlined support for LEON.
>
> One downside is that qemu supports sun4m - and we may loose
> some testing possibilities when sun4m is dropped. qemu supports
> LEON to some degree - I have not yet tried it out.
>
> Andreas from Gaisler have indicated that they may be more active
> upstream on sparc32 - and this will only be easier with a kernel
> where the legacy stuff is dropped.
>
> I decided to divide up the patches to make it possible to review
> the set as some of the patches touches assembler and these parts
> could use some extra eyes if we move forward with this.
>
> For now it builds with the configurations I have tried.

Thank you for doing this, it looks like a very nice cleanup.

> Looking forward for feedback if sunsetting is a good idea or not.

I have no insight on whether there are any users left that would miss
it, but I'm fairly sure that there are lots of people that would rather
see it gone.

> Note: I dunno why git does not see floppy_64.h=>floppy.h as a rename??

It doesn't do that if the old name existed already.

Arnd

[RFC PATCH 0/13] sparc32: sunset sun4m and sun4d

[Sam Ravnborg]

The sun4m and sun4d based SPARC machines was very popular in the
90'ties and was then replaced by the more powerful sparc64
class of machines.
Today there is only Gentoo that to my best knowledge supports
sparc32 and people have moved on to more capable HW.

Cobham Gaisler have variants of the LEON processer that
runs sparc32 - and they are in production today.

With this patchset I propose to sunset sun4m and sun4d and move
focus to a more streamlined support for LEON.

One downside is that qemu supports sun4m - and we may loose
some testing possibilities when sun4m is dropped. qemu supports
LEON to some degree - I have not yet tried it out.

Andreas from Gaisler have indicated that they may be more active
upstream on sparc32 - and this will only be easier with a kernel
where the legacy stuff is dropped.

I decided to divide up the patches to make it possible to review
the set as some of the patches touches assembler and these parts
could use some extra eyes if we move forward with this.

For now it builds with the configurations I have tried.

Looking forward for feedback if sunsetting is a good idea or not.

Sam

Sam Ravnborg (13):
  sparc32: Drop sun4m/sun4d support from head_32.S
  sparc32: Drop floppy support
  sparc32: Drop sun4m specific led driver
  sparc32: Drop auxio support
  sparc32: Drop run-time patching of ipi trap
  sparc32: Drop patching of interrupt vector
  sparc32: Drop sun4m/sun4d specific irq handling
  sparc32: Drop sun4d/sun4m smp support
  sparc32: Drop pcic support
  sparc32: Drop mbus support
  sparc32: Drop unused mmu models
  sparc32: drop check for sparc_model
  sparc32: drop use of sparc_config

Note: I dunno why git does not see floppy_64.h=>floppy.h as a rename??

 arch/sparc/Kconfig  |  16 +-
 arch/sparc/include/asm/auxio_32.h   |  73 +---
 arch/sparc/include/asm/cpu_type.h   |  18 -
 arch/sparc/include/asm/elf_32.h |   2 -
 arch/sparc/include/asm/floppy.h | 786 -
 arch/sparc/include/asm/floppy_32.h  | 393 -
 arch/sparc/include/asm/floppy_64.h  | 779 -
 arch/sparc/include/asm/io_32.h  |   4 +-
 arch/sparc/include/asm/irq_32.h |   1 -
 arch/sparc/include/asm/mbus.h   |  97 -
 arch/sparc/include/asm/mxcc.h   | 138 --
 arch/sparc/include/asm/pcic.h   | 130 --
 arch/sparc/include/asm/pgtable_32.h |  24 -
 arch/sparc/include/asm/ross.h   | 192 
 arch/sparc/include/asm/swift.h  | 107 -
 arch/sparc/include/asm/timer_32.h   |   1 +
 arch/sparc/include/asm/tsunami.h|  65 ---
 arch/sparc/include/asm/viking.h | 255 ---
 arch/sparc/kernel/Makefile  |   8 +-
 arch/sparc/kernel/apc.c |  14 -
 arch/sparc/kernel/auxio_32.c| 140 --
 arch/sparc/kernel/cpu.c |   1 -
 arch/sparc/kernel/devices.c |  10 +-
 arch/sparc/kernel/entry.S   | 354 +--
 arch/sparc/kernel/head_32.S | 190 +---
 arch/sparc/kernel/ioport.c  |   6 +-
 arch/sparc/kernel/irq.h |  35 +-
 arch/sparc/kernel/irq_32.c  | 127 +-
 arch/sparc/kernel/kernel.h  |  28 --
 arch/sparc/kernel/led.c | 146 ---
 arch/sparc/kernel/leon_kernel.c |  43 +-
 arch/sparc/kernel/leon_pmc.c|  14 +-
 arch/sparc/kernel/leon_smp.c|   3 -
 arch/sparc/kernel/of_device_32.c|   4 +-
 arch/sparc/kernel/pcic.c| 841 
 arch/sparc/kernel/pmc.c |  10 -
 arch/sparc/kernel/process_32.c  |  10 -
 arch/sparc/kernel/setup_32.c|  80 +---
 arch/sparc/kernel/smp_32.c  | 102 +
 arch/sparc/kernel/sun4d_irq.c   | 519 --
 arch/sparc/kernel/sun4d_smp.c   | 413 --
 arch/sparc/kernel/sun4m_irq.c   | 240 --
 arch/sparc/kernel/sun4m_smp.c   | 273 
 arch/sparc/kernel/time_32.c | 114 +++--
 arch/sparc/kernel/ttable_32.S   |   9 +-
 arch/sparc/mm/Makefile  |   1 -
 arch/sparc/mm/hypersparc.S  | 414 --
 arch/sparc/mm/io-unit.c |   3 -
 arch/sparc/mm/iommu.c   |  49 +--
 arch/sparc/mm/mm_32.h   |   1 -
 arch/sparc/mm/srmmu.c   | 834 +--
 arch/sparc/mm/swift.S   | 256 ---
 arch/sparc/mm/tsunami.S | 132 --
 arch/sparc/mm/viking.S  | 284 
 arch/sparc/prom/misc_32.c   |   2 -
 55 files changed, 905 insertions(+), 7886 deletions(-)