Topics

1

Angstrom & OpenZaurus / Resurrecting A Collie

« on: February 19, 2009, 06:08:54 pm »

Hi all,

I've been trying to bring my trusty SL-5500 back to life. I have successfully set up OpenEmbedded, built and flashed kexecboot. I'm currently stuck on a few issues:

1. SD card isn't really working. An Angstrom image unpacked onto an ext2 SD partition is recognized by kexecboot but booting ends with a flurry of error messages like this:

Buffer I/O error on device mmcblk0p1, logical block 8
mmcblk0: retrying using single block read
mmcblk0: error -22 sending status comand<3>mmcblk0: error -22 sending read/write command, response 0x4, card status 0xff04
end_request: I/O error, dev mmcblk0, sector 104
...

The same error messages turn up if I boot from ROM or a CF card and then insert an SD card. The most recent kernel I've tried this with is from this morning (19 February 2009) and it's a 2.6.28. I have seen this with two different cards from two different manufacturers. I have tested the cards for errors on a different machine and they seem to be OK.

2. An Opie image on a CF card boots up to the "Tap anywhere..." screen where it freezes.

3. Battery charging doesn't work. When the charger is connected the LED doesn't light up and the battery stays discharged even after several hours. I've established that this isn't a hardware problem - when I flash a Sharp ROM (from http://www.myzaurus.com/ROMupdate5.asp) everything works as it's supposed to.

Any help with any of these issues will be appreciated. A few particular questions:

- regarding issue 3: I've read about a "service menu" accessible by pressing some key or key combination while connecting the charger. Supposedly one can set various voltage thresholds in the menu but I've never been able to get to it in the first place. Anyone know any details?

- regarding issue 1: I have a vague impression that the first OE images I built a couple weeks ago didn't have the SD card problem. Is there a particular node in the git tree that's been verified to have working SD support on collie? Also, would anyone be willing to check SD access on a current OE image on their own collie?

The device is otherwise pretty functional - I can even ssh to the collie over a USB cable. I think I'll make the thing useful again eventually.

Thanks,

z.

2

For Sale / Wanted / Wanted: 5500 Or 5600

« on: April 14, 2005, 09:49:32 am »

Hi all,

I lost my treasured 5500 a few weeks ago. I need a replacement quite badly but my budget is limited. I am looking to spend about US$150 plus shipping, not more than US$180 all together (I live in the EU).

As I'm looking for a replacement, I really don't care much about accessories (I already have what I need). All I need is the unit itself, although I wouldn't mind a CF memory card (lost mine with the Z). Ideally, I would like to buy from someone who is upgrading, or has just upgraded, to a clamshell.

C'mon folks, don't let me down!

Cheers,
z.

3

Software / Zaurus Port Of Treeline

« on: March 20, 2005, 10:34:56 am »

Hi all,

I started working on a Zaurus port of the fine TreeLine outliner early last year but later got distracted. I haven't touched it in about 7 months now and it isn't really ready for a release but I do use it daily and absolutely can't do without it, despite the bugs. As I have trouble finding the time to finish it, I have decided to release it in its crude present state. Either someone will pick it up or enough users will find it promising enough to nag me into activity   Or maybe it won't interest anyone, which is fine. In any case, it is there, on my homepage.

Cheers,
z.

4

Angstrom & OpenZaurus / Problems building an OE image

« on: October 30, 2004, 04:03:31 pm »

Hi all,

today I tried to "oemake opie-image" from a fresh snapshot (2004/10/30 05:00) and libopie2 complained during linking about missing -lsqlite. Can anyone suggest a work-around or point me to the most recent snapshot that is known to build? Thanks.

z.

P.S. I think it would be nice to have a thread where you could mention OE build problems, listing the snapshot you are using and the point where it breaks. This may be such a thread for the future if anyone picks up on the idea. And for people who have absolutely no idea what this post is about, there's an explanation.

5

Angstrom & OpenZaurus / Getting opie-recorder to work in 3.5.1

« on: October 22, 2004, 09:29:46 am »

Hi all,

if anyone of you tried the sound recorder app that comes with 3.5.1, you probably produced samples of length 0.00 seconds - at least that's what happened to me. Turns out it can be fixed quite easily: edit /root/Settings/OpieRec.conf and in the [Hardware] section, add or modify these two lines:

Audio = /dev/dsp1
Mixer = /dev/mixer1

You should now be able to record audio with these caveats:

• It seems that opie-recorder severely miscalculates maximum allowable sample duration (there must be a  multiplication error somewhere). The upshot is that if you leave Limit Size (under Options) at Unlimited, recording will automatically stop after as little as a second (with 10MB of free storage left). The solution is to set Limit Size to the highest possible numerical value, i.e. 60.
• If you change sample rate or bit depth, it is a smart move to shut down and re-start opie-recorder. Otherwise you will get .wav files with incorrect sample rate specifications - to great comic effect I must say.
• You will not be able to play back what you record, because while /dev/dsp1 is the correct device for recording, /dev/dsp is the one for playback. opie-recorder currently does not support specifying one device for recording and another one for playback. Workaround: use xmms-embedded to play back your wav files. Alternatively, you can keep two versions of OpieRec.conf and set up scripts which will run opie-recorder with the proper version depending on whether you want to record or play back.
• As for mixers, both /dev/mixer and /dev/mixer1 seem to work fine for playback although I once got an infinite loop with one of them, forcing a soft-reboot (can't remember which device it was, though). For recording, /dev/mixer1 seems logical (although I haven't actually tried altering input volume).

Hope this helps.

z.

6

Angstrom & OpenZaurus / Prboom in 3.5.1? Any success?

« on: October 18, 2004, 10:11:06 am »

Hi all,

to my regret I've never been able to get Prboom running under OZ, no matter which version. Has anyone got it going on a brick-style Zaurus?

Thanks,

z.

7

Angstrom & OpenZaurus / Workaround for absent Local packages in 3.5.1

« on: October 16, 2004, 08:37:46 am »

Hi all,

as I am used to carrying complete feeds on my CF card, I was quite dismayed that opie-packagemanager in 3.5.1 is missing the Local packages feature. After some trial-and-error, I've come up with a pretty easy way to provide that functionality by setting up a local package feed. It is assumed you have a copy of the current feed, including the Packages file, in /mnt/cf/feed/current.

Code: [Select]

export FEED=/mnt/cf/feed/current
ipkg install --force-overwrite `ls $FEED/mime-support_*.ipk`
ipkg install `ls $FEED/boa_*.ipk`
vi /etc/boa/boa.conf # change DocumentRoot to /mnt/cf/feed/
vi /etc/ipkg.conf # add a line 'src local http://localhost/current'
/etc/init.d/boa startThis will add a new feed into Package Manager, called "local" which you can use just like any other feed. Some notes:

• I use the boa ultra-lightweight webserver rather than the FTP server that is running at port 4242 by default. First, I kept getting errors from wget when accessing FTP (even upgrading busybox to r10 didn't help) and second, sync authorization dialogs kept popping up.
• Running a web server does present an additional security risk so you might want to keep it off when not needed (/etc/init.d/boa stop).
• If you want to use a non-standard feed you will have to generate your own Packages file   which was not necessary with Local packages. There is a tool for it called ipkg-make-index.sh

Overall, I think the fact that opie-packagemanager resolves dependencies vastly outweighs the Local packages limitation and I'm quite happy with the local feed (I also have the impression that the list of packages is generated faster than it used to be with Local packages).

Hope this helps.

z.

8

Off Topic forum / A placebo upgrade

« on: September 08, 2004, 07:40:21 am »

Hi all,

the strangest thing just happened to me so I thought I'd share a story.

I'd been absolutely swamped with work over the past few weeks and, as a result, my Z was relegated to the role of a stress-relief toy. In particular, I developed a habit of playing Patience in any spare moments I had. Over time, I gradually gained a vague impression that the game was running somehow slow. Card animations felt sluggish and the startup time was also less than snappy. I didn't have the time nor was I in the mood to investigate, and so I just concluded that 206MHz is not that much and my recollections of better performance were probably just wishful thinking.

The work stress came to an end this Sunday when I held a big presentation to a group of clients. After it was over, I finally had more time to play around with the Z, and as I fired up my outliner it took _ages_ to start. Saying to myself "whoa, that ain't right!", I opened Konsole and ran "top". Sure enough, there was a stray python process hogging all CPU cycles it could. It must have been there for weeks!

When I killed it, everything just started flying. I put on Patience - the animations were smooooooth. As were the PIM apps and the Settings apps, suddenly. So now I'm enjoying a very fast machine indeed, all thanks to a self-induced bit of pessimization  

z.

9

Off Topic forum / Finally in the 21st century!

« on: July 31, 2004, 12:32:32 pm »

Fellow Zaurus fans,

I am extremely proud to announce that I've become the user of a brand new, shiny DSL connection. I am ready to enjoy the pleasures of a truly connected life (as soon as I overcome my paranoia over non-stop exposure to port scanners, worms and other beasts  ).

z.

P.S.  

10

OpenZaurus/Opie/Qtopia / qcop not reaching Python apps

« on: July 14, 2004, 03:08:03 am »

Hi all,

I have a little problem with Python apps. Say I have a trivial PyQt application in /root/test.py:

Code: [Select]

#!/usr/bin/python
import sys
from qt import *
from qtpe import *
class MyWin(QVBox):
    def __init__(self, parent):
        QVBox.__init__(self, parent)
        self.setCaption('Test')
        label = QLabel(self)
        label.setText('Hello, world!')
app=QPEApplication(sys.argv)
win=MyWin(None)
app.setMainWidget(win)
win.show()
app.exec_loop()I type chmod +x test.py and then ./test.py . The app runs OK but when I open another konsole session and type qcop QPE/Application/test.py 'quit()' it doesn't come through.

How do I know that QPE/Application/test.py is the right channel? When the app starts the file /tmp/qcop-msg-test.py is created. I also tried other channels like QPE/Application/python but the results are the same. The funniest thing, though, is that when I say qcop QPE/System 'quit()' the app does quit - and it is the only one to do so! Konsole continues to run, as well as the rest of Opie.

This is a major problem because the taskbar uses qcop to raise() an application when you tap its taskbar icon. So when I set up my app to be launched through an icon, it misbehaves: once it's "minimized" e.g. by pressing the Home button, there is no way to bring it back up - it has to be shut down with SIGTERM.

What I think is happening is that either the app fails to actually create a QCop channel or it creates a different one than Qtopia/Opie expects. Can anyone tell me how to find out the name of the channel a QPEApplication creates? Thanks in advance.

z.

11

Accessories / Auto-mounting multi-partitioned cards

« on: July 12, 2004, 08:25:24 am »

Hi all,

I recently split my CF card into two partitions (/dev/hda1: FAT, /dev/hda2: ext2). I use the FAT partition for flashing and I store my data & programs on the ext2 partition (it is set up as an ipkg destination).

My problem is that only /dev/hda1 gets auto-mounted. I tried various things:

1. tweaking /etc/fstab
2. installing opie-mediummount and tweaking the settings
3. adding "mount /mnt/cf2" to $HOME/.profile

The last option works in that it handles startup. It does not work when I eject and re-insert the CF card. I don't like this solution. I would like to auto-mount /dev/hda2 using the same mechanism that works for /de/hda1. Can anyone advise me how to do that?

thx in advance.

z.

12

Angstrom & OpenZaurus / datebook day view not using full width

« on: July 08, 2004, 11:14:36 am »

Can anyone explain why opie-datebook sometimes displays events at half-width even though they don't overlap with anything? Usually the entire day is displayed like that.

It's only mildly annoying but I was wondering whether it's by design or by mistake.

z.

13

Python / QSplitter missing in PyQt on the Zaurus

« on: June 30, 2004, 05:19:31 am »

Hi all,

The following Python script runs fine on the big box but fails on the Z, saying name 'QSplitter' is not defined:

Code: [Select]

#!/usr/bin/env python
import sys
from qt import *
app=QApplication(sys.argv)
split=QSplitter(Qt.Vertical, None)
label1=QLabel(split)
label1.setText("Test 1")
label2=QLabel(split)
label2.setText("Test 2")
split.showMaximized()
app.setMainWidget(split)
app.exec_loop()Further, grep QSplitter `ipkg files python-pyqt` returns nothing - so the class isn't even mentioned in the Zaurus implementation. The Python packages I'm using come from the 3.3.6-pre1 feed.

Given that QSplitter is such a basic piece of UI I'm quite puzzled as to why it is absent. I can work around this limitation for now, fortunately, but someday I may well need a split pane so it's quite discomforting to see it missing. Is it perhaps there and I'm just looking in the wrong place? Has it been deprecated & replaced by something else? Can anyone provide an explanation? Any advice appreciated.

z.

14

OpenZaurus/Opie/Qtopia / what\'s up with handhelds.org?

« on: May 25, 2004, 04:25:04 am »

Hi all,

I\'ve been trying to get my hands on recent OPIE source code for the past 2 days but I just can\'t get to it. opie.handhelds.org, www.handhelds.org and cvs.handhelds.org all refuse HTTP connections (although they do answer ping) and cvs.handhelds.org times out on port 2401.

Anybody has any advice or explanation? Thanks.

z.

15

Python / Introducing quickpython

« on: May 21, 2004, 12:54:17 pm »

Hi all.

As I\'ve mentioned in another thread, it would be nice if there was a way to speed up Python apps on the Z the way quickexec speeds up C++ apps. I started thinking about today and it took me 41 minutes to put together a very basic working version. I\'ll call it quickpython because it makes sense (and google yielded just 5 hits mostly related to The Quick Python Book).

Be warned: I\'m a complete Python newbie and I just wanted a proof-of-concept, so it\'s a butt-ugly hack. We\'ll get to that later. First you need to copy the following code into a file and call it quickpython.py:

Code: [Select]

#!/usr/bin/env python

from os import remove

from time import sleep

COMMAND_FILE="quickpython.cmd"

while 1:

 try:

  sleep(1)

  commandFile=open(COMMAND_FILE, "r")

  command=commandFile.read().splitlines()[0]

  commandFile.close()

  remove(COMMAND_FILE)

  if command=="exit":

   break

  else:

   execfile(command, {})

 except:

  continue
The above code plays the \"daemon\" and keeps the Python runtime loaded. Now we need a way to send it innocent Python apps to be executed :twisted:. It will be a trivial shell script called qp.sh:

Code: [Select]

echo $1 >> quickpython.cmd
Once you have both files in place in the same directory, open konsole in that directory (if you\'re not already there) and try this:

chmod a+x qp.sh
./quickpython.py &

Now the daemon is running and we can try to feed it a Python script. Let\'s say you have an app you want to speed up and it\'s launched via myapp.py. Simply type

./qp.sh myapp.py

and it should start up. You will notice no change the first time but if you exit your app and do it again there should be a major difference. In the case of my diary app, launch time went from about 10 seconds to under 1 second (on an SL-5500). The daemon takes up about 2MB of RAM and, last but not least, you can shut it down with

./qp.sh exit

As you can see, it is a butt-ugly hack indeed. The most outrageous shortcomings include:

- namespace trouble - the apps leave residue after they\'ve run; QApplication keeps complaining that there should be only one app instance :oops:
- your app will not receive any command-line arguments you might pass to it
- all exceptions are ignored
- everything must run in the same directory
- the daemon can only run one application at a time; the next one won\'t launch until the current one exits
- it uses the most primitive form of inter-process communication - a buffer file

I know nothing about threads in Python or IPC in Linux (yet) but I\'m posting this to provoke those who do. Things are ridiculously easy with Python and maybe we are not that far away from a nice quickpython_0.1.ipk. After the kinks are ironed out, it shouldn\'t be hard to tweak qp.sh so that it lazily launches the daemon and then we can use it to intercept /usr/bin/python and the whole thing will be completely transparent.

Any feedback appreciated,

z.