powerpc64 backport to g5
Locked
 
|
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 |
|
|
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 |
Re: powerpc64 backport to g5
|
|
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 |
|
|
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 |
|
|
 publicKey - rrondan@itrestauracion.com.ar - 2d1b9a57.asc (4K) Download Attachment signature.asc (858 bytes) Download Attachment |
Re: powerpc64 backport to g5
|
|
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 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 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 in the main stable macppc version ?</div><div><br></div><div>Regards </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 <<a href="mailto:[hidden email]" class="">[hidden email]</a>> wrote:<blockquote class="protonmail_quote" type="cite"> Je 12 Dec 11:59 skribis Peter:<br>> On Sat, Dec 12, 2020 at 11:06:33AM +0100, Marco van Hulten wrote:<br>> > Hello Peter,<br>> ><br>> > Je 11 Dec 17:24 skribis Peter:<br>> > > Now that POWER9 systems are pretty well supported, I'm setting away some time<br>> > > next year to backport powerpc64 to the Mac G5. Is there anyone already doing<br>> > > that? I already tried this once (based on the macppc sources) but failed.<br>> ><br>> > [...]<br>> > What would be specific advantages if OpenBSD/powerpc64 (over macppc)<br>> > were backported to PowerPC 970?<br>><br>> For me it's using my G5 (970FX cpu) without 2 GB limitation. My machine has<br>> 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>> Another thing is it interests me very much, as a personal achievement, to know<br>> how to port an OS to another platform. I've sat in the background with the<br>> riscv64 team and learned quite a bit on how they do that. I also attempted<br>> this before (alone) purchased some powerpc books, invested a lot of time,<br>> trying to do this port, which failed. I miss the exploring part.<br>><br>> A lot of things are already done, in the powerpc64 port, I read a little<br>> for a bit how OpenBSD did the SLB implementation in pmap.c. I compared it a<br>> little with mine that I constructed from FreeBSD's in 2018 and there is a bit<br>> of difference but the functions are very similar. Compare:<br>><br>> pmap_va2vsid() in pmap.c<br>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc64/powerpc64/pmap.c?rev=1.54&content-type=text/plain<br>><br>> with FreeBSD's or my port:<br>> va_to_vsid() in slb.c<br>> https://gotweb.centroid.eu/cgi-bin/gotweb/gotweb?path=powerpc64.git&action=blob&commit=ec46d233f79ed298dde271748a49523aea1522ca&file=slb.c&folder=%2Fpowerpc64<br>><br>> The similarities take me back to a time when I organised putting these functions<br>> into my slb.c back when. I forgot right now what SLB stands for exactly but<br>> it replaced the BAT functions from 32-bit PowerPC which had to do with memory<br>> management and caching. I'll look it up on monday when I am back home. Side<br>> Lookup Buffer popped into my head afterwards writing this mail.<br>><br>> I noticed there may be room to speed these up on the powerpc64 arch as the<br>> virtual to physical mappings (PTE) are a LIST. I took my implementation from<br>> FreeBSD original implementation which used a TREE, which could make lookups<br>> faster if you pass it a virtual address to get a physical address. But I<br>> understand that it's easy to get this wrong so a LIST is likely better than<br>> a TREE for robustness. Also FreeBSD I believe put its SPLAY tree<br>> implementation into a radix tree or something if I remember correctly (I<br>> could be wrong here).<br>><br>> In no way do I want to start arguing about this. I'm very much a student to<br>> Mark Kettenis's teachings (and BSD's teachings too). Granted having said<br>> 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>> So having said a lot of "how" and not a lot of "why", another point is I want<br>> to make use of my hardware to the fullest, a POWER9 machine is expensive and<br>> I won't likely have one for another 2 or 3 years, by which time a POWER10<br>> machine will likely exist, and I have time for one more hobby project outside<br>> 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> > > |
|
|
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 |
Re: powerpc64 backport to g5
|
|
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 |
Re: powerpc64 backport to g5
|
|
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 |
|
|
> 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. |
Re: powerpc64 backport to g5
|
|
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 |
|
|
> 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. |
Re: powerpc64 backport to g5
|
|
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 |
«
Return to openbsd port - ppc
|
1 view|%1 views
| Free forum by Nabble | Edit this page |