Killed My Swisscom Cl4 Using Jtag., don't press reset while using jtag? Options

[juggler]

Hi,

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
simpad.

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
anymore.

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.

regards
Sascha

[sirtet]

jtag should work i guess, maybe u can find a pcb rev. nr. on the mailboard and compare with some available pics...
i looked through my photos, but did not see a pcb rev.
i guess it is somewhere.

reuse the display for sth else than a simpad
is quite impossible i think, displays have proprietary driver electronics, no standard there, so it is quite an engineering task to use it other than in a simpad.

thomas

[Berend]

I started building a JTag cable for my Swisscom CL4 but I couldn't get it to work either. I checked the wiring for a few times but I suspected my parallel port wasn't working properly. The different documentation for different linux distros confused me and I had no idea how to test my software, so I dropped the project since I didn't need it right away. I'm running Ubuntu Breezy.

Maybe I could be of help doing some additional testing, but from what I read from your report I'd figure your pad is fried. Too bad because you we're really coming a long way.

the lack of connectivity options (no USB host, can't find a CSR BlueCore with UART, no PCMCIA) are making me consider looking for a SL4 too.

I'm wondering though, you mention you build an image with new CL4 params. Would it be possible to make it available somewhere? My attempts to set up OE/Monotone have been less than succesful. I know I just have to put some more time in but I'm not sure it's worth the hassle and setting up OE really seems like that..On the other hand --with everything you documented here at the forum, thanks about that-- I'l probably try again in a few weeks.

Good luck and thanks for the all the insights, Berend

[juggler]

Hi Berend,

I'm wondering though, you mention you build an image with new CL4 params. Would it be possible to make it available somewhere? My attempts to set up OE/Monotone have been less than succesful. I know I just have to put some more time in but I'm not sure it's worth the hassle and setting up OE really seems like that..On the other hand --with everything you documented here at the forum, thanks about that-- I'l probably try again in a few weeks.

before I forget it, you can find the latest opie Image I build on:
http://www-user.rhrk.uni-kl.de/~gerkhard/s...l4.rootfs.jffs2

Actually I'm quite eager to know wether it works, since it's not very likely, that
I will by an CL4 again (and I will probably have to wait a few month before I have
time to buy and configure an SL4 pad).

If I find time, I will place some more detailed information about this image in the
corresponding parent directory.
Roughly I have used the openembedded repositiory of ca 20.12.05 for building
an opie-image and modified machines/simpad.conf for 16 MB flash and
an 24-8 ram / ramdisk configuration.

Ofcourse I cannot give any guarantee that this works, since I have never tested it,
but it looks like this is the only currently available opensimad 0.9.0 image for an
CL4, so if anybody tries it, please report your results here.

regards
Sascha

[ric]

before I forget it, you can find the latest opie Image I build on:
http://www-user.rhrk.uni-kl.de/~gerkhard/s...l4.rootfs.jffs2

Hi Sascha,

gave it a very short try last night on my tsinuspad. Unfortunately, it didn't even start correctly. Don't have the errormessage handy right now but I will tell you tonight when I'm back home.
I tried to build an opie-image myself. It started into the login-prompt on tty and showed some welcome image on the screen as well but the touchscreen didn't work at all. Had no time so far to dig deeper into this. My goal is an image for my sinuspad with a reasonable browser and a reasonable (i.e. imap-capable) email client.
so i'm keeping on trying.

Greetings
Richard

[ric]

Hi,

here are the last lines of the boot process with Sascha's image on my sinuspad:
/etc/rcS.d/S01version: 31: cannot create /dev/tty1: Permission denied
/etc/rcS.d/S01version: 31: cannot create /dev/tty1: Permission denied
/etc/rcS.d/S01version: 31: cannot create /dev/tty1: Permission denied
/etc/rcS.d/S01version: 31: cannot create /dev/tty1: Permission denied
/etc/rcS.d/S01version: 31: cannot create /dev/tty1: Permission denied
/etc/rcS.d/S01version: 31: cannot create /dev/tty1: Permission denied
/etc/rcS.d/S01version: 31: cannot create /dev/tty1: Permission denied
Setting up device links for devfs: done
Unable to handle kernel NULL pointer dereference at virtual address 00000008

After this, the machine hangs and must be reset.
BTW: with my own image, I also have the Permission denied-problem with /dev/tty1. While booting, I have to wait some time after all these messages until the boot continues. Any ideas?

Greetings
Richard