FreeBSD booted multiuser on USIII

Marius Strobl marius at
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:
>  >
>  > 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.


This mail was scanned by AntiVir Milter.
This product is licensed for non-commercial use.
See for details.

More information about the freebsd-sparc64 mailing list