KGPE-d16 board status : untested

[tlaurion]

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 ?

[Tonux599]

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 kgpe-d16_workstation and injected some GPU firmware files into the initrd for amdgpu module.

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 :slightly_smiling_face:

[tlaurion]

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.

You mean flashrom used under heads master or dasharo/flashrom? Both are supposed to work AFAIK, unfortunately my kgpe-d16 has some issue, either CPU/RAM after long storage.... If it could boot, I would test myself but it loops on raminit

[tlaurion]

I didn't investigate too much but the "flashing" progress bar just did not progress over many minutes.

@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).

[build-cool91]

@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?

[tlaurion]

@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

[build-cool91]

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.

[tlaurion]

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

[tlaurion]

Crosslinking to #1421

[Tickmeister1]

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.

[Tickmeister1]

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?

[Tickmeister1]

Tested heads internal flashrom: success. Flashrom -p internal found my Winbond W25Q128 and wrote a testbackup.rom at /tmp

[tlaurion]

Wow. That was unexpected. So you need nvme support under workstation?

[Tickmeister1]

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.

[tlaurion]

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. I can add nvme in kernel, but you won't be able to boot from it AND have that controller assigned to an HVM. It's one or the other.

[Tickmeister1]

Understood. The sata controller is separate from the pcie connected nvme, right?

[tlaurion]

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?

[tlaurion]

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

[Tickmeister1]

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.

[tlaurion]

See helpers for make BOARD=xyz linux. Tab tab

@Tickmeister1 :

Sorry, I was away from keyboard last time I gave instructions and they were not specific enough

This helper will make the right thing: https://github.com/osresearch/heads/blob/02c3a1f9ee270403a962fd826ade28d642a232fb/modules/linux#L236

So make BOARD=kgpe-d16_flavor linux.modify_and_save_oldconfig_in_place

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 git diff and you should see that they match above referred changes for other board. You should be good to go building board as usual.

It will be "dirty" since Heads detects that changes were not commited (official, signed).

[build-cool91]

Okay sorry for the delay I built the workstation with usb keyboard yesterday.... Heads-v0.2.0-1743-gfbc0993 and it's not posting. This is what it hangs at looking at serial:

