NovaCustom NV54 Laptop with CoreBoot and dGPU

General Discussion
1

I got a new NovaCustom NV54 Laptop and am logging my efforts to get it working with QubesOS here. This is meant as support for others who are considering this awesome laptop.

Hardware:

  • Intel® Core™ Ultra 7 processor 155H
  • NVIDIA Corporation AD106M [GeForce RTX 4070 Max-Q / Mobile] (rev a1) (the dGPU option)
  • Display: 2880x1800 @ 120 Hz
  • Intel Corporation Wi-Fi 7(802.11be) AX1775*/AX1790*/BE20*/BE401/BE1750* 2x2 (rev 1a)

BIOS Settings:

  • Secure Boot disabled
  • Intel ME left enabled
  • Everything else stock. Coreboot doesn’t have many settings though

Working out of the box:

  • Suspend / Resume with systemctl suspend (awesome!). I think it’s S3 which I like better than modern standby anyway
  • LAN
  • Sound output & Mic
  • Keyboard, Touchpad
  • External 5k Monitor via USB-C (including charging the laptop, monitor USB hub, 2.5 Gbps LAN etc)
  • Webcam

Problem: X does not start (fixed):
After installing X does not start, i.e. boot stops at the command line.
Reason is that neither the integrated Intel GPU nor the NVidia is recognized by the i915 and nouveau drivers.
Workaround:
Disable loading of nouveau by adding this to the kernel boot parameters:

rd.driver.blacklist=nouveau modprobe.blacklist=nouveau

Force the intel driver to load on this Meteor Lake GPU by adding this:

i915.force_probe=* i915.modeset=1

Now X works flawlessly with the full 2880x1800 resolution at 120 Hz. Lower resolutions are working too.

In most cases probably better to buy the option without dGPU. As a bonus you get a second M2 slot.

Problems yet unfixed:

  • WiFi7 card:
    [UPDATE: Solved, WiFi working fine, see post #3]
    iwlwifi can’t load the firmware. Downloading the firmware mentioned in dmesg from kernel.org did not help (uCode file size 11967921 does not match expected size). On other distros people got it to work by upgrading to a newer 6.7 kernel (my sys-net is on 6.6.65-1.qubes.fc37.x86_64). I’ve parked this for another day, am confident it’ll work.
  • The internal screen is too small to read comfortably at its native resolution. When I scale it to 1.5 in panel settings while my 5k monitor is connected then it (a) doesn’t scale and (b) is not reachable via mouse despite correct positioning of the displays via the display settings GUI
  • Battery: When plugged in the battery oscillates between 93 and 98% (the latter is the max charge setting in the BIOS). I got a feeling that when connected to the power supply it still goes through the battery, which I guess is bad.
6 Likes
2

Hey this is amazing, thanks for starting this thread. I am always curious to see how QubesOS works with dGPU @novacustom lapstops. As a tangent, I am particularly interested in this thread: PCI (GPU) passthrough hardening: option ROM edition · Issue #1087 · Dasharo/dasharo-issues · GitHub

May I ask why? You can easily disable intel ME, which prevents a possible attack vector on your infosec.

Have you tried using “kernel-latest” with your qubes? I think latest kernels have a better chance at supporting the cutting edge hardware’s firmwares.

That’s interesting. Wouldn’t this charge/discharge cycle eat a bit from the lifetime of the battery? Maybe @novacustom can chime in here.

Please keep us updated about solving your current problems. I am interested in this hardware (especially with the dGPU model of yours).

2 Likes
3

Awesome, happy this provides value!

My current task is to setup dual boot with Windows 11, since this is a work machine and my organization requires a Windows installation which has to be classed as “compliant” by their Intune policy. That requires Secure Boot and TPM. I see there are some SecureBoot efforts that might be released with Qubes 4.3 but haven’t spent time on it yet.

Setting up dual boot worked with Secure Boot off worked flawlessly. Installed Windows 11 first. In the partition GUI I left enough space at the end of the disk for Qubes.

I feared it would interfere with being compliant on Intune. I can provide an update on this in a few weeks once the laptop is onboarded to the company.

Solved with sudo qubes-dom0-update kernel-latest-qubes-vm, switching sys-net to 6.12.5-2.qubes.fc37.x86_64 and putting those 2 firmware files in /lib/firmware:

That’s my worry. I’ve now set the Min-Charge and Max-Charge in the BIOS to 70% and 98% as recommended in the BIOS help. The laptop then discharged to 70%, then charged to 79% where it stayed for a while (“Waiting to charge”) and then without discernible reason started to charge again, then stopped (“Waiting to discharge”). Curious if @novacustom can enlighten us?
Note that this is with USB-C PD - the normal power supply is not connected (can test that later).

Found another issue:
The kernel log contains lots of these errors regarding the NVMe. However the disk works flawlessly and it has written ~500GB already. Internet says these errors might be false alarms or maybe due to PCIe power management and can be surpressed with a kernel boot parameter.

[  350.405629] pcieport 0000:00:06.0: AER: Correctable error message received from 0000:00:06.0
[  350.405645] pcieport 0000:00:06.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID)
[  350.405647] pcieport 0000:00:06.0:   device [8086:7ecb] error status/mask=00001000/00002000
[  350.405649] pcieport 0000:00:06.0:    [12] Timeout

Note that I swapped the inbuilt NVMe for a previously heavily used Samsung SSD 990 PRO 4TB. The disk is perfectly seated physically. Upgrading dom0 to the latest kernel (6.12.5-2) didn’t help.

