[johnnym]

I admire this project because I know from experience how trying to support a single architecture in a niche project can be a challenge.

Thanks again, for me it's like learning on the job actually. That it really works was crucial for keeping me on the project.

I have my own pet OS that I am working on, off and on.

Nice! Having your own OS allows you to avoid the constant windmill fight against important software products dropping support for your beloved architecture because of constant - not necessarily careless - changes. I saw and see that a lot in Debian GNU/Linux, e.g. a few years ago they dropped userland support for older iconic MIPS machines like Qube(2) and RaQ(2) because a newer ISA promised "loads of performance improvements". Well, I couldn't reproduce these, as I couldn't find a cheap enough MIPS board to test that - and what would such a board be compared to my Qube2 or MIPS RaQs? For the same reason I find most ppc64le ports in - let's call it community - distributions rather useless as POWER8 machinery is still not a hobbyist friendly thing in regard to price. Even worse if supporting ppc64le includes dropping support for ppc64 and powerpc...

Honestly if the OpenBSD guys aren't willing to help at all I think the best opportunity would be to join forces with another project that has interest in maintaining an openbsd port and sharing resources between the two.

Don't know of any, unfortunately. VAX guys will by now have moved on to NetBSD (don't have one unfortunately, but SIMH is there, I wonder what it could do with a 5 to 6 GHz AMD64 processor), as will the SPARC guys (me including, also because of the missing MP support).

A tezro running an IP27 kernel? Interesting.

Yeah, I believe the OpenBSD devs (or most likely Miod himself) tried to get as many machines covered with a kernel as possible. Because for other architectures usually there is only one SP (and one MP kernel if existing) and a singular RAMdisk kernel (SP kernel with integrated RAMdisk for installations and recovery). SGI machines seem to be just too different to each other to cover them all with a singular kernel, or it would be too big then.

If you're interested, the OpenBSD/sgi 6.9 installation manual shows what kernels support what machine in detail.

[Raion]

I wouldn't compare the MIPS II/III to MIPS32/64 transition that happened in the embedded space with what happened with the POWER side of things.

Without getting into an argument about it the benefits of transitioning away from big endian are immense especially on the driver front. If you want beyond OpenGL 3, or get Vulkan, OpenCL, JIT for firefox etc, it's pretty damn imperative to get off big endian. Unfortunately, as sad as I am to say it, Apple PowerPC hobbyists are holding us back there. Talos is as cheap as it ever is gonna get without a serious volume jump and because hobbyists chickened out at the price we may not see a TALOS III, let alone cheaper hardware for POWER. I'll leave it at that lest I go ranting about why the PPC970 community in particular should have shut up.

[johnnym]

I'll leave it at that lest I go ranting about why the PPC970 community in particular should have shut up.

I was tempted to say "challenge accepted" , but I don't have a that detailed knowledge about these POWER/PowerPC "infights" and having a hefty discussion here would also spoil this thread, I think. Though I really don't know why we can't have one and the other at the same time? Are there not enough people to keep both alive at the same time? You know, I look at all that work that went into it and can't understand why it's required to tear down one cathedral to build another one that has its windows upside down. Don't get me wrong, I'm happy for the other cathedral (the one with the windows upside down), too, but why does the other one have to go for that.

---

I also did some work on OpenBSD/sgi since my last post about it:

