KGPE-d16 board status : untested #1395
Comments
|
Hi @tlaurion, long time no speak and I hope your well. This message comes at a convenient time actually as I have recently starting using Heads again after about an 8 month hiatus due to employment requirements. I installed heads on my KGPE-D16 at commit 77b5933 a couple of weeks ago. Using One thing that was worth noting was the internal flash was not working, so could not add my GPG/PGP keys the Heads way. I didn't investigate too much but the "flashing" progress bar just did not progress over many minutes. I resolved it by adding the pubring and trustdb with cbfs tool outside of heads and flashing again. Re the PR above, my install is older than when it was merged. My system has the onboard VGA disabled via the header and Linux inits the GPU and the GUI renders okay. I would also be keen to see Dasharo used for KGPE-D16 in Heads too. I see you have draft PR #1303 open which I'll try and have a play with at some point. My ability to test is however restrained by time, lack of DIP8 chips (I'll buy some spares at somepoint) and that it's my main workhorse. So generally, testing for me would be flash a chip, turn off my main computer, swap, test real quick, swap back and report. I'm hesitant to test too deeply / commit myself on my primary system. I'll ping you a message / comment here when I've restocked and if there is anything I can do let me know 🙂 |
You mean flashrom used under heads master or dasharo/flashrom? |
@Tonux599 flash.sh, called by flash-gui.sh, is drawing progress from flashrom -V output in a file. @Tonux599 It would be nice to just have output from flashrom -p internal -w /path/to/ROM to see what is happening there (pointed commit is still coreboot 4.11 and old flashrom, where patch is for flashing bmc. Would love to know what is happening there). |
|
@tlaurion Hello, I have a KGPE-D16 board with a few extra chips for testing and although I'm not an expert but would be happy to help out. What can I do? @Tonux599 I haven't gotten Heads to work on my system yet with the most recent build. I also have an AMD dGPU, could you share additional details? |
|
@build-cool91 hey there! Nice to see you around! First thing first can you share the filename of the firmware image you built/downloaded so we are sure of what code we are talking about? Building that Biard ils known to work on debian-10. If you attempted to boot from the platform spi chip, you could as well share a post-boot attempt backup of the firmware image of the SPI, since cbmem log is written in the ROM. I might be able to get some information from your ROM ans diagnose the issue or at least have a beginning of an understanding of what is the problem for you. You can contact me through matrix at @insurgo:matrix.org |
|
Thanks...been lurking in the Qubes forum for long time and follow this repo but didn't know how I could contribute. Glad some testing on my end may help others :D Awesome, PMd you on Matrix. |
|
A thread on matrix opened pointing here at https://matrix.to/#/!pAlHOfxQNPXOgFGTmo:matrix.org/$7E8X1kk38SYY3XcZX2L0ukoio_NGcJLeTQ9x_BEqK3M?via=matrix.org&via=nitro.chat&via=fairydust.space |
|
Crosslinking to #1421 |
|
Good news! Did some more tinkering with my rev 1.03G KGPE-D16. Heads-v0.2.0-1713-g06b1b09 starts into the menus. My boot drive is an NVME, so I will have to test booting from USB. Stay tuned. |
|
It will boot from USB. (PureOS 10.3). Fans 100%. Odd behavior, it won't cold boot after shutdown unless I remove and reapply mains power. Board currently has ASMB4 BMC installed with original propriety firmware, so perhaps it is interfering. Would you like me to compile and test the other heads variants? |
|
Tested heads internal flashrom: success. |
|
Wow. That was unexpected. So you need nvme support under workstation? |
|
Ultimately, I would like NVME support under both workstation and server. Intent is to boot from nvme and assign the sata controller to an hvm in qubes. |
Just to be clear. |
|
Understood. The sata controller is separate from the pcie connected nvme, right? |
|
Not sure, we would have to test! You can check other board configs for Linux kernel addition of nvme drive built in kernel and test. Can you do a pr? Kgpe-d16 romsize being 16mb there is plenty of space there so should fly and be enjoyable right away! See helpers for make BOARD=xyz linux. Tab tab You should find what you need to modify the Linux config in place and then can provide PR with modified config, tested working, for inclusion? |
@Tickmeister1 that should help. You need to add those into used linux configs for kgpe-d16 workstation/server board referred files: https://github.com/osresearch/heads/pull/1403/files#diff-ec58c57a7a5a80fe0c75c2c419f804d1f192546b31428c6433f48158a7111862R976-R981 |
|
I've recloned master to my local machine, made the nvme edits to config/linux-kgpe-d16_workstation.config and compiled a dirty .rom file, which flashed and booted fine, except it still has no nvme support. Two concerns, A) at the top of the config file is a warning, "Automatically generated file; DO NOT EDIT" and B) after running make, there exists a .config and a .config.old file in build/x86/linux-5.10.5/linux-kgpe-d16_workstation/. The .config.old file contains my changes and the .config file does not. It appears I am making edits to the wrong file? This is all on 1715-g02c3a1f. |
Sorry, I was away from keyboard last time I gave instructions and they were not specific enough This helper will make the right thing: So Will permit you to use the menu config, activate nvme as you want and it will save the changes in the Linux config associated with the board flavor. Check the changes locally with It will be "dirty" since Heads detects that changes were not commited (official, signed). |
|
Okay sorry for the delay |
|
This is attempting USB boot, but I know the USB and board boot with Dasharo for example. |
Something is weird with usb port. Try another one? There are 1.1 and 2.0 ports, AFAIK? |
I'm confused with that statement since I never had any issue with 4.11+linux kernel enabling both 1.1 and 2.0 usb controllers with proper drivers and dasharo release notes above saying that linux kernel panics on booting from USB media. I'll try to readd kgpe-d16 in my testing time on community time. As per prior report of @Tickmeister1 it seems I could be able to get around past issues I had with either memory training/cpu (machine booted before but stayed collecting dust for years now... :/) |
|
Okay well I just tried a bootable SATA SSD and same thing so I guess it doesn't have anything to do with USB. I want to help with the PR stuff but I will have to ask a bunch of questions, I'll try though. Apologies in advance. So if I go grab Dasharo coreboot , how would I build heads with their coreboot? Or is that not possible and I have to make their code modifications in heads? If I do need to compare their coreboot code and modify heads, where is coreboot in heads? |
@build-cool91 @Tickmeister1 I just tried to make this work and add nvme under #1303 Note that it is not expected to be perfect at all. |
|
@Tickmeister1 @build-cool91 @Tonux599 Added UART=0 for workstation under 95e58a3 + linear FB init + bootsplash, so that console output is over serial console (as opposed to SOL (bmc). Let me know differences compared to 842eda2 roms as opposed to roms of master. Also, NVME as been activated under linux under #1303 CircleCI produced roms. Let me know how that goes for you. Next step there would be to remove amd/nvidia, add efifb as for all other boards wince we have native gfx and linear buffer, and we should be able to draw correctly to ASPEED here. LEt us know here clearly what dGPU are present, and what is your DIMMS as they might not be supported as documented per libreboot/raptorengineering in there HCL. I think best wiki entry is at https://wiki.vikings.net/hardware:kgpe-d16 |
|
I am currently focused on flashing my bmc to openbmc. Will resume testing heads when that is done. |
|
@build-cool91 i would like to see output of @Tonux599 or @Tickmeister1 to compare. It's normal pci output is present since there is a dGPU connected. Serial output should pickup with kernel dmesg output but doest which may be linked with previous discussions on serial configs variation which I'm sorry, enjoying sun right now so AFK. The only thing I saw from coreboot logs is that it reports for discrepancy but still reports both acpi and coreboot correctly for kernel to pickup pci devices and then initialize amd kernel drivers but unfortunately then don't pickup which causes black screen for you. If I recall well, in your situation, neither coreboot 4.11 nor dasharo under Heads works for you so at this point we need to figure out if 5.10.5 kernel has drivers for your dGPU and what reports from coreboot are giving any clue on what is wrong on what coreboot should do and doesn't. My gut feeling is that your dGPU might not be supported by 5.10.5 kernel which is bundled with heads currently. Can you remind me of your dGPU and check what kernel version first supported your dgpu? |
|
@build-cool91 Have you copied over the GPU binary blobs for your card into the initrd? See the Gentoo wiki for an idea of what files you want. |
|
@Tonux599 not sure that is needed but experiments might show otherwise. From recent conclusions of past attempts, 4.11 cannot support anything other then text frame buffer from coreboot. But the story might be different for dasharo fork, but we need to experiment a bit. But we need to make sure that coreboot init works. I'm not sure I understand here why amd dgpu drivers are not initializing display and why kernel output is not sent to serial |
|
@tlaurion My GPU is the AMD Radeon PRO WX 3200 4GB GPU Not sure if this helps, but it looks like it's been supported since 4.10? Is there a concrete way to find that info? |
I now get what @Tonux599 was saying. Both master and other PR are enabling amd GPU, but only Nvidia is configured to drive video output as of now. Just to clarify @build-cool91 you tested master or the dasharo port? I consider if you comment here is because this is master, hence tweaks need to be applied to have amd dgpu properly supported where as of now I do not know if firmware blobs need to be added, that will need more digging as well. |
|
@tlaurion Ah okay maybe this is my bad. I thought this was just the general KGPE-D16 testing thread - I am currently running #1303 ROM (UNTESTED_kgpe-d16_workstation-usb_keyboard) via CircleCI. But I'm not fully understanding --- since the above is the dasharo port right? The only ROM that works is Dasharo (asus_kgpe-d16_v0.4.0_16M_vboot_tpm12), so since #1303 is using Dasharo coreboot shouldn't it work fine? Should I post in the #1303 thread instead then? |
@tlaurion is not so much that only nvidia is configured. Both nouveau (Nvidia) and amdgpu drivers are built into the kernel, but unmodified heads will only display output if the GPU installed does not require binary blobs by those drivers. So for older Nvidia and AMD cards heads will display an output. On newer cards binary blobs need to be copied into the initrd for the kernel modules to load Unfortunately, the Nvidia and AMD binary blobs are many many megabytes in size, so we couldn't just dump all of them onto the flash chip |
|
So would I just be better off buying an Nvidia GTX 780 then? Looking on reddit that seems to be a pretty solid card for the kgpe-d16 |
@build-cool91 its not so easy unfortunately. Coreboot is one thing and then graphic initialization is mostly done per payload normally. What I get now is that the current coreboot and Linux configs under #1303 needs to be reviewed. I had hope that with native gfx init of the framebuffer, we could use the framebuffer directly on amd and Nvidia but missed the fact that blobs are required. It is unclear if simpledrm could drive most of GPU if coreboot initializes the FB in linear, but the coreboot configurations are not adapted completely to go that way as if now and it is unclear if it could which highly depends of the gou supporting vesa or being able to simply use a coreboot prepared FB. Tldr: it won't be that easy to support all GPU under Heads and more needs to be done to go in that direction unfortunately. As @Tonux599 said, packing the blobs under initrd should make it work but generalizing this to include all of them will be hard if not unfeasible. As of master, we take for granted user replaced SPI with 16mb chip and there would probably be enough space to pack some but not all dgpu blobs there. A more generic approach would be desirable but is unclear today. Linux installers are slowly removing gpu drivers in their installer media and are replacing them with simpledrm/simplefb/efifb and are not known to pack all available firmware blobs. The goal is to be able to provide basic framebuffer so the installer can install OS in pre-os environment and delegates to the installed OS the role of advanced 3d post install. It is unclear as of now if that approach can be taken for nvidia/amd but should be attempted in next steps. |
|
Okay thank you for the additional detail...I understand much better now. I will try to go the initrd route then. @Tonux599 I appreciate the Gentoo link, is there a guide for dummies how to add the blobs to initrd? I am quite unfamiliar with doing this - but would like to learn. |
|
@tlaurion Any good reference material, are there any good resources you could point me to for the above? |
|
@tlaurion Okay got my Nvidia 780 in the mail and attempted to boot....IT WORKS!! 👍 Would still like to understand how to add bobs to initrd, but for now using an Nvidia GPU is good enough. |
|
Just to clarify, I am running #1303 UNTESTED_kgpe-d16_workstation-usb_keyboard and with an AMD GPU it wasn't booting properly or even showing the HEADS splash screen. Installing an Nvidia GPU with no other changes and everything is working as expected. |
|
Hey @Tonux599, you're probably busy but I am curious when you have a minute if you could provide any good resources for:
and:
I would like to know how to do this :) |
|
@build-cool91 Yeah sorry for the delay. Going off the top of my head I'd do this, So your Pro WX 3200 is Polaris 23, which if my understanding is correct is a refreshed Polaris 12, so I think (but not sure) you can copy over the Polaris 12 firmware blobs to the initrd and your card should work. In the heads directory I would first do If you have a running system with linux-firmware installed then the file you need are in Then The Done a lot of this from memory so sorry if it's not 100%! |
|
@Tonux599 Thank you so much!!! Just followed your instructions and got it working :D I was having trouble identifying which Polaris it was lol, the output from dmesg said polaris10_smu so wouldn't have known that either. @tlaurion Not sure if it makes a difference, but I forgot to build #1303 and instead built from main (I injected the AMD blobs like above) and so far everything working. |
Sure thing, I just built #1303 with amdgpu blobs in initrd, flashed and so far working as expected 👍 Heads names the ROM "dirty" which just means because I've added the AMD blobs it is not in the signed/verifiable state correct? So this means even when #1303 is merged to main and the board is no longer "UNTESTED", it will be the process for me but I can trust it because I manually altered the ROM right? Hopefully that made sense.. |
|
Okay after testing heads functionality, similar to @Tonux599, the internal flash doesn't seem to be working. Mine has been stuck at "Verifying flash contents. Please wait..." for ~15 minutes now. I will let it sit a bit longer but doubt it will progress |
|
Hey @Tonux599 @tlaurion Any thoughts on the flash issue? Haven't been able to sign any files and do re-ownership yet. |
@build-cool91 the troubleshooting tips are given under settings -> totp mismatch, which leads into setting time manually https://github.com/osresearch/heads/blob/f640fb70bafbb4d2a91e92f0bdbe8b1620e94595/initrd/bin/gui-init#L544 If time is not set and saved you get bad time at boot https://github.com/osresearch/heads/blob/f640fb70bafbb4d2a91e92f0bdbe8b1620e94595/initrd/init#L49 Not sure why cmos settings are not saved for you. Normally syncing will call hwclock to sync time, it might vary from os to os, but if doing it manually doesn't work there might be something wrong with cmos battery socket on the board. |
@build-cool91 can you do a "flashrom -p internal" call and post a screenshot? Edit: wondering if 8342603 not being in current dasharo PR is getting in the way (PR not being on master) |
|
Thank you for the suggestions...I had found similar on the HEADS wiki and tried those instructions already from the HEADS recovery shell as well as from the OS. Something may be wrong with the board like you said. Is there anything I can do or am I SOL?
I added the code from 8342603 and recompiled but also I have noticed my Nitro Key is not seen by HEADS so I haven't been able to properly re-ownership. I'm sure it is user error but I lack the understanding. |
Which one? NK3? |
If you are referring to the cmos battery socket on motherboard and hwclock being successful but time not being kept upon reboot, I have no clue here but maybe cleaning the socket itself and replugging your new battery, considering the battery is new and good :( |
You can try doing And give output here. |
|
I haven't followed the whole discussion here (I don't have any KGPE-D16 hardware), but these fixes were suggested in the Matrix channel: mrothfuss/coreboot-D16@afac3a7 |
Work done under #1378 has not been tested under that board.
Meaning that it is not expected that a flat framebuffer is passed through kexec.
Interesting enough, this board is 5.10.5 linux based for a while.
Seems like users of that board are ok not having no vga until kexec'ed OS is initializing kernel.
Unfortunately, my kgpe-d16 doesn't boot anymore, looping into coreboot raminit.
Someone else still using that board under Heads? (Tagging per #692 board owners)
@0rb677 @Tonux599 @zifxify @blobless ?
The text was updated successfully, but these errors were encountered: