Can't get heads to boot on t430 #1057
Comments
|
mobo has an nvidia GPU. I read this is an extra feature, not on all t430 boards. could this have something to do with my issue? |
|
@walliams : building #1015 for coreboot 4.13 or master for coreboot 4.8.1? |
most probably yes, others reporting working boards didn't specify if they were using Intel i915 only. Thanks for the report, that confirms my basic insight, where without hardware, wat I can do is limited. Adding coreboot graphic initialization, forcing coreboot to use primary display and having libgfx into coreboot might resolve this issue. |
|
Hey @walliams you could also try https://github.com/Nitrokey/heads/tree/nitropad as reference, this is what we use inside our Nitrokey T430 Nitropads and "should" work, although they come without a discrete GPU. We'll share some more insights during this week, we especially @nitrosimon is working on it |
|
well, we're making progress!! i'm going to retry this process with a few more roms on the internal flash step, but at least the external flash hurdle has been cleared. thank you all for the guidance and continued support on this project. by the way, as to the discrete nvidia gpu on my board, i am not so much interested in enabling the gpu as i am in just being able to get heads up and running with hotp verification for my librem key. goal is to run qubes, for which i don't think the gpu would offer any advantages, at least for my intended purposes. however, feel free to use me as a guinea pig to test builds on this board while i'm still figuring out what will work on the internal flash. |
|
internal flash attempts: nitrokey fork, nitropad branch "heads-t430-v1.3.1.rom" - failed, blinking let me know if there's another build I should try that might work. i will try the coreboot 4.13 build next time i have a chance |
|
Hey, yes based on the current PR #1015 the only change to do is: The maximized builds have to be flashed externally, your ME and IFD are set to read-only, you should see this if you fire up |
ahhhh i see. i knew that it could be flashed externally, but i didn't realize that it must. good to know. one other question: is there a reason that one would want to go with the hotp-maximized build over the hotp-verification build? seems they both serve the same purpose as long as you clean the ME in the external flash, but i'm sure i'm missing something. ideally is one method preferred over the other and for what reasons? edit: also, i just built a few boards from the 4.13 branch and they all say "g1f1539c-dirty" including the maximized build. why dirty? is this just because it is not the master branch or did something go wrong? |
@daringer |
Spoke too soon - connecting an external monitor to the VGA port shows the Whiptail interface (ERROR: GPG Keyring empty!). "x" followed by "[enter]" will get to the recovery shell. |
|
I can confirm that the fix from @daringer to specify |
|
@icequbes1 do you have the t430 board with the nvidia gpu? i am still not having any luck, even on the #1015 4.13 build with t430-flash from this branch gives me the same original boot error i had as well, so i tried the nitropad t430-flash, then internally flashed t430-hotp-verification from #1015 and same error again. also -- i'm still unclear why all the builds from the 4.13 branch give me the tag "dirty" |
|
@walliams : dirty means you have stuff changed locally when compared to remote branch, which would be normal since you modified ~/heads/config/coreboot-t430-hotp-maximized.config So Heads reports the version has not clean. Hence dirty. |
|
@walliams, No my T430 does not have the Nvidia GPU. It is (Intel) Integrated Graphics HD 4000 (CPU is i5-3320M). |
|
@walliams can you post the content of your whole t430-hotp-maximized coreboot config here? I could then expend it so its not in a defconfig format and check if the primary display is forced, which should, per other user reports, be Intel one. Otherwise without a board myself, back and forths are the only solution, I'm blind here. |
|
@eganonoa by any chance, you own a t430 with nvidia dedicated GPU? Your PR would suffer from the same community reported problems for t520 and t530 if coreboot doesn't deal properly with the possibility of having dedicated GPU. |
|
FYI, heads store kernel and coreboot configs in defconfig format (differences from default board configurations only). That is, if you do: Then Then exit and save, the result of the modified defaults kept in defconfig stored under heads tree + actual full coreboot config will be stored under build/coreboot-4.13/.config That is what is interesting here. The full coreboot config; not the savedefconfig stored under Heads, which was a leadership decision in the past. ( which maybe, we should revisit since only technical people will understand, and it complexities bumping versions of both Linux and coreboot, in my opinion). We need to figure out a common configuration for each xx20 and xx30 boards, dedicated GPU or not, so that internal display is always initialized and used by Heads, that is, the Intel integrated chipset. We should not care about nvidia. The OS should. That .config is the base we need to tweak so that a make savedefconfig is then saved under Heads tree, where a specific commit would lead into building a functional board config under specified kernel and coreboot versions for all variations of a board config. This is why #1015 is not merged still. And I haven't anticipated so much complications and conflicting reports for a same board which I do not own. This is why board owners need to test configurations and all reports need to be positive before a merge. Otherwise bricks will occur. And not all owners are technical enough to externally reprogram. |
@tlaurion. No. We're running four plain vanilla t430's with integrated graphics, all running fine. But this whole thing I find a bit confusing. The t530 I used does have a dGPU and it runs totally fine with a board and coreboot config simply copied and repurposed from the standard t430 and x230 boards and configs. If you are fine with simply ignoring and not initializing the dGPU my experience with coreboot is that you just run the normal board and everything works fine. This has been my experience with Libreboot on a w500 with a dGPU, vanilla Coreboot (on a t440p with a dGPU), and Heads (t530 with a dGPU). Thing are certainly more challenging if you are trying to actually use the dGPU. But that is a totally different thing. Based on my experience with the t530 with a dGPU (and indeed the other experience with Libreboot and Coreboot), I would suggest that unless @walliams is trying to do something to initialize the dGPU in their t430, there is something else going on that's causing this problem. |
@tlaurion Based on my experience if you want the dGPU to work, you will need a different coreboot config than any with integrated-only boards. But if you don't want it, you should be fine with the vanilla configs you already have. I'm not sure you want to try to have one config that works for all, but rather just have a config file that helps people who want to initialize their dGPU to do so (inc. with the relevant VGA rom extracted from Bios and placed in the blobs folder, as well as whatever is needed for graphic init). I'm really not 100% convinced that the issue here is derived from the dGPU in the t430. |
|
@eganonoa the problem is not just with @walliams board, but other reports for the t430. From my understanding, he is not trying to use the dGPU. Coreboot is probably selecting it by default, if not forced to use Intel GPU. That is my only hypothesis at this point, and since I'm not a board owner, unfortunately I can only point to that from intellectual guess. But it doesn't work for some owners, so the default config is not enough. |
|
Is confirming some behavior fix. But not others, like here. |
@tlaurion This just doesn't reflect my experience and certainly not the experience I've just had with the t530 and Heads. Very strange. |
@tlaurion but the @icequbes1 t430 does not have a dGPU. So that adds again another strange thing. As I say, we have four t430's running, all opened and flashed externally, all integrated boards and I've never had to do anything but build off master and go. This is true for coreboot 4.8.1, coreboot 4.13 and coreboot 4.14. |
|
|
@tlaurion how sure are we that we're not still just dealing with an issue caused by a locked IFD? The behaviour reported above is consistent with that and, while he says he's now unlocked, perhaps it wasn't really by mistake? I would probably suggest @walliams goes and grabs Skulls for the t430 and see if that works. If it does try the upgrade and if that fails then we know. I put my money on it working. Beyond that perhaps try to use nvramcui to switch off any mention of the dGPU to the extent that it is in there (see e.g. here). |
|
From there, Then Then now .config looks like this: To compare from provided coreboot-t430-hotp-maximized.config, we have to save this back to defconfig. And then, to visualize the difference we just generated: To have that configuration used inside of Heads for next coreboot build: And now we can see the actual difference between Head commit and the "dirty" build we are going to make: Where the final, copied over coreboot-t430-hotp-maximized.config looks like that: |
|
So, from above "full" (not defconfig), we can confirm that: And: Which I think, from my best knowledge, should be enough. But @eganonoa @icequbes1 @walliams board owners should confirm, while regression testing for @alex-nitrokey @nitrosimon @jans23 should be done. |
@eganonoa from my experience, and logically, board owner would not be able to type ctrl-alt-del and reboot system. Which is Head's Linux dealing with sysrq magic there. We are dealing with graphic issues here, only, since coreboot+ heads is up and running, which permits crel-alt-del rebooting; owner just not having any intwrnal display where connecting external display magically works, but is not intended use case. |
|
#1015 merged |
|
thanks again for the help @tlaurion. been smooth sailing for a month now with no major issues. i just wanted to ask out of curiosity: any idea how you could get heads to initialize the nvidia dGPU on boards like mine? confirmed with pciids that the only recognized VGA controller is the iGPU. this is by no means an issue-- just wondering if it's a possibility. |
|
@walliams I have scripts, configs and instructions in a PR pending merger (#1080) for the t530 and w530 with dGPU that can easily be converted for the t430 to get the dGPU to run. I just don't have a t430 with dgpu to actually do test it. If you would be willing to test it, I would very happily put everything together for you. |
|
@eganonoa i would be very interested in testing for you! not looking forward to having to pull the machine apart for an external reflash if it doesn't work... so i'm especially interested if you are confident you can get me up and running with an internal flash! let me know if there is any specific info you need from me to make this happen. |
|
@walliams. So long as you are now running a maximized board (i.e. either t430-hotp-maximized or t430-maximized) I am very confident. I have run and tested these builds multiple times on my dgpu T530 and w530 without error. And I would be simply taking the currently-working t430 boards in heads:master and simply adding the necessary for the dgpu following the t530 and w530 model. Nonetheless, of course, you would be testing something not tested before so there is risk involved (and you will brick your device if you are running these via internal flashing / bios update on a device with a board that does not have the ifd unlocked / non-maximized board such as the t430-verification boards). Here's a link to a branch I've just created with the dgpu support for the t430: https://github.com/eganonoa/heads/tree/t430-dgpu. It takes current heads:master and adds specific boards for t430-dgpu-hotp-maximized and t430-hotp-maximized with the relevant dgpu extraction script and coreboot configs. I've successfully built these on my local machine running Debian 10. So you can build yourself. But it is also running on CircleCi right now and should have the roms ready in the artefacts folder there in about an hour or so. Either way, once you have the 12 MB rom, you then need to take that rom and run nvramtool on it to change the default setting from integrated-only to hybrid (or discrete-only) before flashing. Instructions are in the README_vbios file in the xx30 blobs directory, but essentially all it takes is to build nvramtool and then run the following on the 12MB rom before flashing it: Once that's done the dgpu should be capable of working, with of course all the other OS-level things you need to do to make sure that the dGPU is working there. Good luck. Let me know if it all works! |
|
@walliams, the boards have built on CircleCi: If you don't already have it, nvramtool can be gotten in two different ways:
See https://www.coreboot.org/Nvramtool. If you have Heads built on your computer, nvramtool can be built from inside the coreboot folder there (in the builds directory). |
|
currently building t430-dgpu-hotp-maximized on debian 11 edit: debian 11 is proving to be troublesome for this build. setting up a debian 10 qube and trying again |
|
done! the build worked with one small caveat-- my wifi card stopped initializing. ethernet is still good luckily. |
|
@walliams Strange. I made no changes over what's now in the current osresearch master related to the wifi adapter and indeed if I look at the difference between the generated coreboot .config of the regular t430-hotp-maximized and the t430-dgpu-hotp-maximized I don't see any difference that would relate to the wifi card. I'd suggest trying a couple things to double-check whether its this board that's causing this:
You should see "wlan = Enable" (I do). If not, change it to Enable and reflash.
If the current rom you flashed does have wlan=Enable and the non-dgpu version of the current board doesn't disable the wifi card then I'd imagine it's something caused by this board. |
|
@walliams @eganonoa you both use Intel WiFi? May be an error with x230 config having been used as base for all other xx30 boards, where in my tests, I always swap that Intel card with an Atheros,so never tested this. |
|
@walliams @eganonoa nevermind my last comment, Intel Wifi card is initialized in coreboot per default config, which isn't changed in defconfig provided in tree
|
@tlaurion Yep it's a default value it seems (e.g. librem configs have to specify that its not set). As a general matter I eventually switch everything to Atheros because we use an FSF-certified distro. But typically I wait until I've confirmed everything is working with heads (and whatever old device I've managed to source) before investing in upgrades. That means that all my boards get tested on both Intel and Atheros cards, which has been true of both the t530 dgpu and w530 dgpu boards. And I can confirm that both those boards work out-of-the-box on both types of wifi card. The t430 dgpu-version uses the very same dgpu as the t530. So a wifi issue is surprising here. Fingers crossed for an errant change in the cmos values before flashing or something similar. |
|
checked with nvramtool and wlan = Enabled edit: so it appears that heads has initialized the card after all, but it's no longer appearing in my qubes Network menu after the ethernet connection. why would this be? |
|
@walliams basic troublshooting first. Is the wifi physical slider off? |
|
i figured it out! somehow on reflashing, the Centrino card was dropped off of my sys-net "Devices" list. added it back in and it's working! thanks again to both of you for the advice. i am now very happy with this heads rom. @eganonoa since you have gone to some lengths to enable dGPU's in heads, any rec's on a qubes template that plays nice with nvidia drivers? I read something about the fedora kernel being an issue. I was running fedora-34 in a cloned template, and now it still starts but no apps will open, not even terminal. |
Maximized boards being supported here only. I do not have a board to test. But these have been tested as working by another user (see linuxboot#1057 (comment)).
|
@walliams Good stuff. Glad this worked out. I'm not a regular Qubes user. But I do have one (non-Heads, but coreboot nonetheless) device running Fedora 35 (silverblue). Getting the nvidia card set up was no problem at all (on 33, 34 and 35). I just have the nvidia-470xx driver installed (esp. xorg-x11-nvidia-470xx) and use system76-power (via this COPR https://copr.fedorainfracloud.org/coprs/szydell/system76/) for graphics switching. @tlaurion I have set up a new clean branch for this rebased on master, one commit, etc (see https://github.com/eganonoa/heads/tree/dgpu-t430). Happy to make a PR for it, though obviously I can't test on it going forward and will rely on @walliams and others with a t430 dgpu to test. Let me know. |
|
@eganonoa great. qubes doesn't provide a fedora-35 template yet, but it looks like i can upgrade from a 34 template. I'll try that, then i might try an ubuntu template if that won't work. goal is to make this an all purpose machine as well as a security beast. really appreciate the help getting setup. i'm happy to test any boards you are trying to merge with master for the good of the project. feel free to mention me in a thread if you have another t430-dgpu build that needs testing. obviously i would appreciate if you verify that the updates work on your T530 first to minimize risk ;) would you like me to verify that the new t430-dgpu branch you just made is working, or is it essentially the same as what I just built? |
|
@walliams You should be able to get it to work with Fedora 33 and 34 also. I certainly have, always using the latest nvidia driver and system76-power. Ubuntu probably the same, though I have no experience with it beyond servers. Thanks re testing on the t430-dgpu going forward. The latest branch is just a copy of the one you used, just with the additions to master (with dgpu boards for t530 and w530) that happened today included. So there's nothing new related to what you've tested already. |
|
@walliams @eganonoa About https://github.com/eganonoa/heads/tree/dgpu-t430 There are validation concerns (nothing gets validated) because of lack of:
thorough vbios code as reported through Matrix @eganonoa. Result is that the script continues without exiting when a step fails. Other steps should also fail (script calls) without continuing when there is an error. Also, those scripts lack manual installation of bundle in apt install, and then upgrading to proper bundle version. I'm not sure yet why Qubes fails to call rom-tool without sudo in its call to UEFIExtract in your scripts. But that should be looked on independently prior of merging in another PR fixing other vbios extract scripts and then deduplicating here. No problem on debian-10 docker image. @walliams is https://github.com/eganonoa/heads/tree/dgpu-t430 working for you? |
@tlaurion no problems for me so far. the vbios script took two tries-- one without sudo and then one with. i can't say i understand why this was necessary. i had some issues installing nvramtool... the command wouldn't call the script, so i had to manually identify it after cloning the coreboot git. |
|
to be clear though, I am still having trouble getting the dGPU to run properly on the machine. every time i add it into a qube my system freezes up... but that's more likely a combination of qubes & user error than a heads build issue. |
Those needs to be HVMs, and pci/gpu passthrough guides need to be followed. Some links: |
Maximized boards being supported here only. I do not have a board to test. But these have been tested as working by another user (see linuxboot#1057 (comment)).
Maximized boards being supported here only. I do not have a board to test. But these have been tested as working by another user (see linuxboot#1057 (comment)).
did a fresh clone of heads
pulled and cleaned the ME blobs for xx30
built t430-hotp-maximized roms
flashed top & then bottom
upon booting, my t430 made a continuous beep with microphone and power lights blinking
flashed backup dump and the t430 boots. hardware is good.
then I tried just the t430-flash rom on the 4096kb chip only, and I get the same boot error: blank screen, blinking lights, continuous beep. heat sink fan starts up then immediately slows to a stop.
any ideas?
since the backup bios flash worked-- is there some way i could get a prebuilt t430-flash heads rom just for the purpose of testing, to confirm/deny that the rom build is the problem?
The text was updated successfully, but these errors were encountered: