No, AMD Will Not Be Opening Up Its Firmware/Microcode

[bridgman]

Funny fact: the vast majority of issues I've never been able to solve even after years were firmware related.

Just checking, you're talking about power management here (which is driver/microcode interaction, not just microcode) ?

I'm not aware of any other microcode-related issues other than one or two times when we missed an internal microcode update and had to push new images out post-release.

[libv]

@Bridgman: If it was about DP, then it probably was rv6x5 docs? Then it was also rv6x5 that egbert added native C support for (for most things apart from DP) in a handful of changes.

Remember the Dell monitor story? The budget was there quick enough, then it took Dell 6-8 months to actually deliver it, and in that timeframe you heard rumours that they had approached AMD for their DP testing equipment... That thing was really picky about many things, and we were unable to test Christians HDMI audio code on it. So MSHopf and i walked to the playroom at SuSE after hours. Stole the big plasma attached to the Wii, and tested Christians code. 1h later, the facility manager frantically ran through the hall on our floor, and gave me quite the scolding... My answer: "we are doing software development here, you know, that what this company is supposed to be about". That did not help the situation.

[karolherbst]

We have some of that (UVD, VCE, MEC) but also a bunch of lower level HW microcode (memory controller, SDMA controller, ME etc..).

mhh, for video acceleration we currently use the nvidia provided ones and we actually use our own firmware for the PMU (for interpreting memory reclocking scripts), graph context switching and some DMA stuff I have no clue about.

So I suppose on nvidia hardware there is already everything built into the hardware and I have no idea if that's replaceable in any way, but maybe somebody else knows more.

[shmerl]

But why not though?

I suspect because of the control freaks from the media industry who want DRM. DRM can't be open source.

[bridgman]

@Bridgman: If it was about DP, then it probably was rv6x5 docs? Then it was also rv6x5 that egbert added native C support for (for most things apart from DP) in a handful of changes.

Remember the Dell monitor story? The budget was there quick enough, then it took Dell 6-8 months to actually deliver it, and in that timeframe you heard rumours that they had approached AMD for their DP testing equipment... That thing was really picky about many things, and we were unable to test Christians HDMI audio code on it. So MSHopf and i walked to the playroom at SuSE after hours. Stole the big plasma attached to the Wii, and tested Christians code. 1h later, the facility manager frantically ran through the hall on our floor, and gave me quite the scolding... My answer: "we are doing software development here, you know, that what this company is supposed to be about". That did not help the situation.

Sounds right. I remember there was some kind of gap in DP compliance testing tools, so a program our DAL team had hacked together for internal use was suddenly in demand from both OEM and display partners - and we didn't have anything like enough people to properly support external users (I think the compromise was writing user documentation). Interesting times.

[bridgman]

I suspect because of the control freaks from the media industry who want DRM. DRM can't be open source.

Yep. At our request the HW folks have been moving DRM-related functionality from driver-controlled HW into microcode. This is what has allowed us to open up driver support for video decode/encode, but it also means that opening up microcode is even less likely to happen than it was a decade ago.

[dungeon]

To have usable, up to date, whatever... so fixed machine i need to load blob microcodes for CPU, GPU (and a lot else part of today's not just GPU GPUs ) and SPU and my BIOS is blob too So in my case it is not AMD only issue here, but Realtek and ASUS do blobs too.

Of course blobs will stay in non-free repo section of Debian, in case user wants/needs it.

[coder111]

Not unexpected, but still somewhat sucks.

My 6550M still gets "ATOMBIOS stuck in loop" messages if I enable dynamic power management on it...

And without power management enabled, it runs slower than the APU graphics core, which sucks.

[pal666]

But why not though?

why not start with hardware, while we are at it?

[pal666]

We were mostly blocked by things which ATI was unable or unwilling to tell us

so maybe you should start by lobbying us parliament?