Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - iamasmith

Pages: [1] 2 3 ... 8
OpenBSD / Sd And Sdio Support Coming Into Openbsd
« on: June 05, 2006, 01:26:21 pm »
In case you didn't notice the latest kernels built on the i386 now contain SD storage support for some SD controllers including the Ricoh 5C822 popular in certain laptops. (including my Dell Inspiron XPS/2 ).

Uwe is working on SDIO support now so it seems to be reasonable to expect that we may possibly have proper SDIO support on the Zaurus when the SD support eventually gets enabled.


Hardware Mods / Refitting Cf Card For Sl-c3000
« on: May 31, 2006, 02:26:20 pm »
This is a walkthrough of the process.

Do NOT try this unless all of the following criteria are met.

1. You don't care about the Warranty of either the device or the card.
2. You have a single screwdriver that will fit the screws of the Zaurus (they are all pretty much the same).
3. You have a soldering iron and skills necessary to use it.
4. You are really so driven to do it that you have to do it.

Do NOT complain to me, Sharp, your vendor or anyone if you break it badly.

Quite probable pitfalls..

1. You have chosen a card that has slightly higher power requirements than the Microdrive.. will cause failures immediately. Note, a working card in the CF slot does NOT mean a working card inside the Zaurus.
2. Your card may fail much quicker than the Microdrive - Trisoft had a card fail within 1 week of fitting it.
3. You may well strip the screws on the PCB of the Zaurus when removing it.. those robots at Sharp screw em in hard and you MUST have a screwdriver that fits exactly.
4. If you are particularly 'cack-handed' or have a screw driver that doesn't fit then the screw driver may slip and gouge a fairly important part of the unit.
5. You could crack the board.
6. You could zap components with static off your body.
7. You could seriously frustrate yourself

OK.. enough of the warnings, here is the nitty gritty.

Remove all obvious components from the base unit..

* CF Blank, Battery Cover, Battery, Stylus, SD Card Blank an Service Console Gromit from the back of the unit

Remove all the screws. Be particularly careful not to lose the screws at the base of the battery compartment inside the unit.

Note all screws are exactly the same so there is no need to ensure that you have them noted for replacement in the same holes.

With the utmost care remove the back housing.. it may seem to come free from the side nearest the SD slot first. Once it is free like this lift the side nearest the battery compartment (the other side is anchored by the earphone socket) and the back should come free without undue force.

Take a close look at the main board. The two Marked A hold the board onto the mount. The two Marked B hold the CF housing onto the other side of the board. At some point you need to take them all out, if they will easily unscrew at this point then do it. If not I will suggest a tactic after removing this board.

Now note the area marked C, this varies from Zaurus to Zaurus. some may have a wire soldered here with enough slack to allow removal of the board. If as in this case there is a Copper Foil strip soldered to the unit then you must unsolder it before removing the board.

Note that each screw has a 'copper track' artwork arrow beside it on the PCB, you will use this to reference their replacement later.

Fold back the board which should now come out quite easily being extremely careful not to damage the ribbon cables attaching it to the screen and keyboard.

remove the two flat screws from the SD controller daughter board and remove the daughter board. If you need to apply pressure to the board to do this use something as a stanchion on the other side of the board. I simply placed the CF blanking plate under that area whilst doing this.

This should now lift off.

The next step is to remove the plastic housing for the CF card which has 2 clips and 2 hooks and if you didn't remove them earlier 2 screws (previously marked as B ). If you had trouble eariler then I suggest that you get the SD Card blank, apply a little tape to it and adhere the tape to the Microdrive so that it holds the SD Card blank under the area where the screw is. You should be able to apply a little more force with the screwdriver now without fear of straining the board.

Now simply replace the Microdrive with your chosen card...

 [ Invalid Attachment ]

Now reassemble in reverse order, cross your fingers and do the software engineering bit (I class partitioning the device etc in that area).


OpenBSD / Upgrading To Faster Cf Card
« on: May 27, 2006, 05:57:15 am »
OK, I have taken the plunge and ordered a SanDisk Extreme III CF card (133x card) that has ~20MB/sec Read and Write speeds with the intention of replacing my internal 4Gb Microdrive on my Zaurus.

I chose this card because it seems to offer good value for money (about £140 GBP in the UK now), top performance, and a 10 year manufacturers warranty.

Note that there is a Transcend 8Gb card also available for about the same price now, however, the warranty isn't lifetime it is 1,000,000 write cycles and the operational temperature is lower.. I decided to err on the side of caution therefore and go with this card which is known to have write spreading technologies and may yield a considerably longer life (maybe).

I also didn't need the 8Gb version because all my Multimedia stuff is on my iPod.. I prefer to do it this way then at least when the battery is dead from listening to music and watching movies I still have my Zaurus

I believe the write levelling on this card will probably (even with constant running) see out the life of this Zaurus but I guess that only remains to be seen.

When the card arrives I will do some benchmarks and provide some information on runtime with both the original Microdrive and this card fitted since the power consumption is also supposed to be a fraction of the Microdrive.

Benchmarks will probably come first since I can perform those with the card in the additional CF slot.

but daaaaamn, I'm going to ruin my 'uptime' figures. I get disappointed if I have to reboot it more than once per month

More soon,


(btw. in case you are wondering why I have been quiet here it's because my Zaurus 'just works ' and does everything I need it to at the moment... currently it's even running Ruby on Rails with MYSQL - it will be nice to see what performance is like with the new drive for this)

OpenBSD / Xdm Login From Windows Machine
« on: April 01, 2006, 06:23:30 am »

