[RESPONDED] Coreboot on the Framework Laptop

General Topics
553

@Second_Coming, I suggest otherwise. @Alex_Shpilkin explained well why this isn’t the ideal way to provide this. A third-party diagnostic utility that operates on a cut-down version of a Linux or BSD-based OS, invoked from a flashed USB storage device, shall be more reliable.

I’d rather have a leaner EFI with better code quality than one with myriad convenient tools embedded. FW can’t even get it to adhere to the display’s native resolution. I’d rather they kept the code to as minimal of a state as they can reasonably maintain.

I do recommend MemTest86+. It provides much of what you request. [1]

  1. bugzilla.mozilla.org/attachment.cgi?id=9509970 ↩︎

1 Like
554

I guess what I’m saying is I have no preference on how it’s done. But I have a preference on it being accessible even when SSD is dead and / or USB port is dead. End-user’s perspective. (e.g. Where the code is stored, don’t care. How the code is loaded, don’t care. Leaving that to the engineers, the experts.)

1 Like
555

@Second_Coming, if you’ve no preference on how it is achieved, then it’s already been achieved. Many a diagnostic tool that is operable from a USB storage device exists. Most people merely flash a live image of a reliable OS onto one to provide that.

556

I stated what I have a preference on, above. (Implying from an orchestration and flow perspective, minimal dependency, minimal preparation, provided right off the assembly line, first party, near frictionless.)

(e.g. I order an oyster, expect it arrive at my table in 10-15 minutes. Doesn’t matter if it’s fresh from the ocean the moment I order it, or it’s from the kitchen’s fridge. The kitchen does what it has to. I don’t micro-manage / dictate. Frictionless, to me. Arrived at the table. Customer / User experience)

(Another example: Paying by credit card: You don’t hear merchants / shops saying “But I have to work out a PoS with Visa and Master cards, with T&Cs, and paying transaction fees, and the electricity for the card reader…etc”. Just go, make it happen. Frictionless to the customer. They don’t need to know the details, the hurdles, the challenges…)

Take this concept, ignore who the messenger is, it’s more about the observation of Japanese and quality:

1 Like
557

@Second_Coming, that’s intellectually lazy. There are disadvantages to having the EFI be complex, in practice: poor security, slower boot times, and rudimentary toolsets that provide incomplete information, due to being poor imitations of more mature toolsets. [1] Having a spare USB drive with an OS loaded on it is so little work that you don’t need what you’re asking for.

If this were a discussion about a budget laptop, I’d reconsider. However, this laptop costs enough that one should be able to purchase a USB storage device.

  1. https://discussion.fedoraproject.org/t/150707/3 ↩︎

558

I don’t disagree. Don’t we want the benefits of modern day technologies without being the engineers / PhDs / researchers of everything?

The idea is, if there’s a challenge / hurdle / difficult to do….then innovate to break them down. Otherwise, we would still be using stone wheel today…with people saying mining is difficult and life threatening.

1 Like
559

@Second_Coming, indeed, but you’re asking for it in the EFI. It’s like asking for your USB controller to do fancy things. Since the EFi is already being misused, allow those with engineering knowledge to inform you that your specified implementation is a bad idea.

Conceptually, I agree that what you’re saying makes sense for a subset of users. Consequently, this might be a case of the X/Y problem.

As an example, since you want a frictionless diagnostic experience, having these tools in the EFI isn’t necessarily the best way to achieve that. Framework could, instead, partition a small part of the drive with a basic OS on it with diagnostic tools preloaded. Would that be satisfactory? Other manufacturers have done it.

2 Likes
560

That would be a step in the right direction until the edge case of bad storage / NVMe device is faced. So yeah, better than not having it provided. I’ll take progress rather than no progress at all.

1 Like
561

@Second_Coming, bad firmware memory occurs. My first FW16 motherboard, a few months ago, died for that exact reason. That’s one of the reasons why having an external storage device with your tools on it is more reliable in some circumstances.

1 Like
562

Ping, because I still hope one day we’ll get Coreboot supported, or at least an alternative to the original firmware

2 Likes
563

@Graziv, when you send a message, everyone involved is notified. Try to leave advocacy to the double-button on /1:

A Screenshot

4 Likes
564

While we’re here at least, does anyone have any info/input about how the openSIL POC release for Phoenix impacts coreboot prospects for the platform? Discussion above concludes that openSIL is effectively necessary for coreboot on AMD, so now that we have some level of openSIL, is it likely we will get a full coreboot port?

I see support for the FW 13 7040 was added a while back, and that there’s some Phoenix specific openSIL work in the git repo, but it all predates the release. Based on the description of this Gerrit patch log and the submitted documentation file, the existing port is “an unofficial port with non-production-level code from AMD” as “AMD’s FSP and openSIL firmwares for the Phoenix SoC are not fully featured”. Martin Roth notes that “[He] hopes to port from FSP to openSIL in the upcoming months, but the openSIL is strictly proof-of-concept, getting ready for upcoming platforms.” This was back in April of 2024 though, and I’m not sure how the recently released openSIL POC compares.

