"Panthor" DRM Driver Coming Together For Newer Arm Mali GPUs

[phoron]

I'm not very bright today. Can you bear with a paranoid seizure of mine? "The CSF provides a firmware-driven command stream queue" does mean that in addition to the memory init blob, and no public source for the TF-A, the GPU of RK3588 also needs a firmware blob ? Or is it in ROM ? or is it uploaded, but that firmware is free software ?
Thanks.

[coder]

does mean that in addition to the memory init blob, and no public source for the TF-A, the GPU of RK3588 also needs a firmware blob ? Or is it in ROM ? or is it uploaded, but that firmware is free software ?

AFAIK, all modern GPUs have embedded microcontrollers. I presume the firmware for them is bundled with the "init" blob, but I don't actually know. It would be weird to rely on ROM to store anything more than the bare minimum needed to bootstrap the thing, given how complex and subject-to-change this firmware probably is.

[phoron]

AFAIK, all modern GPUs have embedded microcontrollers. I presume the firmware for them is bundled with the "init" blob, but I don't actually know. It would be weird to rely on ROM to store anything more than the bare minimum needed to bootstrap the thing, given how complex and subject-to-change this firmware probably is.

Thank you. But AFAIK RK3399 (which might not be modern for you, of course) does not need loaded firmware. It has the bootrom, then mainstream source TF-A, U-boot (with TPL to init RAM, you don't need init blob), and linux-libre, and it runs panfrost. So if there's non-free firmware for RK3399 GPU I don't know what would be loading it. I think there isn't any.

I don't know why they can't free any firmware that is needed. Blobs end up creeping everywhere...

[nyanmisaka]

Thank you. But AFAIK RK3399 (which might not be modern for you, of course) does not need loaded firmware. It has the bootrom, then mainstream source TF-A, U-boot (with TPL to init RAM, you don't need init blob), and linux-libre, and it runs panfrost. So if there's non-free firmware for RK3399 GPU I don't know what would be loading it. I think there isn't any.

I don't know why they can't free any firmware that is needed. Blobs end up creeping everywhere...

AMDGPU, the most popular open source gpu driver in the phoronix community, has long embraced GPU firmware blobs, and Intel and Nvidia are no exception. Arm also turned to firmware-assisted scheduling after Mali-Gxxx (Valhall 3rd gen and newer). Collabora has an article for this transition.

[phoron]

AMDGPU, the most popular open source gpu driver in the phoronix community, has long embraced GPU firmware blobs, and Intel and Nvidia are no exception. Arm also turned to firmware-assisted scheduling after Mali-Gxxx (Valhall 3rd gen and newer). Collabora has an article for this transition.

Thanks a lot. That's quite informative. I still don't know whether the GPU scheduling firmware for rk3588 is free or not, signed or not, or how does it get loaded, but at least it says it's code for cortex-M7 so at least there should be a free toolchain for it.

One reason I went with ARM is that not all SOCs required blobs. AMD, NVidia and Intel are too encumbered with highly privileged proprietary software. Apparently all good things come to an end...

Thanks again.

[nyanmisaka]

Thanks a lot. That's quite informative. I still don't know whether the GPU scheduling firmware for rk3588 is free or not, signed or not, or how does it get loaded, but at least it says it's code for cortex-M7 so at least there should be a free toolchain for it.

One reason I went with ARM is that not all SOCs required blobs. AMD, NVidia and Intel are too encumbered with highly privileged proprietary software. Apparently all good things come to an end...

Thanks again.

The firmware binary is provided by Arm, so it's unlikely open source, or at least Arm has no current plans to open source it.

Also the panthor_fw.c comment mentions that there is a magic value in the firmware header to check the validity. More details about how it works should be in the driver code.

[phoron]

The firmware binary is provided by Arm, so it's unlikely open source, or at least Arm has no current plans to open source it.

Thanks again. So another blob. Another piece of hardware unusable with linux-libre.

Also the panthor_fw.c comment mentions that there is a magic value in the firmware header to check the validity. More details about how it works should be in the driver code.

So the kernel loads the firmware from the filesystem, seems to keep it in RAM and loads it to the GPU microcontroller at startup and any time a slow GPU reset is needed.
There's a magic value and some checksum, doesn't seem dangerous, but it also doesn't say whether something in the GPU checks some signature to validate what is loaded.
The driver checks whether firmware start fails. Failed signature verification could hypothetically be a cause of failure, but no way to know. Reverse engineering this blob is not known impossible yet, maybe forbidden.
(and I don't understand why it writes what it does in the error message in line 664, but that's irrelevant).

[coder]

So another blob. Another piece of hardware unusable with linux-libre.

But, if the firmware were stored in the SoC's internal ROM, then it would be?

[phoron]

But, if the firmware were stored in the SoC's internal ROM, then it would be?

It would be usable with linux-libre, yes.
Any hardware may have any amount of code hidden in any ROMs and nobody would know it. This is not good. Open hardware is better than closed hardware.
But this not something linux-libre can avoid in any way.
Hardware means the part of the design that is hard to change.
Software means the part that is easier to change.
If you put functionality in software because you don't feel able to get it right at first try and want to change it later, then it is software and I want it free. The software author and the software user should have the same power, even if the software is firmware because it runs on a different processor.
if it can't be changed (because it's in a ROM, in wiring or in patterns of semiconductor doping) then it's hardware. I still want as much documentation on it as I can get, but I won't be able to check the documentation is true, the vendor could give me the documentation of design A and hardware of design B, so the criteria is more do I trust the vendor ? has it a history of deception, etc?
The fact that the same byte sequence can be hardware if it's in a ROM or software if it's in a file may cause confusion at first, but if you think about it, it makes sense.
A dollar bill can be legal or not depending on accounting and money laundering, even if it's the same piece of paper. Someone earns it legally and it's legal. Then it gives it to a dealer for some drugs and it is no longer legal.
Windows could also be stored in read only non removable media, and then it would be hardware, but without MS updates, the hardware vendor would get too many recalls and wouldn't be compatible with new hardware peripherals, so it would be very hard to sell that hardware.

The solution is not to put firmware in ROM. It's to make it free software. Then it would be both fixable and compatible with linux-libre.

[coder]

Hardware means the part of the design that is hard to change.
Software means the part that is easier to change.
If you put functionality in software because you don't feel able to get it right at first try and want to change it later, then it is software and I want it free. The software author and the software user should have the same power, even if the software is firmware because it runs on a different processor.

There's a huge hole in your stance, because it might be stored in embedded NAND rather than ROM. That avoids externally loading it at runtime, but still enables it to be updated in case of bugs or feature enhancements.