linux-kernel - Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191007155252.GQ5610@atomide.com>
Date:   Mon, 7 Oct 2019 08:52:52 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Merlijn Wajer <merlijn@...zup.org>, Adam Ford <aford173@...il.com>,
        Philipp Rossak <embed3d@...il.com>,
        Paweł Chmiel <pawel.mikolaj.chmiel@...il.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Filip Matijević <filip.matijevic.pz@...il.com>,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
        moaz korena <moaz@...ena.xyz>,
        James Hilliard <james.hilliard1@...il.com>,
        kernel@...a-handheld.com,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, maemo-leste@...ts.dyne.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        Tero Kristo <t-kristo@...com>
Subject: Re: Lay common foundation to make PVR/SGX work without hacks on
 OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5

Hi,

* H. Nikolaus Schaller <hns@...delico.com> [191005 16:59]:
> Hi all,
> with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived
> upstream, so we do no longer need them here.
> 
> Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some
> more issues:
> * omap4 build only needs to distinguish between omap4420/30/60 and omap4470,
>   because the latter has an sgx544 inside and the other sgx540
>   This is solved by creating a new omap4470.dts
> * I have added proper reg values and interrupts to the omap4 device
>   tree node of the sgx (child node of the target-module)
> * some updates to my sgxdump and sgxdemo scripts (assuming simple
>   Debian Stretch rootfs)
> * James Hilliard has contributed a fix for osfunc.c
> * omap2plus also needs to be configured for STAGING and PREEMPT
>   to be able to compile the driver
> * I have added the __always_inline fix [2] which is needed for v5.4 with
>   CONFIG_CC_OPTIMIZE_FOR_SIZE=y (which I are enabled on the Letux builds)
> 
> Unfortunately Tero's rstctrl patches did not yet make it upstream (or even
> linux-next) so I also have a copy in this branch.
> 
> Results of first testing are:
> * OMAP3530 (OpenPandora, BeagleBoard C): fails with
> [  559.247558] PVR_K:(Error): SysLocateDevices: platform_get_resource failed
> 
> * DM3730 (GTA04, BeagleBoard XM): kernel module loads
> 
> * OMAP4460 (Pandaboard ES): kernel module loads
> 
> * AM335x (BeagleBoneBlack): reports a problem with omap_reset_deassert:
> [  204.246706] omap_reset_deassert: timedout waiting for gfx:0

Please try with Tero's current github branch at github.com/t-kristo/linux-pm.git
5.4-rc1-ipc from few days ago, the earlier versions had still issues.

> * OMAP5 (Pyra): fails to enable the clocks (did work with the previous version)
> [  304.140363] clock-controller:clk:0000:0: failed to enable
> [  304.147388] PVR_K:(Error): EnableSGXClocks: pm_runtime_get_sync failed (16)

Hmm no idea what might be up with this one. Did some clkctrl clock
fixes maybe cause a regression here? Tero do you have any ideas?

> * OMAP5 with omap2plus_defconfig:
> root@...ux:~# echo on > $(find /sys -name control | grep \/5600)
> [  213.490926] clock-controller:clk:0000:0: failed to enable
> root@...ux:~# 
> 
> * pvrsrvctl --start --no-module:
>   reports (where the kernel module loads) that the uKernel does not run
> 
> So I have several ideas what the reasons for the problems on the non-omap5
> devices could be:
> * initial code may have some omap5 specific hack inside
> * or has omap5 specific magic constants
> * uKernel may "know" on which platform it runs and
>   we would need differently patched user-space code
>   for each one
> * omap5 has a dual core sgx544 while the other
>   have single core
> * the register address translation is not yet correct and
>   this inhibits communicating of the user-space libs
>   with the uKernel
> 
> Maybe, if someone can point me to a complete and working BeagleBone source
> tree (any kernel release) which makes use of 1.14.3699939 SDK, I could compare
> code and address setup to find what makes the difference.

Regards,

Tony

> [1]: https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux-pvr
> [2]: https://lkml.org/lkml/2019/10/2/201