FreeBSD booted multiuser on USIII
Marius Strobl
marius at alchemy.franken.de
Tue Dec 6 07:05:48 PST 2005
On Tue, Dec 06, 2005 at 10:12:40AM +0900, Pyun YongHyeon wrote:
>
> On Mon, Dec 05, 2005 at 08:23:42PM +0100, Marius Strobl wrote:
> >
> >
> > FYI, I managed to boot FreeBSD multiuser on a Blade 1000 via NFS.
> > For those interested a log is at:
> > http://alchemy.franken.de/~marius/xcb.txt
> > But don't get too excited yet, this currently is everything but
> > stable and quite some work still needs to be done in order to
> > get support for USIII and up en par with USI/II{,e,i} in FreeBSD.
> > Currently I'm also not exactly pursuing USIII support in FreeBSD,
> > so far this is more or less research in order to get a clue what
> > needs to be done.
> >
>
> Cool! I have to buy UIII system from eBay in near future. :-)
Not necessarily, for FreeBSD/sparc64 development there is a
Fire V210 (USIIIi) at the "FreeBSD befarm" in .nl. Currently
it's a bit tricky to access as there's a cable missing for
the terminal server. Dwhite also got a Fire 280R (USIII, same
motherboard as Blade 1000 use) that he plans to set up for
remote access.
For now I'd suggest to use these resources until it's clear
that FreeBSD can and will support USIII{,i} (I think it's
at least feasible but then again there's quite some stuff
left to be done).
> 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.
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.
More information about the freebsd-sparc64
mailing list