ch341a_spi.c: In function ‘ch341a_spi_init’:
ch341a_spi.c:447:2: error: ‘libusb_set_debug’ is deprecated: Use libusb_set_option instead [-Werror=deprecated-declarations]
libusb_set_debug(NULL, 3); // Enable information, warning and error messages (only).
^~~~~~~~~~~~~~~~
In file included from ch341a_spi.c:25:0:
/usr/include/libusb-1.0/libusb.h:1300:18: note: declared here
void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Makefile:1030: recipe for target ‘ch341a_spi.o’ failed
make: *** [ch341a_spi.o] Error 1
I was talking about the freezing issues (@beard). It’s probably not Qubes specific: Now I’m getting the freezing issue most of the time when Grub asks me for my disk encryption passphrase. I now also recall having had this issue in the very process of installing Qubes.
Ah yes, you’re right, my commit that changed the URL from code.puri.sm to source.puri.sm is what caused it (I also just changed the flashrom repo from code.puri.sm to review.coreboot.org and made it checkout the v1.0 branch which is “known to work”, but I forgot about the libusb error).
To fix it, a simple change to the make command (line 515) into make CONFIG_CH341A_SPI=n should do the trick in order to disable compiling of the ch341a_spi file which has the error. I’m doing a clean build now on a machine in order to test this, once it goes through a good compilation, I’ll push the fix.
Thanks for letting me know!
I had the problem with my L13v3 shutting down due to CPU overheating under high loads; running Debian Stable. I upgraded coreboot using the build_coreboot.sh script today and believe I now have coreboot v4.8.1, though dmidecode still shows BIOS version as 4.7-purism-4.
After reboot, I tried running high loads (making AOSP variant LineageOS from source) and the machine doesn’t crash anymore, however, I ran ‘lscpu’ multiple times while the process was running and the highest frequency that the CPU can attain is 2.5MHz.
4.8.1-Purism-1 is in the 4.8 branch only and hasn’t been merged yet into master because I’m planning on releasing 4.8.1-Purism-2 this week (which fixes video glitches with iommu/VT-d).
As for the CPU frequency, it was 2.5GHz, not 2.5MHz, and that’s the CPU max frequency according to the spec : https://ark.intel.com/products/88194/Intel-Core-i7-6500U-Processor-4M-Cache-up-to-3_10-GHz
With TuboBoost enabled, it can go up to 3.1GHz, but that’s only for short periods of time, as soon as the temperature starts rising, it will drop back to its base 2.5GHz frequency, then sporadically boost itself to 2.9GHz or 3.1GHz for a few seconds (or less than a second) and if you’re lucky, you’ll see the peak in your sensor data, but it usually happens without the sensor picking it up (unless maybe you have a very fast refresh rate).
That explains the coreboot version as well as the frequency reading and you’re right, it was GHz, not MHz…
However, if I still have the same version as I had earlier (4.7-purism-4), why was I facing the problem with the sudden crashes before yesterday and how is it resolved now on flashing the same version?
Another observation; when the machine used to crash under high workloads, I couldn’t boot it back, sometimes for a few minutes and sometimes as long as a few hours. Plus, I always had to push the reset button on the left side of the body before I could boot it back successfully, which I am told only cuts the power off. What may be the reason behind this?
My guess is you had 4.7-Purism-3 or 4.7-Purism-2. As for your other issues, I have never heard of that, if the PC shuts down due to overheating, you can usually turn it back on right away, not ‘hours later’, and I’ve never had to use that reset button on the side, and I’m not even sure what that’s used for.
is because of a new gcc version. It builds fine with gcc 7.3.1 20180406, but fails with the same error message with gcc 8.1.1 20180531. I’m also on Arch Linux.
Downgrading gcc and gcc-libs to 7.3.1+20180406-1 solves the problem for me.
The issue was that gcc 6.x fails to build when you are using gcc 8.x to do it.
Downgrading gcc, gcc-libs and gcc-ada to 7.3.1+20180406-1 definitely resolved the issue for me. I was able to build and flash 4.8.1-Purism-2 without issue.
Need help with coreboot. I bought my laptop back in May and everything worked fine until a recent update. I did the test to check whether or not Intel ME is neutralized on my machine I and got a list of errors with it. Hopefully someone can point me to what to do.
Here is the log:
ME: Host Firmware Status Register 1 : 0xFFFFFFFF
ME: Host Firmware Status Register 2 : 0xFFFFFFFF
ME: Host Firmware Status Register 3 : 0xFFFFFFFF
ME: Host Firmware Status Register 4 : 0xFFFFFFFF
ME: Host Firmware Status Register 5 : 0xFFFFFFFF
ME: Host Firmware Status Register 6 : 0xFFFFFFFF
ME: FW Partition Table : BAD
ME: Bringup Loader Failure : YES
ME: Firmware Init Complete : YES
ME: Manufacturing Mode : YES
ME: Boot Options Present : YES
ME: Update In Progress : YES
ME: D3 Support : YES
ME: D0i3 Support : YES
ME: Low Power State Enabled : YES
ME: CPU Replaced : YES
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (15)
ME: Current Operation State : M0 without UMA but with error
ME: Current Operation Mode : M0 without UMA
ME: Error Code : Preboot
ME: Progress Phase :
ME: Power Management Event : CM0PG->CM0
ME: Progress Phase State : Unknown phase: 0x0f state: 0xff
ME: Power Down Mitigation : YES
ME: PD Mitigation State : Issue Detected but not Recovered
ME: Encryption Key Override : Workaround Applied
ME: Encryption Key Check : FAIL
ME: PCH Configuration Info : Changed
ME: Firmware SKU : Unknown (0x7)
ME: FPF status : fused
When confirming the presence of the correct coreboot image, it says I have a Librem 13 V 2 when I have a V3:
coreboot-4.7-18-g7ac4919b8a-4.7-Purism-4 Tue Mar 20 22:39:32 UTC 2018 bootblock starting…
coreboot-4.7-18-g7ac4919b8a-4.7-Purism-4 Tue Mar 20 22:39:32 UTC 2018 romstage starting…
coreboot-4.7-18-g7ac4919b8a-4.7-Purism-4 Tue Mar 20 22:39:32 UTC 2018 postcar starting…
coreboot-4.7-18-g7ac4919b8a-4.7-Purism-4 Tue Mar 20 22:39:32 UTC 2018 ramstage starting…
Root Device (Purism Librem 13 v2)
Found mainboard Purism Librem 13 v2
Another strange issue, although not coreboot related: when I log on the cryptsetup login screen, when I turn on the laptop, if I enter the right password I get a warning message on top saying “too many failed attempts” although the password works fine and I’m able to enter the user login screen for PureOS.
@jaylittle ah ok. I hadn’t tried that, and it’s compiling gcc itself, not coreboot so it makes sense. I think it complains if you try to compile gcc with a different version of gcc itself.
@user92992 : when you say “everything worked fine until a recent update”, what stopped working in recent updates? Also, an update to what? to coreboot or to your OS ?
Those “lists of errors” or what says that the ME is indeed neutralized and disabled.
The fact that it says that you have a Librem 13 v2 instead of Librem 13 v3 is ok, both images are the same basically (the only difference is the model name), and for a while the l13v2 image was being used on the l13v3 hardware until I made one specific for it. If you rebuild coreboot, just select librem 13 v3 next time.
I have no idea about the login screen issue, I’d suggest you ask in a separate thread.
Dammit. Had to use Tilix and couldn’t figure out copypaste there. Didn’t occur to me to just take it from the script instead of typing it all in again. Thanks for checking, my mistake.
