question regarding 'missing repos'

[hanetzer]

so, in the process of watching the osfc 2022 talk 'I have come to bury the BIOS, not to open it: The need for holistic systems', and thought I'd take a peek at some of the code mentioned, as I'm also interested in ryzen cpu init. the readme mentions two repos, which github says do not exist: amd-host-image-builder and helios.

I assume the actually do, but are not public facing. my question is, are they not public:

1. yet, but will be soon.
2. ever, because NDA/secret sauce stuff
3. something in between

Interesting stuff either way, and I'd love to hear back from you on this matter.

[dancrossnyc]

The answer for both repos is 1, but I'm not entirely sure what the timeline for both is.

Helios is our distribution of Illumos. If it's not public, it's probably just because we haven't had time yet.

amd-host-image-builder is a tool that emits a bootable image that can be consumed by the PSP embedded in an EPYC SoC. We're working on opening that up, it's just a small matter of doing the work for it.

[hanetzer]

Fair enough, these things take time. From the demo in the talk, it seems that phbl is what handles the 'heavy lifting', so to speak, after the PSP does its memory init stuff; am I correct in this belief, and that the 'secret sauce' I may need for desktop ryzen parts, or at least a portion of it, is contained within this repo? currently tinkering with an x370 mobo with a 2200g in it (raven ridge).

On that note, I had been eyeballing the repo amd-apcb, and I can find no consumers for it on the public facing github or examples of use for it; after reading the readme to this repo I am lead to believe that the host image builder may make use of it during image generation, is that the case? My primary interest was parsing and decoding the apcb binaries I pulled out of vendor bios images using psptool, as my initial and current goal is pulling the psp images out of the vendor firmware for repackaging/reuse (but not redistribution) in {c,}oreboot firmware, similar to how one may pull the ME firmware images out of intel bios images for a similar purpose.

[dancrossnyc]

Fair enough, these things take time. From the demo in the talk, it seems that phbl is what handles the 'heavy lifting', so to speak, after the PSP does its memory init stuff; am I correct in this belief, and that the 'secret sauce' I may need for desktop ryzen parts, or at least a portion of it, is contained within this repo?

I don't think I'd put it that way, honestly: phbl handles setting up the architectural state for illumos and loading the kernel, and then activating it (a one-way trip); it is the code that runs directly from the reset vector when the x86 cores are brought online initially.

As such, everything that it does is pretty well-defined: initialize the BSC and bring it up into 64 bit mode with paging enable, load a known payload in a known-format into RAM and map it, and then execute a jump. It executes in a single-CPU environment, and pretty much everything one needs to know to understand what it does is in the systems programming volume in the APM and in the ELF spec in the SVR4 ABI document and amd64 addendum.

The real "heavy lifting", as it were, of the platform bringup is done in the illumos kernel itself: phbl is just a thin layer of glue enabling that. Bringing the overall platform online is a much larger and frankly harder job.

currently tinkering with an x370 mobo with a 2200g in it (raven ridge).

I'm afraid I have very little insight into Ryzen or consumer gear generally.

On that note, I had been eyeballing the repo amd-apcb, and I can find no consumers for it on the public facing github or examples of use for it; after reading the readme to this repo I am lead to believe that the host image builder may make use of it during image generation, is that the case?

Yes, that's correct.

My primary interest was parsing and decoding the apcb binaries I pulled out of vendor bios images using psptool, as my initial and current goal is pulling the psp images out of the vendor firmware for repackaging/reuse (but not redistribution) in {c,}oreboot firmware, similar to how one may pull the ME firmware images out of intel bios images for a similar purpose.

I think it would work for that. I'd check with @daym, though, as he's the expert there. :-)

[hanetzer]

illumos heavy lifting

I assume this to be the specific helios fork you mentioned. Also, I do have a question regarding the psp images you guys use. Are these 'standard off the shelf' images, that one could pull from any distributed Epyc bios image, or did AMD cook you some special ones for your agesa-less usecase?

ryzen consumer

Yeah, seems to be the status quo. I hope to change that, however.

apcb stuff

cool, good to know.

So, back to the original topic of 'missing repos'. When they do go public, is there somewhere I should watch or be subscribed to, to be alerted to the fact they have done so?

[dancrossnyc]

illumos heavy lifting

I assume this to be the specific helios fork you mentioned.

