René Rebe

The first non x86 machine of mine was a 270MHz Ultra SPARC 5, that over the early years was tuned up a little with a 360MHz UltraSparc IIi, some additional RAM (to 256MB) and an Adapted SCSI controller with a U160 IBM disk. As the Adaptect controller has no OpenFirmware ROM I had to keep an IDE drive for booting, and thus just pluged a spare 2.5″ laptop disk over the floppy which just holds the /boot partition. Recently, however I noticed SILO look extraordinarily long to load while the IDE drive made very disgusting clicking sounds. I figured I’d better replace that drive soon before I have a non-booting SPARC and got a 512MB IDE flash module (after all I just need it to hold SILO, the kernel and the initrd. However, to my suprise, freshly formated with a Sun disklabel generated by fdisk the OpenFirmware would just hang during boot, not loading anything of SILO at all. After some back and forth with my T2 sparc64 recovery CD, the old fashioned regular disk and Google not spitting out anything useful for troubleshooting this problem, I just manually edited the disklabel to another CHS geometry than auto-detected and it just worked again. Puh!

For the records, the (Model=TRANSCEND) flash drive fakes to have CHS=993/16/63 and cfdisk happily fills this values into the partition label, however my former disklabel had 255 heads encoded and thus I manually tweaked the flash disks label to 255 heads, likewise: CHS=62/255/63.

Hope that helps others with ancient hardware.

For our 8-way Xeon with some >TB RAID array I had to find out what filesystems I would want to use on the logical volumes for some different use cases, and as a quick internet search did only brought up years old benchmarks I quickly done one for the T2 SDE magazine on a 2-way (dual-core) 64-bit PowerPC64 (G5) running Linux 2.6.24 - too bad Reiser4 did at least not like the 64-bit, big-endian machine too much and oopsed too much to yield timing data :-(

Once in a year I need to look into a DEB or RPM package, either to just take a look how other package software, or to extract a tiny tool otherwise hard to get built. Right now it was gptsync to synchronize the MBR and GPT partition types on a server supposed to just run Linux (e.g. without OS X consuming disk space).

rpm2cpio some.rpm | cpio -idv
dpkg-deb -x some.deb target-dir

Or without the dedicated packagers for DEBs:

ar xv some.deb
tar xvf data.tar.gz

For quite some time ExactCODE was shipping a Mac OS X TWAIN driver for Avision document scanners. However, with ExactScan version 2 the device support was now extended to cover many Kodak and most Visioneer and Xerox document scanners as well!

This includes, but not limited to the devices: Avision: AV121, AV122, AV210 C2, AV220 C2, AV610 C2, AV3200 SU, AV3750 SU, AV3850SU, AV8050U, AV8350, FB2080E, FB6080E - Kodak: i30, i40, i55, i65 - Visioneer: Patriot 430, Patriot 470, 9450 USB, 9650, 9750 PDF, Patriot 680, Patriot 780 - Xerox: DocuMate 152, DocuMate 250, DocuMate 252, DocuMate 262, DocuMate 272, DocuMate 510, DocuMate 520, DocuMate 632, DocuMate 752.

However, ExactScan 2 is not just about more devices: Under the hood it was completely redesigned and rewritten from scratch to allow monitoring the current scanner’s hardware buttons and profile selection and perform scans to be invoken by a fingertip on the scanner.

Also new are a bunch of ExactCODE’s image enhancement algorithms for automatic and intelligent binarization of images for massive long term archiving, very accurate and fully automatic auto-crop and de-skew as well as faster sharpening, de-screening and more.

This way ExactScan matured from a classic TWAIN data source it was in version 1, to a full blown image processing suite that also runs persistently in the background to monitor scanner actions, interface with existing TWAIN applications non-the-less and comes with sophisticated, state-of-the-art image processing.

Designed for Apple’s Mac OS X.
Made by ExactCODE in Germany.

Update: Finally available!

As I usually use the PNM format as a very minimal container for image data to dump for debugging in low-level places (e.g. even drivers as it only requires a few lines of code) I missed the ability in Apple’s Mac OS X to display PNM files (apparently even the Photoshop CS2 does not support it!).

As I spend rather much time on some OS X code these days, I stuffed together a Quick Look generator plugin for any UTI (file type) supported by our ExactImage.

If you are looking for such a plugin let me know - I’ll also probably publish it later when I find some more time.

Finally my Neo1973 (advanced box) arrived. Finally, because I did not even expect it anymore. Not because they targetted beginning of 2007 to ship the initial prototypes, but because the people running the online store and shipment have been so unresponsible and did not answered a single mail asking on a status update. We where mostly curious, because we ordered early and the shop did not yet had the “no functional software” disclaimer and no color choice option. So we had to answer auto generated mails confirming “YES_I_DO” “know that there is no functional software” and which color to ship: “ORANGE”. But then there was a big silence - and apparently we thought the order would have been gone lost or whatever. But - well - now it is there.

Of course I knew the software is not ready, I even replied “YES_I_DO”. Actually I did not even care, because I’m going to use it for my own development. However, that it would be that incomplete, I did not dare to imagine: Depending on which image set you flash (2007.1 or 2007.2) you either get a little UI phoning capability, but unreadable buttons and fonts (2007.1) or no phoning, but better buttons and readable fonts (2007.2). No phoning due to a non starting gsmd. And on some actions, such as activating GSM with no SIM present and other variations the whole X server dies away. Ooops.

Even for images where a the gsmd is started, they usually (at least not for me for all the pre-built images I gave a try) did not even setup the ALSA mixer to route the GSM audio stream somewhere. And as there is not even an UI part to alter the audio level, yes. This mean you either have to use the built-in terminal or ssh into the phone to load ALSA settings in order to be able to communicate with the person you are talking with. Now both problems should be one-lines to fix, and I wonder why even after man years of development and nearly 1000 shipped phones this did not even happen?

13:18 < hhf423> so, here we go. the new SIM I have here gets accepted by the Neo
13:19 < hhf423> the not so funny part is that I do not get asked for a PIN. libgsmd-tool dialling works, though
13:20 < hhf423> oooh, i get asked for pin, the joy!
13:23 < woglinde> hhf423 hehe
13:23 < woglinde> dial 112
13:26 < hhf423> how do I crank up the vulume, I can hear nothing
13:27 < hhf423> something with slsa, no?
13:27 < hhf423> alsa
13:27 < woglinde> hhf423 alsamixer
13:27 < woglinde> m for mute/unmute
13:27 < woglinde> up down/left right
13:27 < hhf423> woglinde: where is that?
13:27 < woglinde> open console
13:28 < woglinde> type alsamixer

Additionally the closed GSM firmware of the Texas Instruments Calypso based chip has compatibility problems with most SIM cards from the year 2007. While my USIMv1 I use primary in my primary (functional) phone (Sony M600i) my second SIM I just got for testing the Neo phone is a USIMv2 which does work with the GSM modem at all. From the #openmoko IRC channel and their bug #666 it becomes obvious this is one of the biggest showstoppers for new users of the Neo1973 phone right now. Let’s hope FIC and TI can provide a firmware update in the future.

But if that is not all, the Neo has a rather short battery life right now, probably the reason why (at least my advanced) came with 2 battery packs. As the phone did not overlived the first night I explicitly turned it off the second, but still the battery was fully drained in the morning. Yes, while it was “software off”. Maybe the GSM modem was left on in the firmware was proposed as an answer on the #openmoko channel - probably, as I can not imagine the Philips power-management chip would draw that much energy.

Last but not least the GPS chip can not yet used due to no open protocol spec and no clearance to ship the binary blog from the manufacture, …

Well - that said it becomes clear why the OpenMoko company let you select:

Please note that the OpenMoko products are not meant for the end user and explicitly marked as Developer preview at this time. Read this wiki article to find more technical details of what you can and cannot expect of these devices. I have been warned!

Well any other company would probably be bashed badly with such a product, but - well - the OpenMoko is a shiny Open project. Well, almost. The driving force behind the phone is FIC, First International Computer, and it’s newly founded sub-company OpenMoko, Inc. Most development happens behind closed doors and closed IRC channels: #openmoko-devel and #openmoko-core can only be joined with a channel key. The hardware schematics are non-free and most of the time changes appear to be only communicated in the classic, one big PR event at a time fashion with counting news probabilites counting up in the channel:

Probability for major news utill next wednesday 70%.

Now while pointing out this mayor flaws in the #openmoko channel, you get badly bashed about beeing a troll, to go away, to be /ignored, … Now they care about their customers.

At last I like to point out that the OpenMoko folks are also not basing on existing open source code for their applications. With the focus on Gtk+, GPE would have been a natural choice. But the project decided to implement an own application stack from scratch, with custom Gtk+ widgets and applications - maybe to have some IP lock-in for their OpenMoko Inc. company?

For OpenMoko it can only be hoped they get their software stack into an better shape, because otherwise the “just average” phone hardware is of little use and not really an helpful promotion for Linux on embedded end user devics.

Update 2007-11-24:

Still not much progress update, The Rasterman is now paid by FIC/OpenMoko, while Harald Welte quit as technical project lead.

Some random daily IRC scroll-by:

17:35 < Writchie> Crofton: actually the “design process”, if it even exists, is completely closed.
17:35 * mwester still is stuck with a hammerhead.
17:36 < mwester> Writchie: the “if” is a big question when it comes to certain parts of the software ;)
17:36 < Writchie> and hardware
17:36 < buz_> mwester: even with the hardware i have my doubts
17:37 < Writchie> 9 spins of the board - gimme a break
17:38 < edistar> Writchie: 9? quite a lot..
17:38 < buz_> other companies churn out 2 phones a month
17:38 < edistar> buz_: lol.. but I hope the next generation will be faster..
17:39 < Writchie> not unless they get some engineering process
17:39 < edistar> Writchie: What does that mean?
17:39 < buz_> hiring some good industrial designers wouldnt hurt, either
17:40 < Writchie> chinese engineering teams do what you tell them - if you don’t tell them you can get anything
17:40 < CM> I think someone said GTA01 was designed by some guys in taiwan, but gta02 was done “in house”
17:40 < CVirus> in house ?
17:40 < CM> By OpenMoko
17:41 < oramirez> Hi, I am trying to install openmoko h3900 image, but it freezes at the booting. I have been searching for some work-around .. but I haven’t found anything.. any idea?
…
16:25 < borg_> abraxa_: i could deamonize neod and add dbus bindings and outsource the aux/power menu and the lock display, but i wont do it when neod will go anyway :)
16:26 < borg_> so it is like with every other application in openmoko, no information about the future of them at all.

