So is this true about AMD on Trisquel?

8 respostas [Última entrada]
BananaNutBread
Desconectado
Joined: 07/03/2014

I was very excited to learn and start using AMD graphics cards on GNU/Linux with the "open source" graphics drivers, but I'm not sure what the future looks like for these drivers? I've been biting at the bit to be a full Trisquel user but have been too unsuccessful in the past due to the older kernels/versions. I'm waiting on Trisquel 7 and a newer Kernel (I have used Lubuntu 14.04 so I could try the 3.13 kernel with the OSS Drivers). I'm really impressed with the performance of the Xorg drivers for AMD, but here's the big question now. I'm now reading in some places that the AMD OSS drivers won't even work with Trisquel because of 'micro-code issues'. Is this true? I mean has this been resolved with the newer kernels (no micro-code needed)? It seems that some people use the terms 'driver' and 'micro-code' and 'firmware' interchangably, so I'm wondering if this is true or that people are confusing each other by using different terms and referencing older kernels without the newer Xorg drivers. Anyways, I was hoping someone on here had an answer for me. Thanks.

Magic Banana

I am a member!

I am a translator!

Desconectado
Joined: 07/24/2010

Radeon cards work on Trisquel. But because of the proprietary firmware you mentioned (and that remains proprietary until now), some features do not work on a 100% free GNU/Linux distribution such as Trisquel. That includes 3D acceleration.

If your computer has an Intel graphical chipset (the case for all Intel processors, for many years), you had better remove the Radeon card and enjoy the perfect support of this chipset by the Linux-libre kernel (that all free GNU/Linux distributions, including Trisquel, use). You would save energy in this way too.

BananaNutBread
Desconectado
Joined: 07/03/2014

Well then why the heck do they even celebrate these drivers like a win for GNU/Linux users? You can't even use them wihtout proprietary code! I don't understand supposed "Linux enthusiasts" writers that are doing this then... I mean if anything it'll get current Free software users to accidently convert to closed code. At least that's how it's worked for me, lol. I sadly don't have an Intel chipset, I prefer AMD (don't ask why, I just do, lol). I use a high end ASUS motherboard as well, so it can use four videocards at once, but doesn't contain an integrated video card. This kinda stinks! So my only hope of 3D acceleration in Trisquel is using Intel integrated graphics (NOT my prefered choice) or antique Nvidia cards like the 9500GT? Thanks for your respose by the way.

onpon4
Desconectado
Joined: 05/30/2012

That's just what not valuing freedom leads to. You've got people thinking it's fine because of where the proprietary firmware is being run, and it doesn't help that the main distribution of the kernel Linux includes these proprietary blobs. For example, one of the people responsible for the OpenPandora once justified proprietary firmware as "more open" than proprietary drivers because you can get the firmware to work with any OS. If all you value is "openness", this makes sense. If you value freedom, a proprietary firmware requirement is no better than a proprietary driver requirement.

Indeed, using an old Nvidia card (that works with Nouveau) is the best choice if you want to use an AMD CPU. I don't think there's even an active reverse-engineering effort for Radeon cards, so you can expect them to be essentially pieces of junk forever.

megurineturilli
Desconectado
Joined: 01/10/2012

Some time ago when I did not care about freedom, I was using AMD CPUs. When I switched to Trisquel I realized that AMD does not want users to have freedom. AMD could easly solve the problem by burning the firmware into a ROM or hardwiring the command processor. I think releasing the source code would not help here in this specific case, as there is no free compiler that handles hardware description languages and works with real hardware.

I also learned how to reverse engineer the nonfree firmware that drives the Yamaha FB-01. In this case the nonfree program was burned into a ROM, so that old device is not a problematic one. The CPU is a well known one, and free disassembly tools are avialable. I also know how to design a CPU, which can be implemented on an FPGA. I know that there is a reverse engineering project that tries to replace the nonfree tools required to program an FPGA.

Recently I baught a refurbished OpenPandora. First I deleted all nonfree firmwares, and installed the free firmware for the TPE-N150USB. Now I can use the wireless network without giving up my freedom. I think the hardest part here is GPU, as there are no free drivers and no free fireware for the GPU. There is a reverse engineering project at[1], but this seems to be dead. But I can play some games such as Wesnoth and Tetris without using nonfree software. Unlike the Raspberry Pi no nonfree startup software is required, instead a boot-ROM is used instead. I think using a ROM for the boot firmware is the best solution as it prevents the user from accidently bricking the computer.

Currently I do not have time to reverse engineer the GPU as I'm working on a free software replacement for the mbrola speech synthesizer. I can do so without reverse engineering, as the algorithms used by mbrola are well documented. Reverse engineering would be needed if you want to use mbrola voices with a free program. However the licence of the mbrola project does not allow to use of the voices with a different program than mbrola itself.

[1] https://www.fsf.org/blogs/community/new-high-priority-project-powervr-drivers

Legimet
Desconectado
Joined: 12/10/2013

I have a Replicant tablet with PowerVR. I really hope someone reverse engineers it.

BTW, the Raspberry Pi's GPU blob was actually freed by Broadcom. :)
https://libv.livejournal.com/26434.html

Michał Masłowski

I am a member!

I am a translator!

Desconectado
Joined: 05/15/2010

At least the ME microcode for R600 (and probably earlier CP microcode) is simple code with separate instructions for reading or writing registers, Rob Clark of Freedreno partially reverse engineered the instruction format. Newer Radeons have different ISAs. (ME is microengine, CP is control processor which has e.g. ME; it's not related to the Intel management engine used for AMT.)

Lack of existing free compilers is not an issue here: it needs a very simple assembler and some ISA documentation. It's not like CPU microcode or FPGA data.

Some time-consuming work is needed to reverse engineer the ISA and replace the microcode, all interested people that I know have other projects and do not have enough free time to do this.

(There was an important kernel change regarding microcode dependency: now modesetting won't work on recent Radeons without the microcode, since the driver uses features that require it. I don't know the details of these changes.)

lembas
Desconectado
Joined: 05/13/2010

And on the lingo, driver is one thing, microcode and firmware another. And as you've noticed people use all three in a confusing mash.

I don't think there has been any breakthrough vis-a-vis Radeons in freedom.

Michał Masłowski

I am a member!

I am a translator!

Desconectado
Joined: 05/15/2010

They have clear definitions: driver is the code running on the main CPU. There are drivers in the kernel (DRM: direct rendering manager; radeon), X server (DDX; xf86-video-ati), Mesa (DRI; e.g. r600g). Firmware and microcode are different words for the same (Linux calls it firmware, developers and documentation microcode): code uploaded by the kernel driver and run on the GPU.

The "open source" drivers have no nonfree code running on the main CPU (except for code stored in the VGA ROM: AtomBIOS), unlike the fully nonfree driver that AMD develops too. This leads to confusing claims as if no nonfree code was used for 3D acceleration on Radeons.

There were some improvements: xf86-video-radeonhd worked nearly without the VGA ROM, not running AtomBIOS code, there was more documentation available for these purposes then. AMD worked against this.