librem_14 ROM misfunction, no display or freeze then CPU hard LOCKUP #1712
Comments
|
@123ahaha https://github.com/linuxboot/heads/blob/master/README.md#building-heads was followed? |
Yes indeed, first time (GUI update and 1st ch341a_spi) were with the nix. Then i tried to boot an old debian 11, and to just make BOARD=librem_14. Didn't change the result, still the black screen, reboot, then black screen with some backlight. |
|
@JonathonHall-Purism diffoscope fails on romstage and most of the rom is different? |
This is not upstream instructions. |
By doing this, you are using your host buildsystem, not the nix docker built isolated buildsystem. https://github.com/linuxboot/heads/blob/fb9c558ba4ed4d6a581b05d7e47b883e0f79c04a/README.md
Which would translate to this for your librem_14 build case: Since you are building latest commit (which incidently is "latest" docker image. Otherwise doc specifies to check Circleci config to get the docker image version on heads used docker image version to match reproducible build output) To complete your build with self built nix creared docker image, as you intended to do in for that specific Heads commit (observed at the end of your rom name
@123ahaha : makes sense? Please suggest changes you would like to see in README.md that would clarify what was missing so no others come to the same problems. Thanks! |
I know I first did the build via nix+docker I tough this put me inside the docker image with the correct build system. from inside the image, am I wrong ? Are you sure the way I did is not the same as ?
I just tried this way, and flashed via ch341a_spi, still got blackscreen with backlight. Here is the rom |
|
update : The hard LOCKUP also is on CPU 2,3,4,5,6,7,9,10,11 |
aluciani
changed the title
aluciani
changed the title
Correct. If previous commands ran to generate output and output used to construct your docker image you then ran interactively, your docker image should be reproducible and produce reproducible rom. (I didn't ran diffoscope on your latest one, I leave this for after you confirm expected rom outcome works or not before investing more unpaid time into troubleshooting this further, going into a more straightforward troubleshooting path, hope you don't get it wrong) @123ahaha |
Ho. So that's a kernel issue then. Considering coreboot was recently updated, if latest Circleci rom produces same output, I would recommend flashing a rom prior of last coreboot version bump here? Don you have version info of heads version you were using before internal upgrading? |
Ho. So that might be a kernel<->coreboot issue then. Considering coreboot was recently updated, if latest Circleci rom produces same behavior, I would recommend flashing a rom prior of last coreboot version bump here? Do you have version info of heads version you were using before internal upgrading? |
|
I tried the , still same issue I ll try to get a commit before. |
|
My hypothesis then is that you're suffering from last coreboot bump #1703 |
So if my hypothesis is right, this should boot |
You can off course go and use pureboot releases as well, which is supported way from purism support. Heads is a rolling release which OEM decides to support a Heads upstream commit and rebrand (with purism maintaining their coreboot branch). I would doubt librem_14 doesn't boot from their releases not sure which heads master commit they use, but should probably be written in their Bill Of Material (BOM) in their release page. |
booting back to normal with this commit Should I let you close the issue ? |
@JonathonHall-Purism something wrong after commit fd98c8d for librem 14, most probably coreboot / config stuff, where soft lockup watchdog would probably kick back later after enough wait, but definitely a regression. Please pin issue, Afk. |
|
Quick update, I'm able to reproduce this and checking it out, thanks for reporting. |
|
@JonathonHall-Purism depending on timeline for fix, I propose we revert #1703 as per #1713 PR. |
Done to assure visibility |
|
Agree; commented over there too - I'll test that ROM as soon as it's available from CI. If it boots and I haven't found the actual fix yet, we'll merge it. |
|
Even if you know more or less where the problem comes from, I'd like to add that the ROM produced for a nitropad-nv41 is working (heads-nitropad-nv41-v0.2.0-2206-gfb9c558.zip) |
@123ahaha: not related but thanks for the report (I tested nv41 myself, I cannot test librems). |
|
@JonathonHall-Purism @aluciani : https://app.circleci.com/pipelines/github/tlaurion/heads/2636/workflows/f0bfe047-0fa5-40ab-b636-25b63472794d/jobs/48156 finished. Internal flashing zip downloadable from https://output.circle-artifacts.com/output/job/bd451c3d-9c9e-4f8f-a2c1-ddc402dacca6/artifacts/0/build/x86/librem_14/heads-librem_14-v0.2.0-2207-gb20cde8.zip for 30 days starting now. |
working on my librem 14 |
|
Bisecting the few commits we had downstream on Release 30 has led me here, to the commit switching to Purism bootsplashes: https://source.puri.sm/firmware/pureboot/-/commit/7f912babf2aca7af73473b1cd41ca586ebdcc3df The 24.02.01-Purism-1 change works with this commit, but not on any prior commit. Not sure why though, working on it. I would not have expected a bootsplash to cause CPU lockups, I would have thought it'd either show the bootsplash or fail and go on without it. I'm curious to know if any boards from other vendors would work with coreboot 24.02.01 and the Heads default bootsplash if anybody would like to try it! It doesn't look like any other boards use 24.02.01 yet. |
I m willing to test it on t430,even on nitropad-nv41..........
...... but I cannot make the rom for a t430 with coreboot v24.02.01, I don t really have time to get deep down and to make the hack work |
I could start version bumping to coreboot 24.03.01 for xx30's t430+x230 on a PR to see if it bricks my x230, on which I can test myself as a start, and then extend per family this time (ivy, then sandbridge, then haswell). This will target testing for coreboot version bump, which in the past takes a lot of time to test per board owners so I will make smaller changes this time I guess. But nv41 depends on Dasharo's fork which is not upstream under coreboot so that will depend on the version base of next Dasharo release. |
The "hack work" is under #1715, which is basically changing strings, hashes of downloaded github artifacts, and regenerating oldconfigs as per 3a93e44 comment. If the roms artifacts don't boot, there is regression on coreboot side between 4.20.01 and 24.02.01. AFAIK, the patches that were under patches/coreboot-4.22.01/0001-x230-fhd-variant.patch, relative to edp patch for edp/fhd x230 board variant, was merged upstream and unneeded now. So no more coreboot patches should be maintained downstream under Heads, which is where the actual "hack work" was needed before. Let's see. |
I ll just wait the CI to build the rom and try it on nitropad-nv41 |
Won't change anything for nv41. |
This affects platfroms in title of #1715: xx30, xx20, xx40, xx41 and qemu q35 coreboot test platforms. |
|
Here's what happened. After the switch to the Wuffs JPEG decoder in 24.02.01, the JPEG decoder now needs a "work area" allocated from the heap roughly proportional to the image size. The Heads bootsplash is much larger than the PureBoot bootsplashes (1024x768 vs. ~672x112). So the PureBoot bootsplashes were fine, but the Heads bootsplashes exceeded the available heap space. Then, the coreboot allocator left the heap "full" after failing to fulfill a request due to exceeding the heap size. This caused boot to fail entirely after failing to load the bootsplash. Upstream fixes:
I'm preparing a branch to bump Librems again with the heap size fix. (We don't need to cherry-pick the malloc fix, as long as the heap size is increased it won't apply.) |
|
@JonathonHall-Purism fixed in master, should close? Was ebd9fba |
|
Yes thank you, closing |
Please identify some basic details to help process the report
A. Provide Hardware Details
What board are you using? (Choose from the list of boards here)
librem_14
Does your computer have a dGPU or is it iGPU-only?
Who installed Heads on this computer?
What PGP key is being used?
Are you using the PGP key to provide HOTP verification?
B. Identify how the board was flashed
Is this problem related to updating heads or flashing it for the first time?
If the problem is related to an update, how did you attempt to apply the update?
How was Heads initially flashed?
Was the board flashed with a maximized or non-maximized/legacy rom?
If Heads was externally flashed, was IFD unlocked?
C. Identify the rom related to this bug report
Did you download or build the rom at issue in this bug report?
If you built your rom, which repository:branch did you use?
heads-librem_14-v0.2.0-2206-gfb9c558.rom
What version of coreboot did you use in building?
{ You can find this information from github commit ID or once flashed, by giving the complete version from Sytem Information under Options --> menu}
coreboot-purism
In building the rom, where did you get the blobs?
Please describe the problem
Describe the bug
I wanted to update heads on my librem_14 purism.
So I cloned the git repo, built the ROM and put it on a usb key.
I updated the ROM via the GUI (keep settings), rebooted and then got a black screen.
I told myself that I'd removed the USB key too quickly, that the zip file was corrupted.
So I externally flashed the rom with a ch341a_spi programmer.
The result was the same:
A black screen. then the pc rebooted, and displayed a screen that was on but not displayed. Then nothing moves, the pc freezes, or displays nothing.
To Reproduce
Steps to reproduce the behavior:
sudo apt update && sudo apt upgradethe systemgit clone https://github.com/linuxboot/headssee error
THEN
see error
//
I also tried the old build method on a debian 11 system
Expected behavior
the laptop should print the bootsplash and then the head menu
Screenshots
I can put pictures of the blackscreen if needed ...
Here is the zip file produced by the build :
heads-librem_14-v0.2.0-2206-gfb9c558.zip
The text was updated successfully, but these errors were encountered: