Subject: Re: Things to work on
To: David Brownlee , <Richard.Earnshaw@arm.com>
From: Chris Gilbert <chris@paradox.demon.co.uk>
List: port-arm
Date: 05/24/2001 22:34:47
On Thursday 24 May 2001 12:50 pm, David Brownlee wrote:
> On Thu, 24 May 2001, Richard Earnshaw wrote:
> > > On Thu, 24 May 2001, Richard Earnshaw wrote:
> > > > > Make it SMP safe (hard to test, but we should be in case someone
> > > > > ever does an SMP based arm box)
> > > >
> > > > Somewhat pointless at this time, particularly if it will impact
> > > > performance.  Until the models for cache coherency on SMP ARM systems
> > > > are defined it isn't really sensible to consider this (IMO).
> > >
> > > 	We may be able to obtain a bunch of hydra boards, complete with
> > > 	schematics and details of the  changes to make them work with
> > > 	StrongARM CPUs. On a 16Mhz memory bus a fully loaded hydra is..
> > > 	uh, a decidedly mismatched beast, but for two or three CPUs it
> > > 	should give a boost.
> >
> > Hmm, muses.... a hydra with 3 kinnetics...  OK, so they wouldn't be very
> > symmetric.
>
> 	You _should_ be able to get up to five CPUs in the box. Visions of
> 	using the kinetic ram for R/O pages and switching any page that
> 	becomes dirty and has a mapping on more than one CPU to the base
> 	RAM... Bookkeeping nightmare and you would want a very strong
> 	process to CPU affinity :)

Sadly kinetic's won't fit the card, they're too wide, the hydra has a 
daughter board along the right hand side (looking from the front) next to the 
extra processor slots, and a Hard disk power socket next to the main 
processor and PC card slots.

The daughter board provides interrupt routing and the ability to send 
interrupts from one processor to the next.  This is how you do the inter 
processor comms.

There's also has an extra socket for extra memory on the hydra board, 
although the memory board doesn't exist, (it was designed, but never made)  
IE they did a kinetic alike thing way back then.  Gareth used it for watching 
the bus traffic :)

> > > 	Do we have anywhere a brief document that gives an overview
> > > 	of what a NetBSD pmap should provide, how it should be structured
> > > 	to best handle various cache and MMU models, and specific areas
> > > 	to watch out for? (As opposed to the current method for various
> > > 	ports which is 'look at the latest i386 or alpha pmap' :)
> >
> > In -current you can "man 9 pmap", other than that there is only "Design
> > and implementation of the BSD 4.4 OS", but that's getting away from
> > NetBSD these days since it doesn't cover UVM or all the other recent
> > changes (it's still good background though).
>
> 	<sound of a laser printer powering up in the background>
> 	Thanks.

Yep, read the UVM doc once, need to re-read to find the details that are 
important :)

Cheers,
Chris