Author Topic: Status Quo?  (Read 2742 times)


  • Newbie
  • *
  • Posts: 5
    • View Profile
Status Quo?
« on: February 28, 2006, 08:15:53 am »
Simpad development seems to be stalled if it get this right.

I got a CL4 Simpad and it was getting dusty during the last few years.
I always had plans to reanimate it some time and start an own directfb-based distribution.

After fiddling around two days with various bootloaders and crosscompiling-environments I managed to install a modified version of the bootloader from ( - found the link here:

However I had to modify the linuxrc script - it wrongly detected my CL4 as an SLC and thus the bootloader tried to flash erase beyond the end of the 16 MBytes.

First I tried to use the 2.5.1 siemens bootloader to boot a kernel from network, but I didn't get any output from the kernel - what now in retrospect could be caused by passing console=ttyS0 instead of ttySA0 - maybe I'll flash the old bl back the 10th time some day and check if this was the only problem %)

Been there, done that I crosscompiled the kernel and got it started on the simpad with the modified ohh bootloader.
The problem is that I can't pass a commandline to the kernel - I tried to, but it seems to get overwritten somewhere by the bootloader.
(The bootloader also tries to tell the kernel it has 64MB of RAM which isn't the case)
Also I have no chance to save the modified params somehow...

The latest status was that the rootfs (from opie 0.9....) got mounted but my kernel with this damn commandline I'm unable to modify failed to execute /linuxrc.

Anyone an idea how override that damn commandline?
Neither compiling my own commandline into the kernel worked, nor did passing the args to boot vfat zImage <args>.
However I'm quite sure I get this done with some work - help is appreciated as it does accellerate it %)

And yes, I do know there's no mq200 support in the 2.6 kernel tree, but I'm willing to port the mq200 driver to the 2.6 kernel tree. I got the full mq200 datasheet so I'm also willing to add as much hw accel as possible since I want to run directfb on it anyway.

The tda8007 also isn't in the 2.6 tree what's a minor problem. But I also wasn't able to find any image (they're all 2.4 based) for the simpad with tda8007 support.

The reason I'd like to have the tda-driver working is the following:
I'd like to look at the CS (Chip Select) and RD/WR (Read/Write) lines of the tda with my oscilloscope to figure out how "fast" the bus is.

Why that? Well I also want to add SD-support, but not the GPIO-bitbanging style.
It costs quite a lot cpu-power to do it with the GPIOs and you probably don't get much throughput. Anyone here with GPIO-SD-performance readings?

So my approach is to remove the tda and glue a low-power CPLD to the former-tda connections and to an SD-card. (But one could also connect a CF card or CF-wlan etc. to it so one could but a microdrive or internal wireless lan card into the simpad...)
This way you get 1 Byte (tda is 8-bit connected, but >16bit is too much fiddling anyway...) per bus-cycle what results in Bus speed = CF/SD throughput in Bytes/sec.
(I expect the bus to be >=8 MHz what would be >=8MBytes/sec. throughput to the CF/SD)

Anyone here with interest in this project?

One of my first problems to solve is getting a new battery :\ the old one is completely broken :\


  • Newbie
  • *
  • Posts: 10
    • View Profile
Status Quo?
« Reply #1 on: February 28, 2006, 11:52:10 am »
Cheers for anybody picking up a SimPad again!

(see older posting, I try to renovate mine, then found Opera to be gcc-incompatible with the newer Opie)

About SD cards: the serial for the DECT modem is usually free. I don't know of it has a clock and can be used sychronously (SPI), if so you're clear. Even better if the DMA can work with it. We used MMC and SD cards in the Rockbox project, driving it with 3 Mbit/s there (hardware limit).

My battery is also almost dead, but I'm not worried, the RC model people have a large variety these days. The cabinet has plenty of space.

Yay for mq200 acceleration!  \o/



  • Newbie
  • *
  • Posts: 21
    • View Profile
    • http://
Status Quo?
« Reply #2 on: March 01, 2006, 12:40:03 pm »

the ohh bootloader appends its own set of params to the kernel commadline,
but when it find a file called params in the /boot/ directory then he appends
also the parameters from the params-file.

Example: -> params <-
set linuxargs "mtdparts=sa1100:0x00040000@0x00000000(bootldr)ro,0x00FC0000@0x00040000(root
 noinitrd root=/dev/mtdblock1 init=/linuxrc rootfstype=jffs2 jffs2_orphaned_inodes=delete mem=32M" set kernel_filename=boot/zImage

This hint is from Guylhem Aznar and can show at:

With the example you shoud have the following flash-geometry:
256kByte bootloader-partition and 16128 kByte root-partition with jffs2.

When your CL4 has only 16MB of RAM then you must change mem=32M in mem=16M.

My Simpad SL4 works with opie and kernel version 2.4.27-vrs-pxa1-jpm1 from Frederic Devernay with 256kByte bootloader / 32512kByte root (jffs2).

Successfully works Opera 7.55 and Jeode EVM version 1.10.2 -> java applets  
My next project is modding the Simpad with bluetooth and SD/MMC-card
interface on seriell-dect-connector like Guylhem Aznar.

SIMpad SL4 128MB-RAM-Mod, Bluetooth-Mod, MMC-Mod, Accu-repair
Ångström GPE-Image (Kernel-2.6.24)


  • Newbie
  • *
  • Posts: 24
    • View Profile
Status Quo?
« Reply #3 on: March 02, 2006, 05:00:29 am »
As far as I know the mem= param is for the RAM memory, editing the partition part of the linuxargs (in /boot/params) works for me.

The directFB thing looks nice, there's no(t much) touchscreen support as far as I can see though. Won't this be a problem? What's the motivation behind a directFB distro anyway, any specific plans or just looking for good graphics? (MQ200 support sounds nice indeed.)

I'm asking since I'm interested more intelligent touchscreen support (maybe on simpads) and if directFB might fill this gap. Specifically, using multiple fingers on the screen for stuff like moving/rotating/zooming. Could you offer some insight if the could be feasible? I'm guessing that in GPE/OPIE the touchscreen input is simply mapped to a single coordinate and used as mouse in the window manager/GUI toolkit. I'm no expert but I'm afraid that trying to capture multiple points could be a nightmare with the current GUI toolkits.

From what I've seen Apple is already patenting stuff like that and will once again steal the show. I know this would als mean serious adjustements in the GUI (if it even will fit in the current paradigm), but I'm wondering if this input could be possible. Stuff like that could give major usability improvements; it'd be a lot more intuitive.

Just a thought, I look forward to your results.
« Last Edit: March 02, 2006, 05:03:59 am by Berend »