From owner-freebsd-sparc64@FreeBSD.ORG Tue Dec 6 15:05:48 2005 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E69516A41F for ; Tue, 6 Dec 2005 15:05:48 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (newtrinity.zeist.de [217.24.217.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id B17F143D60 for ; Tue, 6 Dec 2005 15:05:47 +0000 (GMT) (envelope-from marius@newtrinity.zeist.de) Received: from newtrinity.zeist.de (localhost [127.0.0.1]) by newtrinity.zeist.de (8.12.11/8.12.11/ZEIST.DE) with ESMTP id jB6F5kZg016213; Tue, 6 Dec 2005 16:05:46 +0100 (CET) (envelope-from marius@newtrinity.zeist.de) Received: (from marius@localhost) by newtrinity.zeist.de (8.12.11/8.12.10/Submit) id jB6F5em4016212; Tue, 6 Dec 2005 16:05:40 +0100 (CET) (envelope-from marius) Date: Tue, 6 Dec 2005 16:05:40 +0100 From: Marius Strobl To: Pyun YongHyeon Message-ID: <20051206160540.L75892@newtrinity.zeist.de> References: <20051205202342.B88929@newtrinity.zeist.de> <20051206011240.GA5298@rndsoft.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20051206011240.GA5298@rndsoft.co.kr>; from pyunyh@gmail.com on Tue, Dec 06, 2005 at 10:12:40AM +0900 X-AntiVirus-modified: yes X-AntiVirus: checked by AntiVir Milter (version: 1.1.1-9; AVE: 6.32.1.63; VDF: 6.32.1.10; host: newtrinity.zeist.de) Cc: freebsd-sparc64@freebsd.org Subject: Re: FreeBSD booted multiuser on USIII X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2005 15:05:48 -0000 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.