powerpc64 backport to g5

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

powerpc64 backport to g5

Peter J. Philipp-3
Hi,

Now that POWER9 systems are pretty well supported, I'm setting away some time
next year to backport powerpc64 to the Mac G5.  Is there anyone already doing
that?  I already tried this once (based on the macppc sources) but failed.
I don't want to throw the little that I learned out the window.  I'm giving
myself more time next year than my last attempt.  Right now I'm dreaming big,
but I'll need to awake to do some work on this.  I'll likely start in
January or February with compiling on G5 macppc arch and testing on amd64 under
qemu.  Please don't give me any kudos until I share something that works. :-)

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

marco
Hello Peter,

Je 11 Dec 17:24 skribis Peter:
> Now that POWER9 systems are pretty well supported, I'm setting away some time
> next year to backport powerpc64 to the Mac G5.  Is there anyone already doing
> that?  I already tried this once (based on the macppc sources) but failed.

I'm not doing that.  I am simply running OpenBSD/macppc on the iMac G5.
Graphics (X11 rendering) is a bit slow but acceptable to me after a bit
of tweaking [1].

What would be specific advantages if OpenBSD/powerpc64 (over macppc)
were backported to PowerPC 970?

Marco

[1]: http://daemonforums.org/showthread.php?t=9971

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Peter J. Philipp-3
On Sat, Dec 12, 2020 at 11:06:33AM +0100, Marco van Hulten wrote:

> Hello Peter,
>
> Je 11 Dec 17:24 skribis Peter:
> > Now that POWER9 systems are pretty well supported, I'm setting away some time
> > next year to backport powerpc64 to the Mac G5.  Is there anyone already doing
> > that?  I already tried this once (based on the macppc sources) but failed.
>
> I'm not doing that.  I am simply running OpenBSD/macppc on the iMac G5.
> Graphics (X11 rendering) is a bit slow but acceptable to me after a bit
> of tweaking [1].
>
> What would be specific advantages if OpenBSD/powerpc64 (over macppc)
> were backported to PowerPC 970?

For me it's using my G5 (970FX cpu) without 2 GB limitation.  My machine has
4 GB of RAM but OpenBSD/macppc only supports max. 2 GB.  

Another thing is it interests me very much, as a personal achievement, to know
how to port an OS to another platform.  I've sat in the background with the
riscv64 team and learned quite a bit on how they do that.  I also attempted
this before (alone) purchased some powerpc books, invested a lot of time,
trying to do this port, which failed.  I miss the exploring part.

A lot of things are already done, in the powerpc64 port, I read a little
for a bit how OpenBSD did the SLB implementation in pmap.c.  I compared it a
little with mine that I constructed from FreeBSD's in 2018 and there is a bit
of difference but the functions are very similar.  Compare:

pmap_va2vsid() in pmap.c
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc64/powerpc64/pmap.c?rev=1.54&content-type=text/plain

with FreeBSD's or my port:
va_to_vsid() in slb.c
https://gotweb.centroid.eu/cgi-bin/gotweb/gotweb?path=powerpc64.git&action=blob&commit=ec46d233f79ed298dde271748a49523aea1522ca&file=slb.c&folder=%2Fpowerpc64

The similarities take me back to a time when I organised putting these functions
into my slb.c back when.  I forgot right now what SLB stands for exactly but
it replaced the BAT functions from 32-bit PowerPC which had to do with memory
management and caching.  I'll look it up on monday when I am back home.  Side
Lookup Buffer popped into my head afterwards writing this mail.

I noticed there may be room to speed these up on the powerpc64 arch as the
virtual to physical mappings (PTE) are a LIST.  I took my implementation from
FreeBSD original implementation which used a TREE, which could make lookups
faster if you pass it a virtual address to get a physical address.  But I
understand that it's easy to get this wrong so a LIST is likely better than
a TREE for robustness.  Also FreeBSD I believe put its SPLAY tree
implementation into a radix tree or something if I remember correctly (I
could be wrong here).

In no way do I want to start arguing about this.  I'm very much a student to
Mark Kettenis's teachings (and BSD's teachings too).  Granted having said
this I invite corrections above.

So having said a lot of "how" and not a lot of "why", another point is I want
to make use of my hardware to the fullest, a POWER9 machine is expensive and
I won't likely have one for another 2 or 3 years, by which time a POWER10
machine will likely exist, and I have time for one more hobby project outside
of my job (within reason), starting in 2021. :-)

