Anybody interested in porting NetBSD to the Sun OpenSparc T1 architecture?

Hello all!

Is there anyone out there who might be interested in porting NetBSD
to the Sun OpenSparc T1 architecture?   This is a very interesting
chip: It has 8 cores with 4 hardware threads per core, plus some other
interesting tricks up its sleeve...

Getting this to work would be a big step forward for the Sparc64 port
and SMP on NetBSD in general.

If you are interested, you have the necessary know-how and some
spare time please contact me off-list.

Note that there's both Linux and FreeBSD people working on this so
we wouldn't be all alone. 

Thanks -- Volker
--

-- 
------------------------------------------------------------------------
Volker A. Brandt                  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH              WWW: http://www.bb-c.de/~vab/
Meckenheim, Germany                                   Email: vab <at> bb-c.de

Re: Anybody interested in porting NetBSD to the Sun OpenSparc T1 architecture?

Volker A. Brandt wrote:
> Is there anyone out there who might be interested in porting NetBSD
> to the Sun OpenSparc T1 architecture?   This is a very interesting
> chip: It has 8 cores with 4 hardware threads per core, plus some other
> interesting tricks up its sleeve...

It's also available with less cores.

> Getting this to work would be a big step forward for the Sparc64 port
> and SMP on NetBSD in general.

Hmm, I'm not sure how much the T1 resembles III and IV, but it would be 
a good thing if those were supported as well. As well as SMP on sparc64, 
ofcourse. But given the fact that support for those is currently 
lacking, I'm not sure how soon it'll surface?

Cheers,
--

-- 
         Thomas E. Spanjaard
         tgen <at> netphreax.net

Re: Anybody interested in porting NetBSD to the Sun OpenSparc T1 architecture?