1. I tested the created 7.0 userland (incl. the recreated kernel) on my Octane with the help of nfsrb2 and it boots fine, the same way as the last "original" 6.9 version does and the same way the respective octeon file systems did.
   
   There is one issue with this release though: You remember that I decided to not build LLVM/clang because it takes much longer than the userland and kernels alone. It looks like the extra software that is available for octeon (and that was available for sgi, too,in the past) through the ports tree (e.g. from https://ftp.eu.openbsd.org/pub/OpenBSD/7...es/mips64/) is built with LLVM/clang, so seems to require the LLVM/clang libraries to run:
   
   
   Code:

   octane# pkg_add nano
quirks-4.53 signed on 2021-10-06T15:02:34Z
quirks-4.53: ok
nano-5.8:libiconv-1.16p0: ok
Can't install gettext-runtime-0.21p1 because of libraries
|library c++.8.0 not found
| not found anywhere
|library c++abi.5.0 not found
| not found anywhere
Direct dependencies for gettext-runtime-0.21p1 resolve to libiconv-1.16p0
Full dependency tree is libiconv-1.16p0
Can't install nano-5.8: can't resolve gettext-runtime-0.21p1
Couldn't install gettext-runtime-0.21p1 nano-5.8
   
   Well, as bad as this looks, the solution is to just copy over the missing LLVM/clang libs from an octeon userland or the respective set. I assume it's in the base set, because if it was in the comp(iler) set, software from the ports tree wouldn't work without the comp set installed:
   
   
   Code:

   octane# cp -v /tmp/llvm-libs/* /usr/lib/
/tmp/llvm-libs/libLLVM.so.6.0 -> /usr/lib/libLLVM.so.6.0
/tmp/llvm-libs/libc++.a -> /usr/lib/libc++.a
/tmp/llvm-libs/libc++.so.8.0 -> /usr/lib/libc++.so.8.0
/tmp/llvm-libs/libc++_p.a -> /usr/lib/libc++_p.a
/tmp/llvm-libs/libc++abi.a -> /usr/lib/libc++abi.a
/tmp/llvm-libs/libc++abi.so.5.0 -> /usr/lib/libc++abi.so.5.0
/tmp/llvm-libs/libc++abi_p.a -> /usr/lib/libc++abi_p.a
/tmp/llvm-libs/libcompiler_rt.a -> /usr/lib/libcompiler_rt.a
   
   I just copied everything I thought was related to LLVM/clang and that seems to have solved that issue:
   
   
   Code:

   octane# pkg_add nano
quirks-4.53 signed on 2021-10-06T15:02:34Z
nano-5.8:gettext-runtime-0.21p1: ok
nano-5.8: ok
octane# pkg_add htop
quirks-4.53 signed on 2021-10-06T15:02:34Z
htop-3.0.5pl20210418:libffi-3.3p1: ok
htop-3.0.5pl20210418:pcre-8.44: ok
htop-3.0.5pl20210418:xz-5.2.5: ok
htop-3.0.5pl20210418:sqlite3-3.35.5p0: ok
htop-3.0.5pl20210418:bzip2-1.0.8p0: ok
htop-3.0.5pl20210418:python-3.8.12: ok
htop-3.0.5pl20210418:glib2-2.68.4: ok
htop-3.0.5pl20210418:desktop-file-utils-0.26: ok
htop-3.0.5pl20210418: ok
Running tags: ok
New and changed readme(s):
    /usr/local/share/doc/pkg-readmes/glib2
   
   The binaries I tested from the ports tree - i.e. nano, htop, git, 7z, eopenssl-3.0 - installed and worked just fine after copying the LLVM/clang libs over.
   
   So that is not the perfect solution I had hoped for, but for now I can live with it. And maybe if some people with more powerful machines chime in in the future, we can bring LLVM/clang back to OpenBSD/sgi, though I'm unsure if it is worth the time for compilation, if we could otherwise just copy over some files to make it work with the software from the ports tree.
   
   
2. I had another idea to tackle the IP28 problem that arose in OpenBSD/sgi 7.2: I don't know how to debug that problem any further without the help of some person with more skills here, but I could do some bisecting to chase down a possible cause. Up until now that wasn't possible, because I use different branches for each version of OpenBSD/sgi and added the needed reverts and adaptations on top. But what if I could make all these changes in one branch and at the time they happened or not happened actually:
   Enter the sgi-never-retired branch, where I rewrote the history of the official OpenBSD source and "deleted" the commits that removed sgi stuff and adapted the commits that changed functionality that also needed to changed in the now still existing sgi related code. I will make another post about how to do that with git when I reached 7.2 in that branch. At the moment I am at 7.1 still. When I have reached 7.2 I can also finally start with the bisecting process and hopefully narrow things down to a reasonable commit, fingers crossed.
   

[Raion]

I was tempted to say "challenge accepted" , but I don't have a that detailed knowledge about these POWER/PowerPC "infights" and having a hefty discussion here would also spoil this thread, I think. Though I really don't know why we can't have one and the other at the same time? Are there not enough people to keep both alive at the same time? You know, I look at all that work that went into it and can't understand why it's required to tear down one cathedral to build another one that has its windows upside down. Don't get me wrong, I'm happy for the other cathedral (the one with the windows upside down), too, but why does the other one have to go for that.

Limited resources in particular. Supporting both endian modes for an arch means double the testing and other necessary management work, and it's not something the BSDs have in terms of manpower. The result is a gimped experience for POWER8 and up.

It's for the same reason that supporting both a GCC and MIPSPro Nekoware release isn't really feasible -- for every C++ GCC program you end up with dozens of duplicated libs and such to isolate the name mangling. You'd need to split the two releases.

You could probably with some hacks create a "universal" release for both endians, but that would probably require more work than most would bother.

So that is not the perfect solution I had hoped for, but for now I can live with it. And maybe if some people with more powerful machines chime in in the future, we can bring LLVM/clang back to OpenBSD/sgi, though I'm unsure if it is worth the time for compilation, if we could otherwise just copy over some files to make it work with the software from the ports tree.

Grab the libs and install them by default? That's my thought.

Good luck, thanks for continuing the hard work. This is really neat.

[johnnym]

Limited resources in particular. Supporting both endian modes for an arch means double the testing and other necessary management work, and it's not something the BSDs have in terms of manpower. The result is a gimped experience for POWER8 and up.

I see. What a pity, my two-node p5 570 was quite the fun when it finally worked as one system. Hey, OpenBSD does that with octeon and loongson.

You could probably with some hacks create a "universal" release for both endians, but that would probably require more work than most would bother.

Or the amount of money Apple could afford. And they have experience in switching arches (plus endianness on the way).

Grab the libs and install them by default? That's my thought.

Yeah, I also already wondered if it could work the other way round: i.e. place the gcc files needed to create the sgi kernels in the octeon FSes and save a lot of compile time.

Good luck, thanks for continuing the hard work. This is really neat.

You're welcome! Give it some time and you might wanna give it a try and switch to OpenBSD for some primal experience on you SGI machines... 

[Raion]

I don't think I'll do that but I'm happy to see someone teach me a thing or two. I might pull your knowledge when I am ready to start pushing out my OS to the masses

[johnnym]

The OpenBSD/sgi 7.0 release files are placed on a webserver allowing for HTTP and HTTPS access, i.e. find everything needed here:

https://ftp.machine-hall.org/pub/OpenBSD/7.0/sgi/

I haven't yet configured an FTP server for anonymous access despite its hostname, but if this is still a thing I think I will do that, too.

I know proftpd and vsftpd, though not sure which one to use. Any suggestions, also for other FTP servers?

---

To verify the contents of the fles I have created a signify(1) keypair and signed the SHA256 file (resulting in SHA256.sig). You can hence verify that what you downloaded comes from me by using signify on OpenBSD (or signify-openbsd on Debian GNU/Linux) using my signify public key below.

My signify public key is:

Code:

RWRmGQ1rewM9vHtQ6vMcAUnRrsJqKO/Z+n07CXxQkTPpAOnsVa26CIUj

As all kernels were rebuilt during the release build, they have a different hash value than the ones on GitHub. But as I didn't yet test each on the matching hardware (bsd.mp.IP30 is OK though) I haven't yet changed the release page on GitHub. Actually they shouldn't differ in functionality as they don't differ code-wise.

I haven't tested on-disk installations from ISO or the RAMdisk kernels, so if interested, suit yourself. I'm happy to provide assistance if needed.

[Raion]

OpenBSD uses pureftpd. If you would like help setting it and anonymous rsync up I would be more than happy to do what I can to help you.

[johnnym]

OpenBSD uses pureftpd. If you would like help setting it and anonymous rsync up I would be more than happy to do what I can to help you.

Sure, that would be nice, thanks for the support. I plan for this after I found something reasonable with the bisecting.

---

I yesterday managed to bring the sgi-never-retired branch to 7.2 and started the bisecting process. I then could limit the error window to just about 10 days yesterday between:

• in sgi-never-retired branch: https://github.com/the-machine-hall/open...c58176db30
  
• in real: https://github.com/openbsd/src/compare/8...7e9884dcd4
  

I didn't spot something obvious there yet, so hopefully the result will make sense  , but it was late and I was tired anyhow, so shouldn't overrate that.

[johnnym]

Got my first ambiguity here:

I consider it a good commit when:

• booting to the login prompt works
  
• login works
  
• uname, machine and sysctl hw work
  

Bad commits usually mount the NFS file systems but give bus errors, illegal instruction or segmentation faults when going through /etc/rc.

Now with a39c18f28d16b1a61658f6ce07a74bc58176db30 applied the Indigo² hangs after mounting the NFS root and the NFS swap (the NFS server logs it as "authenticated mount requests"). And I remember that I've seen something similar on my Octane when getting the commits together for the sgi-is-alive-at-7.2 branch, it didn't happen after applying a specific commit - of course I didn't log that one . So from that I can't really say if this "badness" is related to my actual issue for IP28 and OpenBSD 7.2.

In the end I decided to define it as bad commit - well, it didn't boot until the login prompt - but I now think that was wrong. That because:

• Nobody claims that a kernel will always work correctly for each and every commit
  
• That issue seems to have been solved later on, because although the bad commits so far are bad in the sense of the description, they all didn't hang after mounting the NFS shares
  

So making it a good commit would have set the "left" border ("good" commits) a little closer to the "right" border (bad commits). It could be that I am working now on the wrong half. Well, if it doesn't give a reasonable result, I can still start the bisecting with that ambiguous commit as good, but will cost me hours...