Will the new APUs/GPUs support a fully libre firmware

[Laughing1]

Yes, just hope they don't update the vBIOS like the following: https://www.phoronix.com/scan.php?pa...-New-SMC-Micro

[Laughing1]

Yep, it's only better when dealing with distributions who arbitrarily declare it to be better.

https://www.gnu.org/philosophy/free-...esigns.en.html

"There is a gray area between hardware and software that contains firmware that can be upgraded or replaced, but is not meant ever to be upgraded or replaced once the product is sold. In conceptual terms, the gray area is rather narrow. In practice, it is important because many products fall in it. We can treat that firmware as hardware with a small stretch.

Some have said that preinstalled firmware programs and Field-Programmable Gate Array chips (FPGAs) “blur the boundary between hardware and software,” but I think that is a misinterpretation of the facts. Firmware that is installed during use is software; firmware that is delivered inside the device and can't be changed is software by nature, but we can treat it as if it were a circuit. As for FPGAs, the FPGA itself is hardware, but the gate pattern that is loaded into the FPGA is a kind of firmware."

https://www.fsf.org/resources/hw

So the issue is with Gnu.

[Space Heater]

The only way it's better is that it has more chance of working under the current rules of libre distros (ROM good, file bad, flash TBD).

Yep, it's only better when dealing with distributions who arbitrarily declare it to be better.

[bridgman]

How is it better to put proprietary software on ROM?

The only way it's better is that it has more chance of working under the current rules of libre distros (ROM good, file bad, flash TBD).

[Space Heater]

The perverse thing is that libre distros enthusiastically support HW vendors who deliver closed source firmware in ROM but not HW vendors who deliver the same closed source firmware in files. I guess if they didn't support HW vendors who deliver closed source firmware in ROM they wouldn't be able to run on any hardware.

It's just insane that the FSF prefers proprietary firmware in ROM simply because it allows them to stick their heads in the sand and pretend it isn't software.

Firmware in ROM is a step in the right direction. I think, better than non-working gnu hardware.

How is it better to put proprietary software on ROM?

With a loadable firmware file the user can update the firmware, and they can delete or remove the file to control if the device will be initialized/operate.

[Laughing1]

Firmware in ROM is a step in the right direction. I think, better than non-working gnu hardware.

[bridgman]

Could you just make the ASIC different and have it modular where you could take one libre/drm one out and put another in the card?

Right, that's what it would take - different GPUs for the Linux and Windows markets. That gets into some fairly big supply chain challenges though... question is whether we could even get a board vendor interested in building and distributing a separate SKU for the libre market.

We tried a couple of times to get board partners to include a larger EEPROM on the board so we could store firmware images there but even the sub-dollar cost was a tough sell... I don't see how we could get board partners onside even if we ignore the (much larger) tapeout and fab costs vs the (probably very small) sales.

EDIT - just noticed you were talking about putting the libre version "in the card"... it would have to go "in the GPU" in order for the Windows version to be sufficiently robust. Might be possible to heavily encrypt the interconnect between the die with the microcode engines and the die with the rest of the GPU, but things like key invalidation make that complicated and it's pretty easy to pick apart most encryption schemes if you can control the traffic going across the link (by modifying and rebuilding the libre firmware).

The only workable approach I was able to come up with was having two sets of microcoded blocks on the same die, which would add to the cost of every chip we make (silicon area) in addition to the one-time costs (design, layout, microcode development) but that seems like a non-starter from the... um... start.

The only workable approach I see is waiting for an industry inflection point where we need to double up the size of the EEPROM on the board and use the unused storage for firmware images. Doesn't give you libre firmware but it makes us as open as any vendor on the market, by putting the firmware in ROM rather than files. Not a great solution but modern GPUs have so much of their hardware implemented using microcode that reconciling the "libre firmware vs content protection" conflict is really tough.

[Laughing1]

It's not as easy as just doing separate firmware, unfortunately. In order to have libre firmware you also need toolchains for the firmware... and the IP aspects of the toolchain (instructions set, programming model, registers etc..) would be common to the two and would make it easier to attack the Windows firmware and the mandatory DRM it supports.

Doing it safely would really require a separate HW implementation for Linux and Windows... and even that gets iffy now that we are getting more requests to support content protection on Linux.

Could you just make the ASIC different and have it modular where you could take one libre/drm one out and put another in the card?

[bridgman]

Could you do one firmware for Linux and another for Windows, etc? Just load it at boot?

It's not as easy as just doing separate firmware, unfortunately. In order to have libre firmware you also need toolchains for the firmware... and the IP aspects of the toolchain (instructions set, programming model, registers etc..) would be common to the two and would make it easier to attack the Windows firmware and the mandatory DRM it supports.

Doing it safely would really require a separate HW implementation for Linux and Windows... and even that gets iffy now that we are getting more requests to support content protection on Linux.

[Laughing1]

It would be nice to have more libre hardware with appropriate firmware to add here: https://h-node.org/