Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Dec 2005 11:30:20 +0900
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        freebsd-sparc64@freebsd.org
Subject:   Re: FreeBSD booted multiuser on USIII
Message-ID:  <20051222023020.GA1106@rndsoft.co.kr>
In-Reply-To: <20051206160540.L75892@newtrinity.zeist.de>
References:  <20051205202342.B88929@newtrinity.zeist.de> <20051206011240.GA5298@rndsoft.co.kr> <20051206160540.L75892@newtrinity.zeist.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 06, 2005 at 04:05:40PM +0100, Marius Strobl wrote:
 > 
 > On Tue, Dec 06, 2005 at 10:12:40AM +0900, Pyun YongHyeon wrote:
 > > 

[...]
 > 
 > > It seems most cirtical devices are recognized and works.
 > > What else should be done to make it work on UIII?
 > > 
 > 
 > - Finish rototilling nexus(4) to remove the assumption that
 >   the nexus bus reflects an UPA bus, make it manage the
 >   resources of its children and convert to use the ofw_bus
 >   interface (to simplify things for creator(4) as the UPA
 >   bus in USIII machines is a subordinate bus and not the
 >   interconnection bus, will also help with fhc(4)). Finish
 >   schizo(4) (mainly locking of the interrupt handlers is
 >   missing, this is more important for schizo(4) than in
 >   psycho(4)), some nits left to be shaked out but also
 >   yet have to make sure it also works with the Tomatillo
 >   bridges (code in place, just untested).
 > - Properly support the USIII{,i} MMUs. This is mainly meant
 >   to be factored out into cheetah.c which is fleshed out
 >   somewhat but pmap.c, tlb.c, loader(8), etc. also need to
 >   be reviewed to do the right thing for the USIII{,i} MMUs.
 >   There also seem to be some general problems here like the
 >   infamous "vmspace NULL" panic which I can readily provoke
 >   on USIII (but not on < USIII as others can; haven't looked
 >   at that). USIII{,i} also seem to require flushes, membars,
 >   etc. in situations where < USIII; we'll also have to
 >   review quite some MD code regarding this.
 > - Write USIII versions of the VIS-optimized bcopy() and
 >   bzero(). The spitfire versions just don't work on USIII
 >   and I've just disabled them on >= USIII for now.
 > - For USIII MP support teach FreeBSD that a MP system can
 >   consist of different CPU models (running at different
 >   speed and having different cache sizes). For the MD part
 >   this is quite straight foward (switch to use the system-
 >   tick counters instead of the tick counters, make the
 >   cache info per CPU). I haven't looked at MI assuptions
 >   in this reagard so far.
 > - USIIIi (and probably onwards; I think USIV is merely
 >   dual-core USIIIi) is NUMA-like. I have no idea how this
 >   comes in. We might just ignore it at first and then use
 >   it for optimizations later (as it's currently the case
 >   with AMD64) but then again Gavin Atkinson reported that
 >   he gets strange panics early when booting FreeBSD as is
 >   on dual-USIIIi unless he removes the memory associated
 >   with the second CPU. I've really no idea here so far.
 > - Some other MD bus and device drivers need some tweaking
 >   here and there but all in all no big deal. For USIIIi
 >   we'll however need a bge(4) working on sparc64 as at
 >   least some USIIIi machines have bge(4) NICs on-board.

I just committed bge(4) patch to HEAD. It was tested on U60 and it
seems to work well.  Any chance to give it spin?

 >   For the Blade xx00 workstations we also definitely
 >   want a driver for controlling the fans, otherwise they
 >   run full speed all the time and are plain to loud for
 >   actually using them as a workstation. Unfortunately Sun
 >   seems to use different hardware for this in the various
 >   models; for USII{,e,i} models alone I'm aware of at least
 >   three different approaches but there are probably more
 >   just there. On the other hand all these temperature and
 >   fan controllers are at least all connected via some smb(4)
 >   hardware or PCF8584. We'd however probably need to find
 >   a way to incorporated info from the OFW device tree
 >   into the respective existing bus drivers and properly
 >   lock the whole stuff.
 > 
 > That's about what I currently am aware of and can think of.
 > 
 > Marius
 > 
 > -- 
 > This mail was scanned by AntiVir Milter.
 > This product is licensed for non-commercial use.
 > See www.antivir.de for details.

-- 
Regards,
Pyun YongHyeon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051222023020.GA1106>