Fwd: Time to let sun4m + sun4d RIP?

Fwd: Time to let sun4m + sun4d RIP?

[Kjetil Oftedal]

On 19 April 2014 16:55, Alan Perry <alanp@snowmoose.com> wrote:
>
>
>
> > So the question to you guys...
> > Shall we keep support for sun4d and sun4m?
> > If yes then why?
>
> I collect Sun lunchbox systems and also have an Axil SS20 clone.  I start up the lunchbox systems once a year to make sure they haven't died and regularly run the Axil. One of the lunchbox systems is running some Linux distro that I don't recall (it could be something old on a sun4c).
>
> Number one problem keeping them running long term is the NVRAM battery (I have added external batteries to the chips in almost all of them). Replacement SCSI HDDs are now a problem to source locally; I couldn't get any from the computer recycler last year. I can still get them on eBay.
>
> alan
>

Hi,

I do not see why support for sun4m and sun4d should actively be
dropped. I have contributed to
the sparc32/sun4d port because I still have such a system that is in
working order.
(Along with several other sparc32/sparc64-variants)

I have struggled with running Linux on architectures that are not
supported by the mainline
Linux kernel any more. And backporting features/bugfixes from never
kernels becomes quite hard
after a while.

Is there currently some technical difficulties that prevents us for
keeping the status quo? Or
is this just a suggestion for the sake of suggestions ?

Regards,
Kjetil Oftedal
(Resend to the mailinglist: html was inserted into the email by the webmail)

Re: Fwd: Time to let sun4m + sun4d RIP?

[Sam Ravnborg]

> 
> Is there currently some technical difficulties that prevents us for
> keeping the status quo? Or
> is this just a suggestion for the sake of suggestions ?

sun4m + sun4d is a significant part of the sparc32 architecture.
Some quick hacking revealed the following numbers:
> 16 files changed, 28 insertions(+), 2958 deletions(-)

There are more to come after if we go this route.

The stuff I have on the todo list for sparc32 are (in no particular order):
- Fix to we map memory correct durign startup.
  We need to find a way so we map memory such that we
  do not hit the current limitation where things goes wrong
  after the kernel becomes slightly too big.
- introduce memblock (i have something halfway done, but it fails due to the
  memory mapping problem. And it did not support highmem)
- use proper of_ function for floppy
- analyze what can be shared with sparc64, there seems to be more
  shareable code than what we have today. Especially during startup.
- cpu_data.counter is used to display number of NMI interrupts in arch_show_interrupt
  - this is plain wrong. We do not have any NMI counter on sparc32
- make more sparc drivers buildable on x86 - to get better build coverage
- address some of the sparse generated warnings - try to get down to 100 for arch/sparc/
- get qemu running to ease testing (not kernel related)

And there are probarly more when I start surfing the code again.

The above becomes easier when there are less code to
understand, change and eventuelly test.

	Sam

Re: Fwd: Time to let sun4m + sun4d RIP?

[Sam Ravnborg]

Hi Kjetill.
 
> I have contributed to
> the sparc32/sun4d port because I still have such a system that is in
> working order.
And your effort is highly apprecated!
I am especially glad that you repaired sun4d after I introduced
genirq support - but all the other patches and your testing has also
been very welcome.

	Sam