The Updated AMD Polaris Firmware Blobs Needed For RX 480 Support Land

[bridgman]

I agree for the most part. Either the FSF should care if non-free firmware is built into flash as well and block that, or permit firmware files to be loaded on hardware that requires it. It's the biggest disagreement I have with the FSF, but I am a FSF supporter.

Yep, although the biggest problem IMO is that microcode built into hardware is felt to be fine but the same microcode loaded into the hardware at power-up is not. The flash data point just makes things even more frustrating

But probably there is still a line that should be drawn. We don't want to go down the path where proprietary firmware is needlessly complex just to avoid proprietary drivers (for example). But I don't see any easy way to avoid that without just blocking it all.

My understanding is that the original idea for drawing a line between built-in and soft-loaded microcode came from using "need for regular updates" (and hence soft-loading) as a proxy for "needlessly complex just to avoid proprietary drivers". That was a pretty good idea IMO.

The problem is that the original guideline has not been updated to reflect things like GPU microcode, where soft-loading allows frequent updates prior to launch in support of rapid development cycles (look at the rate of GPU progression relative to CPU) and "standards" that are still changing when the hardware design is locked down. Post-launch updates are relatively rare, other than the case where we regenerated all of the microcode files in order to add headers at the front of each image, and so far have either been in direct support of opening up additional driver code (eg UVD1) or in cases where we released initial driver code using older microcode and didn't have a chance to update the two until later. Now that open source driver development is caught up with HW development again I don't expect to see many post-launch microcode updates for new hardware.

My personal hope was that AMD might be able to release an alternate free firmware for distros like GuixSD which doesn't have any of the DRM stuff that Windows requires (or maybe provide some assistance to teams that want to work on it), but I understand that would be a challenging and time-consuming task. Hopefully one day AMD sees benefit to addressing this.

Agree that that would make most users happy, and we have looked into it a couple of times. Problem is that in order for the alternate microcode to meet "free" criteria there would also need to be a toolchain allowing it to be modified and rebuilt. Once that toolchain was made available (or reverse engineered) the original microcode for that block effectively gets opened as well. We would not only need to implement alternate microcode but would need to build alternate chips with alternate hardware so that having a toolchain for alternate microcode does not put the original microcode at risk.

[Passso]

This is a GPU, not a CPU that also records all you say awaiting for a "wakeup windows" to power on the pc or something.

I really hope Zen does not do these kinds of shit, but it isn't terribly better than intel in openness of their firmwares.

AMD is a US company, I do not expect them to disobey.
Anyway there is no hope on this part, be sure that all the chinese hardware are concerned too... for their own flag.

[Passso]

I agree for the most part. Either the FSF should care if non-free firmware is built into flash as well and block that, or permit firmware files to be loaded on hardware that requires it. It's the biggest disagreement I have with the FSF, but I am a FSF supporter.

But probably there is still a line that should be drawn. We don't want to go down the path where proprietary firmware is needlessly complex just to avoid proprietary drivers (for example). But I don't see any easy way to avoid that without just blocking it all.

My personal hope was that AMD might be able to release an alternate free firmware for distros like GuixSD which doesn't have any of the DRM stuff that Windows requires (or maybe provide some assistance to teams that want to work on it), but I understand that would be a challenging and time-consuming task. Hopefully one day AMD sees benefit to addressing this.

Sorry for my pessimism, but the NSA can/do hide their code as far/low level as they need to.

So "fighting for the firmware" is a waste of time, if you really do want opensource and verified hardware a project has to design it from the ground...
And even in this case, what if the founder itself get involved in the process? Checkmate imo.

[Adarion]

OMG, the premium thingy tells me it's only ~5 h to the release of the tests. I suspect that drivers won't operate on 100% performace in this "rather early" stage, but I'm looking forward to get this hardware to know, see more pictures, learn about generic features, power consumption and to see just launch day support in free and blob stack.

On the firmware: I agree with bridgman that it's kinda silly make that much of a difference between FW that is "part of the HW", aka stored in a ROM and FW that is loaded. Well, one could try to smuggle malware later more easily into the system and have it running on lowest level (even out of reach for kernels, anti-malware solutions and so on); but other than that it's kind of the same.

However I would of course be fond if we had freedom firmware, too. It is the better way below the line (code quality on the long term, security / privacy issues and concerns) - since firmware can be a crucial element of correct operation and it also allows a lot of things and poses a high security threat. (Think of UEFI's network stack -> WTF is that good for? Full network on lowest level, OS independent and transparent to the OS?)

On the other hand I see that there can sometimes be multiple parties involved, microcontroller manufacturers, 3rd party "IP" for purely technical solutions and digital restriction management problems e.g. when it comes to video decoding, transmission of signals via HDMI/HDCP. That can hamper the efforts of an enterprise to write fully free drivers.
Also, once you allow firmware uploads to the HW (even without real flashing), it should be taken care of that no malware could use that mechanism and just load any code into these low levels.

[juno]

This is a GPU, not a CPU that also records all you say awaiting for a "wakeup windows" to power on the pc or something.

I really hope Zen does not do these kinds of shit, but it isn't terribly better than intel in openness of their firmwares.

You might be disappointed when you read about AMD's platform security processor, that will be built in zen CPUs as well... But this is a whole different story

[Slartifartblast]

Where do you think those shills come from? They've been harassing the AMD threads for years.

Not shills, paying AMD customers who had lousy GPU driver support length for both Windows and Linux. If AMD wanted to stick the finger to their customers to save a couple of dollars on a reasonable support time length for their drivers then on their head be it.

[Nille_kungen]

You might be disappointed when you read about AMD's platform security processor, that will be built in zen CPUs as well... But this is a whole different story

Wasn't PSP already included in “Beema” and “Mullins”?

[starshipeleven]

You might be disappointed when you read about AMD's platform security processor, that will be built in zen CPUs as well... But this is a whole different story

That thing is there since a while and I'm a bit pissed but heh.

I was referring to a feature of newer Intel processors that have a controller that LISTENS to all is said around the PC (I assume from microphones you connect to the PC, on laptops the microphone is usually bolted in), waiting for a magic word to wake up the computer.

I'm sure it's benign at this current moment, but shit like this can go TERRIBLY wrong in so many ways that it's not even funny.
When the PC is shut down it is SHUT FUCKING DOWN, not listening to what I say looking for a specific keyword like say "thanks Obama" or "Aloha Snackbar".

Not shills, paying AMD customers who had lousy GPU driver support length for both Windows and Linux. If AMD wanted to stick the finger to their customers to save a couple of dollars on a reasonable support time length for their drivers then on their head be it.

On windows AMD drivers are good since nearly a decade ago, it's currenly NVIDIA drivers that do have some issues and keep pulling bugs from the cylinder.

[Passso]

AMD loses nothing if they put a flash chip with the firmware on the hardware.

it also could be a PR stunt if you use a very fast SSD-like flash chip so they could use it as a shader-cache or speed up loading games or similar use cases. you even could PR it as a VRAM extension and many people just buy the graphic card with the most VRAM on the market even it is only ddr3 instead of GDDR5.

so AMD's PR is just a '''understatement'''

They could even sell even more cards when a bug brick them.

[juno]

Wasn't PSP already included in “Beema” and “Mullins”?

Yes, and also in CZ/BR.