SGX driver installer (beta)

[ElPoco]

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]

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

Hi there is a SGX Driver 5.01.01.02 Out for our Pandora from Texas Insruments:
Maybe you can port and add it please to your Genious Driver Installer?
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html
http://processors.wiki.ti.com/index.php/RN_5_01_01_02

 

[Magic Sam]

Hi all

Hi there is a SGX Driver 5.01.01.02 Out for our Pandora from Texas Insruments:
Maybe you can port and add it please to your Genious Driver Installer?
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html
http://processors.wiki.ti.com/index.php/RN_5_01_01_02

Isn't it for hardfp only ?

Cheers, Magic Sam

 

[notaz]

Isn't it for hardfp only ?

Right, also it's based on the same imgtech release as 4.10 (1.10 RC DDK (1.10@2359475)) so won't improve anything.

 

[ingoreis]

okay thx for the Information to both

 

[edgex004]

Isn't it for hardfp only ?

Cheers, Magic Sam

Does that mean it could be installed in the hardfp Pyra OS on our Pandoras?

 

[TrashyMG]

Does that mean it could be installed in the hardfp Pyra OS on our Pandoras?

From what I recall that driver would only work on a 1ghz unit.

 

[edgex004]

From what I recall that driver would only work on a 1ghz unit.

Hmm... well then maybe I should try it out...

 

[ingoreis]

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]

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]

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]

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]

@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]

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]

Ah yes, @notaz, that's true.

To test "hardfp" calling method, I have played with this little macro

#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

float FASTMATH myfunction(float a)
{
...
}

Of course, you will have issue if you do that in a library, but it works inside a program.