> 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.
