>Malhereusement, cette page n'existe pas. :-(

Sorry for the typo, it's actually:

http://calvaweb.calvacom.fr/bh40/test.html

>Also, is there any advantage to going through RTAS when you can access the
>chip directly?

Yes: That chip (Uni-N) is weird. It contains 3 PCI busses: one is the
AGP, one is external and can be 66MHz on some machines, and the third one
is internal for the built-in ethernet and firewire controllers (Note that
the Uni-N built-in ethernet is currently only used on the iBook, they
still have an external 21143 on other machines, but this will change and
the internal FireWire is never used for now).
The problem is that those 3 PCIs have the same bus number (0), the device
numbers don't overlap, so they should be treated as one single bus. But
they have 3 different io ranges and config space bases. It's a bit
difficult, from a PCI bus/devfn to know which config space registers use
to generate config cycles. Fortunately, the i/o range is only needed for
the external bus, so there is no real problem here, only a potential one.
Using RTAS for config accesses would be a lot simpler ;)

>Cool. That might explain one problem I ran into. On my Blue G3, I can't
>"halt" (drop back into OF), only "reboot". I assume that if OF gets
>returned to after a quiesce, it knows that the mappings might have been
>modified?

OF cannot be called at all (and certainly not returned) after a quiesce.
The purpose of this call is solely to stop HW devices that may be
bus-mastering to memory (and consequently damage the kernel itself or
anything that the kernel puts in memory until it takes over the chips).
Basically, the OF code for this method (see do-quiesce) will call a list
of OF functions that are registered by the drivers themselves when they
are opened.

The fact that dropping back to OF doesn't work well is a known problem:
OF was not designed to allow a client program to return. The "exit"
command works (but you have to unmap everything you map'ed or claim'ed,
"release" will not unmap) if you want to be able to relaunch your program.
I've never been able to boot the MacOS ROM image after booting my OF
bootloader and returning back to OF. The ROM dies with a claim failed.