Difference between revisions of "Firmware Upstreaming"
(note merge of basic support upstream) |
(Tone down my earlier comments a bit :)) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 33: | Line 33: | ||
* Initial port is upstream from https://github.com/open-power/op-build/pull/3341 as of https://github.com/open-power/op-build/commit/592eff791509d66525aea78ae8d35e99c8626a56 | * Initial port is upstream from https://github.com/open-power/op-build/pull/3341 as of https://github.com/open-power/op-build/commit/592eff791509d66525aea78ae8d35e99c8626a56 | ||
+ | |||
+ | * WIP support for Talos is https://github.com/sharkcz/op-build/commits/talos | ||
+ | ** uses a new sysvinit service for signaling to BMC via pnv-lpc | ||
Other things to consider from Raptor's branch: | Other things to consider from Raptor's branch: | ||
Line 39: | Line 42: | ||
* adds openpower/scripts/talos-extra-cleanup script - could be generally useful | * adds openpower/scripts/talos-extra-cleanup script - could be generally useful | ||
* adds pnv_lpc tool - possibly could be omitted for Talos if skiboot uses LPC observer same as Blackbird | * adds pnv_lpc tool - possibly could be omitted for Talos if skiboot uses LPC observer same as Blackbird | ||
+ | ** From a technical perspective, sending the IPL complete code from skiboot is a UX violation. That particular code fires off a number of user visible events including the IPL complete beep, and it must only be sent once petitboot's userspace is online (i.e. the chance of something firmware-related having gone wrong is vanishingly small). Sending it from skiboot not only adds significant delay from the purposefully attention-getting beep to anything showing up on the screen (the boot delay with no graphical output is already a major problem on POWER), but it also allows a lot of things to potentially go wrong after we've just told the user "the system passed all of its boot checks and is online". I'm working on a lockdown-compliant LPC driver module to be upstreamed, but won't have it before Jan. 2020. (Yes, I know none of this was documented; once we have an upstreamed version of this I'll go back and see about writing proper documentation). [[User:TimothyPearson|TimothyPearson]] ([[User talk:TimothyPearson|talk]]) | ||
=== ... === | === ... === | ||
== OpenBMC firmware == | == OpenBMC firmware == | ||
+ | |||
+ | == OpenBMC <-> host firmware communication == | ||
+ | works by writing bytes over LPC to ports 0x80, 0x81, 0x82 | ||
+ | * SBE sends ISTEPs to ports 0x81, 0x82 | ||
+ | * hostboot sends ISTEPs to ports 0x81, 0x82 | ||
+ | * skiboot sends single byte describing module and status to port 0x80 | ||
+ | * skiroot signals the user-space is ready by writing 0xfe, 0xfe to ports 0x81, 0x82 |
Latest revision as of 14:14, 27 December 2019
This page should cover firmware upstreaming for Talos and other RaptorCS systems. Because it would be very useful to be able to build new firmware directly from upstream sources.
Contents
Host firmware
working with the 04-16-2019 branch, which is in the v2 firmware
SBE
same for Blackbird and Talos = https://git.raptorcs.com/git/talos-sbe/log/
- Send IPL status codes to BMC over LPC port 81h/82h = https://github.com/open-power/sbe/pull/15
- Disable SBE console print as it significantly slows down SBE execution
HCODE
same for Blackbird and Talos = https://git.raptorcs.com/git/talos-hcode/log/
- Update ring files from hostboot-binaries
- Allow split of HOST and TARGET toolchain binary names - useful, but likely not required
- Revert "Self Save: Added support for SPR self save in CME hcode(func ver)" - should be superceeded by a real fix in https://github.com/open-power/hcode/commit/cc0b781abd67673240c208df7c77d2d37906057f
-> no changes needed
Hostboot
same for Blackbird and Talos = https://git.raptorcs.com/git/blackbird-hostboot/log/, resp. https://git.raptorcs.com/git/talos-hostboot/log/, but they carry the same patches
- cap voltage offset when biased
- Add detailed ISTEP output option to hostboot
- Don't try to add proprietary CAPP microcode image to PNOR (could be skipped in upstream)
OCC
same for Blackbird and Talos = https://git.raptorcs.com/git/talos-occ/log/
- remove prebuilt GPU1 binary - not required for upstream
- Fix build failure on GCC8
skiboot
Tracked in patchwork: https://patchwork.ozlabs.org/patch/1210958/
op-build
- Initial port is upstream from https://github.com/open-power/op-build/pull/3341 as of https://github.com/open-power/op-build/commit/592eff791509d66525aea78ae8d35e99c8626a56
- WIP support for Talos is https://github.com/sharkcz/op-build/commits/talos
- uses a new sysvinit service for signaling to BMC via pnv-lpc
Other things to consider from Raptor's branch:
- skiroot kernel config changes
- adds openpower/scripts/talos-extra-cleanup script - could be generally useful
- adds pnv_lpc tool - possibly could be omitted for Talos if skiboot uses LPC observer same as Blackbird
- From a technical perspective, sending the IPL complete code from skiboot is a UX violation. That particular code fires off a number of user visible events including the IPL complete beep, and it must only be sent once petitboot's userspace is online (i.e. the chance of something firmware-related having gone wrong is vanishingly small). Sending it from skiboot not only adds significant delay from the purposefully attention-getting beep to anything showing up on the screen (the boot delay with no graphical output is already a major problem on POWER), but it also allows a lot of things to potentially go wrong after we've just told the user "the system passed all of its boot checks and is online". I'm working on a lockdown-compliant LPC driver module to be upstreamed, but won't have it before Jan. 2020. (Yes, I know none of this was documented; once we have an upstreamed version of this I'll go back and see about writing proper documentation). TimothyPearson (talk)
...
OpenBMC firmware
OpenBMC <-> host firmware communication
works by writing bytes over LPC to ports 0x80, 0x81, 0x82
- SBE sends ISTEPs to ports 0x81, 0x82
- hostboot sends ISTEPs to ports 0x81, 0x82
- skiboot sends single byte describing module and status to port 0x80
- skiroot signals the user-space is ready by writing 0xfe, 0xfe to ports 0x81, 0x82