On Sat, 18 Jul 2020 16:44:13 +0000 [email protected] wrote: > On 2020-07-17 19:28, Denis 'GNUtoo' Carikli wrote: > > Hi, > > > > Thanks a lot for posting the log. > > Thank you for guiding me :) . > > I'll be working on this, but as that progresses, I have a question: > > #+begin_QUOTE > So even if this firmware looks trivial to replace, all the fields seem > related to the 3D acceleration, so at first we can just try patching > the code not to report an error if the loading fails. > #+end_QUOTE > > What if I run (raw) Linux? Would there be a way to retrieve those > values of =gpu_info_firmware_v1_0=? (with a debugger, may be?). The issue is not reconstructing that firmware as free software, it's probably trivial to use the printed value and/or the struct and/or even the binary to re-program it in another source form which produces the same binary. The more challenging part is to find a lawyer to make sure that the result is legal.
The issue is that Linux uses the word firmware for a wide range of things. By firmware they typically intend any data that you load from userspace to a device. So that can range from only data to hardware configuration or executable code. And here that data being loaded is most probably not even loaded to the device but just used by Linux to understand which GPU families have which features. The Radeon GPUs have many processors, for instance there is a command processor (named CP), there are probably some computation processor, there are some video decoding offload processors, and so on. I assume that the newer GPU supported by the amdgpu drivers have a similar architecture. So to get 3D acceleration you would probably need to start by understanding which firmware does what, and find hardware that need as few work as possible, and replace only the firmware that enable 3D acceleration. I'm unsure of what these firmware do, but we probably need to understand or reverse engineer the cores ISA and find out what the firmware is doing and re-implement it as free software. There is enough documentation out there to write free drivers, and reading that documentation (and asking questions to radeon/amdgpu developers) would be a good way to start. And if we're lucky we might have way less reverse engineering to do if the cores ISA and what the firmwares are supposed to implement is documented. Another route would be to try to understand if the firmwares are really needed, especially on older hardware, by doing the same approach that we are doing now: trying to find the places in the driver code that prevent it from fully working. If serious reverse engineering is needed, it would probably be a good idea to at least be familiar with C and be able to learn new assembly languages fast, and also learn about the usual techniques that can be used to do such reverse engineering. If it is possible to reverse engineer nonfree CPU microcode for AMD K8 and K10 CPU families, it's probably possible to do it for some classes of GPUs as well at least for 3D acceleration. And the way the microcode reverse engineering was done is very well documented in the corresponding academic paper, so it might be a good idea to look at it too. As there is no free firmware for AMD GPUs, people that are interesting in such project might also want to try to see if some firmwares are signed and which ones are not signed. Denis.
pgpq6bkKqp56D.pgp
Description: OpenPGP digital signature
_______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
