[posted to port-macppc on 2006-07-08] The past couple of weeks I've been using Sanjay Lal's preliminary PowerPC 970 patches to run -current on my dual 2.0 G5 PowerMac. I can directly boot his modified INSTALL kernel without a bootloader both over the network and from an internal hard disk. Console I/O must be done over a serial line, and there is no native support for the onboard SATA controller yet. I've been trying to add display/keyboard console support, with little success. The problem lies in the fact that 64-bit PowerPC chips do not include the Block Address Translation (BAT) facility. Open Firmware requires that the memory region mapped to the display framebuffer be marked as cache-inhibited, so that updates are written directly to video RAM. The BAT mechanism was used on earlier PowerPC chips to accomplish this, by mapping the VRAM's physical addresses to virtual memory and setting the I (cache inhibited) and G (guarded) flags on the corresponding block table entries. The only way to do this on the G5 is to use Segment Address Translation. This entails bringing up the entire pmap interface. This is fine later in the boot process, but since we want to _debug_ pmap and other machine-dependent initializations very early in the kernel boot sequence, before address translation is enabled, we're out of luck. To try to tackle this issue, I first switched from the ofb console device to ofcons, which is a more low-level interface with less overhead. I find the address and size of the framebuffer with Open Firmware's 'frame-buffer-adr' method and 'screen' package properties, respectively. As a temporary measure, Allen Briggs suggested that I manually flush the data cache of the entire framebuffer with a loop of dcbf instructions. While this is grossly inefficient and should eventually be replaced by a better solution, it does the job, and I've gotten console output between the start of initppc() and the uvm_page_physload() call within pmap_bootstrap(). After this point, however, pmap_bootstrap() starts to load the 16 segment registers with a loop of mtsrin instructions. Console output stops upon the first load. I don't understand what effect this should have: Address translation has not yet been enabled in the kernel when this happens, and the Open Firmware client interface routines load up their own segment registers anyway. My only guess was that the addresses that I pass to dcbf, which I got from Open Firmware (and are hence virtual addresses in OFW's context, supposedly), somehow become invalid after the mtsrin. But if address translation is off in the kernel the whole time through, how can that be? I took a copy of the openfirmware() assembly routine [1] and modified it to call dcbf instead, so that the cache flush occurs in the context of Open Firmware. This produces a very strange result: After the first character appears on screen, the string "Sttttttttttttttt" is displayed, and nothing else happens. (I've posted the routine at [2] if anyone would like to check it over for correctness; I would certainly appreciate it.) It may seem overly optimistic to expect stuff to work while pmap is still half-hatched, but I see no reason why this particular operation in Open Firmware, which supposedly preserves and restores the MMU state, shouldn't operate properly. This adds to my existing suspicion that the OFW client interface is not implemented correctly, or at least not on the G5. Although it works well enough while the kernel's address translation is off, it will still not work even after pmap is fully brought up. The key, I believe, lies in the lack of an OFW callback routine. The PowerPC OFW binding specs [3] state that when the client operating system brings up its address translation mechanism and starts modifying the MMU state, it must provide a callback routine in order to continue using OFW services. It seems strange to me that the kernel has been working correctly on older PPC machines without a callback installed, but I believe that one is necessary in order to work on the G5. Then again, I'm no expert, so I welcome your thoughts. I would really appreciate any insights or advice that you can give me on these issues. Thank you, Yevgeny Binder References [1] - see powerpc/oea/ofw_subr.S [2] - http://netbsd-soc.sourceforge.net/projects/ppcg5/docs/ofw_subr.S.20060708 line 230 (ofw_flush_cache_range) [3] - http://playground.sun.com/1275/bindings/ppc/release/ppc-2_1.html