Hi, I realise it's three months later, but I just wanted to give an update where I am. In fact not very far, I had to redo most of the OFW routines to convert them to FDT in ofwboot64, and now it's a little bit better. I have also changed my email address in the meantime and gotten rid of my old website so if you wanted to see progress there is only one place now that I put in place today:
https://github.com/pbug44/openbsd There in the macppc64 branch is all the stuff I have done. I'm hoping in the next month I'll get something printed on my monitor, if not then I have until the end of the year. Best Regards, -peter On 1/20/21 7:36 PM, Mark Kettenis wrote: >> Date: Wed, 20 Jan 2021 15:11:38 +0100 >> From: "Peter J. Philipp" <p...@centroid.eu> >> >> On Wed, Jan 20, 2021 at 02:57:19PM +0100, Mark Kettenis wrote: >>>> Date: Wed, 20 Jan 2021 14:12:07 +0100 >>>> From: "Peter J. Philipp" <p...@centroid.eu> >>>> >>>> Hi list, >>>> >>>> Last year I set out for a year to port G5 to 64-bit and I started this year >>>> with converting OFW to FDT. Yesterday was my first day back at this, and I >>>> made some results happen. In fact walking Openfirmware and adding it to >>>> the >>>> FDT (Mark hinted to me the arm64 fdt.{c,h} which was brilliant) does create >>>> a nice DTB that I think I can work with. Only there is one problem... >>>> >>>> As I walk the properties in OFW and insert them in FDT the order is >>>> reversed. >>>> I don't know if that will cause any conversion problems with drivers, I had >>>> a glance at /sys/arch/macppc/dev/zs.c and that doesn't care the order of >>>> it, >>>> but something in me says that name property should always come first, am I >>>> mistaken in this? >>> The order shouldn't be important. We can probably adjust the code to >>> in fdt.c to add properies in the "right" order. >>> >>>> Anyhow I tried loading the powerpc64 kernel to the loader but it still >>>> blows >>>> up before dmesg, I didn't luck out. I'll have to port the powerpc64 to >>>> the >>>> macppc64 stuff and compile a kernel. I think I'll have to do something >>>> about the slb's anyhow as those are not supported in the 970 processor. >>> The PowerPC 970 processor has 64 SLBs. The OpenBSD/powerpc64 kernel >>> uses 32 SLBs, so this should all work. >>> >>> The kernel expects to be starting with the SF and HV bits set and the >>> DR and IR bits cleared in the MSR register. So your bootloader will >>> have to switch to that mode. >>> >>> You'll need some sort of early console. That is currently only >>> implemented for OPAL firmware. Given that these machines don't have a >>> usable serial port, you'll probably need to implement a framebuffer >>> console. Since OpenFirmware already initializes the framebuffer that >>> shouldn't be too difficult. You could take a look at how arm64 uses >>> dev/fdt/simplefb.c to set this up. >>> >>> Cheers, >>> >>> Mark >> Awesome, thanks Mark! I know what to do then :-). I'll work tomorrow at >> sharing the code that I've made so far you'll be able to find it best when >> checking https://centroid.eu/ppc occasionally. I also am working off a >> tree from december I'll have to merge a -current tree in to this. It seems >> there is enough work to do for a month anyhow :-). > So to help you a bit further, a useful debugging technique is to > memset() some framebuffer memory. 0xff should give you a white block > and 0x00 should give you a black block. At the start of > init_powernv() you should be able to write to the framebuffer using > physical address of the framebuffer. This should work up until the > point where the MMU is turned on. > > You should be able to find out the physical address of the framebuffer > from the device tree. On a PowerMac11,2 for example there is a > "NVDA,Display-A" node that has a > > address: 90020000 > > property. That means the framebuffer is at physical address > 0x90020000. There are some additional properties that describe the > layout of the framebuffer: > > width: 00000500 > height: 00000400 > depth: 00000008 > linebytes: 00000600 > > which indicates that each pixel is 8 bits and each horizontal line is > 1536 bytes. So if you memset a multiple of that you should clearly > see it. >
