openfirmware question

Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

openfirmware question

Peter J. Philipp-3
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?

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.

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: openfirmware question

Mark Kettenis
> Date: Wed, 20 Jan 2021 14:12:07 +0100
> From: "Peter J. Philipp" <[hidden email]>
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: openfirmware question

Peter J. Philipp-3
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" <[hidden email]>
> >
> > 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 :-).

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: openfirmware question

Mark Kettenis
> Date: Wed, 20 Jan 2021 15:11:38 +0100
> From: "Peter J. Philipp" <[hidden email]>
>
> 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" <[hidden email]>
> > >
> > > 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.