Hi,
  Ok just to let folks know how the RiscBSD StrongARM Development is going ...

Bootloader

Ok I have a new version of the bootloader that will be part of the 1.2-release
this is StrongARM compatible.

Unixfs

I now have a StrongARM compatible version of this as well, also part of the
1.2-release.

User binaries

These should not be affected. This only thing that has had problems is Xarm-21
Upgrading to Xarm-24 solved this. The reason for the problem is not known as I
need to discuss that with Rob.

Kernel

Last week I reported having a kernel that ran with the instruction cache and
write buffer but not the data cache. Things have improved but are not perfect..
I can now run fine with the instruction and data cache but no write buffer.
I can run fine with i+d cache and write buffer as long as the kernel
stack is uncached and unbuffered.
i.e. running everything as I would like sooner or later I get a panic.
Currently this panic appear to occur within the console code ...

Performance ...

dhrystones and mflops show expected speed ups, dhrystones is significantly
affected but the write buffer. CUrrently disabling the caching of the kernel
stack kills FPE performance.
The write buffer also significantly affects the speed of the console drawing.
However it doe not make much different to the drawing under X.

Having to clean the dcache on every context switch and also when making
significant changes to pte's etc does hit performance. Although user binaries
run faster there is a big penelty for lots of I/O etc.

The biggest killer is in cpuswitch ... Currently the cache clean (takes up to
0.5ms I beleive) has to be done with interrupts disabled as following the clean
I need to flush the cache when I reload the TTB (since the cache uses virtual
addresses) This means that once I start the cache clean I cannot allow
interrupts that will generate dirty cache entries as the data for these entries
would be lost at the end of the clean when I flush the cache.

I can see ways round this the problem of having to have interrupts disabled but
that requires a lot more coding.

The immediate priority to to debug why having the kernel stack cached when the
write buffer is turned on (whether or not the kernel stack is actually
buffered)
Once that is solved I will start looking at fixing the performance losses due
to the cache design. A number of the performance hits can be fixed by rewrite
chunks of the pmap code etc...

Needless to say I have to do this in the next two weeks before AW96 along
with the 1.2-release & CDROM, and all the other things for AW96 not forgetting
my real work ;-(

Cheers,
				Mark

-- 
Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716