I’ve talked in the past with both Daniel and Kieran, but it’s been a while. They’re both added to the first patch in the series as reviewers.
4 Likes
Thank you for your great work!
Could you tell me where the Git repository of the “The Azalea (Framework 13 Ryzen 7040) coreboot port” is, and the links of the patch series?
The official Git repository is at https://review.coreboot.org/coreboot.git (as the GitHub mirror indicates) and the latest patch in the patch series is at https://review.coreboot.org/c/coreboot/+/81993/2. There’s a “download” button there which will display git commands to download the patch; use the “branch” one to download that latest patch and all the parent commits to a new branch in the cloned coreboot repo.
3 Likes
I’ve just setup an account to say thank you to everyone trying to bring coreboot support to Framework laptops. This (and lack of dGPU) is the only thing that stops me from getting one.
5 Likes
I have a dGPU … 
but using the GW 16 
3 Likes
@Matt_Hartley is there any way Framework can provide a Framework laptop 13th AMD so that I could start working on Coreboot support as well with Martin who works at AMD at the moment and it driving this effort mainly.
I have a FW 13 AMD already but it is my main driver machine, I can’t just randomly swap the BIOS or flash it on a whim and hope it will turn on/work perfectly and be very stable.
EDIT : I also have contacted the Framework support with this inquiry and will update here if there is any news.
EDIT 2 : @Mario_Limonciello would you know if AMD is interested in Coreboot ports or is Martin just working on this as a hobby port (just for learning/experiment sake?)
EDIT 3 : @Piotr_Krol I contacted you on LinkedIn, make sure to check your inbox 
4 Likes
When you say Martin, I’m presuming you’re referring to User:MartinRoth - coreboot?
There is no formal plan for coreboot right now on F13, but if you want to work with Martin on helping it, more power to ya.
If it does get functional and usable enough I will volunteer to wire up the fwupdmgr switch-branch and all that stuff for it.
4 Likes
I’m completely fine with having that conversation in public. I’m not sure I understood all your questions, but feel free to continue the discussion here so the whole community will be informed about the 3mdeb and Dasharo Team positions.
4 Likes
Sure, is there any interest from Framework to pay for Coreboot support and BIOS portage @Matt_Hartley ?
If it’s only funding that’s needed (ie. not needing a special non-fuse-blown unit from FW?), perhaps consider crowd-funding this effort? I for one would be interested in pitching in to make this happen regardless of official plans.
9 Likes
I’d disagree with your comments regarding no one in their right mind using windows. Everyone has their own points of view and reasons for using the operating systems they do, and being a blind computer user, I’ve found nothing more efficient to use with a screen reader than Windows, even Linux isn’t as efficient as it could be, especially when you get an update that may break audio or cause a kernel crash, etc. I have all three. Mac, Windows, Linux, and each has their specific purpose for me, but for primary computer use, it’s windows.
I’ll just leave it at that.
7 Likes
We have removed an inflammatory and off-topic post.
Keep in mind this thread was closed once before. So that we don’t have to close this again, we’re being more proactive.
This thread has gotten productive recently and it might accomplish something - let’s keep it that way. Please keep posts on-topic, cooperative and factual.
4 Likes
You shouldn’t need anything like that. If you look at the output from fwupdmgr security you’ll notice that “Processor rollback protection” is not set. You can flash to the SPI part with a hardware flash tool and the processor won’t reject it.
In order to do a “smooth” software only migration from UEFI to coreboot without a hardware flash tool would however require the support from Framework (they would have to sign a “transition” BIOS image).
8 Likes
Why would framework not try and crowdfund it ? I’m not sure I can deliver Coreboot on my own with no support from Framework nor any other devs help, as well as AMD support too most likely.
Right now, I’m just trying to compile what is available for the Framework 13th AMD and see if I can run it using QEMU.
1 Like
That’s perfect for developping I guess thanks !
Yes I’m referring to him, I don’t know if I’ll be of much help but m willing to check if I can help move this forward.
Thanks for the contribution you might do once this gets somewhere concrete
I’m happy to pitch in too
Right now, I’m just trying to compile what is available for the Framework 13th AMD and see if I can run it using QEMU.
Just a note, coreboot (and firmware in general) is hardware specific, so a coreboot ROM built for the Framework 13 AMD will not run in QEMU.
6 Likes
Azalea port update - Framework 13 AMD 7040 series
Hi All, I’m really happy to have all the interest here, so I thought I’d write an update. Sorry it got a bit long.
For anyone who is interested in testing, I’ll try to get a binary ready for you over the next week or so. I’m working with my team at AMD to get some binaries needed for the initial release pushed to the amd_blobs repo. This might take a bit of time as they test interactions between different versions of the binaries.
The first version of the Framework port will be using the FSP binary implementation that was used with previous AMD chromebooks and not openSIL. I don’t know yet when the Phoenix openSIL might be released publicly, but it will be a Proof-of-Concept only, similar to the released Genoa package. Once that’s released publicly, the plan is that the Framework implementation will be updated to test with either FSP or openSIL.
Before sharing the binary with anyone, we need to be sure that anyone testing with it has a hardware solution in place to restore their existing firmware if things go badly for them. I don’t want to brick anyone’s board if their system doesn’t boot with my image. My previous recommendation still stands, and shouldn’t be too difficult for anyone with decent soldering skills.
This requires that you have a SPI ROM programmer that will program 1.8V. I’d
recommend desoldering the SPI ROM chip from the board and soldering down
a socket so you can swap roms back and forth quickly. I think you’d want to buy
additional SPI ROM chips and set up a way to flash the chips off the board, then
drop them into the socket.
Known issues:
As I said before, suspend won’t be implemented, at least not initially, and maybe not ever. This includes both S3 and S0i3. The OS’s hibernate functionality is probably your best bet.
I haven’t tested USB4, so I suspect it will be broken and that those ports will only work as USB3. We should be able to get that working eventually, but I don’t want to promise anything.
Boot time will also initially be a problem. coreboot doesn’t currently update the APCB data with the information about the SoDIMMs installed, which means that the system will completely re-initialize memory on every boot instead of using the saved APOB data. This wasn’t a problem on chromebooks because they all used soldered-down memory.
Those issues aside, most of the basic functionality should be working. I do appreciate the offers to help test - that’ll help find any of those harder to nail down issues. Not dealing with suspend also makes this significantly easier. During testing, the hardest issues are always those relating to power management. coreboot uses a very small set of SMI handlers, which was historically another place for hard to solve issues.
Finally, for anyone not familiar with coreboot, there aren’t really a lot of setup options supported compared to a typical BIOS or UEFI firmware. Various people at coreboot are currently working to expand this and have a full-featured setup engine, but that isn’t currently available. Changes to functionality mostly get done at build time. If there are options that are important to people, I’d be happy to help coordinate work between people to make those options available.
I do want to note that I was supplied a Framework 13 device by AMD at Framework’s request, but as I said before AMD is not otherwise sponsoring this work. I work in the group that does the core firmware, which currently has the coreboot expertise to do this work. The rest of my team is helping as well, just not with doing the actual port.
If it’s only funding that’s needed (ie. not needing a special non-fuse-blown unit from FW?), perhaps consider crowd-funding this effort? I for one would be interested in pitching in to make this happen regardless of official plans.
If someone wanted to raise some money for additional features beyond what I have planned to be done by one of the amazing coreboot consulting firms, that’d be great. Please do keep in mind that the azalea port likely won’t ever be more than a proof-of-concept simply because of the state of the AMD FSP and openSIL codebases for the Phoenix chip. I don’t begrudge Framework at all for not paying to get a coreboot port done - that’s expensive and they’re still a small company. I appreciate what they’re already doing in pushing to make things open.
Martin
37 Likes
This is very exciting. I’m currently working on a different coreboot-related project, but after that’s dialled in, I might be willing to treat my AMD FW13 as a guinea pig for testing. I run Linux on it exclusively, and while suspend is nice to have, I bet I could live without it. I’ll keep my ears open.
2 Likes