Beta experimental hardfp (armhf) support for Super Zaxxon

[notaz]

Intro
So in the early days when we started with pandora, Cortex-A8 was state-of-art CPU and ARM9 (with no FPU) was still common, so gcc did not have armhf support. It did support the VFP instructions already, but still used the old ABI, so called softfp. The situation was similar when the first units shipped (well Cortex-A8 has become common, but armhf was still not there), so we are stuck on softfp now to maintain compatibility. The same is even true for Android, it's still softfp to this day, but the whole ARM Linux world has moved to hardfp now.

There is a relatively recent thing on Linux called multiarch which allows multiple architectures coexist on a single machine. This was made primarily for x86/i386 to live along with x86_64/amd64, but curious thing is it allows softfp to coexist with hardfp too. What's even better, Debian's armhf doesn't seem to conflict on with Angstrom and they can happily live together. With these instructions you can try it out.

Installation
warning: if things fo wrong, you'll most likely have to reflash.
You need ~12MB of space on NAND for this, I'd recommend at least 10MB free at all times, so check if you have at least 20-30MB free before starting.

sudo opkg update
sudo opkg upgrade
sudo opkg install armhf-support

After this, if you have rebirth or 1GHz, install (or reinstall) 4.10.00.01 SGX driver (use the SGX installer PND). For the OMAP3 chip in CC TI does not provide the hardfp SGX driver, sorry.

There is hardfp SGX support installed with above commands, I've packaged the hardfp driver from TI. They only started packaging hardfp since 4.09.00.01, so I've used 4.10.00.01 (it's the more popular one). A matching driver from SGX PND has to be installed too. If you had 4.10.00.01 already installed, you'll need to reinstall it because OS upgrade may have reverted it to the older one.

A test case
You can try it on Minecraft Pi Edition. Get it from pi.minecraft.net and

sudo opkg install libbcmhost-shim
tar xf minecraft-pi-0.1.1.tar.gz
cd mcpi
LD_PRELOAD=libbcm_host.so:libGLES_CM.so ./minecraft-pi

libbcmhost-shim is a small shim I wrote for libbcm_host.so that r-pi software must link against. libGLES_CM.so preload is needed because minecraft-pi is GLES1 game, but linked against GLES2 library. The pi's driver doesn't care, but SGX gets upset if the wrong lib is linked.

Some thoughts
It should be possible now to make hardfp PNDs, and users who have armhf-support installed will be able to use them. However I recommend against it, because:

• No 3D for CC users (TI does not provide hardfp driver for the old chip)
• In most cases there is no noticeable performance improvement from armhf (I tested PCSX, for example)
• More work for me to maintain PND compatibility on new SuperZaxxon releases
• Only a few hardfp libraries are available in firmware (but I might add more if it turns out to be really useful)

So it's mostly useful for software compatibility with other ARM boards (hopefully including Pyra), and perhaps for something like the hardfp-only flash plugin in Chromium, if that can be made to work.

Anyway it would be great to get some testing, I wonder if it really doesn't break anything...

 

[levi]

I'd imagine these libs take up a bit of space, so does it really fit on the NAND flash, if that's where we're running the OS from? Or should we set up a SD card to boot from first?

 

[Farox]

I'm a bit sad that i can't test this with my CC unit (shame on you TI )...anyway great work notaz

 

[notaz]

I'd imagine these libs take up a bit of space, so does it really fit on the NAND flash, if that's where we're running the OS from? Or should we set up a SD card to boot from first?

Right now it's just the main libs (glibc, SDL, SGX driver and some X libs), that only takes 12MB. I think currently after reflash there is >100MB free, so there should be no problem fitting this in NAND.
Updated the first post with the space requirements.

 

[Linux-SWAT]

Craziness has no end ^^.

 

[Letalis Sonus]

Craziness has no end ^^.

Next step would be trying to program a softfp translation layer in assembler to get the driver to work on the OMAP3 units... is anyone already feeling the madness approaching?

 

[Linux-SWAT]

Is it the multiarch/fatelf from the icculus guy ?

 

[slaeshjag]

Next step would be trying to program a softfp translation layer in assembler to get the driver to work on the OMAP3 units... is anyone already feeling the madness approaching?

glshim-remote would probably be able to. Afaik the plan is to use glshim-remote for softfp support on the pyra anyway.

 

[TrashyMG]

I'll give this a whirl, I have a bit of hard-float compiled programs I played around with on the OMAP5 devboard.

 

[Linux-SWAT]

Oh Lord, I can run Julia !!!
http://julialang.org/downloads/

 

[edgex004]

This is really neat. I'm excited to try a few things out!

 

[TrashyMG]

@notaz - Adding armhf SDL libraries would most likely fill up too much space on the NAND right?

 

[notaz]

@notaz - Adding armhf SDL libraries would most likely fill up too much space on the NAND right?

Which ones? The base SDL1.2 is already included, some more could probably be added.

 

[TrashyMG]

Which ones? The base SDL1.2 is already included, some more could probably be added.

Ah I figured it was completely missing, one thing I was trying yesterday apparently needed: libSDL_net-1.2

 

[joachim]

At the moment I want to try to install Java 8 but this seems to be for armhf. Is it possible to use the new support files for Slackware ? What should I do for this. And if I have problems, can I remove them again (or just let them be)?

 

[notaz]

I don't know anything about Slackware.

 

[Linux-SWAT]

I tested, it works.
Have to make proper packages now.

 

[ashcloud]

This is great. Having some application compiled for armhf instead of the old ABI would surely bring a performance boost, as softfp is awful for floating point calculations. But I guess I'll better test this on an SD card
I'm currently pondering a way to write an ABI wrapper around the 3d driver. As far as I know, the only difference between the armhf and softfp ABI is the location of function arguments, as armhf uses the fpu registers for floating point variables. I guess, the hardest thing will be to trick the dynamic linker into loading something that doesn't match the ABI of the running application. Any ideas on that are welcome.
Anyway, don't expect much, but when I have some spare time I'll try to code a small proof of concept.

 

[Letalis Sonus]

as softfp is awful for floating point calculations.

And you're awfully wrong on that, because you confuse softfp with softfloat. Again: This whole matter is only about the ABI, i.e. the way float values are passed to functions - it has absolutely no influence on how the program actually calculates floats, therefore the performance difference is negligible in most situations.

 

[ashcloud]

And you're awfully wrong on that, because you confuse softfp with softfloat. Again: This whole matter is only about the ABI, i.e. the way float values are passed to functions - it has absolutely no influence on how the program actually calculates floats, therefore the performance difference is negligible in most situations.

Well, yes, I wasn't very clear about that, but I didn't confuse those two. I shouldn't have mentioned 'calculations'. The point is, that the ABI forces the variables from the fpu registers into the core registers for every function call and function return when floating point variables are used. If the NEON engine is used, this causes the NEON-pipeline to be flushed on every function call, which can take a lot of CPU cycles.
Yes, most programs don't suffer much from the ABI, I guess that's because most of the time the compiler won't use any NEON instruction, not even for floating point.

Edit: Oh, I just read the original post more carefully. I somehow thought there was no 3d driver for hardfp at all and this was the problem why the Pandora is stuck with softfp. But it seems that's only the case for the CC-Pandoras.