Release Pandora Model Check


This is a useful little tool for people who are unsure about which model they are holding.

Some remarks:

The PND is 842KB, which is huge for a 1057 byte shell script. There is a ".git" directory inside, which is useless. Also the screenshot takes up more space than needed, I would just show the dialog window itself, without the desktop background.

I don't think the 1GHz units have an OMAP SoC (it's a DM3730), and in any case, OMAP is the name of the entire SoC, not just the processor.

You check for an exact match with system clockspeed 332, which will falsely classify over- or underclocked 600MHz units as 1GHz units. Better check if sys-speed is above 390; if it is, it must be a DM3730 because I don't think any OMAP3530 will clock that high. You still get false results on underclocked DM3730's if you do that, but I don't think many people will do that.

Maybe I should integrate this information as an extra panel in System Info...
 
Something is better than nothing.. but this reallllllly isn't the perfect way to detect this stuff

You can detect the CPU version ID using a few methods for a more failproof detection
 
Something is better than nothing.. but this reallllllly isn't the perfect way to detect this stuff

You can detect the CPU version ID using a few methods for a more failproof detection
Please advise what to use :)

This is a useful little tool for people who are unsure about which model they are holding.

Some remarks:

The PND is 842KB, which is huge for a 1057 byte shell script. There is a ".git" directory inside, which is useless. Also the screenshot takes up more space than needed, I would just show the dialog window itself, without the desktop background.

I don't think the 1GHz units have an OMAP SoC (it's a DM3730), and in any case, OMAP is the name of the entire SoC, not just the processor.

You check for an exact match with system clockspeed 332, which will falsely classify over- or underclocked 600MHz units as 1GHz units. Better check if sys-speed is above 390; if it is, it must be a DM3730 because I don't think any OMAP3530 will clock that high. You still get false results on underclocked DM3730's if you do that, but I don't think many people will do that.

Maybe I should integrate this information as an extra panel in System Info...
will clean up the git directory, it shouldn't be there.

But honestly who cares about 800k nowadays ?

Other than that, good advice on the the rest. Will update.
 
Use this!

I think '/etc/powervr-esrev' is a better idea. wiki

2 = classic

3 = rebirth

5 = 1ghz
If worse comes to worse - Apparently devmem2 is useable on the pandora.... so you can easily poke the SOC registers for some version IDs. wiki

For OMAP35x/AM35x/37xx family of chipsets

./devmem2 0x48004B48 w 0x2

./devmem2 0x48004B10 w 0x1

./devmem2 0x48004B00 w 0x2

./devmem2 0x50000014 > sgxrevision.txt
Depending on the value read out in the last step, OMAPES is determined for the build.

  • If value == 0x10205
Use OMAPES=5.x

  • If value == 0x10201
Use OMAPES=3.x

  • If value == 0x10003
Use OMAPES=2.x
 
Last edited by a moderator:
Just an idea..  I don't have my pandora with me

02:02:44      MrShlee | cat /proc/pvr/version                                                        

02:08:16      MrShlee | 1.0.3 = classic                                                                       

02:08:20      MrShlee | 1.2.1 = rebirth                                                                       

02:08:26      MrShlee | 1.2.5 = 1ghz                                                                          

02:08:53      MrShlee | Pretty safe check.                                               
 
Last edited by a moderator:
For OMAP35x/AM35x/37xx family of chipsets


./devmem2 0x48004B48 w 0x2


./devmem2 0x48004B10 w 0x1


./devmem2 0x48004B00 w 0x2


./devmem2 0x50000014 > sgxrevision.txt
Depending on the value read out in the last step, OMAPES is determined for the build.

  • If value == 0x10205
Use OMAPES=5.x

  • If value == 0x10201
Use OMAPES=3.x

  • If value == 0x10003
Use OMAPES=2.x
I strongly recommend not to do it, those devmem2 calls makes SGX not to go into low power mode and breaks suspend. Not to mention poking SoC registers directly is evil.
 
For OMAP35x/AM35x/37xx family of chipsets


./devmem2 0x48004B48 w 0x2


./devmem2 0x48004B10 w 0x1


./devmem2 0x48004B00 w 0x2


./devmem2 0x50000014 > sgxrevision.txt
Depending on the value read out in the last step, OMAPES is determined for the build.

  • If value == 0x10205
Use OMAPES=5.x

  • If value == 0x10201
Use OMAPES=3.x

  • If value == 0x10003
Use OMAPES=2.x
I strongly recommend not to do it, those devmem2 calls makes SGX not to go into low power mode and breaks suspend. Not to mention poking SoC registers directly is evil.
How about cat /proc/pvr/version   ? is it safe?
 
cat /proc/pvr/version is perfectly safe, it's only reading the content of a file and displaying that on-screen.

Poking in registers can be safe … if you know what you're doing. (hint: I don't :lol:  I've only played with µController's registers. Those are  far more simple than pandora's. )
 
Last edited by a moderator:
For OMAP35x/AM35x/37xx family of chipsets


./devmem2 0x48004B48 w 0x2


./devmem2 0x48004B10 w 0x1


./devmem2 0x48004B00 w 0x2


./devmem2 0x50000014 > sgxrevision.txt
Depending on the value read out in the last step, OMAPES is determined for the build.

  • If value == 0x10205
Use OMAPES=5.x

  • If value == 0x10201
Use OMAPES=3.x

  • If value == 0x10003
Use OMAPES=2.x
I strongly recommend not to do it, those devmem2 calls makes SGX not to go into low power mode and breaks suspend. Not to mention poking SoC registers directly is evil.
I'm not going to say I recommended doing that.. it's just plan C because it "works"  :)

but in all seriousness - If you are running a PND, you're more than likely running the official firmware which should have a working  '/etc/powervr-esrev' 99% of the same.. there might be race conditions when people start to mess with the defaults.
 
Last edited by a moderator:
Safe but not all SGX driver versions provide consistent contents of that file, so it won't work for some users.
Notaz so what do you recommend yourself, personally? Is the way I am in doing in PandoraModelCheck good enough at this stage? Would it work most of the time?
 
Last edited by a moderator:
Maybe the safest way to do this is to display a dialogbox:


"Look into the batterycompartment!"
 
I think you would do it only once, won't you?


But you are right... maybe some people want to check if their Pandora upgraded after a few weeks of use. ;)


Only joking of course.


Back on topic.
 
Last edited by a moderator:
Back
Top