Der erste echte Linux-PDA, der seinen Weg auf meinen Schreibtisch findet.

Folgende WiFi-CF-Card ist hier im Einsatz:

Fragmente:

#Kernel-Modul laden

insmod wlags49_h2_c2

Karte rausnehmen und wieder einstecken, dass Betriebs-LED leuchtet.

# /etc/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
# ap_scan=2 was the one for me you may try 0 or 1 indstead of 2
ap_scan=2
fast_reauth=1

network={
        ssid="JW580755"
        proto=WPA
        key_mgmt=WPA-PSK
        pairwise=TKIP
        group=TKIP
        psk="xxxxxxxxxxxxxxxxxxxxxxxxxx"
}

Aktivierung mit:

#zum Testen
wpa_supplicant -d -c/etc/wpa_supplicant.conf -ieth0 -Dhermes

#im Deamon-Mode
wpa_supplicant -B -c/etc/wpa_supplicant.conf -ieth0 -Dhermes

Bitte die Versionsnummern des Kernels entsprechend anpassen. Auch die IP-Adressen von Zaurus und Host müssen entsprechend angepasst werden. Ich arbeite abweichend von der Standardeinstellung mit der IP 192.168.2.200 für den Host und 192.168.2.201 für den Zaurus.

# Kernelquellen laden

sudo apt-get install linux-sources-2.6.24

# entpacken

cd /usr/src
sudo tar -xvf linux-sources-2.6.24

# aktuelle .config holen

cd /usr/source/linux-source-2.6.24
sudo cp /boot/config-2.6.24-xx-generic ./.config

# .config anlegen

sudo make oldconfig

# erzeugte .config editieren und zaurus.ko als Modul kompilieren lassen
# Zeile CONFIG_USB_NET_ZAURUS suchen und durch

CONFIG_USB_NET_ZAURUS=m

# ersetzen.

# Modul kompilieren und installieren

sudo make drivers/net/usb/zaurus.ko
sudo cp drivers/net/usb/zaurus.ko /lib/modules/2.6.24-19-generic/kernel/drivers/net/usb/

# Modul installieren

sudo depmod -a

Nach dem Einstecken des Z sollte lsusb folgende Meldung ausgeben:

Bus 002 Device 001: ID 0000:0000
Bus 001 Device 008: ID 04dd:8004 Sharp Corp. Zaurus SL-5000D/SL-5500 PDA
Bus 001 Device 002: ID 046d:c03e Logitech, Inc. Premium Optical Wheel Mouse
Bus 001 Device 001: ID 0000:0000

und

tail -f /var/log/messages 

...
Sep 21 15:03:04 snibril kernel: [20754.182578] usb 1-1: new full speed USB device using uhci_hcd and address 9
Sep 21 15:03:04 snibril kernel: [20754.360948] usb 1-1: configuration #1 chosen from 1 choice
Sep 21 15:03:04 snibril kernel: [20754.374819] usb0: register 'zaurus' at usb-0000:00:07.2-1, Sharp Zaurus SL-5x00, 6a:d7:88:67:e2:04

ifconfig

...
usb0      Link encap:Ethernet  Hardware Adresse 6a:d7:88:67:e2:04
          inet6-Adresse: fe80::68d7:88ff:fe67:e204/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1494  Metrik:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:752 (752.0 B)  TX bytes:492 (492.0 B)
...

Looks good! Jetzt noch die automatische Vernetzung schaffen. Händisch geht das mit:

# von Hand
sudo ifconfig usb0 192.168.2.200 netmask 255.255.255.0

aber jedesmal wenn man den Z rausnimmt und wieder ins Cradle steckt wiederholt man das. Nervig, also automatische Festlegung. Die Recherche ergibt:

# Datei /etc/network/interfaces muss editiert werden

# folgende Zeilen ergänzen

auto usb0
iface usb0 inet static
address 192.168.2.200
netmask 255.255.255.0

# fertig

Beim nächsten Neustart funktionierte dann alles wie gewünscht. ( also wie bei OpenSuse out of the box ) Wer beim Anmelden auf dem Z keine IP-Adressen tippen will, dem sei die Eintragung des Z in die /etc/hosts empfohlen.

<Ctrl> wird ersetzt durch <FN> +<SHIFT>. Funktioniert auch auf der Konsole einwandfrei, und ist mit einem Daumen gut bedienbar.

