RaptorCS Blackbird support #3341
Conversation
Hostboot config is basically Witherspoon but with LPC PORT 80h turned on defconfig is from Witherspoon, with Blackbird XML setup from Raptor's tree Signed-off-by: Stewart Smith <[email protected]>
|
I've sent the skiboot patch upstream: https://patchwork.ozlabs.org/patch/1208967/ |
|
Hmm, I guess I should make the same for Talos :-) |
|
Did the IPL observer stuff ever make its way in to upstream? Especially w/ Talos II it's pretty critical. ;) |
|
On Sun, Dec 15, 2019, at 10:45 PM, Timothy Pearson wrote:
Did the IPL observer stuff ever make its way in to upstream? Especially
w/ Talos II it's pretty critical. ;)
Not sure on the BMC side.
The host side, we have it upstream in skiboot, but the hostboot part isn't there, and there's nothing in the petitboot environment which would do the final write of 254,254.
|
|
I have started https://wiki.raptorcs.com/wiki/Firmware_Upstreaming (it got few changes from @merklort for the hostboot part) some time ago, probably based on the Talos GA branch (2018-04-19), not on the v2 firmware (2019-04-16). |
|
I know that was one of the main blockers to upstreaming -- we don't want to have the support issues associated with OCC reads during IPL (or completely disable fan controls, for that matter). The former in particular was quite expensive as the symptoms lead to spurious mainboard / CPU RMA in some cases and escalation to higher level support in many others. The alternarnative, no fan controls, leads to attempted customer initiated RMA as no one expects a desktop to be that loud (and also ends up.being a bit of a PR black eye for POWER itself). While I'd really like to see upstream support, we need to have the IPL observer support merged into the subcomponents first. Any chance that can happen? |
|
Can't we start with the machine specific "overlay" in openpower/patches/talos-patches until they are properly upstreamed? How much of the non-upstream patches is shared between Blackbird and Talos? |
|
It’s probably a fair bit. I’ll try and get an updated PR sometime in the next day or so
…Sent from my iPhone
On 16 Dec 2019, at 08:33, sharkcz ***@***.***> wrote:
Can't we start with the machine specific "overlay" in openpower/patches/talos-patches until they are properly upstreamed? How much of the non-upstream patches is shared between Blackbird and Talos?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
There were some internal network issues recently so I'm guessing that is what the CI fail probably is. |
|
retest this please |
Yes, a local set of patches combined with a RCS overlay directory would work. Most of the modifications are common between Talos II / Blackbird / Condor; please feel free to pull whatever you need from our repos as we have retained the original Apache / GPL / BSD licenses for the modified components (newly written components are normally GPL v3 from our side, licenses are in the file headers). I just don't want a functionally broken upstream version. As to how we get there, I'm quite flexible. :). That being said, we do rely extensively on the RFC LPC communication (both for boot status and for other tasks); the BMC firmware assumes it's available and makes assumptions about what kind of information is provided, so I don't want to modify the "API" of sorts that it's using. The Talos II beta firmware is far closer to the Blackbird firmware; the intent was to merge all three of the RCS hardware platforms onto a mostly common codebase. Don't bother with the older codebase associated with the currently shipping Talos II production firmware; it was largely rewritten for Blackbird and the Talos II beta FW. |
|
The v2 for skiboot patch, which talks IPL Observer: https://patchwork.ozlabs.org/patch/1210958/ |
|
retest this please |
|
@stewartsmith Thanks for that! Getting the IPL observer stuff into the SBE and hostboot would also be good -- in particular, the SBE patches (in our tree) drive the progress bar during the first part of the Blackbird boot, and have proven very useful over time to determine bad CPUs / sockets from hostboot issues at a glance. |
|
hoping we can have someone still working for IBM push the SBE patches, I’m a bit less inclined to mess with mine now that I don’t have crorecoversbe laying around...
…Sent from my iPhone
On 16 Dec 2019, at 22:44, Timothy Pearson ***@***.***> wrote:
@stewartsmith Getting the IPL observer stuff into the SBE and hostboot would also be good -- in particular, the SBE patches (in our tree) drive the progress bar during the first part of the Blackbird boot, and have proven very useful over time to determine bad CPUs / sockets from hostboot issues at a glance.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I'd be willing to test any patches to upstream, since I do have access to the recovery system... |
|
Just dug this back up: |
|
I have updated https://wiki.raptorcs.com/wiki/Firmware_Upstreaming with SBE, HCODE, OCC and Hostboot. Seems there is just few changes in the Raptor branches for these components. |
|
Most center around the IPL observer, bit frustrating to have the simple PRs sit for > 8 months TBH. |
|
Is the SBE PR the only one outstanding? I understand the frustration, I'll try to shake a tree. |
|
If I see right in the wiki page above, then we need https://git.raptorcs.com/git/talos-hostboot/commit/?id=d90e6c513094231f622a427030f3dbca1eeb5ed5 for the hostboot part. @madscientist159 will know if there has been a PR already. |
|
Of course the link was added after I read it. It looks like 3 new commits. Make some PRs and I'll at least get them into the pipeline (with no promises on getting a lot of attention). |
|
op-build WIP with Talos support = https://github.com/sharkcz/op-build/tree/talos be aware, not even compile tested |
|
FWIW 0xfefe is the IPL observer code for Linux online and userspace launched. Skiboot should NOT be sending it; it confuses two parts of the process and tells the BMC IPL has successfully finished when in fact it's only partially done. |
|
@madscientist159, I understand your position. The open question is, whether there is a way to do the signalling correctly and upstreamable. How do the other platforms handle this kind of communication between the host and BMC? |
|
@sharkcz I've seen a bunch of different methods over the years including writes to scratch registers in the southbridge. What exactly is wrong with a small userspace tool poking the last status code out the LPC port? If it's just that the kernel doesn't have a standardized LPC API, maybe all we need is a simple powernvlpc module? The idea is that 0xfefe is only poked out once petitboot is either about to start (we've already tested our initramfs is working, shell works, etc.) or once petitboot is actually starting. If we reach end of skiboot status codes, and don't reach 0xfefe in under 15 seconds, something's wrong and a firmware rebuild / reflash is in order. |
|
@madscientist159, nothing is wrong, it's for my education and overview :-) Also I'm thinking how it could be integrated into upstream. |
|
@sharkcz we actually need an LPC access module for other reasons, something that can allow root to read / write bytes, nothing fancy. I can see why it might be desirable to disable the debug interface, but LPC access is a useful and reasonable thing to have. I wonder if we can do a simple device node that takes basic commands like IO_LPC_SET_TARGET_ADDRESS, IO_LPC_WRITE_BYTE, IO_LPC_READ_BYTE? |
|
We won’t have debugfs mounted in any secure mode
…Sent from my iPhone
On 20 Dec 2019, at 07:45, Timothy Pearson ***@***.***> wrote:
@sharkcz I've seen a bunch of different methods over the years including writes to scratch registers in the south bridge. What is wrong with a small userspace tool poking the last status code out the LPC port?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
What alternate code can I send down that kicks on fan control? By the time skiboot exits there’s nothing touching anything that wouldn’t happen during Normal runtime
…Sent from my iPhone
On 19 Dec 2019, at 15:19, Timothy Pearson ***@***.***> wrote:
FWIW 0xfefe is the IPL observer code for Linux online and userspace launched. Skiboot should NOT be sending it; it confuses two parts of the process and tells the BMC IPL has successfully finished when in fact it's only partially done.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Would there be an objection to an LPC access module in secure mode, if we were to write one? I would be open to engaging fan control on skiboot exit, but that's a BMC change. Could we send 0x80ff at skiboot exit (IIRC 0x80 is the skiboot prefix code)? |
|
Something that did just this poke? Probably not. But arbitrary access? Yeah.
…Sent from my iPhone
On 20 Dec 2019, at 08:58, Timothy Pearson ***@***.***> wrote:
Would there be an objection to an LPC access module in secure mode, if we were to write one?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Yeah was looking at arbitrary access, see my post a few above about a possible IO_ access mechanism around /dev/lpc or similar. Sounds like we'd need a secure mode filter -- e.g. if in secure mode restrict destination address to 0x80-0x82? |
Hostboot config is basically Witherspoon but with LPC PORT 80h turned on
defconfig is from Witherspoon, with Blackbird XML setup from Raptor's tree.
NOTE: without linux v5.4.3 (or at least anything more recent than v5.3.7) my Intel SSD doesn't show up in Petitboot.
Also note that the blackbird-xml project doesn't yet existing in the open-power org, so you need to grab it from my repo (or Raptor's). Consider this a request to branch mine in :)
Signed-off-by: Stewart Smith [email protected]