On 04/27/10 20:53, Michael wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Apr 27, 2010, at 8:38 PM, Nathan Whitehorn wrote:On 04/27/10 19:21, Michael wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, On Apr 27, 2010, at 6:01 PM, Dennis Ferguson wrote:On 27 Apr 2010, at 13:10 , Chris Ross wrote:On Apr 27, 2010, at 15:27, Michael wrote:On Apr 27, 2010, at 2:58 PM, Chris Ross wrote:I have a quad-core Power Mac G5 that I'm thinking about pushing into a server-class machine in the closet at some point over the next year. But, for now, it's still my primary desktop machine. So, I have two main questions:1) Does NetBSD/macppc run (well?) on this hardware?No.Okay. Well, then that's clearly more important to address first. :-)What doesn't work well? Does it work at all?It worked at one point but the code seems to be bit-rotted; I had tofix problems in two files just to get a G5 kernel to compile. I managed to get to an ofwboot prompt, but it kept complaining about an (unspecified) I/O error trying to read the kernel off the HFS disk. I left it at that point; I'll next try to boot it diskless when I have some time to spendon it.Actually it gets much further - it hangs when enabling the MMU and so far I couldn't figure out why. Also, there's conflicting information out there about BATs being emulated in bridge mode ( most docs say nothing or no yet OpenBSD happily uses them anyway )Also, there is no support for the PCIe bridge in last generation G5s.On the 970, all BAT instructions are no-ops. You can run them without triggering a program exception, but they don't do anything.Ah, ok. As it is macppc relies on BAT mapping PCI space 1:1.
Yeah, this is a pain. If you use the actual SLB management instructions instead of the segment register bridge stuff, you can try to fake it with large pages, but otherwise there's a lot of churn.
Is there any work being done on getting this hardware [fully] supported in the macppc NetBSD port?I don't think anyone could be running this code at all (in a recent kernel) since if they were I'd expect not to get compilation errors when trying to build a -current kernel. I don't know about missing hardware support (I can't see any indication that the G5's disk controller is missing support, for what that's worth), but its current problems are more fundamental thanthat in any case.You can compile a 32bit G5 kernel ( or at lease I could not too long ago ) - they don't reach userland however. 'Real' 64bit kernel hit an #error elsewhere, somewhere in OF support IIRC. Otherwise, we have a more or less generic SATA driver, no clue if that's enough for the G5.When I was doing the FreeBSD port to these, I ran into two issues with SATA, which is otherwise a generic Serverworks/Broadcom SATA chip. First, you need to issue a 4-byte read to the ATA status word to actually have it updated, and second, you need to make sure the interrupt is edge triggered, not level triggered, or you end up with an interrupt storm.Eww, I though PCI devices used level triggered interrupts by definition. Otherwise, it's one bit flipped in OpenPIC.
Right. I think it's a fake PCI device, and it uses the same kind of message signaling and pulse generator combination as the HT and MSI interrupts do in the CPC 945. But it's nothing a little bit of #ifdef can't fix :)
-Nathan