F1 = nacheinander: <Cancel>, <FN>, <q>
…
F9 = nacheinander: <Cancel>, <FN>, <o>
F10 = <Cancel>, <FN>, <p>

Funktionstasten im SSH Terminal sind hilfreich für den MC und funktionieren nicht mit VT100. Umstellen auf xterm wie in Terminal in Farbe beschrieben.

Um z.B. den Midnight Commander wieder in Farbe zu geniessen, übrigens auch alle anderen Konsolenprogramme, tausche man in /etc/profile in der Zeile TERM='VT100' das VT100 durch xterm aus.

Nachtrag: Diese Änderung scheint auch dafür verantwortlich zu sein, dass der mc mit dem Stift bedienbar ist.

Achtung!

Nach mehrmaligen Versuchen ist meine Empfehlung auf die bash zu verzichten. Sie läuft nicht stabil, z.B. kehrt ein Kommando meistens nicht zur SHell zurück. Ich bin noch nicht 100% sicher, aber der Absturz der mich zur völligen Neuinstallation gezwungen hat, war eine Folge des bash Einsatzes.

Man installiere das Paket "bash". Man ändere in /etc/passwd 
bei Nutzer root den Shellaufruf auf /bin/bash.

{ <SHIFT> + <FN> + <.>
} <SHIFT> + <FN> + <Return>
[ <SHIFT> + <FN> + <Del>
] <SHIFT> + <FN> + <)>
| <FN> + <SPACE>
` <SHIFT> + <FN> + <SPACE>
^ <SHIFT> + <FN> + <'">
\ <SHIFT> + <TAB>
ESC <CANCEL> (Die Funktionstaste neben dem Steuerkreuz.)

Auf der „richtigen“ Konsole, z.B. nach Beenden der Sitzung, ist ^C Kalendertaste + <c>.

HOWTO build an ipkg (including HOWTO on using I-Linux 4.0)

HOWTO - ipkg building

This document describes how to build packages for use with ipkg. ipkg is a 
utility for the familiar Linux distribution which performs functions similar
to apt-get under Debian. However, ipkg is a lighter-weight application, meant
for embedded Linux applications. It was originally designed for the iPaq, but
it is being used more often these days in various embedded Linux configurations
as a general package management tool.

1) Setup

To build ipk's (ipkg binary packages), you will need to obtain versions of
the ipkg utilities. These utilities can be obtained by pulling down the CVS
repository from the familiar project:

Login to the CVS:
    cvs -d :pserver:anoncvs@cvs.handhelds.org:/cvs login 
    Use "anoncvs" for the password

Obtain the ipkg tools
    cvs -d :pserver:anoncvs@cvs.handhelds.org:/cvs co familiar/dist/ipkg/util

This will create the directory trees familiar/dist/ipkg/util.

This retrieves several shell scripts which are important in the building of
the ipkgs. The function of the most important tools are listed below:

  ipkg-build		Builds ipk's from a given directory structure and
			control files.

  ipkg-buildpackage	Takes source code, a set of control files, and a build
			rule file to compile the source, install it, and
			create the ipk from it. Requires ipkg-build

  ipkg-make-index	Takes a bunch of ipk's and outputs to stdout the 
			contents of the Packages file that would be created.
			

Next, if you are on a multiuser system, you will want to make a few changes
so that ipkg-build* uses ~/tmp rather than the system /tmp. (This can solve
some aggravating problems if someone is creating a package and stopped the
build - namely, the inability to create a package using the same directory).
This is necessary if you wish to build the packages contained in the 
I-Linux source. Apply the ipkg-buildpackage.patch patch to your 
ipkg-buildpackage in this case:

    cd <Location of script>
    patch -p2 < ipkg-buildpackage.patch

Modify the SCRIPTDIR line in ipkg-buildpackage to reflect the location where
you installed your script as well.

The rest of the shell scripts are utilities for working with ipk files.

In addition, it is highly recommended to install the fakeroot(1) program, which
is a program that allows regular uses to pretend that they are root in order to
be able to do things that often require root, but don't require root 
permissions. Such tasks include
  -- Making device nodes
  -- Changing ownership of files
  -- Changing group ownership
Note that fakeroot(1) does not give a user actual root permissions, it merely
enables a user to do these tasks in a special shell. Regular files are created
on the filesystem when device nodes are created, and ownership data is stored
only for the shell session. A fakeroot(1)ed user has no more permissions than
he or she has during a regular session. Note that also the device nodes etc
yA fakeroot(1)ed user has no more permissions than
he or she has during a regular session. Note that also the device nodes etc
you create only last for a fakeroot(1) session - it isn't persistent. 
However, tar and similiar utilties are 'fooled' into thinking that the 
files are special files and retain the information like device nodes, owners
and group, etc.

2) Building ipk's from source

To build an ipk package file from source, we'll use the hello-world
application. This application just does the standard "Hello, world!" greeting.
Not very useful, but it illustrates the various aspects of building the
package (as well as being simple enough that the actual program itself can
be ignored).

The completed and working hello world project is available here to which
those who want to see the final results can simply inspect the code.

But assuming we want to begin from scratch, perhaps just after unpacking the
source tarball, one would proceed as follows:

  -- Learn the build process
  -- Write the control file
  -- Write the rules file
  -- Write optional scripts
  -- Create the package

We'll go through each of these steps in turn.

2.1) Learn the build process

Every application is different. Most can get by with a simple 
   ./configure
   make
   make install

but this is often not the case if you are cross-compiling the packages (i.e.,
you often have to specify prefix directories, architectures, etc). Thus, one
should understand the nuances of building the specific package (i.e., what
options to pass configure, what variables to set to do a make, and what's the
prefix used so make install will do the install inside a directory which will
represent the final filesystem layout) first before proceeding. All the 
utilities to build the packages are shell scripts, and can fail with bizarre
error messages (if they do fail), or silently continue on after encountering
an error condition.

For our hello world program, we'll make a new directory and pretend that 
we've just unpacked it.

  mkdir ~/hello-world
  cp hello.c ~/hello-world
  cd ~/hello-world

Now, the build is simply calling the compiler with the right options.

  arm-linux-gcc -Wall -g -o hello hello.c

To install it, we copy hello to a suitable location on the filesystem, e.g.
/usr/bin.

To clean up we delete hello and any .o files that were created (none).

Thus we note this down and we're done.

2.2) Write the control file

The control file is an important file to the packaging tool. It describes
every aspect of the program. It tells the packaging tools what dependencies 
there are in the program (e.g., requires libc6, etc), what the version of
the program is (for versioning), what the name of the program is, maintainer,
description, etc. The name of this file is, surprisingly enough, "control".

ipkg-buildpackage expects the control file, as well as any other related
script files to be located in a subdirectory called ipkg. Thus we need to
create it.

  cd ~/hello-world
  mkdir ipkg

Now, we go into ipkg, and edit the control file.

  cd ipkg
  editor control

The syntax of the control file is simple. It's basically <tag>: <value>.
If <value> spans multiple lines, each additional line must be indented by one
space. The colon is very important in separating out the tag from the value.

The essential tags are, with the values we're using in parentheses:

Package		- Package name (hello-world)
Priority	- Is this package important in the image? Optional?
		  (most of the packages will be optional) (optional)
Version		- What version is this package? (0.0.2)
Section		- Where do we put this package in the list? (base)
Architecture	- What CPU architecture does this compiled package run on? (arm)
Maintainer	- Who created the package (i.e., who took the source code
		  and makde this package?). (your name here)
Depends		- What packages does this one depend on (none)
Description	- What is the description of this package? Note that there is
              both a short and long description - the short description 
              (approximately 60 characters) is essentially the first line of 
              the description (i.e., the value immediately following the
              Description: tag). The long description follows immediately 
              after, on the next line, indented by one space.

Here is the control file that we're using for hello-world:

-----cut-here-File=control-----
Package: hello-world
Priority: optional
Version: 0.0.2
Section: base
Architecture: arm
Maintainer: James Ng <jng@intrinsyc.com>
Depends:
Description: A simple "hello world" application.
 This is used to show how to build ipkg packages from source
-----end-cut-----

2.3) Write the rules file

The rules file describes to ipkg-buildpackage (and ipkg-buildpackage only)
how to take the source code, build it, install it in a temporary location,
and clean up. ipkg-buildpackage calls the file as:

  rules [build | install | clean]

Thus, you can write a C program, use shell scripts, or my personal favorite,
use make and abuse the POSIX shebang syntax :). The filename is "rules".

The rules file must be executable - the ipkg-buildpackage calls it with the
parameter describing which stage to perform. The rules file exists in the
ipkg/ subdirectory.

The stages are:

build	- Take the source code, and compile it
install	- Take the compiled source code, and install it to a temporary root
 	  filesystem.
clean	- Clean up

Now, ipkg-buildpackage calls "rules build" and "rules install", then copies
over the various control files and scripts necessary, calls ipkg-build to
create the ipk file, then calls "rules clean" to clean up. Your clean stage
does *NOT* have to remove the directory that you installed your application
in.

For hello, recall from 2.1 what each stage needs to do.

build)
	arm-linux-gcc -Wall -g -o hello hello.c

install)
	make filesystem root directory
	make usr/bin under that
	copy hello to usr/bin

clean)
	remove hello (remember we built it in this directory)
	remove the build stamp

Thus, our rules file looks as follows

-----cut-here-File=rules-----
#!/usr/bin/make -f
#
# $Id: rules.example,v 1.1 2001/07/26 15:36:36 oku Exp $
#
# rules for hello

# Make sure PACKAGE reflects your package name (in control). If it's
# different, it'll break.
PACKAGE=hello-world
# Do not touch this. This points to the "filesystem root" where you'll
# be putting your files (e.g. $(DESTDIR)/usr to put stuff in /usr, etc.
DESTDIR=$(HOME)/tmp/$(PACKAGE)
STRIP=arm-linux-strip --remove-section=.comment --remove-section=.note --strip-unneeded

build: build-stamp
build-stamp:
# Rules to compile your program go here. You can call the compiler, or
# you can do a configure, make.
	arm-linux-gcc -Wall -g -o hello hello.c
	touch build-stamp

install: build
# Rules to install your program go here. You can manually install it (like this)
# or go and call make install. Please note that you MUST use $(DESTDIR) - 
# and create your filesystem directory structure from there. Otherwise
# ipkg will NOT pick it up!
	rm -rf $(DESTDIR)
	mkdir -p $(DESTDIR)/usr/bin
	cp hello $(DESTDIR)/usr/bin/
	$(STRIP) $(DESTDIR)/usr/bin/hello

clean:
# Clean up goes here
# This is called after making and installing the packages, and after the
# ipk is made. Use it to clean up after yourself (removing *.o's, calling
# make clean, etc).
	rm -f build-stamp
	rm -f hello
-----end-cut-here-----

Several important notes:
-- Remember to chmod +x rules!
-- ipkg-buildpackage will expect your filesystem root to be ~/tmp/<package name>
   where <package name> is what you defined in the control file. If they're
   not the same, you'll get an empty package.

2.3) Write the optional script files

There are 4 optional script files that can be run at strategic times during
installation and removal, and one optional file describing configuration files.
These files exist also in the ipkg/ subdirectory.

The file "conffiles" lists, using absolute paths, the location of every 
configuration file available. So if you have a package that has a configuration
file placed in /etc named foo.conf, and another file placed in /usr/local called
foo2.conf, your "conffiles" file will contain

/etc/foo.conf
/etc/foo2.conf

The 4 optional scripts run at strategic times during the install and removal
of packages. These can be used to initialize the initial environment, do some
post installation fixups, etc. The four scripts are preinst, postinst, prerm,
and postrm.

The scripts are executed in the following order, starting with the appropriate
ipkg command

> ipkg install <package>

... ipkg searches package lists for <package> and downloads the appropriate 
    file ...
... ipkg unpacks ipk file ...
preinst script (if it exists) is run
... ipkg unpacks the data tarball ...
postinst script is run (if it exists)

> ipkg remove <package>

... ipkg checks ...
prerm script is run (if it exists)
... ipkg removes all the files in the package from the filesystem ...
postrm script is run (if it exists)

These scripts have to be executable and can be anything - programs, shell
scripts, etc. The only requirement is that enough is provided to actually
run the script (e.g., you shouldn't make these scripts makefiles, because
make isn't installed in most cases, unless you can guarantee that it is 
in your package).

Demonstration files are provided in the hello-world demo package that simply
echo what script is called. Simply build the hello-world demo package and
try ipkg install hello-world, and ipkg remove hello-world.

The main reason to use these scripts is to change the way the system works - 
when you install certain types of files, you have to update the way the
system works - vim for example alters several symlinks so /usr/bin/editor
points to it. Another common procedure is to install libraries, at which point
the program ldconfig must be run to finish off the installation and update
the dynamic loader cache. Or kernel modules have to have their dependencies
re-checked.

You would do these things both in the postinst script (so just after unpacking,
you make the libraries available), as well as the postrm script (so after
removing, there isn't a trace left of the old files). Sometimes though, the
prerm script would be the place to put the commands (such as altering the 
symlink to point to another program) before removing the program so that the
symlink works throughout the install process.

2.5) Build the package

Finally, we come to actually building the packages!

In the directory where you put your source code and ipkg files, run the 
complicated commands shown below to actually build the package. Remember, it
took a lot of work to get here, so it must take a lot of work to build the
final package from source!

  ipkg-buildpackage

If nothing went wrong, you shouldn't have any errors and you should end
up with an ipk file one directory up.

3) Using ipkg-build

If you have a binary package, it's easy to convert it directly. The
control file, plus any optional scripts (preinst, postinst, prerm, postrm), 
and optional control files (conffiles) are placed in the CONTROL subdirectory
in the filesystem root. There is no need for a rules file since there is 
nothing to build.

ipkg-build takes one required parameter and has one optional parameter. The
required parameter is the directory which has the filesystem, and the optional
is where to put the produced ipk. If you are in the root of the filesystem
image, then you can do a

  ipkg-build . ..

which will take the CONTROL subdirectory, package up the binaries and produce
the ipk file in the parent directory.

4) Using ipkg-make-index

Once you have all your ipk files gathered up, you have to create the Packages
file which lists all the packages, their dependencies and other information.
ipkg and other utilities will download the Packages file and use it to 
determine what can be installed (i.e., it's a catalog of all the packages
available from a feed).

First, you have to place your files on your feed. Get every file you want
to serve up that isn't simply a mirror of another feed into on directory. 
Then change to that directory, and do a 
  
  ipkg-make-index . > Packages

And messages stating that it's generating the index for each package should
be displayed. As ipkg-make-index writes the package information out to 
stdout, this can be used to append other directories to one Package file
(and thus, one feed). Note that ipkg-make-index must be run from the 
directory the base of the feed is in - the other directories must be 
accessed relative to the current directory.

5) I-Linux 4.0 Notes

Most of the ipk file building is automated through the use of makefiles and 
shell scripts. In fact, the main root makefile (the one in the binonly/ and
src/ directories traverse a list of subdirectories and calls each of them
with the following:

  make build
  make copy
  make clean

where build is used to compile the packages, copy is used to copy the resulting
ipk file from whereever it is to a predefined variable OUTPUTDIR, 

The BlueZ package requires access to kernel sources - thus it's readme file
should be consulted.

To add a package so it can be automatically built, add a directory either the
binonly directory (for binary-only packages), or the src direcotry (for
source packages). Add a Makefile that has rules for build, copy and clean -
most of the time, if it was done right, you'd have a makefile similar to:

-----cut-here-File=Makefile-----
default: build copy clean

build:
	ipkg-buildpackage

copy:
	mv ../*.ipk $(OUTPUT_DIR)

clean:

-----end-cut-here-----

Then modify the main makefile, and add your directory to the list of 
packages. That's all there is to integrate it in - when you go back to the
familiar/ directory and do a make ipks, your directory will be traversed and
the ipk build with the rest and tossed into the output directory, ready for
index making.

6) Converting to/from debian 

One of the goals of the Familiar project was to be binary compatible with the
ARM Debian port. This includes being able to use the Debian deb files in the
port and run them on Familiar. However, the ipk and deb fileformats differ
slightly - an ipk is a tarball, while a deb is an ar archive. The contents
of each are the same - three files, "debian-binary", "data.tar.gz" and
"control.tar.gz".

To mechanically convert a Debian deb file to an ipk file, simply execute
the following commands:

  ar x <package>.deb
  tar cvzf <package>.ipk ./debian-binary ./data.tar.gz ./control.tar.gz

(Although, it's preferable to actually edit the data.tar.gz file (it's the
programs as they'll appear in the filesystem) to remove things like docs and
manpages, and to strip binaries, then just repack it up as data.tar.gz).

Converting an ipk to deb is a less trivial problem. While there's probably
a way to go directly between an ipk to deb, attempts have failed. Thus, the
quickest way is to unpack the ipk file - create a temporary directory, 
unpack data.tar.gz into it, unpack control.tar.gz into a subdirectory named
DEBIAN, and run dpkg-deb -b <temporary directory> to build the deb file. You
should use fakeroot while doing this.

 $Revision$ $Author$ $Date$

Angstrom ist die Fortsetzung von OpenZaurus mit anderen Mitteln. Komplett ein- bzw. durchgelesen ist noch nichts. Ein erster Versuch scheiterte, vermutlich aber an Unvermögen.

• http://linuxtogo.org/gowiki/CollieInstall - Installationsanleitung
• http://www.angstrom-distribution.org/unstable/images/collie/ - Downloadquelle

• http://www.myzaurus.com/ROMupdate5.asp - ROM V3 + PC-Software Quellen und Anleitung

Bisher leider noch nicht zum Laufen gebracht.

• http://www.oesf.org/index.php?title=PdaXrom
• http://www.pdaxrom.org/?q=downloads

http://www.openzaurus.org/download/3.5.4/images/collie/

Das ist das Image das ich momentan auf dem SL-5500 verwende, und mit dem ich auch ziemlich zufrieden bin.

http://www.hentges.net/misc/openzaurus/index.shtml

speziell im Einsatz sind folgende Files:

initrd

CardFS

zImage

1. Die Datei zImage-collie-64-0-20060620045455.bin in zImage umbenennen. Die Datei, die sich im Archiv hentges-opie-image-de-collie_T1.tar.gz verbirgt, auspacken und diese beiden gemeinsam mit dem CardFS cardfs-opie-collie-openzaurus_oz3.5.4.1-rc4-opie1.2.1-T1.bin auf die CF-Card kopieren, und diese in den CF-Schacht am Zaurus stecken.
2. Ich habe gleich noch eine mit ext2 formatierte SD-Card bereitgelegt. Diese wird mein Home-Verzeichnis und zusätzlich installierte Programme aufnehmen.
3. Jetzt den Zaurus flashen.
   1. Stromkabel direkt anstecken
   2. Schalter am Batteriefach auf Replace Battery
   3. <c> + <d> Taste auf der Tastatur gedrückt halten und gleichzeitig den <Reset>-Schalter auf der Rückseite drücken. Das geht am besten mit der Nase vom Batteriefachdeckel. Insgesamt hat diese Aktion einen erhöhten Schwierigkeitsgrad.
   4. Beide LED's auf der Vorderseite leuchten. Falls nicht, vorhergehenden Punkt wiederholen, bis es klappt.
   5. Warten…
   6. Wenn beide LED's aus sind, <Reset>-Taste erneut drücken und Batteriefach schließen
   7. Schalter am Batteriefach wieder in die Normal-Stellung bringen.
   8. Kurz beten…
   9. Gerät einschalten.
4. Ich habe jetzt oben angeführte ext2-formatierte SD-Card bereitliegen, die ich aber beim ersten Start noch nicht einlege, da Opie erst einmal den Bildschirm kalibriert haben will. Und das Mount-Programm funktioniert ohne diese Kalibrierung nicht. Also SD-Card noch nicht einlegen!
5. Bei Abfrage root Passwort festlegen und über die Tastatur eingeben.
6. Bei der Frage ob ein CardFS gesucht werden soll beim ersten Durchgang no eingeben. no ist entscheidend, da so beim nächsten Boot-Vorgang die Frage wiederholt wird.
7. Nach der selbständigen Installation der Standard-Opie-Umgebung erscheint jetzt die Kalibrierung.
8. Nun kann die SD-Karte eingesteckt und gemountet werden.
9. Zeit für ein Softreset.
10. Bei der Frage ob ein CardFS gesucht werden soll diesmal ok eingeben.
11. Bei der Frage nach dem Ziel 3 (/media/card –> SD-Karte) eingeben.
12. Falls die Karte nicht frisch formatiert war, kommt nun die Abfrage ob vorhandene Verzeichnisse gelöscht werden sollen. (Bei meinem nächsten Neu-Installationsversuch werde ich mal no antworten. Jetzt empfehle ich ein ok.
13. Die Abfrage ob das auf der CF-Karte gefundene CardFS benutzt werden soll, mit ok beantworten.
14. Warten, denn jetzt wird wie wild geschrieben.
15. Die nächste Abfrage betrifft die Lage des root Verzeichnisses. Wer hier ok antwortet, bekommt es auf der SD-Card angelegt. Was ja eigentlich auch Sinn der ganzen Aktion war.
16. Et voila! Ist alles geglückt, präsentiert sich der Zaurus mit einer deutschen Bedienoberfläche (Opie 1.2) und reichlicher Softwareauswahl. Das Home-Verzeichnis von root liegt jetzt auf der SD-Card, mit hoffentlich viel Platz.

Vorraussetzung, auf dem PC mit dem der Zaurus verknüppert ist, ist bereits ein Gateway eingerichtet. In meinem Fall gibt es ein Gateway mit der IP 192.168.2.200. Der Zaurus soll die IP 192.168.2.201 erhalten.

1. Wir stecken den Zaurus in die Docking-Station, die auch an den PC angeschlossen sein muss, damit das entsprechende Device (Ethernet over USB) aktiviert wird.
2. Dann tragen wir unter Einstellungen –> Netzwerk und dem entsprechenden Gerät die IP-Adresse des Sauriers und des Gateways (siehe oben) ein.
3. IP des First-DNS nicht vergessen. Im Zweifelsfalle ist es die IP des Routers.
4. Fertig.

Als nächster Punkt macht sich die Paketverwaltung bemerkbar. Will man Software nachinstallieren, stellt man schnell fest, dass die im Hentges-Image voreingetragenen Quellen nicht mehr verfügbar sind. Den Spiegel der dort eingetragen ist, gibt es schlicht und ergreifend nicht mehr. Ich habe Paketquellen unter http://www.openzaurus.org/download/3.5.4/feed/ gefunden. Diese Quelle muss nun in der Paketverwaltung eingetragen werden. Wer übrigens gleich alles für Perl vorbereiten möchte, der trage auch gleich den perl-Feed in der Paketverwaltung ein.

Für mein leibliches Wohl habe ich folgende Pakete installiert:

joe
mc
perl
perl-modules

Und folgende deinstalliert, um etwas Platz auf root zu gewinnen:

kernel-module-bluez-2.4 
+anverwandte Pakete mittels:

ipkg remove -recursive kernel-module-bluez-2.4

Installation eines Paketes auf der SD-Karte

ipkg install -d sd -t /mnt/card/ <paketname>

Reinstallation

ipkg install -force-reinstall -d sd -t /mnt/card/ <paketname>

Deinstallation eines Paketes + abhängier Pakete

ipkg remove -recursive <paketname>

Symbolische Links zur Karte auffrischen/erstellen

ipkg-link mount /mnt/card

Für ein einzelnes Paket

ipkg-link add  <paketname>

• http://wiki.openzaurus.org/HowTos/Native_Development - Native (that is on the Zaurus) Development

Paketliste:

gcc-symlinks
binutils-symlinks 
make
libc6-dev
flex
flex-dev
bison
autoconf
automake
patch
patchutils
diffstat
diffutils
libstdc++-dev

verschiedene Pakete werden automatisch mitinstalliert:

gcc
binutils 
libc6
libstdc++

in Busybox enthalten:

sed
awk
grep
less

Der Empfehlung sed, gawk und grep zu installieren sollte man, zumindest mit meiner Konfiguration Hentges + 3.5.4.1-Feed nicht folgen. Die Installation per ipkg führte zu meiner dritten kompletten Neuinstallation.

Nach endlosen fruchtlosen Versuchen, fand ich dann endlich einen Hinweis, warum mein Hallo.c nicht kompilieren und linken wollte. Folgende Manipulation an der /usr/lib/libc.so muss vorgenommen werden:

/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

/* GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ---> löschen AS_NEEDED ( /lib/ld-linux.so.2 ) ) */

Danach funktionierte ein gcc hallo.c fehlerfrei.

Folgende Paket wurden noch nachinstalliert:

g++
cpp
cpp-symlinks

Hallo Welt! funktioniert. Allerdings sieht der Compileraufruf dazu so aus:

root@collie:~# cc hello.cpp -lstdc++

Irgendwie müssen also die Libs noch automagisch zugänglich gemacht werden. Ich bleibe am Ball.

• http://s91215199.onlinehome.us/zaurus/ - ZGCC GNU Compiler Suite Release 2.02
• http://www.uv-ac.de/opiedev/ - Handbuch für OPIE Development

• http://www.uv-ac.de/ipaqhelp/
• http://www.linux-magazin.de/heft_abo/ausgaben/2003/07/futter_fuer_kleine_saurier

Es gibt für Perl einen eigenen Feed bei Openzaurus. http://www.openzaurus.org/download/3.5.4/feed/perl/ Den trägt man in die ipkg.conf ein und kann komfortabel auf alle Pakete zugreifen.

Für den eigentliche Betrieb reicht es das Paket perl zu installieren. Aber das macht alleine noch keinen Spaß. Wer den Weg des geringsten Widerstandes gehen will, der installiert danach perl-modules um alle verfügbaren Module nachzuinstallieren, oder er wählt aus dem Feed aus, was ihm gefällt.

Anweisungen beziehen sich immer auf die installierte Basis -> Hentges Image mit cardfs 

ipkg install -d sd -t /mnt/card perl
ipkg install -d sd -t /mnt/card perl-modules

allgemein:
ipkg install -d sd -t /mnt/card <paketname>

Da ich am liebsten zu Hause per SSH auf dem Zaurus hacke, fiel meine Entscheidung schnell gegen einen grafischen Editor aus. Und als 8-bit Rookie editiere ich auf der Konsole mit Joe. In der Reinkarnation jstar besitzt Joe das identische Wordstar-Keymapping mit dem ich als Programmierer aufgewachsen bin. Syntaxhighlighting wird übrigens anstandslos beherrscht. Idealerweise werden natürlich die meisten anderen Sprachen auch unterstützt. Aber da hier niemand benachteiligt werden soll, kann natürlich jeder den Editor seiner Wahl benutzen. Im base-Zweig des OZ-Feeds sollte sich der passende finden lassen.

(Trotzdem bleibt natürlich Zeit für ein paar Seitenhiebe.)

Folgende Pakete werden zusätzlich installiert:

gzip

Das Anlegen einer Auslagerungsdatei ist notwendig. Gemacht wird das wie folgt:

root@collie:~# dd if=/dev/zero of=/media/card/tmp/swap bs=1024k count=64
64+0 records in
64+0 records out
root@collie:~# chmod 600 /media/card/tmp/swap
root@collie:~# mkswap /media/card/tmp/swap
Setting up swapspace version 1, size = 67104768 bytes
root@collie:~# swapon /media/card/tmp/swap

Auf jeden Fall muss noch eine C-Compilerumgebung installiert werden.

Und nachdem das alles erledigt ist, erfolgt der erste Test.

cpan

cpan> install LWP

Der Versuch scheitert grandios an einem make-Fehler. Ein

cpan> install Acme::Bleech

hingegen, wird anstandslos installiert. Ein Zeichen dafür, dass der Saurier nicht ernst genommen wird?

Viele Perl-Module gibt es ja auch schon fertig kompiliert für das jeweilige OS. Für OpenZaurus findet sich ein kompletter Zweig in den OZ-Paketquellen. Aber man kann auch für Debian erstellte Pakete verwenden. Problem ist nur, wie macht man aus einem .deb-Paket ein .ipkg-Paket. Der entscheidende Hinweis kam am Ende des ipkg-Howtos.

To mechanically convert a Debian deb file to an ipk file, simply execute
the following commands:

  ar x <package>.deb
  tar cvzf <package>.ipk ./debian-binary ./data.tar.gz ./control.tar.gz

(Although, it's preferable to actually edit the data.tar.gz file (it's the
programs as they'll appear in the filesystem) to remove things like docs and
manpages, and to strip binaries, then just repack it up as data.tar.gz).

Für alle die Ihren SL5500G schon immer mal „nackt“ sehen wollten.

So sieht er normalerweise von vorn aus…
… und so von hinten.
Das hat auch jeder schon gesehen.
Immer noch nichts ungewöhnliches, wir machen es spannend.
Wir lüften den Hut, schon ist er runter

Der Hut fliegt ins Publikum …

Jetzt gehts ans Eingemachte. Und eine Drehung.
Da geht aber noch was:
Ja natürlich die SD-Cardschachtplatine ist runter.
Und auch der BH landet im aufgeregten Publikum…
…darin eine kleine Überraschung.

Für eine größere Darstellung aufs Bild klicken. Höher aufgelöste Bilder auf Nachfrage. Alle Fotos dieser Reihe unterliegen der CC-Lizenz by-nc-sa — Frank Peters 2008/08/24 00:24