Best Regards,
-peter

> Marco
>
> [1]: http://daemonforums.org/showthread.php?t=9971

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

marco
Je 12 Dec 11:59 skribis Peter:

> On Sat, Dec 12, 2020 at 11:06:33AM +0100, Marco van Hulten wrote:
> > Hello Peter,
> >
> > Je 11 Dec 17:24 skribis Peter:  
> > > Now that POWER9 systems are pretty well supported, I'm setting away some time
> > > next year to backport powerpc64 to the Mac G5.  Is there anyone already doing
> > > that?  I already tried this once (based on the macppc sources) but failed.  
> >
> > [...]
> > What would be specific advantages if OpenBSD/powerpc64 (over macppc)
> > were backported to PowerPC 970?  
>
> For me it's using my G5 (970FX cpu) without 2 GB limitation.  My machine has
> 4 GB of RAM but OpenBSD/macppc only supports max. 2 GB.  

This is good to know, especially as I had been looking for extra memory
for up to 4 GiB which I thought was the limit for 32-bit systems.  I did
not know until now that this is different for PowerPC or the specific
macppc port.  Please, correct me if I misinterpret.

I suppose a true 64-bit OpenBSD version for the G5 could also perform
better in general?

> Another thing is it interests me very much, as a personal achievement, to know
> how to port an OS to another platform.  I've sat in the background with the
> riscv64 team and learned quite a bit on how they do that.  I also attempted
> this before (alone) purchased some powerpc books, invested a lot of time,
> trying to do this port, which failed.  I miss the exploring part.
>
> A lot of things are already done, in the powerpc64 port, I read a little
> for a bit how OpenBSD did the SLB implementation in pmap.c.  I compared it a
> little with mine that I constructed from FreeBSD's in 2018 and there is a bit
> of difference but the functions are very similar.  Compare:
>
> pmap_va2vsid() in pmap.c
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc64/powerpc64/pmap.c?rev=1.54&content-type=text/plain
>
> with FreeBSD's or my port:
> va_to_vsid() in slb.c
> https://gotweb.centroid.eu/cgi-bin/gotweb/gotweb?path=powerpc64.git&action=blob&commit=ec46d233f79ed298dde271748a49523aea1522ca&file=slb.c&folder=%2Fpowerpc64
>
> The similarities take me back to a time when I organised putting these functions
> into my slb.c back when.  I forgot right now what SLB stands for exactly but
> it replaced the BAT functions from 32-bit PowerPC which had to do with memory
> management and caching.  I'll look it up on monday when I am back home.  Side
> Lookup Buffer popped into my head afterwards writing this mail.
>
> I noticed there may be room to speed these up on the powerpc64 arch as the
> virtual to physical mappings (PTE) are a LIST.  I took my implementation from
> FreeBSD original implementation which used a TREE, which could make lookups
> faster if you pass it a virtual address to get a physical address.  But I
> understand that it's easy to get this wrong so a LIST is likely better than
> a TREE for robustness.  Also FreeBSD I believe put its SPLAY tree
> implementation into a radix tree or something if I remember correctly (I
> could be wrong here).
>
> In no way do I want to start arguing about this.  I'm very much a student to
> Mark Kettenis's teachings (and BSD's teachings too).  Granted having said
> this I invite corrections above.

From me you won't get technical feedback on this.  I was only curious
(from a user's perspective) and don't have the technical background to
argue about these efforts.  If I'd be saying anything, I'd encourage
this effort! :-)

> So having said a lot of "how" and not a lot of "why", another point is I want
> to make use of my hardware to the fullest, a POWER9 machine is expensive and
> I won't likely have one for another 2 or 3 years, by which time a POWER10
> machine will likely exist, and I have time for one more hobby project outside
> of my job (within reason), starting in 2021. :-)

This makes sense to me.

Marco

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Rino Rondan

publicKey - rrondan@itrestauracion.com.ar - 2d1b9a57.asc (4K) Download Attachment
signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Peter J. Philipp-3
Hi Rino,

I'm starting to develop in january or february and I'm giving myself a year
roughly.  Either it won't work, or it will work (if it won't two strikes on me).
It won't be official OpenBSD port, that's up to the OpenBSD organisation to
decide if it is worthy.  Ask again in a year :-).

Best Regards,
-peter