Is the new openSIL release “fully featured”? Is it good enough for proper coreboot support? If not, will it be at some point, say, after openSIL becomes production on new platforms and old ones are completed and become supported? Martin Roth pushed various other WIP patches that flesh out more of the platform than the merged initial patches, but these haven’t seen any activity since the initial merge. Is development for FW 7040 effectively stalled at this point? Is it likely to continue now that openSIL Phoenix is has a POC release, or not until support moves beyond POC? How much work needs to be done to get to an official port, and what outside factors does it still depend on?

Cheers.

4 Likes
565

Coreboot is soul of Linux.

3 Likes
566

My perspective on the coreboot development is even after it gets to the point where it can boot, likely there will be many things that are non-functional, things you need in order to daily drive it.

Just a guess but the list might be like:

Can’t switch to low power states (battery life very bad)

Can’t enable usb4 features

Can’t use discrete GPU

Lid sensor not working (can’t suspend)

Ram speed lower than expected

Doesn’t work with Win11

Can’t enable laptop panel

Requires disassembly and using a special clip to flash coreboot and to recover if anything goes wrong

To be fair, none of the above would be a permanent problem. They’re representative of the kinds of issues you might encounter after a laptop gets added to coreboot. It would be expected that the community continues to tinker with coreboot and gradually support improves. It might be similar in timeline to the situation with Asahi linux, only because that is another project that has achieved impressive hardware support through efforts in the community without any 1st party manufacturer support.

3 Likes
567

Actually, there is a openSIL coreboot port being worked on for the Framework 16” AMD 7040 series:

https://review.coreboot.org/c/coreboot/+/89634

I hope this is a sign that a openSIL coreboot port for the Framework 13” is on the horizon!

11 Likes
568

Has anyone successfully externally flashed their AMD 7040 Series Framework 13” with @Martin_L_Roth ‘s minimal coreboot port? I don’t know what I am doing wrong, but I can’t get it to boot. CPU fan runs and that is about it until I power off the board.

Reference: https://review.coreboot.org/c/coreboot/+/81978

This is what I have done:
$ git checkout c96201acb1d16dea90d2f8477f694346e0829dd6
$ make distclean
$ make menuconfig
$ make

In the menuconfig, I made these changes:
Mainboard → Framework
Mainboard model → Azalea (autoselected after selecting Framework for mainboard)
General Setup → Allow AMD Blobs repository

It builds the coreboot.rom with a warning:
”ADD_FSP_BINARIES isn’t selected even through this SoC relies on the FSP. The resulting image won’t contain the FSP binaries and will not boot unless they are added later.”

Is this warning real? Or, is it incorrectly referencing intel FSP which isn’t relevant to the AMD board?

I have flashed the factory rom back which successfully booted, so board is not borked.

If anyone has some guidance, it would be appreciated. Thanks!

2 Likes
569

I definitely don’t know.

But I do have some experience with older coreboot builds. So for what it’s worth you definitely need the AMD FSP blob (AGESA or their new open source SIL). I can’t imagine any other way to interpret that warning except exactly what it says. Anyone know how to include the AMD blob?

3 Likes
570

I do not have experience building or flashing coreboot, so I could be incorrect, but as I understand it:

  • There’s no need to checkout that specific patch set because it’s been merged to the main branch: better to build from the latest release or main.
  • You need blobs.
  • The downloads page has sources and blobs for each release.
  • Pre-built binaries can be downloaded from the Jenkins CI, but are considered “testing only”.
2 Likes
571

I thought that at first too. But then I searched the coreboot repo for the ADD_FSP_BINARIES config variable and found this:

