| Message ID | 20201218184347.2180772-1-sam@ravnborg.org |
|---|---|
| Headers | show |
| Series | sparc32: sunset sun4m and sun4d | expand |
On Fri, Dec 18, 2020 at 7:43 PM Sam Ravnborg <sam@ravnborg.org> 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
On 18/12/2020, Sam Ravnborg <sam@ravnborg.org> 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
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
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
Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg <sam@ravnborg.org> 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 :-) <https://github.com/rdolbeau/SBusFPGA> (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,
Hi Romain, Sam, On Sun, Dec 20, 2020 at 6:46 PM Romain Dolbeau <romain@dolbeau.org> wrote: > > Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg <sam@ravnborg.org> 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 :-) > <https://github.com/rdolbeau/SBusFPGA> > (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,
Le dim. 20 déc. 2020 à 09:54, Julian Calaby <julian.calaby@gmail.com> 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 (<http://www.codesrc.com/mediawiki/index.php/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. <https://github.com/rdolbeau/SunTurboGX>, 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,
Hi Romain, On Sun, Dec 20, 2020 at 8:26 PM Romain Dolbeau <romain@dolbeau.org> wrote: > > Le dim. 20 déc. 2020 à 09:54, Julian Calaby <julian.calaby@gmail.com> 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 (<http://www.codesrc.com/mediawiki/index.php/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. I'd forgotten about that. Fair point =) > > 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. > <https://github.com/rdolbeau/SunTurboGX>, again blowing my > own horn here sorry...). Yeah, my issue is that I have no CRTs anymore - all my monitors are LCDs and none of them sync to the frequencies SUNs use. So yeah, you can make adapters (i have home-made adapters to convert both ways) however out of the 4 monitors I own with VGA ports, none of them sync to Sun frequencies. > > (...) 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. That's almost exactly what I was planning to do, but I'd still be lacking a Linux distro to run. > > 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 :-( Same. IIRC there's some ancient versions that have the bits to netboot a SparcStation so you can then do the necessary stuff to install the minimal binaries and stuff, at which point you can do the various configurations, pull in the latest portage tree and emerge world, however the last time I tried this, the disk I was using - my last one - failed somewhere in the middle of that process. > > 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. My distcc plan was to have it talk to a cross compiler on my x86 desktop. I never got to the point where it would have actually used 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. > > 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. QEMU is somewhat slow and never _exactly_ the same as real hardware, so I can see why distros might not use it as a build machine or whatever. And if they do build for QEMU and it doesn't work on real hardware, then we have a distro that's only for virtual hardware and that seems pointless. You're right that with the right bits and pieces resurrecting a Sparc32 machine is relatively "easy", however there's still no modern distros supporting this ancient hardware so the upstream kernel has most likely bitrotted. I still don't think it's worth saving. Thanks,
From: Julian Calaby > Sent: 20 December 2020 08:55 > > On Sun, Dec 20, 2020 at 6:46 PM Romain Dolbeau <romain@dolbeau.org> wrote: > > > > Le sam. 19 déc. 2020 à 22:41, Sam Ravnborg <sam@ravnborg.org> 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. The advantage of netbsd is that the build gives you a kernel and userspace from the same source tree and it is designed to cross build. Even the compilers get built - so all you need is a native compiler that will compile the (probably slightly older) version of gcc. This used to be problematic because gcc sources tended to use gcc-only features (which have been deprecated). The userspace will also be a lot less bloated than a typical Linux, but more complete than the 'busybox' tools often used on small/embedded Linux systems. > > 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. I trashed the PSU on my sun3 trying to get netboot to work. The main problem seemed to be that the switching fet wasn't actually rated for 240v input! (needs to be a 400v device). I never did get around to connecting an ATX psu up to the connector. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
From Experience... The best way to go about Gentoo for 32bit sparcs is in a chroot on a faster 64bit Sparc system, you could probably also run a faster than realtime QEMU but that's a bit more of a hassle if you have fast Sun hardware. Last time I did this was on a T2000, I have been meaning to retrace my steps on a T4. I did run into a bug with portage or python... it would be nice to fix that so those could be used on Slower systems. I'd also like at some point to compile a list of software in the vein of suckless.org (perhaps a bit less masochistic though), that is usable on old machines, the one I really want to dogfood is pcb-rnd and corelEDA on a sparcstation to see how well it could compete with KiCad. Weird thing about the LCDs not syncing... all the LCDs I have that are 1280x1024 or greater work. The problem is that sometimes the default resolution also has a sync rate of a few hz higher than some LCDs can handle, most of my LCDs are older higher end models (1600x1200 etc...) so also happen to support those rates. You can get most commodity LCDs to sync by choosing a display mode via serial port that plays nice with standard VGA resolutions and rates.
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(-)