[Openpvrsgx-devgroup] A little SGX experiment with jz4780 / CI20

H. Nikolaus Schaller hns at goldelico.com
Sat Nov 2 07:39:08 CET 2019


Hi,
I have tried to build and run our new pvrsgx driver
on the CI20 with v5.4-rc5.

Well, the driver compiles and can even be modprobed.

If we add a compatible, it even loads during boot:

[    6.943594] pvrsrvkm_jz4780_sgx540_120: module is from the staging directory, the quality is unknown, you have been warned.
[    7.122346] PVR_K:(Error): SysLocateDevices: platform_get_resource failed
[    7.129182] PVR_K:(Error): SysInitialise: Failed to locate devices

But there is no DTS node defining the compatible
records and register range.

	gpu: gpu {
		compatible = "ingenic,jz4780-sgx540-120", "img,sgx540-120", "img,sgx540", "img,sgx5";
		// unknown: reg = <0x1??????? 0x10000>;
	};

I have located the jz4780 programming manual
but it doesn't say anything about the address
range where the SGX is mapped to. And maybe we
need to define an interrupt like for omap [1].

It may be possible to analyse the older 3.x
kernels which include a working SGX driver and
run on the CI20.

Or it could be possible to scan "interesting"
address ranges for what we would expect to be
an SGX register block (as we can see by
devmem2 on omap).

Looking into upstream code shows that GPU clocks
are handled by CGU code:

https://elixir.bootlin.com/linux/latest/source/drivers/clk/ingenic/jz4780-cgu.c#L444

But a bigger problem to develop for the CI20
is that it appears there is no HDMI/LCD driver
in mainline kernels... So before having some
fix for that, we can't even expect to visualize
any 3D rendering.

And the latest user-space blobs for the jz4780 are
difficult to locate or have gone with some
server-shutdown:

	https://elinux.org/CI20-SGX_kernel_module

But it seems as if there is an archived copy through
guest FTP at

	ftp://ftp.radix.pro/3pp/Imagination/ci20/

It also appears that it is a slightly different
release than we have for OMAP:

	1.14.3759903 vs. 1.14.3699939.

No idea if that will be a problem (maybe yes,
because the pvrsrcvtl seems to compare this
version code to make sure that the uKernel
does match).

BR,
Nikolaus

[1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commit/fca8da5031245d85fdeb4551c47383785da36e06


More information about the openpvrsgx-devgroup mailing list