[Openpvrsgx-devgroup] A little SGX experiment with jz4780 / CI20
H. Nikolaus Schaller
hns at goldelico.com
Sat Nov 2 20:16:25 CET 2019
Hi Paul,
> Am 02.11.2019 um 16:42 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>
> Hi Paul,
>
>> Am 02.11.2019 um 13:29 schrieb Paul Boddie <paul at boddie.org.uk>:
>>
>> On Saturday 2. November 2019 07.39.08 H. Nikolaus Schaller wrote:
>>>
>>> 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].
>>
>> The programming manual isn't helpful about the PowerVR features, merely being
>> a description of the capabilities. It is a similar story with regard to the
>> Synopsys HDMI peripheral which might not even be mentioned beyond a single
>> specification entry.
>>
>>> It may be possible to analyse the older 3.x
>>> kernels which include a working SGX driver and
>>> run on the CI20.
>>
>> 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.101236] Oops[#1]:
[ 1495.103531] CPU: 0 PID: 1737 Comm: modprobe Tainted: G WC 5.4.0-rc5-letux-l400+ #1287
[ 1495.112573] $ 0 : 00000000 00000001 00000001 00000001
[ 1495.095955] $ 4 : 00000000 c0339000 00001000 00000002
[ 1495.101181] $ 8 : 00000000 ffffffbf 8ff60140 08800000
[ 1495.106408] $12 : 0e800000 00000000 0000001a ffffffff
[ 1495.111634] $16 : c0339000 00001000 8fb47b60 8fb47b60
[ 1495.095015] $20 : c0390000 00000000 c0375888 c0380000
[ 1495.100242] $24 : 00000000 8008a2f8
[ 1495.105468] $28 : 8f8a0000 8f8a1940 8ea54100 c03720b4
[ 1495.110695] Hi : 00000000
[ 1495.113570] Lo : 00d507ec
[ 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
[ 1495.097197] PrId : 3ee1024f (Ingenic JZRISC)
[ 1495.101571] Modules linked in: pvrsrvkm_jz4780_sgx540_120(C+) g_ether usb_f_rndis u_ether libcomposite configfs drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea drm drm_panel_orientation_quirks gpio_ir_recv dm9000 mii ipv6 autofs4
[ 1495.104279] Process modprobe (pid: 1737, threadinfo=19f3ed0a, task=678b00ef, tls=77e59610)
[ 1495.112585] Stack : 8f8a1978 304e1e1d 00000cc2 000003cf 00000000 ffffffff c036eadc 8fa81f00
[ 1495.099144] 8fb47b60 00004000 8fb47b60 00001000 8f8a1ad8 8fd93800 c0375888 c0380000
[ 1495.107549] 8ea54100 c0373fac c0375888 0000c000 8f8a1a44 00001000 c03716c8 8fd93800
[ 1495.115954] c0375888 c036ebb0 00000000 304e1e1d 00000000 8f801000 00002cc0 8fd93d80
[ 1495.102513] 8f801000 c0375888 0000c000 8f8a1a44 8f8a1a3c c037190c 8fd93800 8f8a1ad8
[ 1495.110918] ...
[ 1495.113383] Call Trace:
[ 1495.115854] [<8008a2fc>] dma_cache_sync+0x4/0x38
[ 1495.098648] Code: 03e00008 27bd0020 2ce20003 <8c830138> 38420001 00020336 54600003 8c790038 0800a427
[ 1495.108449]
[ 1495.110035] ---[ end trace 496a53fea19a37ef ]---
[ 1495.140618] Kernel panic - not syncing: Fatal exception
[ 1495.145895] Rebooting in 10 seconds..
So how to debug this?
>>
>>> 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).
>>
>> The above should give us something to go on.
>>
>>> 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
>>
>> Yes, I think they should be available for device tree configuration.
>
> Looks as if that would simply provide the
>
> clocks = <&cgu JZ4780_CLK_GPU>;
>
> in device tree.
>
>>
>>> 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.
>>
>> I would have thought that the DRM driver mentioned above is at least a
>> reasonable start. I don't recall seeing the usual Ingenic LCD driver in the
>> drivers/drm directory, so it seems like an effort was made for upstreaming but
>> that it didn't happen due to the usual inertia and social factors involved.
>> And the HDMI stuff is based on work for the i.MX6 family, so I imagine that
>> this may have been mainlined at some point.
>
> Ok, that is something to work on...
>
>>
>>> 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).
>>
>> 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 have written some script to pull the required tools but
it works on Debian Jessie only. Debian Stretch has a problem
with system time which breaks dhcpd or ping or even nslookup:
root at letux:~# nslookup www.debian.org
../../../../lib/isc/unix/time.c:156: Operation not permitted
../../../lib/isc/timer.c:797: fatal error: RUNTIME_CHECK(isc_time_now((&now)) == 0) failed
Aborted
root at letux:~# root at letux:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=2017607 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=1888624 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=1957959 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=1957976 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=1957992 ms
^C
root at letux:~# date
Sat Nov 2 19:55:01 UTC 2019
root at letux:~# hwclock
2016-11-03 17:32:43.979792+0000
root at letux:~# hwclock -w
root at letux:~# hwclock
2037-10-25 12:50:20.246608+0000
root at letux:~# hwclock
2037-10-25 12:50:26.435599+0000
root at letux:~# date
Sat Nov 2 19:55:40 UTC 2019
root at letux:~#
But that looks more like a library problem of my Debian
installation and not of the CI20 kernel.
BR,
Nikolaus
More information about the openpvrsgx-devgroup
mailing list