If and when this happens to the FW13 and is at least MVP then Framework becomes a viable option for me again. I got burned so horribly with the Intel 12th gen platform that never again will I buy a laptop without FOSS firmware already available.
I sincerely hope FW is privately supporting this effort. FOSS firmware and firmware support in general has not been well handled by this company in the past.
Hopefully the port will be complete or in a MVP stage by the end of the year.
No link in that article that I can find, so I’m not holding my breath.
However, a working alternative to Framework’s garbage firmware would be an amazing thing to happen. We are still tortured with terrible firmware bugs over a year into this laptop.
@admins, best to merge with the pre-existent thread:
For the uninitiated like me, what would coreboot support mean? Is it like a custom-bios or something?
I think so. The big advantage would be that Framework would be free to focus on newer hardware without having to support old boards via frequent software updates in order to patch exploits.
Ah gotcha. My first thought was that it might expose options available through something like smokeless easier to get to, but from a business perspective I could see the sense in what you say.
It was a private message from the developer to Michael who runs Phoronix. He said as much in the comments on the article.
It replaces the InsydeH2O BIOS currently in use with a FOSS alternative. This would enable the community to implement features desired that Framework has failed to enable such as ReBAR support and yes, provide firmware support after Framework abandons/EOLs products.
There are theoretical security benefits that come inherently with open-source as well. Plus the ideological consistency between R2R and FOSS.
Ahhh, that’s pretty cool. Thanks! Like many other’s here, I’m also a FOSS enjoyer.
I mean, is there a point in spending time on writing blog posts about something that’s heavily WIP?
After ~2 days of working on API integration we’re already hitting PCIe init. Problem is that SIL_CONTEXT isn’t properly documented, so I need to bother Martin Roth (who released Phoenix OpenSIL) to give me more details.
I thought I was missing something obvious, but my coworker also couldn’t figure it out (even after looking at OpenSFI spec), so they asked about it for me: phoenix_poc: What is `SIL_CONFIG` supposed to be? · Issue #41 · openSIL/openSIL · GitHub
If it would’ve been properly documented, I reckon we’d already be at the point of reaching the payload 
I also don’t have to “proper” (read: NDA) documentation from AMD (I thought I did, but apparently I only have access to Intel one… which makes sense since it’s my first time working on modern AMD hardware). Don’t need it for now and I’ve seen public BKDG floating around for Phoenix so that should be enough if it explains MMIO addressing etc.
P.S: To answer the question I’ve seen floating around: Can’t vouch for newer generation of AMD systems, but on this one (Ryzen 7000, Phoenix) PSB (Platform Secure Boot) is disabled.
I’m doing this on a completely regular system (in fact, I’m a bit shocked my manager allowed me to do this to my work laptop). In other words - yes, everyone will be able to use it once it’s in usable state.
Thanks for your efforts! I’m sure the fruits of your labors will be greatly appreciated when it’s all done!
@ellyqw
What bits are working on your opensil bios?
From memory, the steps are approx:
Your information is outdated (although mostly correct in terms of Intel CPUs).
If i may do a bit of shamelss self-plug here, I explained it in detail at 38C3:
Also worth watching in terms of PSP:
Another (older) shameless self-plug. relevant to the discussion only because of CrosEC:
On AMD Zen architecture you don’t have CAR anymore. Memory initialization is done by the PSP (Platform Security Processor), a tiny ARM core(s) (one per CCX). So it looks more or less like:
https://f.sakamoto.pl/elly/coreboot/boot-cb-lotus-opensil.txt
