Microcode Blobs Added To Linux-Firmware For Latest AMD Hardware

[phoronix]

Phoronix: Microcode Blobs Added To Linux-Firmware For Latest AMD Hardware

The proprietary firmware files for Carrizo, Fiji, Tonga, and Topaz graphics processors from AMD have been added to the linux-firmware tree...

http://www.phoronix.com/scan.php?pag...Firmware-Added

[Nuc!eoN]

No reverse engineering....

Funny, AFAIK this clause is not even legit in most countries (at least in Europe).

[xeekei]

There are a lot of legal things regarding software that is stictly a US thing, that we all have to live with.

[Marc Driftmeyer]

You people make me laugh. I could care less about these binary blobs not being allowed to reverse engineering, etc. Build, invest and produce your own libreGraphics cards that perform to this level, or beyond. Then let's talk and praise you for such efforts. I doubt you'll do it for beer.

[blubbaer]

Funny, AFAIK this clause is not even legit in most countries (at least in Europe).

AFAIK this is not always true when the blob is very close related to the hardware. Therefore it is pretty difficult to legaly reverse engineer a BIOS or firmware.

[chithanh]

That AMD takes a hostile position against people wanting to write a free replacement for their proprietary microcode is not new.
The firmware license for radeon microcode forbids reverse engineering too.

[g7RbdHRt]

Anyone know why they keep the firmware closed source?

I remember an AMA with amd's CTO (I think) and basically just ignore the question.

Not much point going open-source if you keeping the critical part as blob. Kinda defeat the purpose.

[Espionage724]

Does Intel have a similar note about their graphics chips/drivers?

[jrch2k8]

Well, i'm fine with it as long as is only the microcode.

i mean people always get very anal about microcodes but in reality microcodes are useless unless you also have access to hardware diagrams or you are willing to brick several devices finding a way to activate hidden parts of the product which in a GPU is a very dumb idea since the most probable case is you wanna turn your 290 into a 290x(for example) telling the microcode to enable the dormant cores and that will probably burn it instead since is very likely the power routing in changed in the PCB to save that extra power, etc etc etc.

i care about open drivers and software compatibility support not which endian order and switch sequence the GPU need to ask PM chip to send voltage to the VRAM.

[Espionage724]

Well, i'm fine with it as long as is only the microcode.

i mean people always get very anal about microcodes but in reality microcodes are useless unless you also have access to hardware diagrams or you are willing to brick several devices finding a way to activate hidden parts of the product which in a GPU is a very dumb idea since the most probable case is you wanna turn your 290 into a 290x(for example) telling the microcode to enable the dormant cores and that will probably burn it instead since is very likely the power routing in changed in the PCB to save that extra power, etc etc etc.

i care about open drivers and software compatibility support not which endian order and switch sequence the GPU need to ask PM chip to send voltage to the VRAM.

The way I see it; it's not about who is going to do that kind of stuff; it's having the ability to do it. As it stands now; you have a piece of hardware that is as good as the vendor dictates it to be, and you aren't allowed to verify that it's "the best" it can really be.

Who knows, something like a 7850 might end up being able to tank a Titan or something if it wasn't locked up But you can't verify or change it even if it was intentionally crippled, legally anyway.

A similar situation is farmers not legally being able to fix their own John Deere mechanical tractors because of "mysterious DRM" and the end user not being allowed to tamper/re it...