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. |
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 |
built latest workstation locally and runs fine anything particular that needs to be tested? |
Can you detail your HCL? 4.15 was tested with specific ram modules and cpus. I would suggest to show up under heads channel under matrix so I can invite you to the d16 club channel but detailing HCL (hardware compatibility list) would be helpful here. As opposed to laptops, supporting every ram/CPU configurations is way more complicated. |
RAM 2x Crucial 16GB CT16G3ERSLD4160B |
Is NVMe boot currently fully supported with KGPE? I would like to be able to use a single disk to boot Qubes too rather than needing a secondary Satadisk or USB drive as a pre-boot helper to the NVMe. |
There are also multiple board revision numbers which I think we should be including when referencing a bug. I had a number of issues with my Rev 1.3G boards and that version was in general a royal pain in the butt to setup. Max ram I could get was 64gb, a few usb port issues, power issues. When testing on Rev 1.4 and up, a number of problems went away and I was able to get 256gb of ram using the same identical hardware from the Rev 1.3G board that was finicky. Personally I think devs should skip working on the Rev 1.3G boards and purchase a Rev 1.4 or newer and save yourself the time and frustration. I would also imagine it is difficult for devs to communicate problems effectively when not comparing and working on the same revision of board. If for some reason down the road there is a need for Rev1.3G we can revisit at that point in time. |
@jtf7 it should since #1738 was merged, yes |
@jtf7 this is primordial. |
was sitting on this for an hour then did a ctrl alt del and gave up |
Reading old flash chip contents... done. command seems to work just fine when using it like you said dont know why script hangs |
|
@arhabd #1753 (comment) explains the situation. #1755 most probably fixes the situation (I don't see why not). Tests will occur under #1753 first, then regression of #1755 alone against master, which should have none but loss of inhouse progress bar that is maintenance burden, but that should land upstream soon. |
|
@arhabd roms from CircleCI for commit e64685b build at https://app.circleci.com/jobs/github/linuxboot/heads/18656 should resolve your issue. Of course, you have to use flashrom directly from command line here first, but then reflashing the same firmware image from Heads GUI should succeed. Please confirm. |
flashed this and the one thing to note is that if i dont have the usb security dongle plugged in the oem factory reset crashes with the following error but with a security dongle plugged in it goes through and does its thing sucessfully including flashing the new rom so one issue solved another poped up :) |
@tlaurion Yes I will. I spent a solid 4 days on this last week but still working on this. Have a few years of notes and documents to review and aggregate into a single source. I was hoping to finish last week but wasn't able to get through everything. Will finish as soon as able |
@arhabd Are you using motherboard Rev 1.3G and which USB ports are you trying to use? With Rev 1.3G I had issues when trying to use the usb ports next to the ps/2 connector, i was better off using the headers off the mobo for some reason. KGPE Rev 1.4 or higher also seemed to help with a number of issues if you are able to upgrade |
i am using 1.03G and am using the USB ports next to the PS/2 ports without problem maybe its just your specific board that has some issues? other people i talked to have not had the ram issue you described |
Were you able to get more than 64gb working of ram on a 1.03g board? The 1.03g boards were ok for me once a working config was established. But it was difficult to establish patterns across multiple kgpe boards with the 1.03g vs other revisions of boards. |
personally have not tried but someone in the d16 club said it was not an issue for them on multiple boards |
maybe #1760 fixed your issue? |
There's a lot of misinformation out there surrounding this board as well, especially the older posts |
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: