EP93xx fight continued…

During my recent OpenEmbedded related work I merged gcc patchset from Martin Guy to add support for Maverick Crunch FP unit present in Cirrus Logic EP93xx ARM cpus. This makes floating point operations faster then it was before.

But does using it has a sense for whole system? Is it possible at all? The answers are No and Yes. I have root filesystem for EDB9301 created with Maverick optimisations but I also have plain armv4t one for same board. They both work but I do not recommend using Crunch optimized one — there are strange errors. For example “HZ=5.33381e-315” is given instead of “HZ=100” in openssl speed test (problem is somewhere in glibc).

Let me quote Martin’s mail:

My current recommendation is to enable crunch only in the floating point intensive libraries and applications that your application system uses, because having more than one crunch-enabled process running in the system makes the context switches slower because the kernel has to save and restore 19 64-bit registers at every context switch. It doesn’t bother doing this if only one process is using the FPU thanks to some clever Buytenhek laziness). I don’t have figures for how much of a difference this makes, but I guess one could calculate it from the context switching rate shown in the output of “vmstat 5” and the instruction times.

I switched “ep93xx” machine in OE back to armv4t optimisations. Also I am working on adding some more EP93xx related patches from Hasjim Williams (he made first set of patches for OpenEmbedded and Martin Guy improved them and moved to newer GCC).

One note for end of story — I am not interested in doing more ep93xx toolchain work. If your device/company need such help then contact Martin Guy for consulting offer.

consulting ep93xx openembedded