-
-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
coreboot Power9/Power10 support #720
Comments
Interests to have Open Source Hardware and Compartmentalization for the future of computing: |
@pietrushnic :) |
@3mdeb is evaluating the effort of porting the POWER9 Talos II and Talos II Lite to coreboot. The plan should be announced soon. |
Underway! |
@tlaurion As you know the coreboot effort is progressing (https://github.com/3mdeb/openpower-coreboot-docs/tree/main/releases, https://github.com/3mdeb/coreboot/tree/talos_2_support_payload). I believe we are at the point where we could start working on heads, so we can start testing faster once the coreboot bits are in place. I can see following tasks:
Please let me know if you see anything more. If the plan looks ok, we could split them into issues and track the progress in public here. |
There are two more complex threads as well here.
Currently, we are reusing the existing build scripts from the op-build repository. We output PNOR file from there and replace Hostboot with coreboot. We propose to do the similar here. So we could build the PNOR file first from the original op-build repository and then replace selected partitions:
There is a tool which allows us to modify the existing PNOR firmware file: https://github.com/3mdeb/openpower-coreboot-docs/blob/main/devnotes/porting.md#ffs-tools |
@macpijan I can try to do a quick PR draft on which the first points would be addressed as a start.
Would that be helpful as a start? It seems it would ease onboarding to heads ecosystem, while the build will probably fail, of course. |
@tlaurion Yes, that would be helpful and speed things up. |
I decided to not wait and give it a try and might have addressed basic points already, hope you didn't start yet. My WIP changes are here if you want to take a look and maybe correct obvious mistakes early on. Doesn't build yet (kernel build complains about non-retpoline compiler). |
In regards to Linux config: I believe this one is rather used: https://git.raptorcs.com/git/talos-op-build/tree/openpower/configs/linux The config dumped from running device: https://github.com/3mdeb/openpower-coreboot-docs/pull/41/files |
@SergiiDmytruk You can remove support inside of the linux config. Everything looks good at first glance. |
Thanks.
I've seen some of those patches applied in 5.6-rc, but others might be power-specific. I'll make this kernel version specific to power. |
Limiting to power build didn't work as I expected. This: else ifeq "$(CONFIG_LINUX_VERSION)" "5.5-openpower"
linux_version := 5.5
linux_hash := a6fbd4ee903c128367892c2393ee0d9657b6ed3ea90016d4dc6f1f6da20b2330 Only suggests that it shouldn't be used for anything else, while patches are still under |
@SergiiDmytruk Right. Well, the same logic for git/url could be used to have the module depend on ?= by default if not defined and have power linux patch dir and build dir being different then other x86 arch. Not sure what would be the best option here. But once again, if the patches to linux are not breaking x86, maybe they can coexist? |
Another approach could be to play around https://github.com/SergiiDmytruk/heads/blob/4d9ef955bcc23fb362a4113002afa4fe1545be17/modules/linux#L30 And append the arch to the linux_base_dir. I have not reviewed the patches content, but if the build dirs are different from archs, even if same kernel version, it would result in a different build dir. So no need for mr_proper, which would mean not confict between board builds even on CI. |
I have a summary of the patches, they change things in generic files, I'm not sure it's a good idea to use them for x86, maybe they weren't tested there at all:
This is what I used. Frankly, I didn't understand the first one.
For the kernel, yes. However, other modules that are built in-tree (in I've re-committed changes and made #1002 hoping for feedback on the changes I had to make to build successfully. |
@SergiiDmytruk The XHCI patch I believe is to allow the device to survive a kexec(). x86 tends to get around a lot of those types of issues by not kexec()ing in most use cases, whereas POWER kexec()s every time an OS loads. |
This is now stable under 0.7 Fixed
Known issues
|
https://doc.coreboot.org/contributing/project_ideas.html#support-power9-power8-in-coreboot
Hardware provided by RaptorEngineering
The text was updated successfully, but these errors were encountered: