Purism Librem 14 v1

2 Likes

Remarks

Function buttons do not work after suspend.
No suspend on lid close.
Pureboot issues after any Qube Update.

layout:
‘hcl’
type:
‘laptop’
hvm:
‘yes’
iommu:
‘yes’
slat:
‘yes’
tpm:
‘’
remap:
‘yes’
brand: |
Purism
model: |
Librem 14
bios: |
4.16-8-gf88975265a
cpu: |
Intel(R) Core™ i7-10710U CPU @ 1.10GHz
cpu-short: |
FIXME
chipset: |
Intel Corporation Device [8086:9b51]
chipset-short: |
FIXME
gpu: |
Intel Corporation Comet Lake UHD Graphics [8086:9bca] (rev 04) (prog-if 00 [VGA controller])

gpu-short: |
FIXME
network: |
Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
memory: |
65410
scsi: |

usb: |
1
versions:

  • works:
    ‘FIXME:yes|no|partial’
    qubes: |
    R4.1
    xen: |
    4.14.5
    kernel: |
    5.15.57-1
    remark: |
    FIXME
    credit: |
    FIXAUTHOR
    link: |
    FIXLINK
1 Like

Thank you @kenosen for this report, which is online now.

Can you please be a bit more descriptive – what do you see? …what do you expect?

Absolutely; after any update through Qubes Update, I would have to follow regenerate TOTP/HOTP secret in Librem Key, and reset TPM, sometimes this would not validate and eventually the Qubes image was not found and I’d be forced to reinstall. I’m virtually certain that this is user-error, but it became a major hurdle to logins and for now presented too much worry about whether my system would reboot properly after a full shutdown.

EDIT: I expect to use the Librem Key to verify the boot, but not have to reset the key, et.al., each time.

I was also able to manage the lid shut suspend by editing logind.conf in /etc/systemd/ by uncommenting HandleLidSwitch=suspend

And as noted by others in this thread, I’m still experiencing erratic xfce4-power-manager status notifications, but I am one update behind on the EC firmware. Will test with new EC firmware next week along with the librem-ec-acpi-dkms from Purism.

@Sven just an update. I was able to switch back to PureBoot without too many issues, but with dom0 and kernel updates, it’s still preferable to keep Coreboot.

I also now believe the issues with function buttons are a product of ongoing kernel issues, not Librem specific. I also note that after updating the librem-ec-dkms the “killswitch” LED for wifi went dark. Here’s how to fix that:

sudo -i
modprobe ledtrig-netdev
echo netdev > /sys/class/leds/librem_ec\:airplane/trigger
echo wls6 > /sys/class/leds/librem_ec\:airplane/device_name
echo 1 > /sys/class/leds/librem_ec\:airplane/rx
echo 1 > /sys/class/leds/librem_ec\:airplane/tx
exit
2 Likes

Here is my HCL report.
Qubes-HCL-Purism-librem_14-20221230-105916.yml (845 Bytes)

Unfortunately I have the following problems:

  • The CPU frequency maximum is at 1.1GHz (related to this issue I guess CPU Frequency Scaling Broken · Issue #4604 · QubesOS/qubes-issues · GitHub).
  • After suspend the following things don’t work (reliably)
    • Charging (the connected charger is not detected by Qubes but it charges extremely slow).
    • The wifi passwords in sys-net seem to get forgotten (after a reboot I have to enter them again).
    • The screen brightness keys stop working.
  • Graphical glitches on disk unlock LUKS screen.
  • If the camera and mic is turned of via the hardware switch the wifi PCI device is not discovered during boot. Switching it off when Qubes has been started works fine though.

Heads and Coreboot work fine.

1 Like

Regarding the 1.1GHz issue. Could whoever reads this and has a Librem 14 check if it affects also their device?

Run those commands in dom0

xenpm get-cpufreq-states
xenpm start 1 | grep "Avg freq"

and report back if anything bigger then 1.1GHz shows up.

This is expected, if you are using a disposable sys-net. See this: Convert sys-net to disposable - #8 by fsflover

Just tried suspending and, after getting back, the brightness keys are working. Try to switch on “Handle display brightness keys” in Xfce Power Manager, “General” tab.

Yes, the first command shows max 1.1 GHz. No such problem with Librem 15 though (the latter shows up to 2.5 GHz).

But the second command showed up to 2.2 GHz for me under a load on L14.

My sys-net is not disposable.

Thanks for testing.

Didn’t helped for me unfortunately.

I have tested on my Librem 14 and confirm 1.1GHz issue exists.

1 Like

Thank you @wqpw for your HCL report, which is online now!

2 Likes

The 1.1GHz issue seems to be fixed. Doing stress testing with qvm-start --all I get up to 2.8GHz also my compile times are much shorter. Anyone has a better idea how to stress test the full 4.7GHz?

This is only a problem for me if the charger is connected after the laptop is resumed from suspend. Connecting the charger while it is still sleeping works fine.

This occurs only after an EC and Coreboot update for me now. Several restarts fix the problem.


Here is an updated HCL report with PureBoot 24 and the latest EC firmware (upload doesn't work. So here the file content):
---
layout:
  'hcl'
type:
  'laptop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  ''
remap:
  'yes'
brand: |
  Purism
model: |
  librem_14
bios: |
  PureBoot-Release-24
cpu: |
  Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Device [8086:9b51]
chipset-short: |
  FIXME
gpu: |
  Intel Corporation Comet Lake UHD Graphics [8086:9bca] (rev 04) (prog-if 00 [VGA controller])
  
gpu-short: |
  FIXME
network: |
  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
memory: |
  32642
scsi: |

usb: |
  1
versions:

- works:
    'FIXME:yes|no|partial'
  qubes: |
    R4.1
  xen: |
    4.14.5
  kernel: |
    5.15.94-1
  remark: |
    FIXME
  credit: |
    FIXAUTHOR
  link: |
    FIXLINK

---
1 Like

Remarks

Qubes OS 4.1.2, as expected, runs perfectly on the Librem 14, and there is one notable update.

Microphone input via the headphone jack has been implemented by Purism developer Jonathon Hall with the releases of Librem-EC 1.13 and coreboot 4.19-Purism-1/PureBoot 25, as described here:

@fsflover, I think that my other HCL Reports here and here should be edited to reflect this update and link to this post.

Even though Qubes OS 4.0 is EOL, a Librem 14 on Qubes OS 4.0 with the latest Librem-EC and coreboot would have working microphone input via the headphone jack.

Obviously, I recommend updating to Qubes OS 4.1.2, as there are no drawbacks, and it has new features and security updates.

Attachments

Qubes-HCL-Purism-Librem_14-20230330-172504.yml (846 Bytes)

4 Likes

Thank you @dom0 for your updated HCL report, which is online now! The remark makes clear that coreboot 4.19 is required to make the microphone work. Since your other two reports are for the identical machine with different BIOS versions, I think this makes the point rather clear.

2 Likes

I agree, the remark in the HCL is quite clear.

Thank you @Sven for continuing to maintain the HCL, as well as your posts here in the forum.

1 Like
---
layout:
  'hcl'
type:
  'laptop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  ''
remap:
  'yes'
brand: |
  Purism
model: |
  librem_14
bios: |
  PureBoot-Release-27.1
cpu: |
  Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Device [8086:9b51]
chipset-short: |
  FIXME
gpu: |
  Intel Corporation Comet Lake UHD Graphics [8086:9bca] (rev 04) (prog-if 00 [VGA controller])
  
gpu-short: |
  FIXME
network: |
  Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)
  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
memory: |
  65410
scsi: |

usb: |
  1
versions:

- works:
    'FIXME:yes|no|partial'
  qubes: |
    R4.1
  xen: |
    4.14.5
  kernel: |
    6.1.35-1
  remark: |
    FIXME
  credit: |
    FIXAUTHOR
  link: |
    FIXLINK

---

Qubes-HCL-Purism-librem_14-20230730-013440.yml (846 Bytes)

No issues found. I will do another report when Qubes OS 4.2.0 is released.

2 Likes

Thank you @FranklyFlawless for your HCL report, which is online now!

2 Likes

As promised, here is an updated HCL report of my same Librem 14 v1 laptop.

---
layout:
  'hcl'
type:
  'Laptop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  '2.0'
remap:
  'yes'
brand: |
  Purism
model: |
  librem_14
bios: |
  PureBoot-Release-28.3
cpu: |
  Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Device [8086:9b51]
chipset-short: |
  FIXME
gpu: |
  Intel Corporation Comet Lake UHD Graphics [8086:9bca] (rev 04) (prog-if 00 [VGA controller])
  
gpu-short: |
  FIXME
network: |
  Qualcomm Atheros AR9462 Wireless Network Adapter [168c:0034] (rev 01)
  Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
  
memory: |
  65410
scsi: |

usb: |
  1
certified:
  'no'
versions:
  - works:
      'FIXME:yes|no|partial'
    qubes: |
      R4.2.0
    xen: |
      4.17.2
    kernel: |
      6.1.62-1
    remark: |
      FIXME
    credit: |
      FIXAUTHOR
    link: |
      FIXLINK

Qubes-HCL-Purism-librem_14-20231220-024442.yml (917 Bytes)

As far as I know, I am pretty sure the TPM is not supposed to be a value of 2.0. My experience with the Librem 14 v1 so far using Qubes OS is still seamless, even on R4.2.0.

3 Likes

I’ve never run an HCL report, but in my Qubes Global Config it says that my TPM is “2.0 (not yet supported)”, so maybe the HCL report is just missing that caveat?

1 Like