On Sat, Dec 12, 2020 at 11:55:24AM +0000, Rino Rondan wrote:
>    <div>Hi, I was trying to use openbsd in iMac and Powermac &nbsp;g5 three years ago , I had a lot of issues with disk so I was moved to g4 where everything works so nice , I???m using Mac mini g4 for everything!! My brother wrote this post regarding his experience&nbsp;https://rebelion.digital/2020/12/11/como-transformar-tu-vieja-mac-mini-g4-en-un-server-p2p/ .</div><div>Also I want to know how to use golang in g4 because it is not supported . But I???m happy your are doing a good job so I can start again testing in g5 , are your tested job &nbsp;in the main stable macppc version ?</div><div><br></div><div>Regards&nbsp;</div><div>Rino<caret></caret></div><div><br></div><div id="protonmail_mobile_signature_block"><div>Sent from ProtonMail Mobile</div></div> <div><br></div><div><br></div>On Sat, Dec 12, 2020 at 12:43, Marco van Hulten &lt;<a href="mailto:[hidden email]" class="">[hidden email]</a>&gt; wrote:<blockquote class="protonmail_quote" type="cite">  Je 12 Dec 11:59 skribis Peter:<br>&gt; On Sat, Dec 12, 2020 at 11:06:33AM +0100, Marco van Hulten wrote:<br>&gt; &gt; Hello Peter,<br>&gt; &gt;<br>&gt; &gt; Je 11 Dec 17:24 skribis Peter:<br>&gt; &gt; &gt; Now that POWER9 systems are pretty well supported, I'm setting away some time<br>&gt; &gt; &gt; next year to backport powerpc64 to the Mac G5.  Is there anyone already doing<br>&gt; &gt; &gt; that?  I already tried this once (based on the macppc sources) but failed.<br>&gt; &gt;<br>&gt; &gt; [...]<br>&gt; &gt; What would be specific advantages if OpenBSD/powerpc64 (over macppc)<br>&gt; &gt; were backported to PowerPC 970?<br>&gt;<br>&gt; For me it's using my G5 (970FX cpu) without 2 GB limitation.  My machine has<br>&gt; 4 GB of RAM but OpenBSD/macppc only supports max. 2 GB.<br><br>This is good to know, especially as I had been looking for extra memory<br>for up to 4 GiB which I thought was the limit for 32-bit systems.  I did<br>not know until now that this is different for PowerPC or the specific<br>macppc port.  Please, correct me if I misinterpret.<br><br>I suppose a true 64-bit OpenBSD version for the G5 could also perform<br>better in general?<br><br>&gt; Another thing is it interests me very much, as a personal achievement, to know<br>&gt; how to port an OS to another platform.  I've sat in the background with the<br>&gt; riscv64 team and learned quite a bit on how they do that.  I also attempted<br>&gt; this before (alone) purchased some powerpc books, invested a lot of time,<br>&gt; trying to do this port, which failed.  I miss the exploring part.<br>&gt;<br>&gt; A lot of things are already done, in the powerpc64 port, I read a little<br>&gt; for a bit how OpenBSD did the SLB implementation in pmap.c.  I compared it a<br>&gt; little with mine that I constructed from FreeBSD's in 2018 and there is a bit<br>&gt; of difference but the functions are very similar.  Compare:<br>&gt;<br>&gt; pmap_va2vsid() in pmap.c<br>&gt; https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc64/powerpc64/pmap.c?rev=1.54&amp;content-type=text/plain<br>&gt;<br>&gt; with FreeBSD's or my port:<br>&gt; va_to_vsid() in slb.c<br>&gt; https://gotweb.centroid.eu/cgi-bin/gotweb/gotweb?path=powerpc64.git&amp;action=blob&amp;commit=ec46d233f79ed298dde271748a49523aea1522ca&amp;file=slb.c&amp;folder=%2Fpowerpc64<br>&gt;<br>&gt; The similarities take me back to a time when I organised putting these functions<br>&gt; into my slb.c back when.  I forgot right now what SLB stands for exactly but<br>&gt; it replaced the BAT functions from 32-bit PowerPC which had to do with memory<br>&gt; management and caching.  I'll look it up on monday when I am back home.  Side<br>&gt; Lookup Buffer popped into my head afterwards writing this mail.<br>&gt;<br>&gt; I noticed there may be room to speed these up on the powerpc64 arch as the<br>&gt; virtual to physical mappings (PTE) are a LIST.  I took my implementation from<br>&gt; FreeBSD original implementation which used a TREE, which could make lookups<br>&gt; faster if you pass it a virtual address to get a physical address.  But I<br>&gt; understand that it's easy to get this wrong so a LIST is likely better than<br>&gt; a TREE for robustness.  Also FreeBSD I believe put its SPLAY tree<br>&gt; implementation into a radix tree or something if I remember correctly (I<br>&gt; could be wrong here).<br>&gt;<br>&gt; In no way do I want to start arguing about this.  I'm very much a student to<br>&gt; Mark Kettenis's teachings (and BSD's teachings too).  Granted having said<br>&gt; this I invite corrections above.<br><br>From me you won't get technical feedback on this.  I was only curious<br>(from a user's perspective) and don't have the technical background to<br>argue about these efforts.  If I'd be saying anything, I'd encourage<br>this effort! :-)<br><br>&gt; So having said a lot of "how" and not a lot of "why", another point is I want<br>&gt; to make use of my hardware to the fullest, a POWER9 machine is expensive and<br>&gt; I won't likely have one for another 2 or 3 years, by which time a POWER10<br>&gt; machine will likely exist, and I have time for one more hobby project outside<br>&gt; of my job (within reason), starting in 2021. :-)<br><br>This makes sense to me.<br><br>Marco<br><br></blockquote><div><br></div><div><br></div>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Mark Kettenis
In reply to this post by Peter J. Philipp-3
> Date: Fri, 11 Dec 2020 17:24:51 +0100
> From: "Peter J. Philipp" <[hidden email]>
>
> Hi,
>
> Now that POWER9 systems are pretty well supported, I'm setting away
> some time next year to backport powerpc64 to the Mac G5.  Is there
> anyone already doing that?  I already tried this once (based on the
> macppc sources) but failed.  I don't want to throw the little that I
> learned out the window.  I'm giving myself more time next year than
> my last attempt.  Right now I'm dreaming big, but I'll need to awake
> to do some work on this.  I'll likely start in January or February
> with compiling on G5 macppc arch and testing on amd64 under qemu.
> Please don't give me any kudos until I share something that
> works. :-)

