@Niko_Cantero thanks for cc’ing me, but I’m not sure how it helps. Maybe you are not aware I’m the founder of 3mdeb company which does coreboot development for a living. Finding or training coreboot developers is not an easy task, but competition is always good for the market, so we wish Framework the best of luck with filling that role. We hope it will grow the open-source firmware community and market.
Because of our commitment, we provide free training resources through, OpenSecurityTraining2 if someone would be interested in starting to learn coreboot or UEFI development or wants to transition from another role.
One thing that is often misunderstood is that doing coreboot for a hobby is a completely different thing than doing coreboot for a daily job. Some who understand that and know coreboot, often don’t want to transition to making it professional because they will lose their cool hobby. This is part of the problem while hiring coreboot developers. I fully respect that position, but an incorrect approach to porting often leads to failed projects and unmaintained ports in coreboot.
Most vendors prefer to build their teams and avoid dependency on external service providers. That is a strategic choice. Part of the Dasharo Team’s commitment is to show there is a better approach to coreboot development than the expensive path of team building. We hope we are transparent enough to be an example.
Do you have Felix’s contact info from the talk? Is he an employee of yours or a freelancer? If a freelancer, would you mind informing him or the possible position he may/may not be interested in?
Follow up question, has framework reached out to any of those it already sent boards too? It seems to me like they would be the obvious candidates interested in such a position.
Felix in reply (part) to me on Mastodon (@migy@chaos.social) 3 days ago
I’m definitely going to continue the work on it. (We are planning to be present on some conferences with coreboot, so no chance to get around it now ;))
And yes, I made progress before, but nothing that will work on any other device than mine. Let me catch up and I will try to give some updates soon.
That’s good to hear that framework sent out the job option. I am stunned it happened this soon. I was beginning to think they wouldn’t do it for a while. I am glad to be wrong here.
Only one thing remains though and that is someone accepting the application.
This goes without saying, but intel me being disabled would probably be desired for this cause as well. In any case, this is a good sign.
Thanks for the notice. Whether its dasharo, or coreboot that gets ported, both are very good options. If one coreboot based bios gets ported others will happen in the future anyhow.
I continue to wait and see I guess then. Hoping though!
It isn’t standard and no firmware makes it standard. There is no known way of eliminating the ME, the most people can do is tell it to turn itself off. This does negatively impact the laptop but the tradeoffs might be worth it to you. It isn’t easy to deal with in the slightest.
I was browsing coreboot’s Gerrit code review and noticed some patches pushed about an hour ago: “mb/framework: Initial push of azalea (Framework 13 AMD 7040)” https://review.coreboot.org/c/coreboot/+/81978
Edit: For reference, Martin Roth (the author of those patches) works on coreboot at AMD. However, I do not know conclusively the level of official involvement, if any, that AMD or Framework have had in that code, the full extent of it’s functionality, or if there is anything different about the board that is being developed for compared to the publicly available production boards.
I hear it wastes more electricity in newer gens, which is… to say the least, stupid.
It is definitely a manufactured problem. when intel me is on, it can only ever waste more power, so there is something unknown going on there if it wastes more power when its not on.
The Azalea (Framework 13 Ryzen 7040) coreboot port I pushed is not being officially supported by AMD. It’s also only a proof of concept firmware at this point, and will not be feature complete, so I’m not sure it’s going to be suitable for regular users. It will boot and run linux and hopefully windows, though I’m not focusing on windows. I do have access to internal tools and data which will help me with the port, but it’s not my job inside AMD to do this work.
The main piece that I’m not planning on doing is suspend. Maybe it can work, but getting suspend to be solid is probably the hardest part of any firmware. There are lots of hardware quirks. Hopefully hibernate will work, but that’s done outside of the firmware, and is more about just booting the system again, then restoring context.
In addition to Azelea, I’m also planning on doing a Lotus (Framework 16 AMD 4070) port that will be taken to the same quality level. I’m writing this and doing the Azalea port on my personal Framework 16 laptop that I received last week (batch 8), so I have a big personal incentive to get it working.
I’m hoping that whatever AMD platform comes next from Framework will be fully supported on coreboot, but I don’t know anything about any future plans involving framework and AMD, so this is just my personal hope as a consumer.
If anyone wants to help with testing the Azalia port (again Framework 13 Ryzen), feel free to reach out - my contact information is all over the coreboot project. 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.
If anyone has any questions about the project, feel free to reply here and I’ll do my best to answer.
(but are on Intel) thanks for the work and good luck