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.

EP93xx fight continued…

6 thoughts on “EP93xx fight continued…

  • 4th June 2009 at 15:13

    Freescale iMX353 is only $1-2 more. It is twice and fast and has 8x the FPU power. Why torture yourself with a broken FPU? I threw my ep93xx boards in the trash after a week of fighting with this.

    • 4th June 2009 at 15:23

      Jon: I already told you that I know that EP93xx have sick FPU. I also told what do I think about Freescale i.mx31 cpu.

      I am doing that ep93xx stuff to improve it’s support in OpenEmbedded and also to learn something new. Not everyday has to be spend with great working stuff.

  • 17th July 2009 at 07:38

    Hi Marcin,

    Is there a chance to emulate this board in Qemu? I’d like to have some linux distribution with custom kernel configuration to be run on EP9302, but don’t have a board to test it. I’ve downloaded Angstrom but both vanilla qemu-arm and one of Poky distribution failed to boot it. First one just showed black screen when started and Poky’s told that it is unsupported platform. So is there any info on how to start any linux distribution (with kernel 2.6) for EP93xx on qemu or how to make it by myself?

    • 17th July 2009 at 15:55

      I do not think so. EP93xx emulation would require some developer time to write it.

      You have to build for arm920t or arm926 (so any pxa/s3c/etc) to be able to use QEMU for testing.

      Or you can spend 99€ on Sim.One board which uses EP9307.

      • 17th July 2009 at 20:11

        Oh, thanks, I’ll try it

  • 24th April 2012 at 19:08

    Hi Marcin Some updates to your June 2009 article. I fixed the last GCC bug in september 2009 – since then no more have surfaced and “everything works”, so I guess they should be updated for 4.2 and 4.3 if they haven’t yet. Yes, glibc also needs looking at if you want to compile the whole system with crunch. It would make a difference in libm, for example. However, I had to move on to other things after 6-8 months’ work on GCC. The sim.one is now on sale at 4star.it and I am open to new work.



Comments are closed.