OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | #planetgemini chat on matrix.org | #gemini-pda chat on Freenode | #zaurus and #alarmz chat on Freenode | ELSI (coming soon) | Ibiblio


Welcome Guest ( Log In | Register )

Personal Photo
Personal Statement
juggler doesn't have a personal statement currently.
Personal Info
Age Unknown
Gender Not Set
Location Unknown
Birthday Unknown
No Information
Joined: 20-December 05
Profile Views: 218*
Last Seen: 24th August 2006 - 02:29 PM
Local Time: May 20 2018, 05:11 PM
11 posts (0 per day)
Contact Information
AIM No Information
Yahoo No Information
ICQ No Information
MSN No Information
* Profile views updated each hour



My Content
27 Dec 2005

since flashing the hh.org bootloader on my swissom cl4 did not
work, we tried to fix this using jtag.
It seems that we have found a subtle way to finally kill the

The primary problem, while trying to jtag the pad, was that
the jtag software didn't detect the self soldered cable.

After verifying all soldered connections we figured three possible
sources for our problems:
1. My brother-in-law used higher rated resistors for the jtag
cable, since he had no correct resistors at hand.
2. Basically the mainboard layout could have been altered,
so that jtag would not work anymore, even though the soldering
points are still available. Since jtag is no official feature
and it is usually only used during development, it might
be possible, that the swisscom pads don't support it anymore.
3. Some specific problem with our simpad.

While fumbling around we realised, that the bootloader was starting
even if the jtag cable was connected.
My brother-in-law was a little bit astonished, since he expected, that
the jtag cable should keep the processor permanently in reset state.
Later on he guessed, that it might also be possible, that the jtag
interface only blocks the cpu from interaction with other peripherals.
Somehow I proposed to enforce this reset state by pressing the
reset button while the jtag cable was connected.
We later on guessed that this was the trick to kill the simpad, since
some minutes later we realised, that the cpu started to get really
hot (i.e. hot enough to burn your fingers). Furthermore the
boot messages started to get messed up (i.e. most text was
undecipherable due to strange symbols, just a few strings
remained readable) and finally the simpad didn't boot at all

We later on figured, that the strongarm processor provides two
separate reset logics and my brother-in-law remembered, that
he had already damaged another device by triggering two reset
logics simultaneously before.
Since in this other case only a reset IC was killed, we started looking
for such an IC but we have not succeded yet and it might be even
possible, that the reset logic is not driven by an IC but just by an
RC component.

So it looks like we have really bricked the simpad, but we are not
really sure why and furhtermore we still don't know, why the
jtag cable was not detected.
My brother-in-law said, that the resistors for the jtag cable, where
technically unnecessary, but we didn't have the possibility to test
this simplified jtag cable, since we killed the pad before.

The interesting question is wether someone can verify, that the
jtag process works on swisspads.

And ofcourse if we really cannot fix the pad, the question arises
wether it is possible to somehow make use of the simpad screen
as a display. For this we would probably need a controller or at
least some specifications to program a controller, but currently
we have not yet found a model number or any other information
about the display, even the manufacturer is unclear.

So if anybody has informations about the last point, this would be quite
helpfull. On the other hand, if somebody has a simpad with a broken
display we could either buy the mainboard or sell our display.

22 Dec 2005

after fumbling around with oe and bitbake I finally managed to build
an opie-imag, that is small enough (< 16mb) and hopefully provides
the correct kernel command line (i.e. parittion definitions for 16 MB flash).
But as it turns I could even flash this image due to bootloader problems.

Since Documentation about any bootloader and 16 MB simpads seems
to be non-existent I had the following choices.

Install bloader.2.5.3 from opensimpad.org, which is specifically labelled
as not compatibel with cl4


directly flash blupdater.img without erasing flash before.

I decided to try the last version, it looks like this was a failure.

The bootloader boots as expected and after an unsuccesfull
attempt to flash an img from cf (hda1) falls back to a prompt.
So far this is OK and expected, the problem is that the
prompt is not reacting to any inputs, effectively making
it impossible to do anything (esp. flashing something over

I have no Idea what to try now, besides using JTAG or soldering
an pcmcia slot, so that I can place a flash image on /hda1.

For neither of the two options I have the necessary hardware at hand.

Even worse I have still no idea, what went wrong, respectively how
to do it right.

If not erasing the flash was the source of the problem, then
I would have to install the 2.5.3 bootloader, which sounds not
like something that could work. But if this was not the problem,
what else can go wrong (the blupdater.img file is OK and
serial upload seemed to work).

As far as I have read in this forum several people in this
forum have managed to get bootloader running on a cl4,
so how did you do that?

20 Dec 2005

I recently bought a simpad cl4 and after
some struggling with the hardware and the
old opensimpad release (see my other two threads),
I am now trying to build opensimpad using

This ofcourse also raised some Questions / Problems,
most of which I have not resolved yet.

Concerning Monotone:
I tried to pull the repository, after 3 days
and several interruptions due to 404s, I gave
up. This raises two Questions:

1. How long should pulling the repository
normally take (I have a 3 Mbit DSL connection)
2. If monotone breaks due to 404, does a
new call restart it from the beginning
or does it continue from the last stop?

I also tried to grab the OE.db.bz2 database
snapshot, but monotone complained about
an incompatibility (I think it concerned
the database version) and threw two hashkeys
(I think that is monotones replacement for a
version number). I also tried to migrate
the db, but this resulted in the same error.
Finally I settled with a direct snapshot
of the source and skipped monotone.

After I started the build process, I found
somewhere the warning to rename the OE.db
file to oe.db. I dont want to test this
currently, to avoid interferences with the
build process.
But these questions remain.

Would renaming OE.db to oe.db resolve the
above compatibility problem and if yes,
On the other hand if this is not the
solution, how can I make use of these
database snapshots?

Concerning Bitbake:
In the local.conf file I had to alter the line
CVS_TARBALL_STASH = "http://www.oesources.org/source/current"
CVS_TARBALL_STASH = "http://www.oesources.org/source/"
Is this normal / correct ?

And now for the hard part, which I have just started with.

How do I specify the hardware specs of my simpad.
In local.conf I can only specify to build opensimpad.


Should I alter settings in /conf/distro/opensimpad-0.9.0.conf ?


Furthermore after starting bitbake, it seems that
srcs get pulled from the net, for some modules this produced
404s but didn't stop building immediately.
But now I got the message that building failed:

NOTE: package module-init-tools-3.2-pre9-r0: task do_fetch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package module-init-tools-3.2-pre9: failed
ERROR: Build of task-bootstrap failed

Anyway to fix this, or should I just wait?

Last but not least I concluded from some threads here,
that the patches for mmc and bluetooth were already included
into the openembedded, thus

how do I acitvate the mmc-module, or do I have to compile it by hand.

So far for now, I fear that I will stumple upon a some more questions
during the next days, so I appreciate any help.

20 Dec 2005

I recently bought a Swisscom pad (actually a simpad cl4),
more details about the hardware can be found in my previous

When trying to install the last official opensimpad version
(i.e. 0.8.1) I ran in to a lot of problems, which were
mainly due to unprecise or lack of documentation.

First off some installation instructions refer to buttons
by letters (at least r and f), but I have not found
any documentation for the association between these
letters and the actual keys on my simpad (maybe
the swisscom pads are labelled differently from
normal simpads?).

So is there any common letter key association for simpads?

I decided to use the key with the small rectangle and
interpreted reset as the r key, this seemed to work.

The next problem is the advise to erase
the flash before installing. According to the
docs this requires a booloader >= 2.5.3, but the latest
version available for small cl4 models is 2.5.1, thus
it is not possible to erase the flash.

I decided to skip this step, though the docs, explicitly
warn because of non immediate problems that might result,
the question is still:

What is the correct way to flash opensimpad on a
cl4 simpad, can I use the sl4 bootloader or is an
cl4 version of this booloader available?

Finally I want to use part of the ram as a ram disk.
For this purpose I found appropriate kernel images,
but there is no instruction about what to do with it.

I guess I can simply flash the kernel images like I flashed
the initrd... image, but I'd like to have a confirmation
before I do this.

By the way, it is not quite clear to me wether it is
possible to write to flash with the 0.8.1 release.
I concluded from some remarks here, that writing
to flash is not possible from within linux
(I think jffs2 would be necessary).
Despite this I could store a few MB on my simpad
and I had the impression that the files were
stored in the flash ram.

So since I have to patch my kernel for the mmc slot and
I'd also like to be able to write to the flash
I decided, to try to build my own images
(see next thread), thus these questions will hopefully be
not to important for me anymore, but answers are still
interesting and might helper other people who bought
the swisspad.


P.S. I found some Siemens internal informations on emule,
that state, that the flash ram is only specified for
1000 flash cycles, thus it might not really be a good
idea to use it via a file system anyway....
20 Dec 2005

I recently bought a simpad with the intent to abuse it as
a cheap, flexible, big, high-resolution digital picture frame.
(Currently commercially available image picture frames have cga to vga
resolution and cost > 200 Euros...)

I am probably not a total newbie, since I use openzaurus on my
zaurus since some monthes, and I use Linux since ~ 10 years.
Despite this I stumbled across a lot of problems and questions
most of which I have not resolved yet.

Instead of solving this by try and error on my own, I will try
to put all or at least most of my questions and observations
here, in the hope that I will get some answers and the corresponding
threads will end up collecting the most relevant informations
concerning opensimpad on cl4.

To restrict my posts and the collected problems to a moderate size
I will split my Questions into 3 separate Threads
concerning Simpad Hardware, Opensimpad prebuilt versions and finally
building opensimpad using openembedded.

So far now for the hardware topics.

I think my biggest "failure" was, that I decided, that for my digital
picture frame 32 MB ram an 16 MB flash would be enough.
Thus I went for the cheaper CL 4 or to be more precise for the
swisscom ScreenPad Top WP50@ISDN, which an ebay trader currently
sells very cheap on ebay.de.
Ofcourse I completely missed the point, that the small versions
also lack the pcmcia slot, which I planned to use for a flash card reader
in a first step. Besides this opensimpad seems to be poorly supported
/ documentend for this version as I recently figured (see my next thread).

Since I always bought the simpad with the idea of adding an sd slot
in mind, I decided to immediately attack my simpad with a soldering iron.

After opening the simpad I immediately realized, that soldering this
is probably rather difficult for an untrained person like me, so
this was not so obvious for me from the webpage.
Luckily my sister and her husband are both electrical engineers, so
I simply passed the simpad to them and they soldered in an sd slot.

This also let us to investigate another point, that had come to my
mind after seeing the missing pcmcia slot.


Ofcourse my question is wether it is possible to add the missing
pcmcia slot?


By comparing my simpad to images of the sl4 from the internet
I figured that besides the actual slot, it seems that only
three more ICs are missing.
The problem was figuring the number of these ics.
I think we found the correct number (so I have the number
not at hand atm) and the corresponding chips seem to
be bus drivers (im not quite sure if this is the correct
technical term...) which would coust around 3 Euro per piece.

Soldering them is probably not easy, but surely easier
then desoldering and soldering new ram chips.
(Actually my sister and her husband were rather
impressed, that some of you guys were able to desolder
a ram chip from a dimm module and resolder it into
the simpad without breaking it by overheating...)


So this now raises two Questions:

1. Has anybody already done this, i.e. adding a pcmcia a slot to CL4?
2. What is printed on the 3 missing chips?


The last Question is basically for verification purposes, the
3 identicall ICs missing on my CL4 are positioned immediately
below the card slot (i.e. below the flash chips) and the missing
pcmcia slot, they have approx. 50 pins.

Another point that came to my mind, so it is probably not usefull
for me, is, wether it might be possible to use the dect and sd
functionality alternatingly.
Basically the Idea is, that the SD-slot, does not close any
new circuits, as long as no card is inserted, on the other
hand, I concluded from one description on the internet, that
the dect module can be switched on and off on a hardware basis,
which itself can be controlled by apm events.


Thus it might be possible to use sd by switching off dect
and dect while no sd-card is inserted or am I wrong?


Still I don't think my picture frame needs a dect module,
so if someone needs a dect module, I have a spare one.

Finally one question concerning wlan:

Is it possible to add wlan funcionality without
adding the pcmcia slot?

I guess the answer is no, since the trick with the
bluetooth modules seems to be, that they can be
accessed in a serial mode.
But maybe this works also for those sd-wlan modules?

So far for the hardware questions, which are actually
least important for me at the moment, but I think
it gives a good starting point for the next

Last Visitors
juggler has no visitors to display.

Other users have left no comments for juggler.

There are no friends to display.
RSS Lo-Fi Version Time is now: 20th May 2018 - 08:11 AM