On Sat, 28 Oct 2000, Dave Daniels wrote:
> In article <00102810200401.00754@pinky>,
> Chris Gilbert <chris@buzzbee.freeserve.co.uk> wrote:

[snip kinetic bits]

> Size=131072  size=4096
>          4 blocks of DRAM found
>          1 block of VRAM found
>          2 blocks of ROM found
> Dynamic RAM:
> 10000000 4096 pages
> 18000000 4096 pages
> 20400000 7168 pages
> 30000000 8192 pages
> 23552 pages found
>
> So the memory addresses and the page counts are wrong. It looks as
> if the physical memory is arranged in 28K byte blocks with 4K byte
> intervals between them, but this is nonsense as this is the layout
> of the physical, hardware memory.
>
> We could detect the fault but working around it would not really
> be feasible as the memory addresses returned are wrong.

Fair enough, the PC card requires it and it's freely available on the web.

Looking at it, that output clearly shows where the kinetic ram is (the last 2 
blocks, (it's also correct that one of them is smaller, the first 4 MB are 
used for loading risc os into ram))  I think given this info that writing 
something to split out the 2 types of ram so that the high stuff is not used 
in DMA etc should be pheasible, other ports have different ram types.  I may 
investigate this at some point (but I also need to figure out why having the 
ram in my computer makes the console screen go funny (cured when I remove one 
of my simms, but the kernel panics in pmap).

Note that I do not believe I'm saying anything not already known. (I say this 
to cover my own bottom as I have spoken with castles tech dir about the 
kinetic...)

Do you have that program anywhere, it might be useful for whoever takes on 
the riscstation port.

> > It's the default in !BtRiscBSD, as there are a few bits that may
> > need looking  at with BtRiscBSD it might be a case of changing the
> > default string...
>
> Hmm... Methings I should have read the original message more
> carefully. I agree that changing the default in !BtRiscBSD would
> be the way to go.

Perhaps make it pull in the screen res from the current mode?

> [gzip'ed kernels...]
>
> > It would be an useful feature to add (the reason being that the
> > real kernels on the CD I did were gzipped, the install ones weren't,
> > and the ones that are downloaded are normally gzipped as well.)
>
> And as I seem to be the unofficial bootloader maintainer...

Aha, is that a volunteer in our midst :)

Cheers,
Chris