Hello,
This is perhaps naive, but it's a question that I've been thinking about for a while.
Pretty much all AMD GPUs (both integrated and otherwise, including PCIe cards) rely on vgabios blobs for init and to support the driver(s).
From what I've heard, the people writing open source drivers for these GPUs really don't want to deal with the init and modesetting, ect. Does this mean it's more practical to try to make open source versions than to try to eliminate their use outright?
If that's the case, it seems like there's insufficient tooling?
There's been some stuff about reading and writing of vgabios blobs with flashrom [1] but I haven't heard anything about a compiler or toolchain that can produce them. The closest is the available disassembler [2], which can provide some insight but probably wouldn't be useful for building vgabios blobs from source as part of a coreboot build. (I think there were also some modified radeon drivers for tracing vgabios calls, but I can't find them now)
Besides a compiler, what other infrastructure would be needed? Maybe tools for testing and debugging?
-------------------------------------------------- A side tangent:
One thing realized recently is some versions of the G505s contain slightly different versions of the same rom. It seems my G505s' for example has different LVDS timings that perfectly match the slightly different panel that mine shipped with. [4]
I haven't been able to try a "normal" rom with the panel yet, but one theory to be tested is that the proprietary bios is patching the rom with the values from the panel's EDID information. (I tried installing a different panel, but was only met with a temporarily nonfunctional laptop)
Assuming it's not the rom modifying itself (do vgabios' have access to EDID information?), would it be correct to supply values from the EDID information to the vgabios build? Or would it be better to have the coreboot's loader patch the tables by parsing the current panel's EDID info? (I've seen comments that coreboot's lack of EDID parsing support also makes native graphics init harder [5])
Does anyone else know of other tooling that's out there?
Sincerely, -Matt
-------------------------------------------------- [1] https://www.phoronix.com/scan.php?page=news_item&px=Flashrom-AMD-SPI-Pat... [2] https://www.phoronix.com/scan.php?page=article&item=amd_atombios_dumper&... [3] [4] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/LKB4V... [5] https://www.raptorengineering.com/coreboot/kcma-d8-status.php I also came across some other misc stuff: https://www.phoronix.com/scan.php?page=news_item&px=MTQyMTg https://www.nongnu.org/vgabios/ --------------------------------------------------
Hello Matt,
On 04.06.19 22:21, Matt B wrote:
Pretty much all AMD GPUs (both integrated and otherwise, including PCIe cards) rely on vgabios blobs for init and to support the driver(s) > From what I've heard, the people writing open source drivers for these GPUs really don't want to deal with the init and modesetting, ect. Does this mean it's more practical to try to make open source versions than to try to eliminate their use outright?
the display engine (modesetting and such) seems to be undocumented for AMD devices. I guess many people would actually be happy to write proper open-source code for it (including myself). But without documentation from AMD it is a PITA.
If that's the case, it seems like there's insufficient tooling?
No, AFAIK it's just insufficient documentation. While AMD documents the computational/3D engine part of their hardware, the display engines are undocumented (unless that changed for recent generations). It's quite odd, I've never heard about any silicon vendor that is closed up as AMD on the matter. I guess it's some internal political issue because sb. is convinced that AtomBIOS (their closed implementation) is the way to go. Maybe we have to wait until the stakeholders retire.
There's been some stuff about reading and writing of vgabios blobs with flashrom [1]
This is just about being able to write to the flash chip on a graphics card.
but I haven't heard anything about a compiler or toolchain that can produce them. The closest is the available disassembler [2], which can provide some insight but probably wouldn't be useful for building vgabios blobs from source as part of a coreboot build. (I think there were also some modified radeon drivers for tracing vgabios calls, but I can't find them now)
I don't see the incentive behind creating some "open-source" version that simply replicates what the original VGABIOS does, without anybody understanding what it does. If you were happy with that, couldn't you just use the original binary?
Nico
[1] https://www.phoronix.com/scan.php?page=news_item&px=Flashrom-AMD-SPI-Pat... [2] https://www.phoronix.com/scan.php?page=article&item=amd_atombios_dumper&...
FYI: AMD's latest cards have a VGA card version of their PSP Platform "Security" processor aka a DRM chip for hollywood which apparently refuses to power on the card if there is an unsigned/non approved firmware flashed to the device.
It would have been good if they added this but made it owner controlled and didn't just simply break a card if a non-standard firmware gets flashed, it should have just re-flashed the firmware unless you flipped a dip switch on the card itself to shut if off making it owner controlled and an actual security measure not simply DRM for hollywood.
-
Matt B -
Nico Huber -
Taiidan＠gmx.com