[I've kept just port-sparc64 and dropped tech-kern.]

> > Is there anyone out there who might be interested in porting NetBSD
> > to the Sun OpenSparc T1 architecture?   This is a very interesting
> > chip: It has 8 cores with 4 hardware threads per core, plus some other
> > interesting tricks up its sleeve...
>
> It's also available with less cores.

Yes.  But it's an 8 core design; the 4 and 6 core versions are
just to increase manufacturing yield.  There is a T2 in the works,
but we should stick to what's real now.

> > Getting this to work would be a big step forward for the Sparc64 port
> > and SMP on NetBSD in general.
>
> Hmm, I'm not sure how much the T1 resembles III and IV, but it would be
> a good thing if those were supported as well. As well as SMP on sparc64,
> ofcourse. But given the fact that support for those is currently
> lacking, I'm not sure how soon it'll surface?

I have no idea how soon.  The chip is binary-compatible to sparcv9,
but there are some differences under the hood.  The platform is
called "sun4v" (as opposed to "sun4u), and there is a hypervisor
layer "below" the OpenSparc cores.

The difference is that for USIII and USIV, not all documentation
is available.  For the T1, there is...

Regards -- Volker

Re: Anybody interested in porting NetBSD to the Sun OpenSparc T1 architecture?

Volker A. Brandt wrote:
> [I've kept just port-sparc64 and dropped tech-kern.]

I'm not on that list; please CC me replies.

>>>Getting this to work would be a big step forward for the Sparc64 port
>>>and SMP on NetBSD in general.
>>Hmm, I'm not sure how much the T1 resembles III and IV, but it would be
>>a good thing if those were supported as well. As well as SMP on sparc64,
>>ofcourse. But given the fact that support for those is currently
>>lacking, I'm not sure how soon it'll surface?
> I have no idea how soon.  The chip is binary-compatible to sparcv9,
> but there are some differences under the hood.  The platform is
> called "sun4v" (as opposed to "sun4u), and there is a hypervisor
> layer "below" the OpenSparc cores.

'Sources' say it's sooner than I was thinking initially ;).

> The difference is that for USIII and USIV, not all documentation
> is available.  For the T1, there is...

OpenSolaris can function as hardware reference.

Cheers,
--

-- 
         Thomas E. Spanjaard
         tgen <at> netphreax.net

Re: Anybody interested in porting NetBSD to the Sun OpenSparc T1 architecture?

Thomas E. Spanjaard wrote:
> Volker A. Brandt wrote:

> >The difference is that for USIII and USIV, not all documentation
> >is available.  For the T1, there is...
> 
> OpenSolaris can function as hardware reference.

If I remember correctly, you cannot even build OpenSolaris for SPARC.
There are missing pieces of source code for SPARC but I do not know
whether this affects USIII and USIV or only other pieces of hardware.

ciao
     Klaus

openafs on netbsd/sparc64?

HEADS UP: Flag day when switching to gcc4

As you probably heard already, we soon will switch over to gcc 4.1.

This means, unfortunatley a flag day for sparc64, since a few corner
cases in the sparc64 ABI have been fixed in gcc. See:
http://gcc.gnu.org/gcc-3.4/sparc-abi.html.

The base system seems to be mostly fine, i.e. no problems have been reported
mixing in-tree libs (and shared libs) compiled with gcc 3.3 and binaries
compiled with gcc 4.1. But there has been no audit for the cases documented
in the above URL, so no guarantees.

The recommended update procedure is: after upgrading the base system to 
gcc 4.1, recompile every installed pkg from pkgsrc.

Martin

Sun OpenSparc T1 port followup

(I deleted the original message about porting to the OpenSparc T1.)

As a point of information, the FreeBSD web site has a claim
that FreeBSD 7.x (where x=some branch inside of perforce, not
yet merged to -current) is self-hosting on a OpenSparc T1:

	http://www.freebsd.org/news/newsflash.html#event20060521:01

With the dmesg from a boot here:

	http://www.fsmware.com/sun4v/dmesg_latest.txt

-Kurt

Re: openafs on netbsd/sparc64?

On Mon, Jun 05, 2006 at 11:20:47AM -0400, Sean Caron wrote:
> hello all!
> 
> i am trying to get some kind of distributed computing environment up and
> running on my network which runs entirely on
> sun sparc and ultrasparc systems using netbsd/3.0. i'm mucking around with
> both coda and afs, jumping between the
> two when i feel like putting more effort into one or the other. right now,
> i've got coda to build right but it doesnt work quite
> right, so i'm back looking at afs momentarily.
> 
> now, there have been reports [1] that openafs can be made to run on netbsd
> as a server, and you can use arla as a client.

I'm doing it here.  (I have met both of the authors of that presentation,
and have regular contact with one.)

> great. so i go to download the pkgsrc and -- of course -- it is only
> available for the i386 architecture. ugh. now, my question
> is:
> 
> ** if it is known that openafs can run on netbsd [1]
> 
> ** and it is also known that openafs can run on big-endian architectures
> like SPARC (running solaris) [2]
> 
> ** is there some reason why openafs would not run on netbsd/sparc and/or
> netbsd/sparc64?

Because OpenAFS is missing a param file that defines various
things about a specific platform.  (in openafs's src/config directory)
Once someone pieces one together (and tells autoconf about it and
various other things) it should work.

There are already param files for

alpha 1.5 and 6

i386 1.5-3.0

ppc 1.6 and 2.0

> 
> ** were there any tweaks needed to get openafs to build on netbsd?

See above.

Once I tried getting OpenAFS to compile on macppc 3.0 by trying to hack
the build system, suffice it to say I gave up and got another i386 box.

> 
> i find it hard to believe that whoever did the port got it to build right
> out of the box, but yet there is no pkgsrc-SRC available on
> netbsd that we might actually try to use to build on different architectures
> -- just binaries -- and i have found nothing besides [1]
> that indicates that netbsd could run afs and what sort of tweaks would be
> required to get it to build.
> 
> has anyone tried this before? if so, could you furnish any pointers as to
> what i'd need to do to build it? i tried to do it once in the
> past, just trying to hack it up whenever the compiler ran into an error, and
> i didn't really get very far. i'm not planning on spending
> a lot of time mucking with it further when i can get coda to at least build
> -- which is more than i can say for afs -- but i just thought
> i'd ask.
> 
> thanks in advance,
> 
> sean caron
> scaron <at> umich.edu
> scaron <at> diablonet.net
> 
> [1]
> http://www.public.iastate.edu/~kula/talks/afs-bpw-2005/afs-bpw-2005-iowa.html
> 
> [2] http://www.openafs.org/release/openafs-1.4.1.html

Just some more thoughts:

Getting arlad to be useably stable on sparc64 took some time, but, it's
now known that compiling it with -O0 is the shortcut to get around the
anomalies associated with gcc compiling arla.

OpenBSD has s/arla/afs/ in their base system, however, they don't care
about it working on their various lesser-used platforms (this
from personal experience with a bug report about s/arlad/afsd/
on OpenBSD/hppa 3.9)

You might also try arla's experimental server.

In short, feel lucky that this stuff at least works on NetBSD/i386.

Tracy is the maintainer of the openafs package for NetBSD,
and there are people in Ames who would be willing to loan her
a sparc64 box to do a port.  It's just not terribly important
to the 2 other people I know who have considered running OpenAFS
on NetBSD/sparc64, especially considering it Just Works on i386.

	Jonathan Kollasch

Re: openafs on netbsd/sparc64?

To add a bit to what Jonathan said:

On Tue, Jun 06, 2006 at 06:22:33PM -0500, Jonathan A. Kollasch wrote:
> On Mon, Jun 05, 2006 at 11:20:47AM -0400, Sean Caron wrote:

> > ** if it is known that openafs can run on netbsd [1]
> > 
> > ** and it is also known that openafs can run on big-endian architectures
> > like SPARC (running solaris) [2]
> > 
> > ** is there some reason why openafs would not run on netbsd/sparc and/or
> > netbsd/sparc64?

I can't see why the OpenAFS server components would not work, someone
just needs to, like Jonathan said, fill in enough param files and make
glue so that it builds. I looked at trying it once, stared at it for
about a half hour, then got distracted by something shiny. I'd like it
to work, but have enough other boxes that Just Work as AFS servers
that it never gets high on the priority list.

Now, the OpenAFS *client* components are a whole other matter, since 
those require kernel module stuff. It apparently used to work with 
NetBSD (or so I've heard), but does not now, for any arch. Looking at 
that makes my head want to explode, so I never try it for long. I'd 
love to see it happen, though, enough to bribe people with offers of
cookies if they make it so.

As noted in pr pkg/33354 changing the CFLAGS with which arla is compiled 
seems to make it more stable on the sparc64. It probably needs more 
testing/investigation to find out why.

My talk is a bit outdated --- I'm using the OpenAFS in pkgsrc for all of
my AFS servers, with just a few tweeks to make it and arla co-exist (see
pr pkg/33399). Other than that, I don't do anything special. Updating
this talk and developing it into a better guide has been on the Project
List for a while, but I never seem to get around to it.

In summary:

 - OpenAFS server would probably be easy, someone just needs to do it
 - OpenAFS client is hard, I'll make you cookies if you make it work on
   NetBSD
 - Arla probably needs some attention on sparc64 machines
 - My talk is a bit outdated and I'm lazy

On a side note, I will be at the 2006 AFS and Kerberos Best Practices 
Workshop [1] in Ann Arbor next week and would love to chat with any
people interested in AFS and NetBSD in the area.

[1] http://www.pmw.org/afsbpw06/

--

-- 
Thomas L. Kula | kula <at> tproa.net | http://kula.tproa.net/
Mathom House upon the Canw, The People's Republic of Ames