FreeBSD booted multiuser on USIII
Pyun YongHyeon
pyunyh at gmail.com
Wed Dec 21 18:31:13 PST 2005
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
More information about the freebsd-sparc64
mailing list