For a while now I have wanted to be able to simply run an X server on a Windows machine periodically to access the Zaurus in the hope of having more screen real-estate. The main stumbling block has always been that there were no quality free X servers that I could install on machines without licensing for each of those X servers.

Another thread got me started on using X/deep-32 which is now free and offers a good X11R6.5.1 server for installation on Windows.

I have been running a moinmoin Wiki on my Zaurus for a while now and have both the X/deep-32 installation and files present on the wiki pages for download so that they may be easily accessed for installation on a Window machine without carrying them around on seperate storage. You could use this or apache to host the files... this side of things I'm not going to go into.

What I will discuss are the minor settings required to get xdm login running from the X server.

Step 1, configuring xdm for xdmcp

Firstly it should be noted that the default xdm configuration on OpenBSD runs a local X server and services a login on the local display. This isn't what we are interested in here so the first thing is to disable the local server.

Edit the /etc/X11/xdm/Xservers file, you will find a line that looks like this..
Code: [Select]
:0 local /usr/X11R6/bin/X
comment that line out with a # and save the file.

Now we must configure the xdmcp chooser..

edit /etc/X11/xdm/Xaccess file and add a line (you may want to position this line near the similar, commented out line, this is a matter of preference)..
Code: [Select]
*                 CHOOSER NOBROADCAST
I choose to use NOBROADCAST because I only want my own X server to show the Zaurus and I don't really want other clients running xdmcp to spot the Zaurus and attempt to login there.

Finally I created two scripts to be run by root because I didn't want to run xdm constantly from startup.. if you do want to run xdm constantly then simply specify the -tcpPort 177 as opts in /etc/rc.conf. Here are my 2 scripts.
Code: [Select]
if [ -f '/var/run/' ]; then
echo XDM maybe already running /var/run/ already exists..
xdm -udpPort 177
Code: [Select]
if [ -f '/var/run/' ]; then
kill `cat /var/run/`
rm /var/run/
echo XDM wasn\'t running

Step 2, configuring X/deep-32 for access

Install and run X/deep-32.

On the X-server menu select X-server options and go to the XDMCP page.

Deselect the broadcast options for XDMCP and in the section X-Deep/32 Local XDM Chooser select XDMCP by Query Host then type in either the hostname or IP address of the Zaurus. Note that you may need to set up name resolution either by hosts file on the Windows box or by a name server if you are using a name.

OK, that's it...

If you startxdm now and then start X/Deep32 you will should get an OpenBSD login screen.

Additional tip, if you are using an environment such as xfce4 on the Zaurus and you want this to be active under xdm rather than just on the Zaurus console create a .xsession file in the user's home directory that starts the environment. This is a good place to put in profile type statements also that you may want to use to configure the environment... mine looks like this...

Code: [Select]
export TERMCMD=aterm
export LANG=en_GB
export PS1="\h$ "

