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