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

Paul Boddie paul at boddie.org.uk
Sun Nov 3 13:15:55 CET 2019


On Saturday 2. November 2019 20.16.25 H. Nikolaus Schaller wrote:
> 
> > Am 02.11.2019 um 16:42 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> > 
> >> Am 02.11.2019 um 13:29 schrieb Paul Boddie <paul at boddie.org.uk>:
> >> 
> >> Fortunately, the 3.18 kernel code, specifically in drivers/gpu/drm/jz4780
> >> contains files related to HDMI and the LCD peripheral. Meanwhile, the SGX
> >> 
> >> stuff appears in the jz4780.dtsi file from 3.18 as follows:
> >>       gpu: jz4780-sgx at 13040000 {
> >>       
> >>               compatible = "ingenic,jz4780-sgx";
> >>               reg = <0x13040000 0x4000>;
> >>               
> >>               clocks = <&cgu JZ4780_CLK_GPU>;
> >>               clock-names = "gpu";
> >>               
> >>               interrupt-parent = <&intc>;
> >>               interrupts = <63>;
> > 
> > Cool! I will simply copy that and give it a try...
> 
> Well:
> 
> root at letux:~# modprobe pvrsrvkm_jz4780_sgx540_120
> [ 1494.994444] pvrsrvkm_jz4780_sgx540_120: module is from the staging
> directory, the quality is unknown, you have been warned.
> [ 1495.070880] CPU 0 Unable to handle kernel paging request at virtual
> address 00000138, epc == 8008a2fc, ra == c03720b4

[...]

> [ 1495.094615] epc   : 8008a2fc dma_cache_sync+0x4/0x38
> [ 1495.099842] ra    : c03720b4 CheckExecuteCacheOp+0xec/0x284
> [pvrsrvkm_jz4780_sgx540_120] [ 1495.107930] Status: 10000403 KERNEL EXL IE
> [ 1495.112113] Cause : 00800008 (ExcCode 02)
> [ 1495.094298] BadVA : 00000138

So, this looks like some kind of memory access exception in dma_cache_sync 
which is invoked by CheckExecuteCacheOp in the SGX kernel module.

> So how to debug this?

We would probably need to look at the SGX module code and see what it is 
actually trying to do. It seems possible that it just acquires an address from 
somewhere that makes no sense, and once bad information gets introduced into a 
program, all sorts of nonsensical things start to happen.

The dma_cache_sync function is in arch/mips/mm/dma-default.c but seems to be 
stable across kernel versions, so I doubt that the code there is really at 
fault by itself.

[...]

> >> I did download various user space archives for the CI20, so I can check
> >> what I actually have.
> > 
> > If you find a 1.14.3699939 for the CI20 it would be great. If not, the
> > link suggested by Merlijn also works for a 1.14.3759903.
> > 
> > Since we also have the kernel driver source code available, we can compare
> > if and where they really differ and add some quirks to our driver code.

I'll try and remember to look at this when I boot the CI20 again today.

Meanwhile, I looked at the 3.08 kernel code which does things in a less 
"clean" way. Instead of a DRM driver, there is a collection of PowerVR related 
code that may be of interest. For example, looking for the memory locations 
exposed to control the GPU, I found this...

#define SYS_XB4780_SGX_REGS_SYS_PHYS_BASE  0x13040000

...in drivers/gpu/pvr/xb47/sysconfig.h. So, we can be fairly sure that the 
3.18 device tree is correct.

Paul


More information about the openpvrsgx-devgroup mailing list