Subject: mapping XPRAM in OF
To: None <port-macppc@netbsd.org>
From: Mark Abene <phiber@phiber.com>
List: port-macppc
Date: 11/12/2003 19:44:46
Greetings all.  I have an old Beige G3 Rev 2 which many of us know is fairly
useless if not extremely unreliable at booting IDE hard drives.  That aside,
I've been playing with the "Startup Disk" control panel in MacOS 9, setting
the startup disk to different available devices and partitions, and dumping
out /dev/nvram in yellowdog (which I have on another partition) and comparing
the contents.  It was fairly easy to deduce how it was storing devices and
partition numbers, and changing these bytes in /dev/nvram and rebooting was
a valid test that it was working as expected (boot-device set to /AAPL,ROM in
all cases).  I submit the idea that on these machines with screwed up IDE
support that we could use the Apple ROM itself (default boot device) to boot
a small HFS partition with yaboot or ofwboot, etc.  This is especially useful
in situations where we're sharing a drive with MacOS, and NetBSD or Linux is
not at partition zero (OF 2.4 even with System Disk patches doesn't seem able
to seek very reliably into a drive without hanging the whole OF environment).
In theory, it should be possible to write a simple forth script in OF to
modify the proper bytes indexed into the NVRAM starting from offset 0x1300
(where XPRAM lives), and present this as a simple, fun-loving menu.

The problem is that XPRAM doesn't seem to be memory mapped by OF 2.4 on 
startup (even looking at the .properties of the /pram device shows that it
has no address property, and its only other properties are zero).
So my question is, can anyone think of or suggest a way in OF to map the
(not visible) physical address of parameter RAM into virtual address space
so that we can play with it?  There must be phys-to-virt functions in OF
already to faciliate this, I just don't know what they are.  I *think* the
physical address we want to map-in is 0xfff11300.  At least kernel cruft I've
seen indicates the use of page 0xfff1.  OF memory-mapping wisdom would be
most welcome.

Cheers,
-Mark

P.S.: OF COURSE I'm writing this to the NetBSD list because you folks would
be much more knowledgeable about hardware matters than any other list I could
think of...