(TERMCMD is used by xfterm4 to select the desired term application, LANG I am using to select the en_GB dictionaries for ispell from AbiWord but it does cause PERL to complain... PERL_BADLANG=0 stops perl complainiing, I haven't seen a downside to using the BADLANG env variable yet. PS1 sets my prompt and finally the startxfce4 command starts my xfce4 environment).

 [ Invalid Attachment ]

Apologies for the screen shot quality, at 1920x1200 the files are huge unless I reduce the quality considerably.


OpenBSD / #xdm Login From Windows Machine
« on: April 01, 2006, 06:22:33 am »
had some database error on posting, pls ignore this

OpenBSD / Resizing Windows And Installiing Openbsd After
« on: March 24, 2006, 08:58:45 am »
This is just a note for those of you that potentially want to have an OpenBSD i386 system to use alongside your Zaurus but want to keep it on the same machine as Windows.

I did this recently with a laptop because I really didn't want to wipe everything off that laptop and reinstall it but I needed something to do some development on that had PCMCIA slots. - I can report that it worked for me.

Basically this is just to state what 'worked well for me', if you choose to follow this path though be aware that I don't warranty the procedure, the authors of the tools don't and if you break things (oh I like this phrase coming up) 'you get to keep both halves'.

Firstly, if you have read Absolute OpenBSD which was written several years ago the book gives a convoluted example for creation of a multi-boot system based around an 8Gb limit on disk, I can confirm that if your system has true INT 13h EBIOS calls then you can actually boot from a partition well beyond that 8Gb limit.

Furthermore the book recommends looking at a boot manager called gag and gives the old URL. Gag is now located at ''  and can be installed from a bootable CD (iso is in the zip file now) - which suited me fine because I didn't have a floppy disk on the laptop at all.

Finally, in my case the original Windows installation took the whole 80Gb disk. I didn't want to reinstall it and was fuming at the thought of spending £40 on some partition resizing tool that I would use once. I used an OliveBSD CD ( which is an OpenBSD 3.8 Live CD (takes ages to boot but it works) to dd the entire disk (/dev/rwd0c) to an NFS share on another OpenBSD box - if you don't have another OpenBSD box then think carefully since there are some size limits for files over NFS2 - NFS3 relaxes those limits. Then I used qtparted from a Knoppix 4.2 CD to resize the Windows partition (resize and then select commit to apply the changes) - the Knoppix 4.2 distribution has a tool that moves data and resizes the NTFS file system before resizing the partition - this seems to work fairly well but ensure you have a good backup.

When you install OpenBSD if you choose not to use the entire disk you will find that 'boot' is installed inside the OpenBSD partition. This makes it convenient to use with GAG and doesn't disturb Windows at all.

Windows of course has a secondary stage boot loader in the Windows partition to which gag can chain so your multiboot should properly boot Windows too.

Gag is really simple to install, burn yourself a CD, boot into gag, configure it and write the config to hdd. You can then reconfigure gag later on without requiring the CD since the gag configuration stuff is all in the boot manager. Gag actually works so well that I gave up using the rather sexy boot selection stuff in my BIOS on my main machine that allowed me to change boot drives and started using gag configured to boot operating systems on different drives. - That machine can now boot OpenBSD from the first SCSI drive, Windows from a second SCSI drive and chains onto GRUB to load Gentoo Linux from a second IDE drive (primary ide drive is Windows archive - note grub had to be reinstalled inside a partition instead of onto the MBR of that drive).

So there you go... not instructions per-se, just reporting success with this set of tools so if you are hunting round for tools to do some of these tasks I suggest that you have a look at qtparted and gag - OliveBSD is also a good thing to have.


OpenBSD / Maintaining Sanity With The Ports Collection
« on: March 13, 2006, 07:34:15 am »
I thought I would offer up my build environment for people to consider because it gives a little flexibility in maintaining the ports collection both on your Zaurus and on your desktop OpenBSD machine.

The idea behind this build environment is that you can maintain ports trees with arm and i386 binaries present in the trees and only have to lose the object files when you need to update from CVS. The advantage of this is that if you have a build that mostly completes on the Zaurus but fails part way through you can try the same build on the i386 desktop machine without having to clean the build directory of arm binaries - that way you can return to the zaurus build later and save a lot of time rebuilding.

The build environment uses shadow directories quite heavily to avoid pollution of the cvs - which is maintained pristine so that normal cvs updates will keep you in sync with the latest -current environment. The main dependency of the environment is that you have a partition that you can mount in the same location on both the OpenBSD desktop system and the Zaurus. I achieve this by having an ffs partition mounted on the desktop machine at /obsdarc which is shared out by NFS and mounted to /obsdarc on the Zaurus.

Step 1.

Prepping the environment on the desktop machine...

Create a directory structure like this...

cd /obsdarc
mkdir -p {cvs,zaurus,ports-persist/{distfiles,packages}}

The idea behind the ports-persist directory structure is that we shall maintain a shared location of downloaded sources (distfiles) and a shared location for output packages since the output location is broken down by architecture this does not represent a problem for us. The advantage here is that when the source shadow trees are cleared we keep our build packages and previously downloaded source files.

Step 2.

Check out cvs to the cvs location as follows...

I use a mirror in Germany for my source tree and have a simple file called /obsdarc/cvs/cvsenv containing..


Create yourself a suitable file containing the cvs location and checkout the CVS as follows...

cd /obsdarc/cvs
. ./cvsenv
cvs co ports
cvs co src
cvs co XF4

The above cvs example is checking out the whole OpenBSD source as well as the ports tree... you may want just the ports tree but this build environment works for all if you choose.

Step 3.

Create some update scripts.. I have 3 scripts called, and

Firstly the script...

#Recreate main location shadow directory
rm -rf $MAINLOC/ports
mkdir $MAINLOC/ports
lndir $SRCLOC/ports $MAINLOC/ports
cd $MAINLOC/ports
ln -s $PPLOC/* .
#<Apply Patches>

#</Apply Patches>
#Update secondary location for Zaurus
rm -rf $DUPLOC/ports
mkdir $DUPLOC/ports
cd $MAINLOC/ports
cp -R * $DUPLOC/ports

This script is the basic building block, you can assemble the script however you like for sys and XF4 if you choose to implement them too by simply changing the ports location to src etc.... below is an example of patches that I use from my shadowpatch-sys script... (note that the final cp -R is critical that you use uppercase R so that symlinks rather than files are copied).

#Recreate main location shadow directory
rm -rf $MAINLOC/src
mkdir $MAINLOC/src
lndir $SRCLOC/src $MAINLOC/src
#<Apply Patches>
cd $MAINLOC/src/sys/dev/usb
cp $DRIVERS/Kern.visorpatch/uvisor.c-ajs-clie.patch .
mv uvisor.c
cp uvisor.c
patch -p0 < uvisor.c-ajs-clie.patch
cd $MAINLOC/src/sys/arch/zaurus/dev
cp $DRIVERS/Kern.ztsrotate/zts.c.rotationpatch .
#</Apply Patches>
#Update secondary location for Zaurus
rm -rf $DUPLOC/src
mkdir $DUPLOC/src
cd $MAINLOC/src
cp -R * $DUPLOC/src

as you can see in this snippet I am using a location under /mnt/obsdarc called drivers to hold my private patches which I am applying to a copy of the file taken from the link.. I move the original link first then copy the file and in this manner the patch only updates the shadow directory and not the linked location (the original CVS). - also note the omission of the ln -s $PPLOC command in this version of the script.

As you can see these scripts maintain two shadow copies of the output locations such that you do not have to keep the build source on the Zaurus. Also note that the ln -s $PPLOC . command (in the ports script) is creating symlinks into the ports-persist structure so that it becomes shared between the two environments. You may therefore perform a build from the Desktop and then the Zaurus and the source files will already be available (note you want to remove that ln -s $PPLOC . command from any shadowpatch-sys or shadowpatch-XF4 that you may implement)..

on a final note for this step it is traditional to shadow link XF4 to /usr/Xbld so implement any shadowpatch-XF4 to link to that location.

Step 4.

Run those scripts..

Run the scripts that you created and you should have a directory structure present on your desktop that you can build from (for the src and XF4 trees too if you chose to implement those scripts).

You should also have a set of shadow directories located in /mnt/obsdarc/zaurus.

Step 5.

Create the Zaurus hookup..

Mount the volume to the same path as the desktop using nfs.. in this scenario I use /mnt/obsdarc

Now create the symlink locations as follows..

ln -s /obsdarc/zaurus/ports /usr/ports
rmdir /usr/src
ln -s /obsdarc/zaurus/src /usr/src
ln -s /obsdarc/zaurus/Xbld /usr/Xbld

Note that the initial directory structure for OpenBSD will have the /usr/src directory present so it is necessary to remove it.

Once these links are in place you may produce builds from the zaurus and since /sys is a symbolic link into the kernel source under /usr/src that link will take effect automatically.

OK, that's it...

Once set up you may periodically updated the cvs and simply run the scripts to shadow the directories and you will have immediate version sync for the sources for both the desktop and the zaurus.

One last thing that is worth mentioning... how do you tell which ports that you want to update between version sync (it is important that you do this)...

In the directory /usr/ports/infrastructure/build is as script called out-of-date. This script audits all the packages that you have installed and compares them against ports available in the ports tree producing a list of packages that need to be updated. If you have never done this before it may take a while to update everything reported using make update but it is worthwhile doing it after every cvs update to ports. (note that this script takes a helluva long time to run on the zaurus).

One final thing to note about the out of date script is that you may get this specific message..

Outdated ports:

devel/gettext                  # expat.4.0 -> expat.5.0
lang/python/2.3,-expat         # expat.4.0 -> expat.5.0

This message is telling me that gettext and python-expat are linked against version 4.0 of the expat library and that version 5 is available on the system. Ignore anything related to version 4.0 expat!

Version 4.0 expat is present in the ports system and all ports are built against that version. Version 5 libraries, however, are present in XF4... this causes the script to say there is a later version available. The ports system will never link against version 5.0 unless it is brought into the ports system and since 5.0 expat doesn't exist in ports this isn't going to happen. The official response to this is to ignore the out of date warnings for expat until the OpenBSD team decides how to cleanly handle this in the future.


Hardware Mods / 'self Powered' Hdds And Zaurus
« on: March 03, 2006, 11:40:09 am »
Many people would sacrifice that spare pocket in their bag (or preferrably suit pocket #2) for the ability to have 40Gb+ of USB storage that they could access from their Zaurus (preferrably with a real file system ).

I was pondering this a couple of days ago and set off down 'Tottenham Court Road' in London browsing the Electronics boutiques down there with a rather dubiuos hitlist of devices that I hadn't seen for sale much in this country..

1. CF 10/100 Ethernet adaptor (not in Tottenham Court Road.... ordered from Expansys finally).
2. Stowaway Full Size Keyboard - The USB one, no, NOT the Bluetooth one and not the IRDA one... I'm still working on the Bluetooth drivers OK! (glazed look from the sales person).
3. A Self Powered Disk Unit.... umm... NO not a bus powered drive... one with a battery.... yes I said a battery.... why? oh ok.... (he didn't really want to know why).

Item 3 I struck out on and was at that point extremely tempted by those rather sexy looking iPod Video units that come with 60Gb of storage (hmmm.... nice MP3, sits on your belt - don't need to revisit my tailor to get that extra heavy seam fitted to my suits). - I'm pretty sure that I could hack the partition table so I could fool the iPod into only using 20Gb and have a nice 40Gb ffs (BSD Fast File System) partition..that's not an issue...

Then a thought struck me...

iPods charge themselves through the USB port

This thankfully stopped me from buying another device without considering the consequences.

So... the big question is... do most of these USB OTG devices that are emerging that look perfect for the Zaurus start to stealthily draw from the Zaurus to charge themselves?? if so there is no advantage to them other than they will have enough juice onboard to spin themselves up.

Perhaps someone has done some testing... maybe some of the devices are configurable?

(anyway this isn't an invite for PM spams saying... so you want an external HDD then - we sell em... it's just a query over how Zaurus friendly they really are - the Gadget lust has cooled off on this device - I may buy something later if I decide that I actually need it rather than just want it).


OpenBSD / Socket 10/100 Cf+
« on: March 03, 2006, 09:33:51 am »
Since trying the USB 10/100 network adaptor I really, really, wanted a CF based 10/100 adaptor that I could use under OpenBSD.

The list of supported CF 10/100 adaptors on the Zaurus platform is fairly small (2 of them actually and neither is available in the UK). So I decided to purchase the only adaptor that seems to be available in the UK.. the Socket 10/100 CF+ which according to some information on the Socket web site ( worked with the Zaurus on Sharp ROMs with a slight tweak of /etc/pcmcia/config

Here is the adaptor compared to a cigarette package (regular Marlboro, not 100s) to give you an example of the size of the adaptor.

As you can see it's quite bulky and I really need to find a rugged little box for it since it cost me around £100 GBP and I don't want it busted (no I'm not going to carry it in an old Marlboro packet).

You may notice that the CF part of the card is quite long... my first test was to plug it into my old SL-C860 that is running Cacko at the moment just to see if it was indeed recognised.... here's a picture of the card in the SL-C860...

As you can see the card does protrude a little.... This is possibly deliberate to avoid any issues with mounting in Laptops that have funny shaped sides... ah well..

The card functioned perfectly on Cacko 1.23 (without mods to the pcmcia config file)... here's a screen shot of a Konsole under Cacko showing the remainder of dmesg and an ifconfig of the card.

 [ Invalid Attachment ]

OK, Linux dudes can stop reading here... the rest is about running it on OpenBSD.

firstly the official posting I made..

The card isn't recognised under OpenBSD at the moment but can be made to be recognised very easily using a couple of simple patches.

Simply inserting the card will result in the Zaurus pretty much saying.... oh, a PCMCIA card... here's what it is... (no driver attachment).

These two diffs apply to sys/dev/pcmcia/pcmciadevs.h and if_ne_pcmcia.c respectively, they define the appropriate product code for the card and the appropriate identification structure for the card (note the use of the non SOCKET Ethernet Vendor code - see the quoted posting for more info).

Patches removed...they have now been committed to -current

Following patch application the card will be recognised correctly... dmesg output looks like this...

ne0 at pcmcia1 function 0 "Socket, CF+ 10/100 Ethernet, 1.0" port 0x0/32, irq 137, address 00:12:0e:xx:xx:xx
acphy0 at ne0 phy 1: AC101 10/100 PHY, rev. 11

ifconfig ne0 looks like...

        lladdr 00:12:0e:xx:xx:xx
        groups: egress
        media: Ethernet 100baseTX full-duplex
        status: active
        inet6 fe80::212:eff:fexx:xxxx%ne0 prefixlen 64 scopeid 0x5
        inet netmask 0xffff0000 broadcast

and ifconfig -m ne0 (showing media options) gives...

        lladdr 00:12:0e:xx:xx:xx
        groups: egress
        media: Ethernet 100baseTX full-duplex
        status: active
        supported media:
                media none
                media 10baseT
                media 10baseT mediaopt full-duplex
                media 100baseTX
                media 100baseTX mediaopt full-duplex
                media autoselect
        inet6 fe80::212:eff:fexx:xxxx%ne0 prefixlen 64 scopeid 0x5
        inet netmask 0xffff0000 broadcast

I have tested (on OpenBSD) all of the media selections and they seem to be reliable for me.


Linux Applications / A Note About Libmpeg2 Support In Scummvm
« on: February 28, 2006, 05:27:40 am »
I have been playing with ScummVM 8.2 on OpenBSD and it works pretty well especially when SDL and scummvm are built with xscale optimisations.

I would, however, have liked to have the video support working well on Broken Sword 2 and have had this built into various test attempts on PDAXROM, Cacko and OpenBSD in the past and all have yielded extremely poor performance. I assumed that this was due to video bitrate of the provided mpeg2 files so when I found instructions yesterday (on the pocketscumm site) on how to re-encode these files I did so and found... it was still darned slow.

I then took a good look at libmpeg2 (also built with xscale optimisation) to see if there was any floating point stuff that could be optimised and I found that it actually comes with a player.

Running the player against these files produces perfect video, however, when run through ScummVM you get about 1 frame every 2 seconds.

Finally I took a look at ScummVM and found that ScummVM calls the render code from libmpeg2 and renders it internally to a buffer that it draws with a routine called drawYUV. It also attempts to time music playback against the frames that it emits to the display and introduces frame skip to attempt to synchronise music against video (in Sword2 the sound and video come from seperate files). This isn't a great way of doing this for a few reasons.

i. The libmpeg2 library still has to render all the frames anyway because mpeg2 uses a key frame and incremental update mechanism for rendering individual frames - non key frames therefore require incremental changes from the last key frame. So the hard work of mpeg2 rendering has been done already, all ScummVM is skipping is its output of the frames.

ii. In most X server implementations on the Zaurus the display is handled by a Shadow Frame buffer since the natural screen orientation is portrait. This means that libmpeg2 is rendering a frame to a buffer, the drawYUV command is rendering to shadow buffer and finally the X server renders the shadow frame buffer to the display.. this is a lot of information to pump out frame by frame (many buffer copies here per frame)

So unless somebody fancies rejigging ScummVM radically in the area of video playback don't expect to get these video cutscenes at a reasonable frame rate.


OpenBSD / About Running Openbsd Vs Other Distributions
« on: February 22, 2006, 04:52:14 pm »
This is a long posting and doesn't cover the whole story, any more would be a waste of time probably on my point because nobody would read it all. This hopefully will give an insight into OpenBSD but may not necessarily hint at all the appealing aspects of OpenBSD.

Some of the things that I say in here are going to provoke a response from GPL fans. Let it be known that I don't care to be drawn into a heated debate about the rights and wrongs of GPL. That isn't the purpose of this posting. GPL is an important consideration and I try to put the point of how GPL can effect the uptake (or not) of functionality produced in a seemingly free environment. Beyond that I have no concerns.

I like GPL for many reasons but I, and a lot of other folks, don't think it's a suitable free software framework for many things.

In short if you want to discuss the 'rights and wrongs of GPL' please do it on another thread. I may comment if I have the energy left to do so  

Many folk ask about OpenBSD on the Zaurus and what they could expect when running OpenBSD on a Zaurus.

There are some short answers which will probably give some people the information that they are after and there are some longer answers which hopefully will give the others what they are after.

Short answers.

General OpenBSD

The OS - identical to any of the other ports of OpenBSD. 'Out of the box' it will behave exactly as it does if you install it on your i386, Vax, SparcStation or whatever. - This may mean of course you need to do a bit of tweaking to have an appropriate environment for your tastes but the tweaking will be standard across all architectures too

man pages are also available for every user command, this isn't unlike Linux, it's just unlike most Zaurus distributions.

The build environment - identical to any of the other ports of OpenBSD. OpenBSD is in sync across all architectures so it will behave like it does on other architectures. There are a few exceptions to this when you get into using ports (build from source collections of software that come from third parties) in that some ports require a lot of work to make them run on ARM architecture due to inexperience or lack of interest on the part of the developer to make the product as fully portable as possible.

It isn't Linux - Linux is only the Kernel - most people running Linux run GNU/Linux which is the Kernel plus a set of utilities that define the environment, provide the commands and a lot of other things. OpenBSD has its own set of tools that under Linux would be provided by the GNU toolsets. Both OpenBSD and GNU commands give POSIX compliance where standards exist, however, the GNU toolset has extended many commands (for example rm -v (verbose), find -regex (regular expression match)) beyond the core of the POSIX compliance requirement - such extensions will probably not be available in OpenBSD (some others may) so software that aims to be portable should cater for these differences.

Licensing is a BSD license and not a GPL license - There are many differences between BSD licenses and GPL licenses, possibly the most radical is that you can build systems on BSD, customise it (modify Kernel etc. if you like) and distribute it without the need to provide source code. You must adhere to displaying appropriate copy-write messages if a particular module, subsystem or licensing clause requires it but you have that freedom. This makes it appealing for some commercial operations and it is one of the reasons that for example, Apple's DarwinOS can retain binary only components and strict control over their operating system - even imposing their own licensing on top of the BSD license because it is their own product. - Many people hate this about BSD, many people love this about BSD, I am ambivalent, it has some far reaching implications.

Answers related to usability that are of key interest to Zaurus users

It's slower than PDAXROM - PDAXROM and OpenBSD (on the Zaurus) are both built with Software Floating Point, however, PDAXROM uses a vector floating point library which outperforms the library used in OpenBSD on the Zaurus.

On OpenBSD default build uses no xscale optimisation for the bulk of the executables - The Kernel is compiled with -mcpu=xscale but the rest of the distribution is compiled (for compatibility with other ARM architectures) with no optimisations. - It is possible to set some environment variables prior to build that will enable xscale optimisations and you get much better performance when you do this.

QVGA is not yet supported on the X server in OpenBSD - The X server uses facilities provided by the zaurus_lcd driver which currently only implements 640x480 mode. - This is going to make gaming and probably video slower than you want it to be - if that's your main thing then OpenBSD is probably not for you.

Things that you take for granted in Linux such as BlueZ bluetooth, squashfs, cramfs and many other things aren't present in OpenBSD. Bluetooth is a big problem for a lot of folk. At the moment the slickest solution you can have is to get a second SIM card and a CF UTMS/GPRS modem for your dialup stuff.

Linux style /dev/rtc control doesn't exist, which means no APM sleep - lay-persons terms this means that you can't run a PIM application and expect it to wake the device at a certain time, there is no support in the OS for that level of control over the rtc alarms of the system. - It doesn't lend itself to being a PIM based system if you need traditional PIM type environments (it does rock at running Personal Wiki's though if that's what your bag is!).

It runs entirely from hard disk and of the three distributions that do this (OpenZaurus, PDAXROM for SL-C3000 and OpenBSD) it does this the best. It manages the drive handling effectively and rapidly, will suspend and resume cleanly and will flush unwritten data to the drive when the unit resumes if there was a difficulty doing this when the unit was suspended. This is one of the more appealing sides to OpenBSD, the kernel is clean, stable and well behaved - admittedly it doesn't get functionally enhanced too often but the emphasis is always on making it as stable and secure as possible.

It runs entirely from disk as mentioned above and does NOT support inbuilt flash or SD cards yet - supporting inbuilt flash would require jffs2 support and jffs2 support would require writing a BSD licensed (non GPL) driver to support jffs2. SD cards you can connect via USB or via a CF adaptor but the SD slot isn't supported yet. Looking at the comments in the Linux driver source - about how badly implemented the hardware is - I wouldn't be surprised if this never happens.

Now some longer discussions about pertinent issues

GPL and BSD licenses

GPL when strictly enforced (look forward to seeing a lot more of that) imposes a few restrictions on its use. One being anything that directly utilises GPL code (in various ways) becomes GPL too. i.e., Linux being GPL means all Kernel modules written using Linux source code are also GPL forever and must forever adhere to GPL, that license cannot be changed or revoked regardless of the writer's wish and source code must be made available to anyone requiring it should the product be distributed in any way.

GPL consumes other licensing and is contentious in the way that it prohibits the freedom to use its code in some ways. This is by design and I don't wish to debate the higher ideals of GPL, this is just plain fact.

The OpenBSD ethic with regard to what enters the mainstream product states that nothing shall enter the product that converts or makes the licensing ambiguous from a BSD license. Therefore, GPL software cannot enter the Kernel and various other parts of the OS.

Many enhancements to Linux including Bluez, squashfs etc. explicitly state that they are GPL - you cannot therefore take these components and integrate them into BSD without your distribution of BSD taking on a GPL license and being insubmissible back into OpenBSD for general use. Furthermore as a developer that has developed a GPL piece of code you cannot have a change of heart and change the license. It stands.

Many modules, however, state a primary licensing terms which are independent of GPL - stating some of the major clauses of GPL without stating that they will impose GPL license inheritance then go onto say that they may be used within GPL software. This is a nice way for developers to aim at total portability.

The OpenBSD community and the developers

OpenBSD is carefully managed through a core team of developers who implement many changes themselves if bugs or limitations are reported and will vet any submissions of patches for stability, impact and licensing on the product. Changes in OpenBSD therefore happen slower than in Linux.

The distribution is largely favoured by security specialists since the goals of OpenBSD are stability and security. Many systems prevalent in Linux including OpenSSH are developed upon OpenBSD and since the distribution governs how a system should be set up  (with which tools, startup, permissions, scripts etc.) OpenBSD can aspire to be 'secure by default'. This is something that cannot be stated of many Linux distributions and there is always an uncertainty when approaching a new Linux distribution as to if this important part of the work has been performed correctly.

More about the Kernel

The Kernel is monolithic - unlike Linux OpenBSD does not have loadable module support, instead all drivers are linked into the Kernel. This can cause a certain amount of bloat if a Kernel aims at supporting a wide range of hardware, such as may be the case with the i386 Kernel; however, it is more secure and offers more stability to avoid the issues associated with dynamic linkage of modules into a running Kernel and it also reduces some of the implementation complexity associated with driver presence particularly during boot (see Linux use of initrd's for module based SCSI drivers where kernel doesn't have SCSI driver linked in).

Focussing on stability, security and maintainability has allowed the developers to make the Kernel sources extremely clean and readable. They are liberally commented and even without these comments are coded with a fairly unambiguous style such that they can be read with a reasonable understanding on the first pass by competent developers.

The benefits of the way this Kernel has been developed are most evident in the ability to rapidly support new architectures and it is a goal to introduce new architectures purely from the standpoint of proving the portability of the Kernel. - this is one of the primary reasons that OpenBSD was ported to the Zaurus.

Instead of using procfs (which is available), system control is performed through a sysctl interface which allows the administrator to fine tune many elements of a running Kernel or to configure those elements for system boot using a file called /etc/sysctl.conf.

The Kernel has some interesting things built into it such as random stack allocation so that rogue software that potentially exploits stack vulnerabilities cannot perform in a predictable way.

Building things...

The base build system can cross compile for things like the base distribution (Kernel, userland tools, scripts and layout etc.) and XOrg, however, cross compilation is discouraged.

OpenBSD focusses on native build wherever possible for all elements of the operating system or ports.

No effort whatsoever has been made to make the ports system cross compile.

The ports system is a set of scripts and patching tools that build software packages from source and to qualify for inclusion in the ports system the software (patched by the ports system) must be stable, secure and not interfere with OpenBSD licensing as a whole.

The reason that cross compilation is discouraged is that it effects many things in building software.

Firstly cross compilation requires that the software being compiled doesn't have a build environment that prohibits it from being cross compiled or makes it extremely challenging to cross compile. An example may be that the build process builds its own tools to complete the build process and isn't mindful that it is being cross compiled. This may, for example, lead to a component required by the build process being built as an ARM binary that needs to run on the i386 type host that is actually performing the cross compile. This may sound trivial to fix but if you have 16 different architectures to consider in a cross compile matrix and an unknown complexity in each application then it can become prohibitive.

Secondly cross compilation can introduce subtle differences in the binary output. In fact it is true that the binary output for many targets using GCC tools is so radically different between versions of GCC to render the binary output totally unusable for certain purposes. Consider Dan Kegel's information on gcc/binutil/glibc  and Linux versions as an indication of sometimes how 'hit and miss' it can be to get a stable build combination for some architectures.

Remove the cross-compiler element and the resulting code generation tends to be less problematic but not completely.

OpenBSD raises the stakes a little with code generation by using the ProPolice extensions that reportedly only work with certain versions of GCC. The GNU team aim to make these work with GCC 4, however, to date they are only stable with GCC 3.3 (possibly other 3.x). ProPolice is aimed at introducing countermeasures to stack smashing code within the compiled code of a product such that a user may reasonably be able to take open source code with minimal analysis and assume that stack smashing exploits will be countered by the compilation environment. This is particularly useful in large projects.

For these reasons and potentially many others OpenBSD favours a native build environment which can be time consuming but as discussed can produce a more predictable output.


OpenBSD is typically at 3 versions at any one time.

OpenBSD -release is the snapshot of a stable working environment that is pushed out every 6 months.

OpenBSD -current is up to the minute CVS commits flaws, claws and all - typically this is what we have been running on the Zaurus because the best developments have come since 3.8.

OpenBSD -stable is what you want to be running in business production environments but paradoxically is the hardest to implement. OpenBSD -stable consists of OpenBSD -release with critical security patches and the easiest way to build this is via CVS by selecting the stable release branch of CVS. This is slightly harder than -current which day by day releases a tarball wrapping all changes.

OpenBSD / A Nice Surprise
« on: February 20, 2006, 02:19:43 pm »
I just bought a Sitecom LN-029 USB2 NIC having struck out on buying a CF based 10/100 NIC locally and deciding to spend the grand total of £24 at Maplins (uk electronic buff store) on a USB NIC. hehe.. even managed to persuate the guy at the store to open the box so I could see if OpenBSD recognised it as I had intended to get a CF NIC and didn't have the USB supported list with me.

Anyway, I though USB, it's got to be really slow and I certainly aren't going to get USB2 speeds out of it, however, here's the results of 2 transfers.

andrews@aslinhome ~ $ time scp pak1.pak mungo:quake/id1
pak1.pak                                      100%   33MB 423.5KB/s   01:19

real    1m21.767s
user    0m1.024s
sys     0m0.200s
andrews@aslinhome ~ $ time scp pak1.pak mungo:quake/id1
pak1.pak                                      100%   33MB 548.4KB/s   01:01

real    1m4.063s
user    0m1.064s
sys     0m0.180s
andrews@aslinhome ~ $

The first transfer was over my NL2511-CF WLAN CF card and the second one was over the USB NIC, it's actually pretty reasonable... certainly just cutting the overhead of the WLAN stuff from the transmission increases throughput quite a bit.

it's got me wondering what a CF based 10/100 card would be like though now

anyway I think I will be using this a lot for those long compiles now, certainly if nothing else my Zaurus should stay a little cooler than it was with the Wifi card in all that time.

- Andy

OpenBSD / Warning About Ports
« on: February 18, 2006, 09:26:59 am »
I don't know how many of you have actually built some of the stuff from ports like scummvm and SDL but I thought I should just mention something.

When you build Zaurus binaries from ports don't assume that they are being xscale optimised. They (I'm pretty sure about this) all being built as default arm binaries which makes them pretty slow, particularly if you have built things like ScummVM and libSDL.

You can 'hint' to the build system that you want xscale binaries by doing the following before you make a port.

export CFLAGS="-mcpu=xscale"
export CPPFLAGS="-mcpu=xscale"

in the case of libSDL this makes a significant difference in performance speed.

Ideally once you have started the make on the port and it has passed the configure stage you should be checking that the -mcpu=xscale flag is being included in pretty much all the compile statements that fly by.

Well worth a rebuild of a few things if you didn't do this

take note, if you just redo the make install it may look like the library has been replaced. it almost certainly won't have. you will probably have to do...

pkg_add -r -F installed tarball.tgz

Don't believe it until you see it being removed and re-added.

- Andy

OpenBSD / Anyone Interested In Prebuilt Bleeding Edge?
« on: February 14, 2006, 12:00:42 pm »

I have patched my Zaurus quite a lot since I put OpenBSD on it and submitted most of these patches here.

To list a few patches.. contains a fix to wsfb that correctly implements mode storage - there is a bug in the original driver where only the current mode was fixed up. In 640x480 screen mode a query of display modes via xf86vm queries would return 480x640. This patch fixes that. The original developer passes this behaviour off on XOrg issues - the XOrg issues that I know about are related to the GetViewPort extension which admittedly is still buggy - this isn't directly related to this issue. - Note that with this patch you will still need GetViewPortIsFullOfLies: True in ~/.xscreensaver if you are running it. - Longer term the original developer suggests that this will be fixed by XOrg fixing it..hmm. contains Caps Lock fixes that work in the Console and in X, the console fix is a Kernel patch to wskbd and the X patch is a fix to kbd_drv. The console  problem has been acknowledged by one of the OpenBSD guys and I expect that there will either be my patch or his own patch to correct the issue. The X patch hasn't been commended on by maintainer of the X stuff. contains a non Zaurus specific enhancement to the uvisor driver that may enable a sizable range of CLIE devices with OpenBSD. No acknowledgement as yet at all from the OpenBSD guys. Finally yet another patch (not posted here). It contains modifications to the zts driver to allow rotation to be implemented directly within the driver and also contains a command line utility to select touch screen rotation. This is to overcome the scaling flaw that effects OpenBSD on the Zaurus when the display is placed into Portrait mode. For a full description of the issue please read the thread. Again the X developer hopes to address this when OpenBSD finally adopts a speculative version of XOrg with new (note still being planned) extensions to support rotation handling for input devices. At the moment this I see as the cleanest workaround for the scaling issue since rotation can be applied directly to the zts driver without effecting the usb mouse driver that also runs through the same X driver.

OK, now the point of this message.

It is established that there is generally a lag in patch feed into OpenBSD because it's run by a core team and they want to QA and fix or dismiss patches for a variety of reasons.

It seems that particularly with regard to the X environment we may be in for something of a wait before we have some of the fixes implemented through the suggested channel of waiting until XOrg is fixed and does everything  - The maintainer has suggested that we will have xrandr support soon as a stopgap to some issue but we shall have to see what that brings with it.

I myself am enjoying the benefits of a Zaurus that runs a lot more cleanly in both the console and in X than with the stock distibution (subjective view of course) and have shared all my discoveries without even including the customary 'I was here and I fixed this' lines in the patches - in the end I just want to see these issues fixed and I don't care if they are fixed with my patches or somebody elses patches just as long as I don't have to wait forever for them.

So practically speaking I will probably patch every little annoyance that I come across on the Zaurus and it may be that some of these patches do get implemented in the distribution and some dont.

My question to you folks using OpenBSD on your Zauruses is this...

Do you want to accept a kernel binary that I will post periodically containing these fixes? I can post X drivers on this board without a problem but I think a prebuild kernel should be kept off these pages since it's too darned big and offroadgeek will be getting his guns off the rifle-rack if we really swamp these pages ().

If I do this then I can also place the X fixes up there too in binary form.

I will always include the patch source so that people can see what is going on and will probably patch and build each -current snapshot that emerges. In fact since I am using a Kernel based on a cvs sync rather than a snapshot the base kernel will be more recent anyway than the snapshots.

So what are your thoughts folks? Do you want this stuff posted somewhere so you don't have to build all that kernel stuff or do you just want me to post patches?

Incidentally running a custom Kernel doesn't rearrange your Zaurus in any way, you will simply either replace /bsd with the custom file or copy it to /bsd.custom you are then free to boot into either from the boot prompt. By default the boot prompt will boot /bsd. You can override this simply by typing an alternate Kernel name, you can copy over /bsd with a custom kernel or you can make a /etc/boot.conf to select an alternate configuration.

Anyway let me know what sounds good to you.

- Andy

Pages: [1] 2 3 ... 8