PCI: 00:00.0 sr5690_set_resources
sr5690_set_resources: PCI: 00:00.0[0x1c] base = c0000000 limit = cfffffff
PCI: 00:00.0 c0010058 <- [0x00c0000000 - 0x00cfffffff] size 0x10000000 gran 0x00 mem <mmconfig>
sr5690_set_resources: PCI: 00:18.1 <- index a8 base c00003 limit cfff90
PCI: 00:00.0 fc <- [0x00fcc00000 - 0x00fcc000ff] size 0x00000100 gran 0x08 prefmem
PCI: 00:00.2 44 <- [0x00fcb00000 - 0x00fcb03fff] size 0x00004000 gran 0x0e mem
PCI: 00:02.0 1c <- [0x0000004fff - 0x0000004ffe] size 0x00000000 gran 0x0c bus 01 io
PCI: 00:02.0 24 <- [0x00fccfffff - 0x00fccffffe] size 0x00000000 gran 0x14 bus 01 prefmem
PCI: 00:02.0 20 <- [0x00fcbfffff - 0x00fcbffffe] size 0x00000000 gran 0x14 bus 01 mem
PCI: 00:04.0 1c <- [0x0000004fff - 0x0000004ffe] size 0x00000000 gran 0x0c bus 02 io
PCI: 00:04.0 24 <- [0x00fccfffff - 0x00fccffffe] size 0x00000000 gran 0x14 bus 02 prefmem
PCI: 00:04.0 20 <- [0x00fcbfffff - 0x00fcbffffe] size 0x00000000 gran 0x14 bus 02 mem
PCI: 00:09.0 1c <- [0x0000001000 - 0x0000001fff] size 0x00001000 gran 0x0c bus 03 io
PCI: 00:09.0 24 <- [0x00fccfffff - 0x00fccffffe] size 0x00000000 gran 0x14 bus 03 prefmem
PCI: 00:09.0 20 <- [0x00fc900000 - 0x00fc9fffff] size 0x00100000 gran 0x14 bus 03 mem
PCI: 03:00.0 10 <- [0x00fc900000 - 0x00fc91ffff] size 0x00020000 gran 0x11 mem
PCI: 03:00.0 18 <- [0x0000001000 - 0x000000101f] size 0x00000020 gran 0x05 io
PCI: 03:00.0 1c <- [0x00fc920000 - 0x00fc923fff] size 0x00004000 gran 0x0e mem
PCI: 00:0a.0 1c <- [0x0000002000 - 0x0000002fff] size 0x00001000 gran 0x0c bus 04 io
PCI: 00:0a.0 24 <- [0x00fccfffff - 0x00fccffffe] size 0x00000000 gran 0x14 bus 04 prefmem
PCI: 00:0a.0 20 <- [0x00fca00000 - 0x00fcafffff] size 0x00100000 gran 0x14 bus 04 mem
PCI: 04:00.0 10 <- [0x00fca00000 - 0x00fca1ffff] size 0x00020000 gran 0x11 mem
PCI: 04:00.0 18 <- [0x0000002000 - 0x000000201f] size 0x00000020 gran 0x05 io
PCI: 04:00.0 1c <- [0x00fca20000 - 0x00fca23fff] size 0x00004000 gran 0x0e mem
PCI: 00:0b.0 1c <- [0x0000004fff - 0x0000004ffe] size 0x00000000 gran 0x0c bus 05 io
PCI: 00:0b.0 24 <- [0x00fccfffff - 0x00fccffffe] size 0x00000000 gran 0x14 bus 05 prefmem
PCI: 00:0b.0 20 <- [0x00fcbfffff - 0x00fcbffffe] size 0x00000000 gran 0x14 bus 05 mem
PCI: 00:0c.0 1c <- [0x0000004fff - 0x0000004ffe] size 0x00000000 gran 0x0c bus 06 io
PCI: 00:0c.0 24 <- [0x00fccfffff - 0x00fccffffe] size 0x00000000 gran 0x14 bus 06 prefmem
PCI: 00:0c.0 20 <- [0x00fcbfffff - 0x00fcbffffe] size 0x00000000 gran 0x14 bus 06 mem
PCI: 00:0d.0 1c <- [0x0000004fff - 0x0000004ffe] size 0x00000000 gran 0x0c bus 07 io
PCI: 00:0d.0 24 <- [0x00fccfffff - 0x00fccffffe] size 0x00000000 gran 0x14 bus 07 prefmem
PCI: 00:0d.0 20 <- [0x00fcbfffff - 0x00fcbffffe] size 0x00000000 gran 0x14 bus 07 mem
PCI: 00:11.0 10 <- [0x0000004020 - 0x0000004027] size 0x00000008 gran 0x03 io
PCI: 00:11.0 14 <- [0x0000004040 - 0x0000004043] size 0x00000004 gran 0x02 io
PCI: 00:11.0 18 <- [0x0000004028 - 0x000000402f] size 0x00000008 gran 0x03 io
PCI: 00:11.0 1c <- [0x0000004044 - 0x0000004047] size 0x00000004 gran 0x02 io
PCI: 00:11.0 20 <- [0x0000004000 - 0x000000400f] size 0x00000010 gran 0x04 io
PCI: 00:11.0 24 <- [0x00fcb0d000 - 0x00fcb0d3ff] size 0x00000400 gran 0x0a mem
PCI: 00:12.0 10 <- [0x00fcb08000 - 0x00fcb08fff] size 0x00001000 gran 0x0c mem
PCI: 00:12.1 10 <- [0x00fcb09000 - 0x00fcb09fff] size 0x00001000 gran 0x0c mem
PCI: 00:12.2 10 <- [0x00fcb0e000 - 0x00fcb0e0ff] size 0x00000100 gran 0x08 mem
PCI: 00:13.0 10 <- [0x00fcb0a000 - 0x00fcb0afff] size 0x00001000 gran 0x0c mem
PCI: 00:13.1 10 <- [0x00fcb0b000 - 0x00fcb0bfff] size 0x00001000 gran 0x0c mem
PCI: 00:13.2 10 <- [0x00fcb0f000 - 0x00fcb0f0ff] size 0x00000100 gran 0x08 mem
PCI: 00:14.1 10 <- [0x0000004030 - 0x0000004037] size 0x00000008 gran 0x03 io
PCI: 00:14.1 14 <- [0x0000004048 - 0x000000404b] size 0x00000004 gran 0x02 io
PCI: 00:14.1 18 <- [0x0000004038 - 0x000000403f] size 0x00000008 gran 0x03 io
PCI: 00:14.1 1c <- [0x000000404c - 0x000000404f] size 0x00000004 gran 0x02 io
PCI: 00:14.1 20 <- [0x0000004010 - 0x000000401f] size 0x00000010 gran 0x04 io
PCI: 00:14.2 10 <- [0x00fcb04000 - 0x00fcb07fff] size 0x00004000 gran 0x0e mem64
PCI: 00:14.3 a0 <- [0x00fcb10000 - 0x00fcb10000] size 0x00000001 gran 0x00 mem

[tlaurion]

@Tickmeister1 ?

[build-cool91]

This is attempting USB boot, but I know the USB and board boot with Dasharo for example.

[tlaurion]

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? Dasharo fork should definitely be investigated, but here we are still based on 4.11. Seems like some people are interested in actively testing this. I will try to find time switching coreboot to dasharo in a PR, but if @Tickmeister1 or @build-cool91 you are faster then me, there are PR drafts exactly doing so that could be customized on top of master. We should collaborate in those PR to make it upstream, while Dasharo on kgpe-d16 has its own subsets of known bugs, so I do not know what is best to use currently on 0.4 release notes

