[Openpvrsgx-devgroup] Reverse engineering SGX 540 userspace driver
H. Nikolaus Schaller
hns at goldelico.com
Fri Nov 12 10:58:18 CET 2021
> Am 12.11.2021 um 05:18 schrieb Lucas Fryzek <lucas.fryzek at hazeco.xyz>:
>> Hello Nikolaus,
>>> It *could* work but was never tested. We have the matching DDK release version in the tree. Just choose CONFIG_PVRSGX_1_14_3759903=y
>>> It may be that the branch is missing some fixes that have been applied to the versions CONFIG_PVRSGX_1_14_3699939 and CONFIG_PVRSGX_1_17_4948957 which are more or less well running on OMAP3/4/5.
>>> Do you have the user space for 1.14.3759903? I am not sure but it may be stored in the factory flash image.
>>>> I'm trying to get a setup right now where I can compile a kernel mode driver and make modifications to get a better idea on how the GPU is being controlled. If I can use a more modern kernel and linux userland that would be very nice.
>>> Just get the letux tree: https://github.com/goldelico/letux-kernel/tree/letux-5.15
>>> It includes everything incl. HDMI driver for the CI20 (use letux_defconfig) and compiles the SGX driver that is configured. But the default is CONFIG_PVRSGX_1_17_4948957=y so there may be surprises when switching to CONFIG_PVRSGX_1_14_3759903 we can discuss how to fix.
>> I believe my board is currently flashed with the `Debian 8 2015-09-09` image from this webpage https://elinux.org/CI20_Distros.
>> I took a look through the filesystem and I cannot find the DDK as a zip package, but all of the PVR libraries seem to be versioned as `1.14.544606452`. The reason I referred to `1.14.3759903` before was this is the version listed on this web page https://elinux.org/CI20-SGX_kernel_module.
>> I'm not sure what the latest available kernel module + userland is for the CI20. I did find this git repo https://github.com/MIPS/CI20_PVR-prebuilts, that seems to have userland libraries for version `1.15.4568187`. But I'm not if there is a matching open source kernel driver for this repo.
>> I am currently trying to get a setup where I can build the open PVR kernel module and have it work with the userspace. I've been working. Building my own kernel with the old debian images seems to break DRM, so I suspect there is so version mismatching going on. I'll take a look at the kernel in the letux project instead as this looks like a more productive use of my time. I'll also take a look at some of the older debian images for the CI20 to see if the `1.14.3759903` to attempt to use with the letux kernel.
> So I managed to get the letux kernel building and running on my CI20.
That is great!
> Had a bit of trouble there where the prebuilt kernels don't see to run properly on the CI20, but once I grabbed the latest kernel from github and built that everything seemed to work fine. I managed to find the `1.14.3759903` userland at this link https://ftp.radix.pro/3pp/Imagination/ci20/ <https://ftp.radix.pro/3pp/Imagination/ci20/>
Cool! So I should fetch that for my experiments or at least to support you with yours...
> I changed the kernel config to build the kernel module version `1.14.3759903`, there were several errors but I just looked at the `1.17` version and copied the fixed from there.
Maybe, can you git-format-patch and submit on this list so that I can add them to the branch on github?
> Unfortunately the userland does not seem to be happy, I tried testing a few of the applications and none of them seem to work. I ran `strace` on the binaries and it looks like they call `DRM_IOCTL_VERSION`, are unhappy with results and then error out saying they can't find a PVR GPU.
Yes... IMG did everything to make sure that kernel driver and user-space are compatible. So user-space cross-checks with the kernel drivers for two things I am aware of:
a) the version number
b) some compile flags and options
For a) I had thought about adding a mechanism that pvrdrv can report an arbitrary version number (maybe through some /sysfs entry).
For compile flags and options it was a little experimental until there were no more complaints.
AFAIR, the 1.14.3699939 user space for omap3 could be run in debug mode which told which flags were missing.
I guess this allows IMG to change data structures, features etc. of both UM and KM in parallel and avoid efforts to remain backwards compatible.
This is contrary to the idea of stable interfaces we usually have...
> I think to do any effective reverse engineering of the GPU I'll need a working userland, so it looks like I have a bit of work there :P The DRM version error gives a path to start looking, so I'll try messing with that and see where I can go from there.
Yes, that is IMHO the right thing to start with. It gave me some insights how the whole pieces fit togehter (but I forgot most of them over the years :).
BR and thanks for sharing any thoughts and findings,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openpvrsgx-devgroup