What would be nicer than a mobile phone with Linux system? Well there are available some phones with Linux but they're certainly not mainstream. New Mobile Linux Iniative (MLI) and Linux Mobile Standards Forum (LiPS) are going to change this. We're about to see the first mainstream Linux phone in near future.
For example MLI is focusing technically on fast booting, small memory footprint, power management, security and multimedia. Sound nice, but what are really the technical details? Does it say what components to use or does it allow manufacturer to choose the components? Does it require compability between the devices, are they building a new platform or just best practices? I tried also find out more about LiPS, but got nothing but high level non-technical talk. They mentions LiPS API and SDKs but nothing more about them. Let's assume they're allowing the basic solutions to be changeable and their API extended with POSIX and other standards provides a common platform. Sounds reasonable, doesn't it?
As I don't know any details about LiPS API we can assume it has some multimedia and phone APIs included. You could make an application which calls some function to send a SMS message and it works on another phone just by recompiling it. Nice. But wait a minute, how about the user interface? Can we standardize it or does they say you must use for example GTK+ or Qt to build your UI. Id like to see GTK+ based phones, some other prefers Qt. Unfortunately I'm sure they must choose between these two if they want easily portable applications. Or do they want it? Something makes me think they do.
From my point of view GTK+ is a better choice than Qt. There's many things that makes me think like that. First of all: licensing. GTK+ has LGPL which allows linking against closed source. Qt is GPL and requires that application which uses Qt must be also licensed under GPL (known as the viral effect). If you want closed source Qt application, you must buy a license from Trolltech. Secondly one little thing: Qt is C++ and can't be easily used on C apps without a wrapper. GTK+ is C and can be used in C++, there's also gtkmm which is interface for C++. Third: there's lot of GTK applications ready to be ported on GTK phone, see Maemo for a good example. Unfortunately I'm not the one who makes the decicions, but you might be one so choose wisely.
Monday, August 28, 2006
Thursday, August 17, 2006
Building iPaq kernel
I have advanced with the iPaq project and successfully compiled the kernel. For the build process I used cross compiling on my desktop system. The cross compiling itself is quite simple operation, but there's some little thing to take in acccount. We need only binutils, Kernel headers, compiler and glibc. So let's start.
Compiling binutils is easy, just "./configure --target=arm-linux", make and make install. It install required tools under /usr/local/ and creates directory arm-linux under it. Next we need kernel headers. Just make directory /usr/local/arm-linux/include and copy include/asm-arm from the Linux sources as asm to under it, include/asm-generic and include/linux as well. Then symbolic link from /usr/local/arm-linux/include to sys-linux.
Glibc I took from Debian repository, downloaded proper deb-packages, opened it (ar x package.deb), untarred the data tarball to temporary directory and copied the lib and usr/lib directories contents to /usr/local/arm-linux/lib. Another option is to compile glibc yourself from the sources but since I wanted to use Debian prebuilt binaries as much as possible and keep this as Debian based solution so this is the better way.
Then we need a cross compiler. We need gcc sources and compile it for arm using "./configure --target=arm-linux --disable-threads --enable-languages=c" and traditional make and make install. However I got problem with libc.so.6 and had to change contents of /usr/local/arm-linux/lib/libc.so (it's text file) to point to files under /usr/local/arm-linux/lib/ instead of /usr/lib/ (or wherever they point to). After that compiling was successfull out of the box. Now testing with the Hello World example (arm-linux-gcc hello.c -o hello) and see what file tool said about it. It should show that resulted binary is for ARM.
Finally the kernel. You must remember that we're cross compiling so we need to give some arguments for the make. First configuring the kernel "make menuconfig ARCH=arm CROSS_COMPILE=arm-linux-", making proper choices (SA-1110 and iPaq 36xx most important) and optimizing for embedded device. Saving the configuration, and finally "make ARCH=arm CROSS_COMPILE=arm-linux-". Never forget those parameters ARCH and CROSS_COMPILE. I did. I had to make some recovery (untar the kernel arcive again) to get back to proper architecure. I got the kernel compiled finally properly. The final result was 1.6 megabyte sized kernel plus the modules. But wait a minute, we have option to pack the kernel, so "make zImage ARCH=arm CROSS_COMPILE=arm-linux-" and (drums please) we got 760 kilobytes sized kernel. That's under a megabyte which was the target.
Next I'll try to build some system and make some minimal system image ready to be flashed to the device. It'll take some time, but what's the horry? Be seeing you.
Compiling binutils is easy, just "./configure --target=arm-linux", make and make install. It install required tools under /usr/local/ and creates directory arm-linux under it. Next we need kernel headers. Just make directory /usr/local/arm-linux/include and copy include/asm-arm from the Linux sources as asm to under it, include/asm-generic and include/linux as well. Then symbolic link from /usr/local/arm-linux/include to sys-linux.
Glibc I took from Debian repository, downloaded proper deb-packages, opened it (ar x package.deb), untarred the data tarball to temporary directory and copied the lib and usr/lib directories contents to /usr/local/arm-linux/lib. Another option is to compile glibc yourself from the sources but since I wanted to use Debian prebuilt binaries as much as possible and keep this as Debian based solution so this is the better way.
Then we need a cross compiler. We need gcc sources and compile it for arm using "./configure --target=arm-linux --disable-threads --enable-languages=c" and traditional make and make install. However I got problem with libc.so.6 and had to change contents of /usr/local/arm-linux/lib/libc.so (it's text file) to point to files under /usr/local/arm-linux/lib/ instead of /usr/lib/ (or wherever they point to). After that compiling was successfull out of the box. Now testing with the Hello World example (arm-linux-gcc hello.c -o hello) and see what file tool said about it. It should show that resulted binary is for ARM.
Finally the kernel. You must remember that we're cross compiling so we need to give some arguments for the make. First configuring the kernel "make menuconfig ARCH=arm CROSS_COMPILE=arm-linux-", making proper choices (SA-1110 and iPaq 36xx most important) and optimizing for embedded device. Saving the configuration, and finally "make ARCH=arm CROSS_COMPILE=arm-linux-". Never forget those parameters ARCH and CROSS_COMPILE. I did. I had to make some recovery (untar the kernel arcive again) to get back to proper architecure. I got the kernel compiled finally properly. The final result was 1.6 megabyte sized kernel plus the modules. But wait a minute, we have option to pack the kernel, so "make zImage ARCH=arm CROSS_COMPILE=arm-linux-" and (drums please) we got 760 kilobytes sized kernel. That's under a megabyte which was the target.
Next I'll try to build some system and make some minimal system image ready to be flashed to the device. It'll take some time, but what's the horry? Be seeing you.
Thursday, August 10, 2006
Backups
Keeping your files in safe is very important. I have lost some files because hard drive failure. How about to lost your embedded device? You also lost your files, notes and everything on the device. Backuping data should be done on daily basis. Why it's done so hard, could it be easier?
What should be backuped. Notes, music, documents, images & photos, movies, game records, preferences and everything on the device which does not come by default. However there's no point to backup installed applications but their settings should be. So is it enought to backup users home folder? It should be a safe start. Good system and applications should save their data and settings to the user's home folder, but there might be also a memory card which should probably be backuped as well.
The backup device. Usually you want to backup your embedded devices to the desktop machine. Fine, let's do so this time as well. However some clever people might have USB port on their devices and might want USB storage devices to be backup target, but let's forget it. We need a software on the desktop machine side. It should probably support different backup versions, easy restore and storing backups to external media such as CD, DVD and tapes. Files would be nice to be accessed on the desktop machine as well.
The backup progress I'd like to see is: attach the embedded device to the desktop, press a couple of buttons, backup done. What are the candidates? I think there's not really any ready to ship software for backuping Linux based embedded device. Simpliest we could have a script which copies home directory to predefined desktop machine path with date information. Restore would be copying data back to the embedded device. More sophisticated solution would be preferred, since we could have different operating systems for desktop machine and single script would not work. Client-server type would be nice, having server on desktop machine, embedded device would simply contact to the server, transfer files and ask for restore. Server would handle archiving data, choosing correct backup to be restored, store files to external media, show files and all kind of stuff. Server for multiple operating systems, standard protocol for clients to talk. And why not to backup desktop machines as well. There would be a nice project for somebody, anybody?
What should be backuped. Notes, music, documents, images & photos, movies, game records, preferences and everything on the device which does not come by default. However there's no point to backup installed applications but their settings should be. So is it enought to backup users home folder? It should be a safe start. Good system and applications should save their data and settings to the user's home folder, but there might be also a memory card which should probably be backuped as well.
The backup device. Usually you want to backup your embedded devices to the desktop machine. Fine, let's do so this time as well. However some clever people might have USB port on their devices and might want USB storage devices to be backup target, but let's forget it. We need a software on the desktop machine side. It should probably support different backup versions, easy restore and storing backups to external media such as CD, DVD and tapes. Files would be nice to be accessed on the desktop machine as well.
The backup progress I'd like to see is: attach the embedded device to the desktop, press a couple of buttons, backup done. What are the candidates? I think there's not really any ready to ship software for backuping Linux based embedded device. Simpliest we could have a script which copies home directory to predefined desktop machine path with date information. Restore would be copying data back to the embedded device. More sophisticated solution would be preferred, since we could have different operating systems for desktop machine and single script would not work. Client-server type would be nice, having server on desktop machine, embedded device would simply contact to the server, transfer files and ask for restore. Server would handle archiving data, choosing correct backup to be restored, store files to external media, show files and all kind of stuff. Server for multiple operating systems, standard protocol for clients to talk. And why not to backup desktop machines as well. There would be a nice project for somebody, anybody?
Thursday, August 03, 2006
iPaq in action
Looking through my old stuff and found my Compaq iPaq 3660. I have installed Familiar Linux to it some time ago, version is 0.7.something. The system is nice, featuring GPE and Linux kernel 2.4.19. Indeed it's better than the default Pocket PC system. But could we get better system running on it?
The device itself is featuring 206 MHz StrongARM CPU, 64 MB RAM memory, 16 MB ROM, touch screen, great connectivity by USB, serial and infrared. So the starting situation is quite challenging. What I'm planning is to set a new kernel (2.6 series), Debian based system and minimal X with Matchbox window manager, featuring GTK+. And of course some test application. Am I able to fit this all to 64 MB? And if possible some extra free space would be nice for extensions and extra applications.
First starting from the kernel. Taking latest 2.6 series stable kernel, optimizing it for handheld use, removing futile drivers, etc. I want as minimal kernel as possible. Under a megabyte would be nice, just dreaming of it? Debian and basic libraries, uClibc would be nice, let's replace traditional libc with it. Saved some preciciuous megabytes. Other required libraries. X takes some megabytes, Matchbox is slight enough, but GTK+ taking again some more memory. Still speculating, only theorical level. The next step: implementing all this.
The best way to compile for ARM target is to use Scratchbox. We have qemu emulator support or we may use the ARM device with sbrsh to compile for ARM. For most compiling operations qemu is sufficient. Scratchbox has proper debian devkits and all required tools to make everything to work. Everything is set up, next I'll start compiling things. Debian provides precompiled ARM binary packages, so I'll just get the kernel and missing packages compiled, build image and flash my device. It'll take some time. Until that, please report your devices running Linux, and what kind of Debian based solution you would like to see on it?
The device itself is featuring 206 MHz StrongARM CPU, 64 MB RAM memory, 16 MB ROM, touch screen, great connectivity by USB, serial and infrared. So the starting situation is quite challenging. What I'm planning is to set a new kernel (2.6 series), Debian based system and minimal X with Matchbox window manager, featuring GTK+. And of course some test application. Am I able to fit this all to 64 MB? And if possible some extra free space would be nice for extensions and extra applications.
First starting from the kernel. Taking latest 2.6 series stable kernel, optimizing it for handheld use, removing futile drivers, etc. I want as minimal kernel as possible. Under a megabyte would be nice, just dreaming of it? Debian and basic libraries, uClibc would be nice, let's replace traditional libc with it. Saved some preciciuous megabytes. Other required libraries. X takes some megabytes, Matchbox is slight enough, but GTK+ taking again some more memory. Still speculating, only theorical level. The next step: implementing all this.
The best way to compile for ARM target is to use Scratchbox. We have qemu emulator support or we may use the ARM device with sbrsh to compile for ARM. For most compiling operations qemu is sufficient. Scratchbox has proper debian devkits and all required tools to make everything to work. Everything is set up, next I'll start compiling things. Debian provides precompiled ARM binary packages, so I'll just get the kernel and missing packages compiled, build image and flash my device. It'll take some time. Until that, please report your devices running Linux, and what kind of Debian based solution you would like to see on it?
Subscribe to:
Posts (Atom)