[Openpvrsgx-devgroup] Building the 1.7.862890 branch for x86

[Julius Schwartzenberg]

Hi Nikolaus,

On 27.05.24 11:59, H. Nikolaus Schaller wrote:
> 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.

So I wasn't aware of CONFIG_SGX_CEDARVIEW! Does that mean I'm using the 
wrong branch? The CONFIG variable used by my branch is the one that 
Intel's developers chose (CONFIG_DRM_INTEL_CDV).


> 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.

Do you have a branch for this? I will switch to your branch then.


>> 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.

I see. Did you get the kernel part to work on any 64-bit system?


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

I just dumped the files I couldn't find from the Intel driver in the 
branch with the matching version. I was already wondering whether I was 
using the right path. Just in case the full package with that is here:
https://archive.org/details/PowerVR-Graphics-Media-Drivers-for-Linux-Intel-GMA3600-3650-GPU

I also found a 1.0.1 package somewhere and a Meego image that is 
supposed to work.


> 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.

That would be really great. I was already hoping we could look at 
building Cedarview also with a newer DDK and see where to go from there.


> 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.

I did a grep on CONFIG_SGX_CEDARVIEW with my branch and it doesn't 
return any results, so I need to switch to your branch :)


> 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

Yeah I was thinking about something like that too, but I have no idea 
how tightly coupled those things are. I was even thinking I might be 
changing too much already. My goal would be to boot and get at least 
working output and the kernel part with /proc/pvr loaded. Then see 
whether any userspace driver could work.


> 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.

It seems that Intel actually used a crappy algorithm to strip comments. 
It removed everything after /* up to */ and some whitespace. The 
whitespace before the /* consistently remained, so there's all kinds of 
loose whitespace exactly in spots where other DDK versions have 
comments. Maybe you saw I put some back.


> 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.

Ah interesting, there are also multiple firmware versions matching with 
different kernel DDKs?


> 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.

Yeah this would be helpful :)


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

Hopefully we could simply move everything to the latest DDK instead? :)

Many thanks!!
Julius

PS: I'm getting all the messages sent to the list, no need to add 
another address.