\~/coreboot$ git grep “ADD_FSP_BINARIES”
configs/builder/config.intel.cpx.crb:CONFIG_ADD_FSP_BINARIES=y
configs/builder/config.ocp.deltalake:CONFIG_ADD_FSP_BINARIES=y
configs/builder/config.ocp.deltalake:CONFIG_ADD_FSP_BINARIES=y
configs/builder/config.ocp.tiogapass:CONFIG_ADD_FSP_BINARIES=y
configs/config.google_reef_cros:CONFIG_ADD_FSP_BINARIES=y
configs/config.intel_harcuvar:#CONFIG_ADD_FSP_BINARIES=y
configs/config.mitaccomputing_ws_2:CONFIG_ADD_FSP_BINARIES=y
src/drivers/intel/fsp2_0/Kconfig:config ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Kconfig:       depends on ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Kconfig:       depends on ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Kconfig:       depends on ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Kconfig:       depends on ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Kconfig:       depends on ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Kconfig:       depends on ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Makefile.mk:ifeq ($(CONFIG_ADD_FSP_BINARIES)$(CONFIG_FSP_CAR),yy)
src/drivers/intel/fsp2_0/Makefile.mk:endif # CONFIG_ADD_FSP_BINARIES && CONFIG_FSP_CAR
src/drivers/intel/fsp2_0/Makefile.mk:cbfs-files-$(CONFIG_ADD_FSP_BINARIES) += $(FSP_M_CBFS)
src/drivers/intel/fsp2_0/Makefile.mk:ifeq ($(CONFIG_PLATFORM_USES_SECOND_FSP)$(CONFIG_ADD_FSP_BINARIES),yy)
src/drivers/intel/fsp2_0/Makefile.mk:cbfs-files-$(CONFIG_ADD_FSP_BINARIES) += $(FSP_S_CBFS)
src/drivers/intel/fsp2_0/Makefile.mk:ifeq ($(CONFIG_PLATFORM_USES_SECOND_FSP)$(CONFIG_ADD_FSP_BINARIES),yy)
src/drivers/intel/fsp2_0/Makefile.mk:ifeq ($(CONFIG_ADD_FSP_BINARIES),y)
src/drivers/intel/fsp2_0/Makefile.mk:else # CONFIG_ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Makefile.mk:endif # CONFIG_ADD_FSP_BINARIES
src/drivers/intel/fsp2_0/Makefile.mk:   printf “ADD_FSP_BINARIES isn’t selected even though this SoC relies on the FSP.\\n”
src/soc/amd/cezanne/Kconfig:    select ADD_FSP_BINARIES if USE_AMD_BLOBS
src/soc/amd/cezanne/Kconfig:    depends on ADD_FSP_BINARIES
src/soc/amd/cezanne/Kconfig:    depends on ADD_FSP_BINARIES
src/soc/amd/common/fsp/Makefile.mk:ifeq ($(CONFIG_ADD_FSP_BINARIES),y)
src/soc/amd/common/fsp/Makefile.mk:endif # CONFIG_ADD_FSP_BINARIES
src/soc/amd/mendocino/Kconfig:  select ADD_FSP_BINARIES if USE_AMD_BLOBS
src/soc/amd/mendocino/Kconfig:  depends on ADD_FSP_BINARIES
src/soc/amd/mendocino/Kconfig:  depends on ADD_FSP_BINARIES
src/soc/amd/picasso/Kconfig:    select ADD_FSP_BINARIES if USE_AMD_BLOBS
src/soc/amd/picasso/Kconfig:    depends on ADD_FSP_BINARIES
src/soc/amd/picasso/Kconfig:    depends on ADD_FSP_BINARIES
src/soc/intel/snowridge/Kconfig:        depends on ADD_FSP_BINARIES && FSP_CAR
src/soc/intel/snowridge/Kconfig:        depends on ADD_FSP_BINARIES
src/soc/intel/snowridge/Kconfig:        depends on ADD_FSP_BINARIES

So, it appears to be used for Intel Firmware Support Package binaries. But is it possible the variable also refers to AMD FSP blobs too for certain AMD builds (src/soc/amd/phoenix/ not mentioned)?

Additionally, the only place the printf statement that is output at the end of building is here:

src/drivers/intel/fsp2_0/Makefile.mk:   printf “ADD_FSP_BINARIES isn’t selected even though this SoC relies on the FSP.\\n”

Martin said here:

https://review.coreboot.org/c/coreboot/+/81994/2

”This is an unofficial port with non-production-level code from AMD. I hope
to port from FSP to openSIL in the upcoming months."

So, I figured the FSP or AGESA binaries were included in the port and it sounds like the necessary binaries are not publicly available if they are non-production-level?

I even git pull’ed the 3rdparty amd_blobs git directory before compiling, so if something is missing it isn’t in that directory.

@Guest68
Also, for my first attempt I did use the main branch, but I faced the exact same behavior during boot. So, I reverted to the release’s commit to verify there were no regressions. But, I don’t how enough about the coreboot project to know if that makes sense to do.

I did not know about the pre-built binaries. Very cool, thanks for sharing. I’ll investigate and possibly flash that instead.

2 Likes
eGPU not working properly. Probably issue with BIOS
572

Based on the commit message of c96201acb1d16dea90d2f8477f694346e0829dd6, that is essentially just the minimal boilerplate to get the build to complete. It lacks all the necessary board specific initialization and configuration code that would be needed to be able to boot. You would have a better chance of a boot by building from the last commit in the series, which is https://review.coreboot.org/c/coreboot/+/81993. There’s a download button there, which will present some git commands to retrieve that code. I’d recommend using the branch option, as that will also pull all the parent commits and put them all in a branch.

That said, I think the AMD FSP blobs are necessary for that code, and they don’t seem to be available anywhere.

3 Likes