Closed XV-02 closed 1 year ago
Having tested firmware on Galp4, I'm seeing the same behaviour as I did on Lemp9. Builds after the 4.19 rebase seem unable to boot on 10th gen Intel. I did note that I was able to establish a state where a post 4.19 rebase EC version was reported with the bios reporting as b337ac6 on a functional boot, though that was more the result of the recovery process.
I again had to build from b337ac6 and flash with the CH341A programmer.
Also same issue when testing 799ed79 from new-models on lemp9 trying to check out secure boot. Recovered with CH341A flashing b337ac6.
At current, this is a complete list of 10th gen and older systems for which firmware can be built from System76 repositories:
Entries with check marks are (as of 2023-07-27) known to be functional enough to recover to released firmware with at least one post https://github.com/system76/firmware-open/commit/b337ac66fb3b8d77880e81f35acf3c50072a85c2 build from this repo.
So, for the moment, I would recommend running sudo dmidecode -t1
and seeing if the laptop version is checked off before attempting to flash a post https://github.com/system76/firmware-open/commit/b337ac66fb3b8d77880e81f35acf3c50072a85c2 build.
[List edited to reflect corrected information]
coreboot-based firmware was never released for the following and so are not blockers:
lemp9 (both with or without DIMM):
[INFO ] POST: 0x92
[INFO ] POST: 0x98
[INFO ] POST: 0xe3
[EMERG] FspMemoryInit returned with error 0x80000007!
Using system76-4.19
with lemp9 checked out from system76-4.17
works. So likely something broke when converting lemp9 to a variant of cml-u.
https://github.com/system76/coreboot/pull/190 will fix booting on CML-U and unblock making new firmware releases for them.
While testing https://github.com/system76/ec/pull/338, I managed to render a Lemp9 unbootable after flashing an up-to-date 85f8a8b firmware-open dirty build with the PECI EC branch checked out.
Attempting to flash a clean 85f8a8b build did not recover the system, and I eventually recovered it by flashing a build from commit b337ac6.
Subsequently, I tested the 85f8a8b-dirty build again to the same results, and recovered it the same way. Testing a clean 85f8a8b build also rendered the system unusable, as did a clean 6562cf2 build.
After flashing any of the builds rendering the system unusable, I noticed the following behaviour: