All of lore.kernel.org
 help / color / mirror / Atom feed
From: Meelis Roos <mroos@linux.ee>
To: sparclinux@vger.kernel.org
Subject: Adding support for Fujitsu SPARC64 machines?
Date: Wed, 07 Jan 2015 22:55:08 +0000	[thread overview]
Message-ID: <alpine.LRH.2.11.1501080029010.18104@math.ut.ee> (raw)

I am playing with the idea of adding support for SPARC64 V and VI CPUs 
for sparclinux (actually maybe supervising a master student doing it).

Before we take it on, I would like to understand what needs to be done, 
what are the hard points and what are the risks. Below is my current 
understanding - please correct me where I am wrong. Also, if someone 
else might have some knowledge or docs that could help, please do tell.

* CPU support - 
http://www.fujitsu.com/global/products/computing/servers/unix/sparc-enterprise/downloads/documents/ 
has a bunch of developer docs for newer SPARC64 CPUs. Seems to be 
detailed enough for just the CPU.

* Machine support - I have PrimePower 250, 450, 650 and Sparc Enterprise 
M4000 available. Of them, 450 and M4000 have XSCF with full remote 
management with power and reset control, PP650 does not have it, and I 
do not know about PP250. M4000 is more complex so maybe PPP450 would 
be the best for start?

* PCI I/O - Solaris tells there is pcicmu0 at root: SAFARI 0x8 0x4000 
and px1 at root: SAFARI 0x1 0x700000 in the M4000. Am I correct if I
think support for this bridge needs to be implemented? There are some 
references to Safari in linux/arch/sparc/kernel code but Illumos seems 
to have more complex code.

(prtconf -pv sent to DaveM for prtconfs repo)

* Are there any other devices that need support? Console device at the 
least, maybe something else? Storage and network seem to be normal 
PCI.

* Is there any hypervisor protocol for talking to scf firmware from 
domains? scf management protocol is probably not too important for start 
since it should not be needed for boot/runtime support.

* Are there any devices know to have no documentation that would keep us 
from doing it?

* OpenBSD guys had a problem with some specific invalid hardware access 
causing fault in xscf firmware that needed to be cleared by service 
engineer, assuming there is a service contract. My Fujitsus are in my 
museum so there is no service contract. Has anyone heard if the current 
firmwares are more reliable? I'm running the latest on M4000 and 
whatever came with the PrimePowers.

*

-- 
Meelis Roos (mroos@linux.ee)

             reply	other threads:[~2015-01-07 22:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 22:55 Meelis Roos [this message]
2015-01-12 20:53 ` Adding support for Fujitsu SPARC64 machines? David Miller
2015-01-12 21:48 ` Mark Kettenis
2015-01-12 22:07 ` David Miller
2015-01-12 22:11 ` David Miller
2015-05-17 13:26 ` Xose Vazquez Perez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LRH.2.11.1501080029010.18104@math.ut.ee \
    --to=mroos@linux.ee \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.