As gone thru the media, Debian is retireing the sparc32 port. However, despite the lack of an upstream Linux kernel sparc32 maintainer, our T2 SDE will just continue to support sparc32 - so if you need an up-to-date and optimized distribution for your older SPARC boxes, or new ESA satelites just give T2 a try.

For the past 5 years I just used ReiserFS (3) for all file-systems, as it was the first and then fastest journaling filesystem that made it into the Linux kernel. However since then Ext3 made progress and with XFS and JFS new player hit the Linux kernel “game”, I recently gave the alternatives a little test-run and just wanted to drop my tiny, unnumbered notes on the topic.

First of all I should mention that I have quite an exessive workload - even on my laptop’s /home partitions. This is due to my full-system development with multiple complete root filesystems and deep ccache directories beeing created as part of my development with and on the T2 SDE.

Testing XFS (somewhere around 2.6.19) oopsed the kernel a couple of times already in the first hours, so I went on testing JFS. While JFS never oopsed in my testing it shared the same slightly slower initially performing on operations like “svn st” on the multiple-thousand files T2 working copy with XFS. JFS does not come with in-kernel log replay after crashes or power outage - the user-space fsck.jfs is needed to perform this job. This decreased in-kernel code complexity, however your distribution must support fsck’ing JFS, especially the root (/) partition if you want to use JFS on it. As the Ext2/3 family was way too slow on the multi million files partition, I kept using JFS for half a year. However, it degenerated significantly in performance over time to a point where it was no fun to work anymore. Right now I even cleanup temporary files as well as the resulting root filesystems sandboxes created over the past 6 months in oder to backup the whole partition and re-format with reiserfs (v3), but unfortunatle just wiping the ccache directories already took over an hour so far:


