Jochen Kunz wrote:
> On Sat, 06 Oct 2007 12:37:22 +0100
> Matt Sealey <matt@genesi-usa.com> wrote:
> 
>> too much "we must poke the hardware directly".
> Seconded. When available NetBSD should use the firmware functions.
> 
>> If you use
>> the device-tree to probe PCI and the RTAS functions to access PCI
>> configuration space, you needn't deal with the host controller at all.
 >
> You don't even need RTAS for this. You can proble the devices by walking
> the device tree. Configuration space is accessible by the "config-l@"
> and "config-l!" methods of the PCI device node. This are the
> pci_conf_read(9) and pci_conf_write(9) functions I wrote for RS/6000.
> They worked on the Pegasos too when Jorge tested my hacks.

They should, but they might be a little unreliable. It's also a bit of
a jaunt into the client interface (far more heavy than an RTAS function)
to read PCI configuration space.

The only reason to use Firmware over RTAS is when you need to specify
a domain - each pci node in the device tree knows implicity which
PCI domain it belongs to. RTAS has no domain support (but the Genesi
firmware implementation knows what you are trying to do, since it
implicitly knows where you are poking around in the address space
and which device it has attached to the single-device-bus-fake-AGP
on Pegasos)

Since you *require* RTAS for RTC, reliable poweroff/reboot, it's
worth implementing, and you may as well use RTAS as your config
space interface as this would be the very start of supporting the
IBM hypervisor (NetBSD on a JS21? It could happen...)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations