building galp5 firmware from source results in intermittant boot issues

loftlifter31 commented 2 weeks ago

Model: galp5
BIOS version: built from source
EC version: built from source
OS: PopOS 21
Kernel: 5.16 Built from source using both master branch and edk2-stable branch. Running flash.sh reboots into system-update efi but then says no updates found. Imaging usb.img onto usb drive and booting from there does successfully update the firmware and ec, but rebooting into the new firmware takes me to a black screen. After rebooting several times it does finally boot into the OS using the new firmware, but on next reboot black screen again. Successfully boots 1 out of 3 or 4 tries. Have also tried using external firmware programmer to flash BIOS with same results, either using rom built from master or edk2-stable. Re-flashed original ROM and there are no boot issues, even using the new EC.

Steps to reproduce

Build firmware.rom and ec.rom from source
Update galp5 firmware with built from source rom
Reboot

Expected behavior

Boot into OS

Actual behavior

Intermittant boot failures

Additional info

Even on successful boot, the source firmware does not present a boot options menu when ESC is pressed. Instead there is an error message which disappears too fast for me to read. system76_build.log dmesg.new.rom.txt dmesg.original.rom.txt

crawfxrd commented 2 weeks ago

There is no edk2-stable branch. The only branch you should be using is master.

loftlifter31 commented 2 weeks ago

Screenshot_2024-08-28_11-07-38

crawfxrd commented 2 weeks ago

Yes, there is a branch called edk2-stable202405, not edk2-stable. And it's a development branch; you should not be using it.

loftlifter31 commented 2 weeks ago

As I mentioned, I built from both edk and master branch and both demonstrate the same issue.

crawfxrd commented 2 weeks ago

You did not provide the commit you used. You have a modified local repo, because the version in the build log is "1.0" and not the commit. If you are using the master branch, you are on an old commit, because the Rust toolchain is using nightly-2023-09-07.

loftlifter31 commented 2 weeks ago

The commit to master I am workng with is 4b32a3e9f5ebeabfa0549bdf2eabb0fd3899f893

crawfxrd commented 2 weeks ago

Use 5002c9ad95bd or newer. The VBTs for TGL had to be regenerated because parsing stopped working after an FSP update.

loftlifter31 commented 2 weeks ago

I was using commit 6a6f7f8db01a366c98246f5847f58a266d0f7f10 of coreboot. So you are saying the vbt.rom included with this commit doesn't work with the parsers included in the open-firmware repo for the commit of that I was using? If so, that seems to be bad luck on my part as the 2 commits are only a few days apart. https://github.com/system76/coreboot/compare/6a6f7f8db01a366c98246f5847f58a266d0f7f10...792996fc8cd673f24335ae52e5b2066cccba2f77#diff-441eb6832cbe04acdf2a92203b3d4587a983102af3f391fc951782ac7d76593e

loftlifter31 commented 2 weeks ago

@crawfxrd I can confirm the vbt.rom was the culprit here. For future reference, how do I know which version of vbt to use with which version of coreboot? I am experimenting with other coreboot payloads and running into similar problems.

crawfxrd commented 2 weeks ago

Normally, you just use whatever is in the coreboot repo. In this case, coreboot/coreboot@4c7e97b26a34 to coreboot/coreboot@5d1494adda44 will have broken graphics on our TGL boards.

Ref: #525

loftlifter31 commented 1 week ago

@crawfxrd Are you saying that those versions of coreboot you listed won't work on system76 tgl boards at all or a different vbt must be used?

tlaurion commented 6 days ago

From https://github.com/linuxboot/heads/issues/1765#issuecomment-2338646515

I got it working. Just needed to update vbt.

system76 / firmware-open