![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Group: Members Posts: 11 Joined: 20-December 05 Member No.: 8,761 ![]() |
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 |
|
|
![]()
Post
#2
|
|
Group: Members Posts: 11 Joined: 8-November 05 Member No.: 8,492 ![]() |
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 |
|
|
![]()
Post
#3
|
|
Group: Members Posts: 24 Joined: 2-October 05 From: The Netherlands Member No.: 8,235 ![]() |
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 |
|
|
![]()
Post
#4
|
|
Group: Members Posts: 11 Joined: 20-December 05 Member No.: 8,761 ![]() |
Hi Berend,
QUOTE(Berend @ Dec 28 2005, 01:15 PM) 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 |
|
|
![]()
Post
#5
|
|
Group: Members Posts: 8 Joined: 24-November 05 From: Germany Member No.: 8,604 ![]() |
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 |
|
|
![]()
Post
#6
|
|
Group: Members Posts: 8 Joined: 24-November 05 From: Germany Member No.: 8,604 ![]() |
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 |
|
|
![]() ![]() |
![]() |
Lo-Fi Version | Time is now: 23rd April 2018 - 01:37 PM |