SGX driver installer (beta)


ElPoco

Very Active Member
Joined
Feb 16, 2012
Messages
808
Age
36
Location
Paris, France
No they don't, it's in "legacy mode" already.
A miracle, that such a short-support-strategy doesn't lead into bankruptcy, who buys chips that are not supportet anymore after 1-2 years? Why it just can't be like onto PC where I get still new drivers for my 5 year old graphics card? is it really that hard onto the SoC front? Especialy when I see what new drivers can still pull out of older hardware sometimes.
In the mobile phone industry, nearly all parts have a very short life span. So short in fact that if you start designing a product with available parts, you might end up releasing it just as they reach end of life.
 

fusion_power

Advanced Member
Joined
Dec 25, 2005
Messages
13,099
Location
germany
Website
Visit site
It doesn't look like TI has sold OMAP5 to anyone but a few board producers, so it's not surprising they want to forget about it.

It's also not completely unsupported as (I think?) TI does pay a few mainline kernel developers who work on many areas that also touch OMAP5, similar to how AMD pays a few people to work on open source drivers for their GPUs. We might get some unofficial help from those people (already had some help mostly in form of advice), but there is no guarantee for that.

I think I have posted about this before, but yeah it looks like it's the norm in the SoC world anyway. Have you ever seen a driver update for a phone? I don't think I have, my old Android phone had an official Android 2.3 -> 4.0 upgrade, but that dragged all the same old kernel and the drivers (they were unchanged).
Want any bugs fixed? Buy a new device.
I've heared from that, I don't use a Smart-anything but the general Update philosophy with Android or even iOS is indeed not that great. Google updates only their Nexus series regulary afaik. Very poor move imho. It's almost funny that Microsoft is the only company right now that do regular updates on their (mobile)OS - of course nobody uses Windows(10) mobile, that's the problem. :D
Well, I hope that the Pyra will still get regular updates and do not suffer from this poor SoC driver support philosophy. It's good to hear that you have unofficial help from official people, this is really nice. :)  
 
 

ingoreis

Advanced Member
Staff member
Joined
Jan 18, 2010
Messages
8,096
Age
39
Location
49.491276,8.423518
Hmm... well then maybe I should try it out...
That should not work.
You can see it near like 32bit and 64bit.

You can use 32bit Software in the 64bit System but not otherwise.

Softfp is more Softwarebased and hardfp is programmed and compiled more near onto the Hardware itself.
Hardfp will run Softfp Software but not otherwise.

The Pandora Zaxxon is programmed/compiled in Softfp.

Thats how i do understand it...was this right?
 

ptitSeb

Serial Porter
Joined
Aug 15, 2012
Messages
8,680
Age
47
Location
France, near Lyon
That should not work.
You can see it near like 32bit and 64bit.

You can use 32bit Software in the 64bit System but not otherwise.

Softfp is more Softwarebased and hardfp is programmed and compiled more near onto the Hardware itself.
Hardfp will run Softfp Software but not otherwise.

The Pandora Zaxxon is programmed/compiled in Softfp.

Thats how i do understand it...was this right?
Not really.

Both Softfp and Hardfp use Hardware for mathematical calculus (only softfloat don't use hardware). So NEON and VFPv3 are use in SoftFP ad HardFP. The difference is how the call to function is done when a "float" is passed (like when you call "sin(1.0f)". If softfp, the 1.0f is pushed on stack (memory) befor "sin" function is called. The sinus function pop the stack to get the value, calculate sinus using hardware vfpv3, and push the result on the stack. The caller pop the result from the stack to get it... Many push/pop on the stack is not efficient, but this is compatible with softfloat, where the process is the same except the sinus is calculated with CPU using integer only.
On Hardfp, the caller put 1.0f in a float register and "sin". The function sinus already has the value in a float register, calculate the sinis, and let the result in a float hardware register... This is much more efficient, but not compatible with softfp or softfloat.
 

ZXDunny

Deep avatar
Joined
Oct 12, 2010
Messages
2,561
I do know that my interpreter runs faster on a RasPI (v1) than it does on the Pandora, and the most probable reason is that Raspbian uses hardfp.

D.
 

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,359
You can use 32bit Software in the 64bit System but not otherwise.
Ages ago I have read somewhere that you can actually do that on Linux if the program was entirely statically linked (and the hardware is capable, of course) . Never tried it myself, though.
 

edgex004

Advanced Member
Joined
Jan 5, 2008
Messages
1,201
@ingoreis: I am proposing installing the hardfp driver into a copy of Pyra OS (or Pandian) installed on a 1 GHz Pandora, because Pyra OS and Pandian are both hardfp an do not have SGX drivers for now.
 

notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
If softfp, the 1.0f is pushed on stack (memory) befor "sin" function is called. The sinus function pop the stack to get the value, calculate sinus using hardware vfpv3, and push the result on the stack. The caller pop the result from the stack to get it...
This is not accurate either. What you said is only true if there are more than 4 arguments. First 4 arguments are always passed in ARM registers, and the penalty comes on move from VFP register to ARM register when you do the function call. Moving from VFP->ARM register is very slow on Cortex-A8.

I do know that my interpreter runs faster on a RasPI (v1) than it does on the Pandora, and the most probable reason is that Raspbian uses hardfp.
That's more because ARM11 has faster float in general than Cortex-A8.

You can use 32bit Software in the 64bit System but not otherwise.
Ages ago I have read somewhere that you can actually do that on Linux if the program was entirely statically linked (and the hardware is capable, of course) . Never tried it myself, though.
The same is true on pandora, you can happily run statically linked hard float program on pandora's OS.
 

ptitSeb

Serial Porter
Joined
Aug 15, 2012
Messages
8,680
Age
47
Location
France, near Lyon
Ah yes, @notaz, that's true.

To test "hardfp" calling method, I have played with this little macro
Code:
#ifdef __GNUC__
#ifdef __arm__
  #ifdef __ARM_PCS_VFP
   //#warning Arm Hardfloat detected
   #define FASTMATH
  #else
   #ifdef __ARM_FP
    //#warning Arm SoftFP detected
    #define FASTMATH __attribute__((pcs("aapcs-vfp")))
   #else
    //#warning Arm no FP detected
    #define FASTMATH
   #endif
  #endif
#else
  #define FASTMATH
#endif
#else
#define FASTMATH
#endif
and then, when you create a function that use some float, you define it with
Code:
float FASTMATH myfunction(float a)
{
...
}
Of course, you will have issue if you do that in a library, but it works inside a program.
 
Top