[Openpvrsgx-devgroup] Status & HW to bring

H. Nikolaus Schaller hns at goldelico.com
Sat Nov 9 14:16:26 CET 2019


> Am 09.11.2019 um 10:11 schrieb Merlijn Wajer <merlijn at wizzup.org>:
> Hi,
> I'm going on a 5+ week work trip, but will have plenty of time outside
> of work, so I'd like to bring some SGX hardware.
> My question is, apart from a Motorola Droid 4 and a Nokia N900, what
> would make sense to bring? I have a Pandaboard ES and a Beaglebone Black
> (those also have SGX). I probably don't want to bring both, as I'll also
> be bringing other hardware with me... (Maybe just the phones make sense,
> since they have a display built in)

Both are also useful targets. Regarding a display, i have a BB Black with
an LCD+Touch cape for testing (chipsee EXP43).

For the PandaBoard I am not aware of screen solutions and it is a little
thick by its stacked Ethernet+USB sockets.

> The other question from me -- I've been reading all of the discussion,
> but haven't been diving into the kernel side of it too much, what is the
> current status and plan? The ultimate goal is a driver that works with X
> (and maybe Wayland), I assume.

Yes. Current status is in short:

* work head is as of today v5.4-rc6

* we have low-level glue (clock & reset) almost upstream (partially in linux-next)
  but I have collected everything we need:


* I have a patch set for extending the DT nodes of all SoC to load a matching driver variant


  This is in review process and is mainly stalled because of my low experience in
  writing the new YAML schema bindings.

* we have a kernel driver tree for drivers/staging/pvr based on the TI DDK1.14 which
  builds multiple variants of pvrsrvkm so that they all can be installed in
  parallel in /lib/modules. They differ by file name and compatible so that only
  the right one is loaded


* we also have DDK1.9, DDK1.10 and DDK1.17 kernel drivers residing in staging/pvr
  in parallel, but they have not been adapted. DDK1.9 has a little and is built
  if SGX_114 is not configured, but fails linking to omaplfb.


  BTW: there is an interesting patch in DDK1.17 which indicates that it also
  should work with the am335x:


  So it may be possible to try to switch to that one - but we have no MIPS and x86 version.

* all these are based on the latest mainline kernel (v5.4-rc6) and just need to
  be merged together. There is a branch for convenience that already merges them all:


  but that is a result and not a branch to work on.

* for all OMAPs that we have tested so far we can successfully load the driver
  and on most, pvrsrvctl --start --no-module works or reports a minor failure.
  Assuming we have a pvrsrvctl...
  This means the kernel driver itself is generally working and communicating
  with the SGX hardware. It only fails to properly boot the uKernel provided
  by pvrsrvctl. Maybe DMA access to screen or whatever internal checks are done...
  Nobody knows the details of the uKernel except what it is doing and why it is needed.

* for some OMAPs with SGX540 (omap4) we seem to completely lack the right user-space
  variant or do not yet know how to hack something to be fully compatible with the
  DDK1.14 driver.

* the same DDK1.14 source code can build a pvrsrvkm for the JZ4780 based CI20 board
  I am not sure yet if the user-space code matches since it has a slightly
  higher subrelease version (pvrsrvctl seems to check DDK release 1.major.minor)

* I could not yet test the CI20 because the Ethernet connection seems to
  be broken with v5.4-rc6 and I could not install/update files without trying
  severe hacks.

* User-Space is the biggest mess...
  It seems not only depend on SGX release (530,540,544) but also on SoC (omap3, am33,
  omap4, omap5, dra7, ...) and on specific DDK releases.

* I have a script and a .deb package that tries to pull the correct user-space from
  the web and applies some patches when needed:


* This is also packaged for Debian Stretch:


* BTW: there is someone who started to reverse engineer the SGX544 registers (which
  seem to differ from SGX530):


  This is not important for us, except that it may help to give magic register
  offsets in the kernel driver a better name.

The plan is to:

1. provide working demos on some devices (done to some level - I'd like to see Droid 4 and OMAP3 as well)

2. upstream all kernel glue (waiting for v5.5-rc1 for >50% of that)

3. streamline driver code and stay compatible with the working demos

4. make driver more and more generic so that all compiler switches and runtime dependencies
   go away and a single pvrsrvkm.ko for all SoC and architectures (ARM, MIPS, x86)
   and SGX versions (530,540,544 - 112,116,121,125 etc.) remains

5. reshape the driver to be able to submit it into drivers/staging/pvr mainline

6. improve user-space and provide a reference implementation for those who want to
   take the adventure of reverse engineering a new user-space stack with full
   DRI, DRM, Mesa, X11, Wayland and whatever integration.

> And there are a few devices where HNS has
> a working (and rendered) demo on the screen? (Right?)


I have managed to compile from the same sources (and 100% the same zImage and
other kernel libs) a working setup for BBB+LCD *and* OMAP5 (Pyra):


BBB does not always start smoothly and fails with a memory fault. So I think
there is some uninitialized variable or dynamically assigned address out of

OMAP3530/DM3730 (e.g. OpenPandora) can load the driver but fails with some
memory error or similar (I had it running with DDK1.9 approx. 6 years ago:
https://www.youtube.com/watch?v=gA7L_Y2iqWc ). Pandaboard ES shows a similar

This indicates some user-space incompatibilities.

CI20 / JZ4780 loads the driver but there is sadly no mainline HDMI driver.
And user-space alone isn't tested.

Puolsbo, CedarView and Allwinner A83 (BananaPi M3) variants are included
in the TI code but have neither been tested nor touched or adapted.

> Does it make sense to write-out the plan, what components would be used?
> (e.g. updated kernel, compatible userspace, X11 modesetting driver, and
> dri3wsegl?)

The key issue is IMHO how to hack user-space for a device that is not
officially supported by TI in the driver+um DDK version... For example the
jacinto6 user space needs us to patch a single byte in some non-free blob
which most likely disables a test for the machine model and rejects OMAP5432.
Unfortunately each user-space release comes with slightly different binaries
so that even the position in the file changes. I still don't know who did
find it out (zmatt maybe?) and how...

For the Droid4 it should suffice to build the letux-pvr tree and experiment
with different user-space versions that can be found on


BTW: there also seems to be yet another DDK release: 1.15.4564147 (x11-experimental)

So if you want a reference that is known to work, take the BBB (plus an LCD cape
if possible) and work on Droid4, especially as Tony is also working for the Droid4.
Having someone to discuss and exchange test code is not to be underestimated
for such a project.

> And as someone who generally prefers userspace to kernel hacking, what
> would be the best way to help out? I'm also fine offering advice for the
> next few weeks until kernel space is more in shape and we're more ready
> to focus on some compatible userspace.

IMHO a first big milestone is to get pvrsrvctl run without error messages
and then get gles1test1 running.

> For me the 'short term' ultimate goal is probably getting 3D to start
> working on the Droid 4, using mainline + patches. Then I can try to play
> with dri3wsegl, and see if hildon-desktop from Maemo Leste can run on
> the Droid 4, and we'd have a nice phone to target for years to come.

Yes, looks good and reachable if we can find some working user-space

BR and happy hacking,

More information about the openpvrsgx-devgroup mailing list