Hi Peter,

The core powerpc64 kernel code (pmap, traps, etc.) should work just
fine on the PowerPC 970.  The powerpc64 <machine/endian.h> uses
instructions that the G5 doesn't have, but that is trivial to fix.

Your biggest challenge will be the firmware differences.  The POWER9
machines use OPAL whereas the older systems use Open Firmware.  The
way I envisioned supporting Open Firmware systems is to have the
bootloader translate the Open Firmware device tree into a "flattened"
device tree before entering the kernel.  That way you don't need a
special kernel for the G5 systems.

One warning though: we may switch the POWER9 systems to little-endian
at some point in the future.  Supporting both big-endian and
little-endian in the codebose shouldn't be a huge burden.  But I'm not
sure we'll have the infrstructure to build both big-endian and
little-endian releases and packages.

Cheers,

Mark

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Peter J. Philipp-3
On Sun, Dec 13, 2020 at 08:46:38PM +0100, Mark Kettenis wrote:

> > Date: Fri, 11 Dec 2020 17:24:51 +0100
> > From: "Peter J. Philipp" <[hidden email]>
> >
> > Hi,
> >
> > Now that POWER9 systems are pretty well supported, I'm setting away
> > some time next year to backport powerpc64 to the Mac G5.  Is there
> > anyone already doing that?  I already tried this once (based on the
> > macppc sources) but failed.  I don't want to throw the little that I
> > learned out the window.  I'm giving myself more time next year than
> > my last attempt.  Right now I'm dreaming big, but I'll need to awake
> > to do some work on this.  I'll likely start in January or February
> > with compiling on G5 macppc arch and testing on amd64 under qemu.
> > Please don't give me any kudos until I share something that
> > works. :-)
>
> Hi Peter,
>
> The core powerpc64 kernel code (pmap, traps, etc.) should work just
> fine on the PowerPC 970.  The powerpc64 <machine/endian.h> uses
> instructions that the G5 doesn't have, but that is trivial to fix.

Awesome, that'll help a lot!  Thank you!

