[powervr-devel] Entering the Fray

Tristan Miller trismandev at gmail.com
Tue Oct 9 14:15:07 VET 2012


Hello everyone,

  I'm actually at a point where I can start actually contributing to the
project in meaningful way.

  So yeah, I've been doing RE on the powervr (focusing on the SGX530) for a
while now, off and on.  I've been mainly focusing on the init sequence, but
also trying to get global understanding of the whole system.

  First, good news and bad news.  Bad news:  the SGX is actually a minimum
two different microcontrollers (or execution engines, or what ever you want
to call it) with even completely separate ISAs.  The USE that you guys know
about and the PDS (Program Data Sequencer) in the CGS (Coarse Grain
Scheduler).  I'm not entirely sure what all the PDS does, it seems to
be marshaling data, and perhaps making USE scheduling decisions.  Good
news:  the PDS is much simpler at ~28 opcodes (at least on the 530, there's
more on later SGX cores), and I've nearly completely reverse engineered the
ISA.  Wasn't terribly difficult as pdsasm (the official PDS assembler) has
a disassembler as well.  There's still some outstanding questions as I
haven't actually run code on it yet, but I've been able to dump the
programs out of libsrv_init and they seem to make sense.  Most of the mmap
calls that you've seen in pvrsrvinit are allocating device addressable
memory for the little PDS programs.  There's undoubtedly more uses of this
processor (it seems to be used by user space proper in the GL libs).  I
have a (dis)assembler I've been using for RE, but my version is scarily
close to the official version unfortunately.  This is probably the thing
that we want most to be a clean room implementation, so I'm writing down
some docs for you guys on the opcode formats (should be done by sometime
this weekend).  I'd think most of the higher level stuff should be fine to
not be as stringent about clean room as simply the change from
IMG's proprietary gl libraries, memory managers, and what have you to
gallium/mesa/gem/ttm should be enough that what remains is simply
functionally similar.

  Next, I would think that we should standardize our efforts on one SGX
core, and one set of drivers to properly coordinate our efforts.  To me,
the SGX530 makes sense (hence why I've been focusing on it), as it seems to
be the first of this series.  All of the other cores seem to be an
evolution of this core.  The 520 seems to be just a cost reduced 530.  As
for the drivers, I've been using these
http://downloads.isee.biz/pub/files/igep-dsp-gst-framework-3_40_00/Graphics_SDK_4_05_00_03/
to
base my RE off of recently.  These were the newest that I could find with
symbols and -O0.   IMG has refactored the libraries around quite a bit, so
I really do think it makes sense to standardize off of these.

What (if anything) are people using for RE?  IDA, objdump, custom stuff?

  Have we given any thought to what we're going to use for user facing
code?  ie. are we going mesa/gallium, or are we going in our own direction?
 I'm leaning towards gallium/mesa but don't really know enough about the
implications.  Thoughts?

Tristan Miler
(Monocasa)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.gnu.org.ve/pipermail/powervr-devel/attachments/20121009/2f9c80cb/attachment.html>


More information about the powervr-devel mailing list