Release Pandora Model Check

[ekianjo]

I have a fix ready. Will roll it out later today.

 

[ekianjo]

Build #2 in the repo: RAM bug correction + Added additional info display (ARM processor type and Linux kernel version).

Please update!

 

[_wb_]

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...

 

[ShleeDragon]

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

 

[ekianjo]

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.

 

[ShleeDragon]

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

 

[ShleeDragon]

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.                                               

 

[ShleeDragon]

All three of these methods work fine

 

[ekianjo]

Thanks ParadisoShlee, I will implement them

 

[notaz]

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.

 

[ekianjo]

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?

 

[Asiyura]

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. )

 

[notaz]

Safe but not all SGX driver versions provide consistent contents of that file, so it won't work for some users.

 

[ShleeDragon]

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.

 

[ekianjo]

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?

 

[mcobit]

Maybe the safest way to do this is to display a dialogbox:


"Look into the batterycompartment!"

 

[ekianjo]

Maybe the safest way to do this is to display a dialogbox:


"Look into the batterycompartment!"

Not very practical to shut down the unit just for that

 

[PowerGod]

lol

 

[mcobit]

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.

 

[PowerGod]

Because I asked the same question time ago, here is the solution that Seb3 proposed to me:

http://boards.openpandora.org/index.php/topic/12447-finding-the-pandora-version-with-a-bash-script/#entry234302

if [ $(awk '/MemTotal:/{print $2}'</proc/meminfo) -lt 264000 ];then
  echo "Original Unit"
elif [[ $(awk -F: '/CPU variant/{print $2}' < /proc/cpuinfo) == "0x1" ]];then
  echo 512Unit
else
  echo "1Ghz"
fi