> Your biggest challenge will be the firmware differences.  The POWER9
> machines use OPAL whereas the older systems use Open Firmware.  The
> way I envisioned supporting Open Firmware systems is to have the
> bootloader translate the Open Firmware device tree into a "flattened"
> device tree before entering the kernel.  That way you don't need a
> special kernel for the G5 systems.

It's quite funny, I actually thought of that too, but had discarded it for
porting the realtime ofw code from macppc over.  I had taken a small peek
at FreeBSD's code and had wondered why they had an FDT and an OFW register.
I did spot some fdt routines in their bootloader.

I guess I can do this though if you think it's the better way it's the
better way, the bootloader that came with macppc I had converted
to load 64-bit ELF binaries back in 2018 and I was thinking of re-using it.  I
guess I can tie in translation routines and that would be the core of the
work.

> One warning though: we may switch the POWER9 systems to little-endian
> at some point in the future.  Supporting both big-endian and
> little-endian in the codebose shouldn't be a huge burden.  But I'm not
> sure we'll have the infrstructure to build both big-endian and
> little-endian releases and packages.

OK good to know.  I have a stereotype in me that the 970 doesn't do little
endian even though it has the MSR support for it.  It would be worth it
to stay on big endian for my port anyhow so that I can dual boot
between macppc and macppc64 and share disk partitions perhaps.  I'm thinking
that would be helpful in many scenarios.  So then POWER* cpu's can go little
endian.

In regards of packages, there will be a way, but first the macppc64 port has
to complete.  Perhaps we can set up a sort of DPD among the users to build
packages for just that port.  And there is no real word that this port will
make it into OpenBSD at all.  When it's ready I guess it's up to you guys to
weigh options to put it in or not and then the question of making space for
the release will likely be visited.

> Cheers,
>
> Mark

I'm looking forward to this.  I'm interested how conversion from OFW to FDT
would work in the bootloader.  I'll likely take a peek at FreeBSD's bootloaders
and see if I can use some of that.

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Peter J. Philipp-3
On Mon, Dec 14, 2020 at 08:58:36AM +0100, Peter J. Philipp wrote:
> I guess I can do this though if you think it's the better way it's the
> better way, the bootloader that came with macppc I had converted
> to load 64-bit ELF binaries back in 2018 and I was thinking of re-using it.  I
> guess I can tie in translation routines and that would be the core of the
> work.

Hi I just want to pass an idea by you, I wonder if you like it or not.

As you know the powerpc64 (and octeon) archs have a BOOT kernel.  Instead of
dealing with the OpenBSD/macppc ofwboot and converting it to boot 64-bit ELF
kernels (which I've already done) and do a FDT compilation (while still in
virtual memory mode), how would you feel if I strip down the ofwboot to just
boot /boot instead of /bsd and it boots a 32-bit BOOT kernel (from macppc)
with a special boot driver to jump to 64-bit mode before executing the
running 64-bit kernel.

Then I could write general functions in the BOOT kernel to compile a FDT tree.
It may be easier to work with the kernel than with ofwboot.  I just don't know
if a BOOT kernel can be cross compiled in 64-bit mode native environment.  It
sorta has a large footprint across architectures but could give freedoms back
inside the BOOT.

It could make dual-booting easier on a G5 while adding a (half) stage to
macppc64 (and perhaps eventually macppc arch?).

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Mark Kettenis
> Date: Mon, 14 Dec 2020 10:27:24 +0100
> From: "Peter J. Philipp" <[hidden email]>
>
> On Mon, Dec 14, 2020 at 08:58:36AM +0100, Peter J. Philipp wrote:
> > I guess I can do this though if you think it's the better way it's
> > the better way, the bootloader that came with macppc I had
> > converted to load 64-bit ELF binaries back in 2018 and I was
> > thinking of re-using it.  I guess I can tie in translation
> > routines and that would be the core of the work.
>
> Hi I just want to pass an idea by you, I wonder if you like it or not.
>
> As you know the powerpc64 (and octeon) archs have a BOOT kernel.  Instead of
> dealing with the OpenBSD/macppc ofwboot and converting it to boot 64-bit ELF
> kernels (which I've already done) and do a FDT compilation (while still in
> virtual memory mode), how would you feel if I strip down the ofwboot to just
> boot /boot instead of /bsd and it boots a 32-bit BOOT kernel (from macppc)
> with a special boot driver to jump to 64-bit mode before executing the
> running 64-bit kernel.
>
> Then I could write general functions in the BOOT kernel to compile a
> FDT tree.  It may be easier to work with the kernel than with
> ofwboot.  I just don't know if a BOOT kernel can be cross compiled
> in 64-bit mode native environment.  It sorta has a large footprint
> across architectures but could give freedoms back inside the BOOT.
>
> It could make dual-booting easier on a G5 while adding a (half) stage to
> macppc64 (and perhaps eventually macppc arch?).