Fixed

    [KGPE-D16 can not boot with a GPU connected](https://github.com/Dasharo/dasharo-issues/issues/48)
    [Configs for platforms without TPM](https://github.com/Dasharo/dasharo-issues/issues/62)
    [Bugs in DQS timing (kudos to Mike Rothfuss)](https://github.com/Dasharo/coreboot/pull/116)

Known issues

    [Booting from recovery doesn't work](https://github.com/Dasharo/dasharo-issues/issues/66)
    [Fan controller gets stuck at 100%](https://github.com/Dasharo/dasharo-issues/issues/169)
    [FreeBSD serial output is broken](https://github.com/Dasharo/dasharo-issues/issues/170)
    [Linux kernel panic on booting USB media](https://github.com/Dasharo/dasharo-issues/issues/171)
    [Builds are not reproducible](https://github.com/Dasharo/dasharo-issues/issues/189)

[tlaurion]

This is attempting USB boot, but I know the USB and board boot with Dasharo for example.

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... :/)

[build-cool91]

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?

[tlaurion]

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 https://github.com/osresearch/heads/pull/1303

Note that it is not expected to be perfect at all.

[tlaurion]

@Tickmeister1 @build-cool91 @Tonux599 Added UART=0 for workstation under https://github.com/osresearch/heads/pull/1303/commits/95e58a34849e5367c8da766225c6c8e12c66a735 + linear FB init + bootsplash, so that console output is over serial console (as opposed to SOL (bmc).

Let me know differences compared to https://github.com/osresearch/heads/pull/1303/commits/842eda22326b9433dcea484de42046c923d6ae56 roms as opposed to roms of master.

Also, NVME as been activated under linux under https://github.com/osresearch/heads/pull/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

[Tickmeister1]

I am currently focused on flashing my bmc to openbmc. Will resume testing heads when that is done.

[build-cool91]

Okay looks like I'm getting successful POST message in serial with #1303 CircleCI "kgpe-d16_workstation-usb_keyboard" rom but nothing on my monitor and no OS boot. May be a dumb question, but I should at least be seeing the HEADS gui menu right?

My GPU is: AMD Radeon PRO WX 3200 4GB GPU

[build-cool91]

Going back to the Dasharo rom I am able to boot both USB and SSD.

[tlaurion]

Okay looks like I'm getting successful POST message in serial with #1303 CircleCI "kgpe-d16_workstation-usb_keyboard" rom but nothing on my monitor and no OS boot. May be a dumb question, but I should at least be seeing the HEADS gui menu right?

My GPU is: AMD Radeon PRO WX 3200 4GB GPU

@build-cool91

Please dump your serial output here so that can be used to see what is working or not

[build-cool91]

Okay attached the text file heads-1303-test.txt

[tlaurion]

@build-cool91

Ok just to make sure we are at the same page. Jumper on board is set to bypass ASPEED iGPU?

[tlaurion]

Okay attached the text file\nheads-1303-test.txt

Reading the logs, I see vga being detected from PCI but see also this error

• Base: 1040000000, Size: ffefc0000000, Tag: 100200 PCI: 00:18.3 94 [0xd0000000 - 0xd3ffffff] limit: d3ffffff mem PCI: 00:18.0 90 [0xd4000000 - 0xd7cfffff] limit: d7cfffff mem ERROR: Resource didn't fit!!! PCI: 00:18.0 80 size: 0x10000000 limit: cfffffff mem PCI: 00:18.0 88 [0x1040000000 - 0x10c01fffff] limit: 10c01fffff prefmem DOMAIN: 0000 mem: base: 0 size: 0 align: 0 gran: 0 limit: ffffffffffff done PCI: 00:18.0 io: base: 1000 size: b000 align: 12 gran: 12 limit: bfff PCI: 00:18.0: Resource ranges: * Base: 1000, Size: b000, Tag: 100

[tlaurion]

@Tickmeister1 can you post your cbmem -1 logs from Circleci flashed Rom just like reported in previous post?

[build-cool91]

@build-cool91

Ok just to make sure we are at the same page. Jumper on board is set to bypass ASPEED iGPU?

Yes 100%, the VGA_SW1 jumper is set to disable. Unsure why VGA is still detected though.... ?

Just as a troubleshooting step I'll remove the PCI sound card and retry also.

[build-cool91]

@tlaurion Removing the PCI sound card didn't make a difference...any troubleshooting tips you can think of?

[tlaurion]

@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?

[Tonux599]

@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.

https://wiki.gentoo.org/wiki/AMDGPU#Known_firmware_blobs

[tlaurion]

@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

[build-cool91]

@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?

[tlaurion]

@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.

[build-cool91]

@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?

[Tonux599]

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.

@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

[build-cool91]

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

[tlaurion]

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?\n\nShould I post in the #1303 thread instead then?

@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.

[build-cool91]

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.

[build-cool91]

@tlaurion Any good reference material, are there any good resources you could point me to for the above?

[build-cool91]

@tlaurion Okay got my Nvidia 780 in the mail and attempted to boot....IT WORKS!! :+1:

Would still like to understand how to add bobs to initrd, but for now using an Nvidia GPU is good enough.

[build-cool91]

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.