SMART looks OK, although interestingly it says that it does not support Self-test. Which I’m pretty sure worked in the previous computer I used it.

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        52 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    5%
Data Units Read:                    146,285,066 [74.8 TB]
Data Units Written:                 327,977,649 [167 TB]
Host Read Commands:                 3,732,139,198
Host Write Commands:                1,526,186,400
Controller Busy Time:               6,578
Power Cycles:                       24
Power On Hours:                     4,388
Unsafe Shutdowns:                   13
Media and Data Integrity Errors:    0
Error Information Log Entries:      10
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               52 Celsius
Temperature Sensor 2:               60 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

Read Self-test Log failed: Invalid Field in Command (0x002)
2 Likes
4

Hi!

Please make sure that:

  1. The date and time are set correctly before installing Qubes OS. You can set the date and time with any Linux live USB pen drive.
  2. You install Qubes OS with kernel-latest: it’s the last option of the GRUB menu when booting to the Qubes OS installation USB pen drive.
  3. You have a Fedora-based sys-net template.

Screen display scaling in Qubes OS is problematic overall.

@tanky0u NovaCustom laptops have battery charge thresholds to reduce battery wear and tear on the long term. Although we don’t recommend to do so, it is possible to disable this function in the UEFI firmware settings.

Please note that there is no official Qubes OS support for your configuration, since you have chosen an NVIDIA dedicated graphics card.

4 Likes
5

Understood, this makes sense.

You mean, during the QubesOS installation setup wizard?

Is this really a must? Can one use the Wifi7 hardware with the kernel latest on debian 12 based sys-net?

1 Like
6

I’m curious about this as well. My sys-net is debian based and LAN & WiFi are working great so far.

2 Likes
7

It is if you are solely relying on the Debian 12 template to provide firmware updates:

Note that this blog article is for the NovaCustom NV56, but it should equally apply to @Finbob’s NovaCustom NV54 HCL report without their workaround:

3 Likes
8

After upgrading dom0 to kernel-latest (6.12.5-2) a few things changed:

  • Now the ONLY resolution I can select on the inbuilt screen is the native 2880x1800@120. No other one is available. They were in the stock kernel (6.6.48-1).
  • The nvidia card is recognized by the kernel, so no need for the blacklist parameters anymore
  • The i915 kernel parameters aren’t needed anymore either

Another big issue: The panel’s DPI is so high that you need scaling (0.75 to 0.5) to be able to read the screen comfortably. However setting that doesn’t work, I get a black screen with a small normal strip at the top. I was able to fix that by adding the panning option: xrandr --output eDP-1 --scale 0.5x0.5 --panning 1440x900. However this option slows the whole system down to a crawl. Every command on xterm takes like 60 seconds to even type.

3 Likes
9

Hey @FinBob,

TL;DR
Fix for only native screen res
Fix for scaling : The important fix is this: echo Xft.dpi: 144 | xrdb -merge

I had the same issues on my V54, wrote a HCL with fixes for most of them. My only “issue” now is that the performance is somewhat bad, was not thinking to get much out from it but just browsing is pretty bad. Video playback in browser is impossible unless you have the window small.

3 Likes
10

Do you think these issues are connected to high screen resolution of the hardware? Issues like these push me to 1080p screen resolution model V56/54.

1 Like
11

Interesting thread & thanks for chiming in.

Setting the DPI doesn’t seem like a viable option for me, as I need to set it per screen. My external monitor is fine with the default DPI while the panel isn’t.

The 14" V54 doesn’t seem to have a lower resolution option, only the 16" and the V56. I feel you might be right in that the higher resolution isn’t worth the hassle in linux, sadly.

2 Likes
12

Yes, and in my chat via whatsapp with NovaCustom it was mentioned another Full HD res on the V54 model, so for anyone else maybe wait?

Update: “but we won’t have that available till February”.

2 Likes
13

This should be fixed with recent Xorg package update: xorg-x11-server v1.20.14-27 (r4.2) · Issue #5295 · QubesOS/updates-status · GitHub

3 Likes
14

Great, ty! Can confirm, fixed just by updating Qubes (normal stable channel).

For clarity, I meant the laptops are not sold with lower resolution panels (as an option in their configurator). So we are still left with the problem that having a high DPI laptop panel and a normal DPI external screen leads to one of them being hard to read.
But setting a lower res on the high dpi laptop panel will be an okay-ish workaround, so that’s great

2 Likes
15

Maybe you would like to test and further develop this as a temporary workaround.

2 Likes
16

With some testing I found a solution that makes browsing better. Set the ram to fixed without ballooning, and use mullvad browser (disable hardware acceleration). Fixed all performance issues, now yt 1080p and other streaming services works just fine. Not sure what mullvad does different but it works so not complaining, its a great browser either way. Other apps works fine, still not the best performance but that is most likely the screen res being pretty high. Tbh qubes works great now for daily driving.

Funny thing is that mullvad is the only browser that works fine, other browsers still laggy unless running on my archlinux qube. Browsers tested: firefox, chromium, brave, opera and mullvad.

5 Likes
17

Was already using Mullvad, but this made a big difference.

This setting is found by unchecking “Use recommneded performance settings” and then “Use hardware acceleration when available” will appear, uncheck that as well.

3 Likes
18

I’ve switched to a NV54 without dGPU since I don’t really need it and it’s expensive. See this thread for my journey with the new machine.

2 Likes