Doesn't really make sense.  The BOOT kernel is there because POWER9
"firmware" doesn't provide a device access interface.  That limitation
doesn't exist with Open Firmware.  Having a BOOT kernel adds a
significant delay to the boot process, so if we can avoid it, we
probably should.

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Peter J. Philipp-3
On Mon, Dec 14, 2020 at 11:31:46AM +0100, Mark Kettenis wrote:
> > It could make dual-booting easier on a G5 while adding a (half) stage to
> > macppc64 (and perhaps eventually macppc arch?).
>
> Doesn't really make sense.  The BOOT kernel is there because POWER9
> "firmware" doesn't provide a device access interface.  That limitation
> doesn't exist with Open Firmware.  Having a BOOT kernel adds a
> significant delay to the boot process, so if we can avoid it, we
> probably should.

OK, that explanation makes sense to me.  Good I have something to work with
on the ofwboot64 stuff I did in 2018, I just have to bring it up to date and
then add FDT blob compiler, shouldn't be harder than constructing a DNS
packet :-).

And I gave myself a year to do this project so I'm not gonna rush it :-).

I also looked on your include/endian.h hint and it looks like I already wrote
conversions back in 2018 as well for the __mswap64() macros (iirc).

This will be fun, I'm looking forward to late January to get started.

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Mark Kettenis
> Date: Mon, 14 Dec 2020 11:50:42 +0100
> From: "Peter J. Philipp" <[hidden email]>
>
> On Mon, Dec 14, 2020 at 11:31:46AM +0100, Mark Kettenis wrote:
> > > It could make dual-booting easier on a G5 while adding a (half) stage to
> > > macppc64 (and perhaps eventually macppc arch?).
> >
> > Doesn't really make sense.  The BOOT kernel is there because POWER9
> > "firmware" doesn't provide a device access interface.  That limitation
> > doesn't exist with Open Firmware.  Having a BOOT kernel adds a
> > significant delay to the boot process, so if we can avoid it, we
> > probably should.
>
> OK, that explanation makes sense to me.  Good I have something to work with
> on the ofwboot64 stuff I did in 2018, I just have to bring it up to date and
> then add FDT blob compiler, shouldn't be harder than constructing a DNS
> packet :-).

There is some code in sys/arch/arm64/stand/efiboot/fdt.c that can add
nodes and properties to a tree, so you don't need to start from
scratch here.

Reply | Threaded
Open this post in threaded view
|

Re: powerpc64 backport to g5

Peter J. Philipp-3
On Mon, Dec 14, 2020 at 12:01:57PM +0100, Mark Kettenis wrote:
> > OK, that explanation makes sense to me.  Good I have something to work with
> > on the ofwboot64 stuff I did in 2018, I just have to bring it up to date and
> > then add FDT blob compiler, shouldn't be harder than constructing a DNS
> > packet :-).
>
> There is some code in sys/arch/arm64/stand/efiboot/fdt.c that can add
> nodes and properties to a tree, so you don't need to start from
> scratch here.

I have been toiling with this for the greater part of the week and I brought
the ofwboot64 code up to 6.8 status (without the FDT).  I have made some
announcement here:  https://centroid.eu/ppc/#20201218 .  I have some sysadmin
tasks to do at home which will take me into January and then I'll work on
putting a flattened device tree into this loader.  

However I'm already dreaming in the clouds (could be a detriment), I wonder
if this work pays off and it works if I can get a IBM BladeCenter H with
these JS21 Blades for it.  I wonder if they are compatible and utilize
openfirmware in a way that ofwboot can be used.  If so that's really cool
as a build-farm for ports or something could be built with these (each unit
would have 16 GB RAM).  I found this on ebay...

http://vi.raptor.ebaydesc.com/ws/eBayISAPI.dll?ViewItemDescV4&item=131558745375&category=11211&pm=1&ds=0&t=1598358778000&ver=0

The possibility of getting such old hardware is exciting...

So anyhow back to coding in 2021...have a merry season all it's been a good
year!

-peter