removing build/ccache-arm-1 ...
removing build/ccache-avr32-1 ...
removing build/ccache-x86-64 ...


and is still going on :-( with an average disk-load of just 300kB/s and and CPU load (of the Core 2 DUo @ 2GHz) of just 1%/0% … :-(

At least the disk-io while removing increased to 700kB/s, now - so I have the hope that removing the various complete systems (== the next million files to delete), becomes a little more performant.

I also tested reiser4 which in contrast to to XFS did not oops and showed quite a performace increase over reiser (v3), however with reiser4 not beeing in the mainline kernel and the still ongoing cleanup and rewriting and uncertain future, I rather do not put my data at that risk. It’s on-the-fly compression however would probably be a nice benefit for the laptop HD and the many plain/text files resulting while compiling whole systems.

I wanted to review the historically cumbersome endianess conversion for our ExactImage for some time now. Thanks that the good old C macros (and the various variants of it) annoyed me enough to finally do so. What we now have in our “exact-base” repository is a C++ template setup that can be used to either define variables that have a specifc endianess in memory - probably because the composed structures are read and written as part of a externally defined format (such as BMP :-) - or to explicitly convert as in former times, just with the syntactic sugar of C++.

Using the template in packed structures is as easy as:


/* Size in bytes of the bitmap file */
Exact::EndianessConverter < uint32_t, LittleEndianTraits > iSize;


This defines iSize as ‘unsigned 32 bit’ with little-endian representation in-memory.

The next handy thing this Plain Old Data template avoids, is accidently messing with the data. As the type is incompatible with the usual ‘uint32_t’ it can not mangled. hWile the assignment operator is overloaded to store the data in the indended order, the cast to type passed to the template yield the swapped value, so straight-forward code just works:


#include < iostream >
#include “utility/Endianess.hh”

int main() {
Exact::EndianessConverter < int16_t, Exact::BigEndianTraits > test;
test = 0×1234;
std::cerr << "sizeof: " << sizeof (test) << std::endl
<< "value: " << std::hex << (int32_t)test << std::endl
<< "in-memory: " << test.value << std::endl;
}

Prints out:

sizeof: 2
value: 1234
in-memory: 3412

Checking the actual native endianess is as easy as:

if (Exact::NativeEndianTraits::IsBigendian)

And explicit conversion done like this:


Exact::ByteSwap < BigEndianTraits, NativeEndianTraits, uint16_t > ::Swap (some_data)

The whole source is available under the terms of the GPL!

With the ongoing T2 System Development Environment efford, I wonder if we do not only build up an awesome tool to create customized systems and appliances, but also a more and more complete, generic Free and Open Source reference map.

The nearly 3000 (still increasing quickly) packages of T2 generically describe where the software comes from and includes meta-data like: verbose overview, author, license, supported architectures, kernels among others and the packages are not cluttered with branding or other unnecessary patching. The packages are left vanilla as the up-stream author intended it to be and only patched where needed to get the source code actually build.

The term “generic Free and Open Source reference map” mostly came into my mind when I noticed that we more often get packages that are not even listed on Freshmeat.net nor part of other major Linux distrubitions. And the T2 packages are just soo clean and lean, just take a look into one yourself, the just added ipmiutil for example :-)

To get a complete list just take a look at the T2 package matrix listing.

I think putting some efford to setup a search and browse engine around this meta data might really worth the effort, promoting it as uncluttered “Free software map”.

A last note: Don’t let other’s distributions high package numbers confuse you, in T2 the 3000 package number refer to one package for a single piece of software, and not like 4 or more in other Linux flavours, such as -devel, -doc, … So one would have to strip this split packages from the published numbers of other distributions such as Ubuntu, Fedora, SuSE or Debian when comparing raw-numbers.