[Openpvrsgx-devgroup] Building the 1.7.862890 branch for x86

[H. Nikolaus Schaller]

Hi Julius,

> Am 25.05.2024 um 21:05 schrieb Julius Schwartzenberg <julius.vrijheid at freedom.nl>:
> 
> I forgot to reply to the list.
> 
> Hi Nikolaus,
> 
> Thank you so much for the fast elaborate response!!
> 
> On 25.05.24 12:22, H. Nikolaus Schaller wrote:
> > I've tried to get it compiled but it fails with:
> >
> >    MAKE    drivers/gpu/drm/pvrsgx: cedarview
> > scripts/Makefile.build:41: drivers/gpu/drm/pvrsgx/1.7.862890/pvr/Makefile: No such file or directory
> > make[8]: *** No rule to make target 'drivers/gpu/drm/pvrsgx/1.7.862890/pvr/Makefile'.  Stop.
> > drivers/gpu/drm/pvrsgx/Makefile:64: recipe for target 'drivers/gpu/drm/pvrsgx/pvr' failed
> > make[7]: *** [drivers/gpu/drm/pvrsgx/pvr] Error 2
> > scripts/Makefile.build:481: recipe for target 'drivers/gpu/drm/pvrsgx' failed
> >
> > So is drivers/gpu/drm/pvrsgx/1.7.862890/pvr/Makefile missing?
> 
> I do not have this file either. I guess we are using different steps to compile.

For LetuxOS releases we use a cross-compiler toolchain built from scratch (making sure that
the toolchains for different architectures are really comparable), but that usually works
equally well.

>  What I am doing on Debian:
> 1. I copied /boot/config-6.1.0-17-686-pae to .config

well, I used arch/x86/configs/letux_defconfig

> 2. Ran 'make menuconfig'
> 3. Disabled the GMA500 driver
> 4. Enabled the CDV driver

ok, that was the reason why my build failed!

My defconfig uses CONFIG_SGX_CEDARVIEW=m and I wasn't aware so far that you have introduced
a new CONFIG variable for the same purpose.

letux_defconfig has also a CONFIG_SGX_DEBUG controlling the same as the choice between
DRM_CDV_RELEASE and DRM_CDV_DEBUG would do. Only DRM_PVR_PDUMP and DRM_PVR_TRACE are not
directly avaiable.

So we do not really need to introduce a new drivers/gpu/drm/pvrsgx/1.7.862890/Kconfig.
And drivers/gpu/drm/pvrsgx/1.7.862890/Makefile can be moved to drivers/gpu/drm/pvrsgx/1.7.862890/pvr/Makefile

After fixing this (see below) I could (also) compile and confirm your error messages.

> 5. Save
> 6. Ran 'make bindeb-pkg'

> Note that I'm using a 32-bit system. I have no idea if the driver could be compiled for 64-bit too, there were never any AMD64 binaries for the userspace part.

The same is for ARM/ARM64 that there is no 64 bit build and no user-space code.

> 
> This triggers a full build which eventually should reach the CDV/PVR driver. Are you trying to only compile the driver itself?
> 
> 
> > So essentially it means to backport the 1.17 code for OSTimerCallbackWrapper
> > to make this compile. The trick is to provide a private struct which has the
> > struct timer_list as its first element and then using the from_timer() macro.
> > Sort of subclassing with additional variables in the subclass.
> 
> Alright, I guess it means more copy-pasting of the parts related to OSTimerCallbackWrapper? I could try that I support and see where I end up ��
> Many thanks for analyzing this!! It will surely help!

So I can now confirm that this solves the issue.

> > Hope this helps. And making me able to compile your code would allow me to
> > even verify my theory.
> 
> Yeah that would be great, let's try figure out why it seems to behave differently on your end.

Basically I can now compile equally well.

But I wonder about the structure. Especially the introduction of new CONFIGs for doing the same.

Basically the idea of the OpenPVRSGX driver is to separate decision on platform (e.g. omap3 or omap4
or jz480 or cedarview etc.) and the DDK version to be built. In theory every DDK should be buildable
for every plaform.

So choosing CONFIG_SGX_CEDARVIEW or CONFIG_SGX_POULSBO should generates gma500 or gma3600 kernel modules
(potentially both) and the idea is that some installation or boot mechanism outside the kernel decides which kernel
module to load.

So essentially there is no need for new config options and I have made a version that can be used
without.

Now with all this let's look into the /proc question/issue. It seems to have been solved between
DDK 1.7 and DDK 1.14. Try

	git blame letux/pvrsrvkm-1.17.4948957 drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/env/linux/proc.c

and you will see patch 

	0b33504e01242c (Anand Balagopalakrishnan 2016-02-11 14:02:23 +0530  792) #if LINUX_VERSION_CODE < KERNEL_VERSION(3,10,0)

just before 

	RemoveProcEntry() and RemovePerProcessProcDir().

So for all kernels >= v3.10 the recommended call is proc_remove(psPerProc->psProcDir);

One general thought: Tracing down all these fixes and backporting to 1.7.862890 seems to be quite a lot of work
and may introduce errors...

So I thought about something like

	cp drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/services4/srvkm/env/linux/* drivers/gpu/drm/pvrsgx/1.7.862890/pvr/services4/srvkm/env/linux

Despite some initial success we run into problems with this approach. We need header files not available in 1.7.862890.
Many files are identical (except adding comments and new functions), but some do really subtle changes.

Obvious are the changes to pvrversion.h. More subtle is that for example include4/sgxapi_km.h changes the
_SGX_MISC_INFO_REQUEST_ enum constants which are very likely hard baked into the firmware. So taking this
file simply from DDK 1.17 makes DDK 1.7 certainly broken. But this could be handled by #ifdef but this needs
a careful analysis.

Some idea to analyse this would be to pile up all DDK revisions in one git branch and use git to detect the
changes for each one. This is sort of reconstructing the version control system contents where we have
snapshots from.

Some far distance goal could be to merge all SGX revisions into a single tree and have these differences
covered by #ifdefs...

Hope this helps,
Nikolaus