Marcin Juszkiewicz - ep93xx

Sim.One #0006 arrived

2009-11-17T18:10:00+01:00

Today I got nice package in post office — Simplemachines One developer board (Sim.One in short). It is based on Cirrus Logic EP9307 processor with Maverick Crunch floating point unit. I got board with #0006 serial number.

Board is much better then EDB9301 which I used so far for EP93xx toolchain tests. What is on board:

EP9307 CPU
64MB ram
8MB NOR flash
MMC slot (connected over SPI so ~250KB/s max)
2 USB host ports
VGA out port — XGA 8bit or SVGA 8/16/24bit
serial port in RJ-45 instead of standard DB9 (but cable is in package)
audio in/out jacks
many connectors with different signals — will have to check schematics for that.

By default board boots into Debian ‘lenny’ system stored on 4GB SDHC card. But there are problems with it as this is MMC over SPI so speed is very limited (about 250KB/s only) and it time outs quite often so I plan to move to USB stick during next days.

Next step will be adding it into OpenEmbedded and running Ångström as base distribution.

BTW — how did I got it at all? That’s due my recent work on merging EP93xx support into OE — I was asked do I want developer board with this processor.

EP93xx fight continued…

2009-06-04T13:46:00+02:00

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.

EDB9301 hacking

2009-04-15T17:04:00+02:00

Today I visited friend at his office and during talk I found dusted EDB9301 board at shelve. As he do not use it any more I was allowed to take it for experimenting.

First problem was bootloader — I am not so familiar with RedBoot so it took me a while to get it to load kernel from TFTP server. For reference: proper command is "load -v -r -b 0x01000000 /zImage-ep9301" where “/zImage-ep9301” is name of file to fetch. If you will get “Unrecognized image type: 0xe1a00000” message instead then you forgot “-r” switch (RedBoot do not know format of zImage kernel). I got some hints from HitchHacker Guide to ENP-2611 page.

Second was Linux kernel as support for EDB9301 was not present in 2.6.29 version. Quick search on LAKML gave me patch which adds EDB9301 support. But even with this patch kernel does not wanted to boot due to different machine ID (454 instead of 462) — small patch to “arch/arm/tools/mach-types” solved problem :D

Now I have board booted with root over NFS and wait for “base-image” build to end to have rootfs which will fit that device better then Openmoko one ;D

EDB9301 board