Actually no.... The helios repository just contains build tools and the like. Take a look at our fork of the illumos-gate repository; everything is in there in a branch (which should be pretty discoverable if you're familiar with ARCHitecture...hint hint).

Also, I do have a question regarding the psp images you guys use. Are these 'standard off the shelf' images, that one could pull from any distributed Epyc bios image, or did AMD cook you some special ones for your agesa-less usecase?

We use the distributed PSP firmware blobs, if that's what you mean. Unfortunately, we don't (yet!) have any insight into the PSP itself; AMD's kept it pretty tightly locked down.

I think it's accurate to say that, from the PSP's perspective, it thinks that it is loading AGESA;

ryzen consumer

Yeah, seems to be the status quo. I hope to change that, however.

Good luck!

apcb stuff

cool, good to know.

So, back to the original topic of 'missing repos'. When they do go public, is there somewhere I should watch or be subscribed to, to be alerted to the fact they have done so?

I think look for the appearance of an, amd-host-image-builder repo in the oxidecomputer org. I don't know if there's a way to wait for that?

[hanetzer]

Dunno if there's a mechanism, other than maybe setting up a cron job to try and clone it or so.

On an unrelated note, is there somewhere one could possibly have a chat about some difficulties I'm facing? I've managed to get coreboot's bootblock and romstage to execute, but it always reboots shortly after starting the FSP memory init (yeah, amd is shipping an intel-like FSP binary in coreboot as of right now).

This reboot takes the exact same amount of time, as best as I can tell, no matter what the particular alteration to the flash I've made is (full erase, replace the type 0x62 bios binary with another x86 payload but leave the rest of the flash alone, full replacement with coreboot) so I think it may be something like a watchdog that the vendor's binary turns off or feeds.

[dancrossnyc]

Dunno if there's a mechanism, other than maybe setting up a cron job to try and clone it or so.

On an unrelated note, is there somewhere one could possibly have a chat about some difficulties I'm facing? I've managed to get coreboot's bootblock and romstage to execute, but it always reboots shortly after starting the FSP memory init (yeah, amd is shipping an intel-like FSP binary in coreboot as of right now).

Huh. We don't use anything like that.

This reboot takes the exact same amount of time, as best as I can tell, no matter what the particular alteration to the flash I've made is (full erase, replace the type 0x62 bios binary with another x86 payload but leave the rest of the flash alone, full replacement with coreboot) so I think it may be something like a watchdog that the vendor's binary turns off or feeds.

This doesn't sound like anything that we use, so I don't know how much help we'd be. @daym, is this something you have any familiarity with?

[hanetzer]

Just an update. Turns out the reboot was, of all things, the rgb controller on this motherboard. It acts like a watchdog, and you have to send it an i2c payload very early on to prevent it from rebooting the system. I've made more progress but there's still a lot of issues to be dealt with.

[dancrossnyc]

Huh; that's wild. At any rate, congratulations at moving past that roadblock!

[hanetzer]

On another note. I stumbled across your serialice fork while researching this stuff for myself. I notice a lack of an asrock_epycd8.c and any lua filters under simba for it, was hoping for some info on how to get around a roadblock I'm facing in my pursuit: while I have a mostly functioning serialice setup for my above mentioned board (I've since exchanged the 2200g for a 3200g as the latter is hypothetically better supported in coreboot) which does show me quite a lot of nice io stuff (hell, I even managed to hack some debug printfs over serial into the vendor bios; runs on both real hardware [until it locks up for unknown reasons] and serialice [until it locks up for semi-known reasons]

My problem is, when the stars align just right, I can get a damned good serialice run going (the vendor fw is extremely touchy about rtc and nvram stuff lmao), but eventually it always ends up at a particular loop:

3b71.ef9e    RH.U    [0000:ffdff026]   MEM: writel f80000b8 <= 03b10564
3b71.ef9f    RH.U    [0000:ffdff0a7]   MEM:  readl f80000bc => 00000000

This code exists in the UEFI module AmdNbioSmuV10Pei, and resembles the coreboot code src/soc/amd/common/block/smu/smu.c:smu_poll_response

Did you guys run into a similar issue? If so, if you overcame it, how?

[dancrossnyc]

Hmm, I don't think I know what serialice is; it's definitely not part of phbl, though. :-) Perhaps ask on that repo? All of our interactions with the SMU are in our kernel fork.

[wesolows]

On another note. I stumbled across your serialice fork while researching this stuff for myself. I notice a lack of an asrock_epycd8.c and any lua filters under simba for it, was hoping for some info on how to get around a roadblock I'm facing in

That is some extremely old work of mine that dates to an era long before we had hardware (even reference platforms, never mind our own). I don't think I ever got it working completely and I never ran the AMD UEFI code through SerialICE. I apologise for the attractive nuisance; it'd probably have been better to delete that repo as it was never used for anything in our bringup process but was a dead end we didn't pursue.

3b71.ef9e RH.U [0000:ffdff026] MEM: writel f80000b8 <= 03b10564 3b71.ef9f RH.U [0000:ffdff0a7] MEM: readl f80000bc => 00000000

This code exists in the UEFI module AmdNbioSmuV10Pei, and resembles the coreboot code `src/soc/amd/common/block/smu/smu.c:smu_poll_response`

Did you guys run into a similar issue? If so, if you overcame it, how?

I don't think we did, no. It is necessary to poll the SMU as part of PCIe setup, and the address of the RPC registers to use is specific to the processor family. It is possible (quite easy, in fact) to make the SMU panic and reset the entire processor, but I don't believe I've ever seen it just go out to lunch and never reply with completion to an RPC. I can't comment at all on Ryzen either, but the code we have for Milan can be found in e.g. https://github.com/oxidecomputer/illumos-gate/blob/8d3a008f6738cf5486c9c168c09a5fc0482a06e7/usr/src/uts/oxide/milan/milan_fabric.c#L2118 and associated. If coreboot already has code for doing this on your CPU and your intent is to use coreboot, that will probably be the better code to read than ours.

[hanetzer]

Hmm, I don't think I know what serialice is; it's definitely not part of phbl, though. :-) Perhaps ask on that repo? All of our interactions with the SMU are in our kernel fork.

Well, that repo didn't have an 'open issue' option so couldn't do that there, lol.

@wesolows well, coreboot on this board is in a 'eh' state. I can get it to do some things, but it does not result in a usable system. can load payload by not sending dxio descriptors and nop'ing out a cpuid check in the fspm binary, and said payload can boot linux, unsuccessfully. I've managed to get serialice working a bit better; I think part of it is mismatched psp and x86 binaries on the real device and the emulated one, respectively.

[daym]

My primary interest was parsing and decoding the apcb binaries I pulled out of vendor bios images using psptool, as my initial and current goal is pulling the psp images out of the vendor firmware for repackaging/reuse (but not redistribution) in {c,}oreboot firmware, similar to how one may pull the ME firmware images out of intel bios images for a similar purpose.

I think it would work for that. I'd check with @daym, though, as he's the expert there. :-)

If you can get psptool to work that far, it should be possible (it worked for me a few years back). Heads up though that amd changed the firmware metadata format a year or two ago--and psptool messes up with the new format a lot.