One could split the rom the same way it is split in thr board configuration file, but im not sure why you would do it that way. If you applied nvramtool to the image and you already flashed Heads, why not simply flash that full rom internally instead?
Should we add nvramtool inside of Heads for those models? First model to need this, but dGPU support is kinda new to Heads. And the more I read the forum on the interest for gGPU support from users and the more i realise that nvram settings should have persistence between firmware upgrades.
Someone willing to open an issue over heads to discuss nvram persistence, and a pull request for the w530 missing bits of documentation over heads-wiki?
I haven’t already flashed heads on W530. I made the ROMs and was going to flash 8+4 as per instructions. Then I saw the dGPU instructions that applied to the 12 MB ROM. So now, can I flash the 12 MB ROM? I assume not.
I did some additional research and after running this command: sudo nvramtool -C /path/to/12MB/rom -w hybrid_graphics_mode="Dual Graphics"
I ran the following two:
But I have yet to flash. I just need a confirmation that the splitting was the right thing to do.
I can add W530 information to heads-wiki once I succeed flashing!
For hardware flashing, yes, you need to split. For software flashing you don’t need to.
And yes, you need nvramtool to switch the GPU mode. However I don’t believe that “Dual Graphics” / Optimus support is not yet implemented in coreboot, i.e. you might just see a black screen [1].
IIRC hybrid_graphics_mode="Discrete Only" should switch to the dGPU. I got a black screen for that, too, but I guess my dGPU is dead. Removing the CMOS battery can be used to reset nvramtool settings IIRC.
Confused here.
If Discrete only, t530 and w530 AFAIK drives external displays only. So it would be normal that iGPU gets deactivated here, and internal display would not work.
That sentence contains a double negation. Support in coreboot depends on inclusion of gGPU firmware, but the Heads payload doesn’t include nvidia drivers in its kernel as of now. So disabling iGPU from setting nvramctl to Discrete only will result in a blank screen, yes.
We could include nvidia driver into linux-x230-maximized.config, but i’m not sure this is required. In notes from merged pull requests and issues, it was thought sufficieent to have only iGPU support inside of Heads, where coreboot prepares devices to be managed by the main OS.
Short version: dGPU is not activated under Heads payload, only iGPU (laptop screen) is driven under Heads. But that could be changed by adding nvidia driver under Heads’ kernel configuration.
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.
it will be a week at least before I can track down the old laptops.