cannot boot with linux-libre>=5.7, amdgpu and cryptsetup

[Denis 'GNUtoo' Carikli]

On Sat, 18 Jul 2020 16:44:13 +0000
edgar at openmail.cc 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20200718/b4f8e011/attachment.sig>