Looks good to me on inspection. That was always something annoying about trying to configure the PCI bus on ppce500 in qemu. Things should be a lot easier to work with now, before this, we had to manually assign slots high enough.

Final powerpc changes:

Finalized boostraps for powerpc uploaded to my public_distfiles on freefall.

In D30099#675684, @bdragon wrote:

In D30099#675678, @tobik wrote:

In D30099#675645, @bdragon wrote:

Note: I have the bootstrap side working for 32 bit powerpc, been holding off on submitting it though because I haven't successfully gotten a full lang/rust build out of it yet (problems with linking.)

That's nice. What problems specifically?

Out of range PLT relocs.

http://drop.rtk0.net/20210504.txt

In D30099#675678, @tobik wrote:

In D30099#675645, @bdragon wrote:

Note: I have the bootstrap side working for 32 bit powerpc, been holding off on submitting it though because I haven't successfully gotten a full lang/rust build out of it yet (problems with linking.)

That's nice. What problems specifically?

Note: I have the bootstrap side working for 32 bit powerpc, been holding off on submitting it though because I haven't successfully gotten a full lang/rust build out of it yet (problems with linking.) I did upstream the obligatory openssl-src-rs crate changes needed to bootstrap though at https://github.com/alexcrichton/openssl-src-rs/commit/9cc3301e6168237d2b466cb92d5535e0a6252c51 .

It ended up being not entirely necessary due to the linker behavior of forcing required sections into whatever segment is a natural fit for them, unless we explicitly break it with /DISCARD/.

Rebase against latest code.

Updating comments

Retested powerpc/powerpcspe. Still good.

Oh! So it's not a contract between libc and rtld, it's just internal functionality that is used in both static libc as well as rtld, so it ends up being hidden visibility and just a common piece of code that both happen to pull in. Makes sense to me now.

Testing libexec/rtld-elf, lib/csu, lib/libthr on powerpc*.

BTW I got a second PS3 in the mail today so I now have the ability to test both a modern OtherOS++ (Rebug 4.86.1) setup and a classic OtherOS on OFW 2.80 setup.

I haven't had any luck doing raw kernel loads on mine. Are you trying with ELFv1 or ELFv2 kernels? I can't get either 12.2 or -current kernels to load properly, is there some special petitboot version you are using with yours?

• Fix bug in host_open error path
• Fix linker script problems

I did a full test run with the updated version of this patch in (among others) and it worked fine.

OK. Tested on POWER9.

OK PowerPC

Makes sense to me.

• s/frozen/freeze/
• Add G5 handling for "platform function that is just a GPIO write" style timebase control like PowerMac11,2.

In D29136#652512, @markmi_dsl-only.net wrote:

In case it helps for some G4 dual socket contexts (captured while the machine happens
to be up and accessible). Turns out each of the cpus has a timebase-enable listed, but
they are numerically equal on the machine in question.

...

timebase-enable:
  00 00 00 73

Yep. 0x73 is the "expected" value for this. It is the GPIO base offset of 0x6a plus the offset to the timebase control of 0x9. As far as I know, that's how all G4s are wired, but we respect the property in case there is a model out there that is wired differently.

Tested on PPC32.

Confirmed that I can still install on powerpc64le in qemu with this change, and that the empty /boot/efi directory exists again.

Should be good for HEAD.

Universe build went fine.

Confirmed correct on an nvidia-based powerbook g4.

In D28580#640085, @markj wrote:

In D28580#639939, @bdragon wrote:

On a deca-core POWER8 (SMT-8):

Presumably this is not a NUMA system? Or should we be seeing an additional layer in the topology?

In D28580#640084, @markj wrote:

In D28580#639940, @bdragon wrote:

One possible problem with your assumptions is that arbitray cores may be GUARDed out for a given boot. So some cores may exist but be offline due to being deconfig'd during IPL. I'm not sure whether that would have an effect on this or not. The IPL logic will always deconfig the entire core, and therefore the entire thread/smt group when there is a fault entry. So the domains might have differing numbers of online cores.

When is this done in practice?

I'm not a huge fan of assuming that all domains have an identical number of cores, this assumption is just needed to use the somewhat simplistic smp_topo_*() functions. I'll revisit this and see if I can handle asymmetric domains without having to complicate the code too much.

One possible problem with your assumptions is that arbitray cores may be GUARDed out for a given boot. So some cores may exist but be offline due to being deconfig'd during IPL. I'm not sure whether that would have an effect on this or not. The IPL logic will always deconfig the entire core, and therefore the entire thread/smt group when there is a fault entry. So the domains might have differing numbers of online cores.

On a deca-core POWER8 (SMT-8):

Since jhibbits tried for Talos II already, I will try on TYAN POWER8 instead.

Will try this on Talos II.

Looks good.

Manually closing. Phab didn't pick up on the commit message due to a glitch in the documentation.

Yes please.

Addressing review comments.

I'm fine with it on readthrough, I just hadn't gotten around to the actual tests. If it broke anything in powerpc land, it should be easy to fix. Thanks for tidying up the procedure annotations!

In D27293#610389, @bdragon wrote:

In D27293#610225, @pkubaj wrote:

Doesn't apply on fresh ports tree:

C         devel/cargo-c/Makefile
>         rejected hunk @@ -2,6 +2,7 @@
C         lang/rust/files/patch-compiler_rustc__target_src_spec_i686__unknown__freebsd.rs
>         rejected hunk @@ -1,5 +1,5 @@
C         lang/rust/files/powerpc64-elfv1/patch-compiler_rustc__llvm_build.rs
>         rejected hunk @@ -1,5 +1,5 @@
C         lang/rust/files/powerpc64-elfv2/patch-compiler_rustc__target_src_abi_call_powerpc64.rs
>         rejected hunk @@ -1,5 +1,5 @@
C         lang/rust/files/powerpc64-elfv2/patch-compiler_rustc__target_src_spec_powerpc64__unknown__freebsd.rs
>         rejected hunk @@ -1,5 +1,5 @@
C         lang/rust/files/powerpc64le/patch-compiler_rustc__target_src_spec_mod.rs
>         rejected hunk @@ -1,5 +1,5 @@

Yeah, that's just a side effect of moved files. I worked around this on my end when patching by pre-moving the changed patch files.

I don't know why the uploaded patch isn't able to do this automatically, I think it might have just been uploaded with the wrong options or needs to be applied in a certain manner. It's not showing up as a delete/add like usual though.