To clarify: Back in the days with vinalla coreboot I had a black screen on both the internal and external display in dGPU mode - probably because my dGPU hardware is simply dead. But I guess that’s irrelevant in the OP case.
And yes, my double negation was one too much. I was typing too quickly, sorry!
Anyway I think that you missed the point that there are 3 modes: iGPU, dGPU and dual mode/Optimus/both at the same time.
Dual mode probably never works due to the aforementioned lack of coreboot code, dGPU may work as you pointed out. Since it might only drive the external display (not sure), it’ll mostly be useless though unless one wants to live without the internal display or use nvramtool and reboot all of the time.
Those use cases were reported to be all functional under Heads with blobs and hybrid mode activated with nvramtool.
If your usage is different, using those images, please open an issue on Heads repository. It would need testing and proper fix.
This misunderstanding of how coreboot needs to be configured is the reason it didn’t work for you on vanilla coreboot. Your dGPU was just never initialized. Which is needed to go in hybrid mode as well.
That would be true if the settings were in nvram (CMOS memory, persistent through CMOS battery).
In the current use case where one modifies the default in the rom (as instructed right now), this is reapplied on boot from flash, and disconnecting the battery won’t change the default coming applied on boot. Also, upgrading the firmware would reset the settings to iGPU only.
I think if users wants to be able to activate/deactivate dGPU:
1- nvramtool should be provided as an additional and optionally packed tool inside of Heads so that CMOS settings are changed in nvram and living in cmos momory (so that disconnecting CMOS battery resets to default being iGPU only)
2- We should make sure that coreboot CMOS settings reads from nvram are read if they exist. (Not surenitnis the case)
As long as someone tunes dgpu to be hybrid or deactivated, there should not be any black screen at boot.
Any other idea to ease usage of iGPU/dGPU/hybrid inside of Heads
Actually i reviewed config just now, and as opposed to x230 where coreboot graphic initialization is deactivated and delegated to linux completely, w530 has both iGPU firmware and native init. I didn’t saw that before and not sure why @eganonoa did that
Ok… I will search to buy a cheap w530… and be able to test this myself eventually. As of now, I do not own a w530.
Could someone please clarify how it looks at the moment with the w530? Is using external monitors possible? In the Heads needs testing thread there is a remark that pull requests were merged back in September 2023. At the moment I use Skulls and it does boot in dual graphics mode but I did not use external monitors yet (so far it’s not recognized). I would like to test it though and am not sure about the right approach.
W530 under Heads comes in different flavors, with/without dGPU.
I’m still waiting for successful tests from testers to remove those dGPU boards from UNTESTED which is the nicest disclaimer I can give to next users like you expecting things to work when they are not reported working by other board owners.
A gentle reminder that QuesOS is not Heads and Heads is not QubesOS and Heads has its own community which is on github so energy is not dispersed.
I plan on trying to install coreboot on 2 of the 3 w530 shown below. the first 2 have a nvidia K1000M and the third has a K2000M. Which 2 would best serve as testing platforms?
w530 jtag cadidate #1. Qubes-HCL-LENOVO-243856U-20231130-061636.yml (1.1 KB)
@Insurgo Thank you for the hints! I’m trying to puzzle together the details. If I’m not mistaken, it might be possible to simply update from Skulls. I’m not sure if this x230 update script could be used (with some necessary minor changes) on a w530?
As the docs reveal, having Skulls installed means the process would look like
building Heads,
booting Linux with iomem=relaxed,
copiing Heads’ 12M image file build/w530/coreboot.rom to Skulls’ w530 directory and
run sudo ./w530_heads.sh - if the ported script from above can be used. As switching back to Skulls is simply running ./skulls.sh -b w530, I guess it’s not too risky to give it a try.
No. Do not flash maximized board 12mb Rom image over skulls. Never. Unless you verify unlocked state first. The official and documented way is the flash maximized board roms externally once and then upgrade internally from the menu options happily ever after.
If and only if you run flashrom -p internal on a boot with “iomum=relaxed” you get an output from flashrom that doesn’t say any region are locked as outlined here:
Then and only then you can flash a whole rom internally, but manually, wihtout specifying any specific region for flashrom to flash. You want the whole 12mb Rom content to overwrite the whole combined 4+8 Mb physical SPI flash content to match 12mb Rom image. Doing anything else will not work.
The logic behind that is that it depends if you flashed Skulls with the option of unlocking IFD.
The BIOS region under maximized board is bigger then on stock firmware and required an unlocked ifd/me/igb région under IFD to be flashed internally.
If you didn’t flash externally with an unlocked at least once, the IFD protects itself, the ME region and IGB region of the flash descriptions and prevents you from being able to overwrite them. The IFD inside of Heads is modified to extend the BIOS region with freed ME region space and contains a crafted IGB with a crafted Mac address for the Ethernet network card to apply.
If you flash internally a 12mb heads image over a initially locked firmware from skulls : getting a brick is the only thing you will get.
I see, thank you for the explanation. Just found out IFD is the Intel Flash Descriptor. This is a data structure that is programmed on the SPI flash chip on all Intel based platforms. It contains information such as space allocated for each region of the flash image, read-write permissions for each region, chipset configuration parameters and more.
I run flashrom -p internal with iomem=relaxed enabled on the system with skulls and this was the output:
sudo flashrom -p internal
flashrom v1.2 on Linux 5.10.0-18-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
coreboot table found at 0x7ff63000.
Found chipset “Intel QM77”.
Enabling flash write… SPI Configuration is locked down.
Enabling hardware sequencing due to multiple flash chips detected.
OK.
Found Programmer flash chip “Opaque flash chip” (12288 kB, Programmer-specific) mapped at physical address 0x0000000000000000.
No operations were specified.
While flashing Skulls I used the option for later internal updates. It seems there are no references to read-only sections in the output. If it’s ok, I will give flashing the 12mb Rom a try.
As a sidenote for flashing the w530: I used a Pomona clip and a CH341a without any additional power supply. I had to enable Wake on Lan (also left the CMOS battery in place), plug in the ethernet cable (wait for the light) and this provided enough juice for the process (otherwise shorting the pins on the right chip, etc. did not work, the chip was not recognized properly).
8086,0166.rom is the VGA Bios for the Native Intel Graphics card and can be downloaded from github (Running the ./vbios_w530.sh worked but stopped saying Failed to extract FL1 - btw bios 2.76 is not for classic keyboards, only up to 2.75). Although I put the 8086,0166.rom file in the xx30 directory, it still fails to build (with same error message). I will test it again.
For the record the vbios_530.sh script in the /blobs/xx30 folder seems to work after all. It requires ruby (it was missing, hence the issue I had). So the steps to start building heads on the w530 are (after getting the repo):
Go to the folder /heads-master/blobs/xx30 and run the vbios_w530.sh script (NOT as root). The end of the output should look like:
... `Verifying expected hash of extracted roms` vbios_10de_0ffb_1.rom: OK `vbios_10de_0ffc_1.rom: OK`vbios_8086_0106_1.rom: OK `### Moving extracted roms to blobs directory`### Cleaning Up
When searching online I did not find the 8086,0106.rom. But it could be built.
The last step in the master main folder is supposed to be running:
make BOARD=UNTESTED_w530-dgpu-K2000m-maximized
Obviously this is only the command in my specific case with K2000m and without hotp (check the board types in the /boards folder).
What I’d like to ask @Insurgo, if there is anything to consider while using the classic keyboard bios mod?
Before flashing Skulls it is important to use the mod first and flash Skulls afterwards (required Bios 2.74 in my case as 2.75 did not change the EC back to 1.13, which allowes to use the mod).
At the moment building heads/coreboot 4.19 still fails.
Could you file an issue for that, or better, à pull request adding that dependency to the apt calls under circleci, referred as being the way to track build dependencies under Heads documentation?
First of all a remark regarding dependencies: I switched to a different system and it required
sudo apt install python-is-python3 2to3
@Insurgo Thank you for showing in the right direction. CircleCl did work as those steps described the process. I know github but only used it as user. If anyone can help out with such a request mentioned above, please do so. When trying to build heads again the machine overheated while building gcc. Whole set of new problems. In the end I used new thermal paste and also switched to a new system to try from the beginning.
Now I know why it was complaining showing the “Not injecting” file size error message. me.bin was downloaded from the github site mentioned above. Instead of this it was required to run the
./download_clean_me.sh
script. This me.bin was accepted by the build script. Result looks good, the built heads-UNTESTED_w530-dgpu-K2000m-maximized- rom has the same byte count as the one downloaded from CircleCl. It takes a bit of time to build heads but considering those steps described above it’s not that complicated in the end.
@Dutch Not sure under which aspect. But you could try to have max 32 gb memory (and even a 3940XM CPU) on the K2000 and flash heads. On the other K1000 then Coreboot (or Skulls). This might reveal if it’s worthwhile to upgrade. From own experience it’s good to have 32 GB ram and best quality thermal paste.
Hi oxpoz,
I have seven W530s. Two have 3940xm processors that were unlocked in production by Intel. They were used in some Dell Alienware laptops. I also have one with a 3840qm processor, which is my favorite of the bunch. All of those have matched sets of 32G memory.
In addition I have three with 3740qm processors and one with a 3720qm processor. These I picked up to experiment on as proof of concept. They have 16G of matched memory each.
#2 from my post up above is stripped down to the motherboard and I am waiting for my Tigard programmer to arrive. I am typically a man of few words. Thank you for posting oxpos and I agree with you that 32G is the way to go.
P.S. As a side note everything works with Qubes OS installed on these machines. The only exceptions that I have encounter were some peripherals such as external monitors.
Yes, that’s confirming my experience too. Little issue is that brightness slider and the keys do not work out-of-the-box but setting brightness works on CLI. Did not test heads so far. I tried an other distro with built-in nvidia installer. It installed nvidia-tesla-470, but it did not work with an external monitor.
HINT to users with Skulls: On Skulls do NOT set Discreet Only graphics in the coreboot config menu as it will show a blank screen.
Fix (changing the config blindly): Turn on machine (remove storage so it will not boot anything). When it supposedly reached the coreboot config utility, press “down” arrow 19 times and “right” arrow once and press F1. Restart.
As an extension I was looking for an expresscard-to-nvme adapter (thinkmods seems to be out of business). No luck finding one so far. Maybe I’ll use that slot for USB.
it will be a week at least before I can track down the old laptops.