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

H. Nikolaus Schaller hns at goldelico.com
Sun Nov 3 17:20:30 CET 2019


> Am 03.11.2019 um 13:15 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> 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...

https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commit/d6ad756b56467ccd7cb0f2727421afcf9fecf486

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

Here would be the code variant of the driver for the jz4780:

https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr/drivers/staging/pvr/1.14.3699939/eurasia_km/services4/system/sgx_jz4780

i.e. branch letux-pvr

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

Fine!

I have found in the meantime that my runtime problems are - contrary to my
first conclusion - not a user-space or Stretch problem but kernel related.

If I install an v4.19.81 kernel everything works fine (but I have no SGX code
included).

With v5.4-rc5 I have trouble setting up networking (Ethernet) and get strange
error messages, maybe from the time() or gettimeofday() system calls.

So I have to debug (bisect?) this problem first before I can continue to run
and debug the sgx driver.

But I have already added the new sgx node to the jz4780.dtsi. You just may
have to blacklist the module so that it is not modprobed during boot.

If you want to try the letux kernel tree, please let me know for instructions
how to build a µSD.

BR and thanks,
Nikolaus



More information about the openpvrsgx-devgroup mailing list