Sorry, it's time since I last updated this blog but I've been busy with work projects. However I have had some time to play around with a nice embedded device on my spare time. I needed a wireless router so I bought a Linksys WRT54GL. It's originally a WLAN router with 200 MHz mips CPU, 16 MB RAM and 4 MB flash, with Linux based firmware.
There's lot of projects to replace the firmware, such as DD-WRT, OpenWRT and HyperWRT. I choosed to flash the DD-WRT to my box. Flashing went fine. After the flash I was able to access the router by telnet and HTTP. It was easy to set up SSH running from the web interface. So I had a Linux system running with SSH access on a embedded box. The next step was to install own software on it. I set up JFFS on the box and Samba share on a bigger server which was mounted by DD-WRT.
Next step was to install some packages with ipkg. I took the prebuilt packages from OpenWRT repositories. There was some problems installing some libraries because a Samba share does not support symbolic links. Solution is to make the proper links on the server side. It required some tweak to make the applications to run, such as set LD_LIBRARY_PATH to proper location. Some applications required some extra parameters to work properly. Generally the Samba share provided virtually unlimited amount of storage for applications. The only limitation is the box itself.
I'd like to set up a compiler environment for my desktop environment to build applications for mips and to run them on my WRT box. I have some ideas to make it run different kind of applications. However first I'd like to set up a web server on it and make my primary router to forward them to the WRT box. Which one would hit first, the power or the memory limit? How about to set up a swap over the Samba share? To be seen...
Thursday, December 21, 2006
Saturday, November 04, 2006
Mobile calendar and synchronization
At home I use OS X iCal application on my Mac to mark up important events and meetings. Then I have Nokia 9500 Communicator with me all the time and mark events to it also. I have also Nokia 770 hanging round sometimes. To make things even more wicked I carry a laptop along me on my trips. This works usually but one night it became a real nightmare.
Communicator has a table stand which connects via USB to computer. It has sync button on it. However I have never managed to get it working with OS X. With my Linux laptop it works ok, but never successed to synchronize calendar events. Fortunately my Mac has bluetooth and so has the communicator. The next problem after pairing these two devices was that iSync didn't want to work properly. After googling a while I found instructions how to set up iSync for 9500 and how to install 9500 plug-in to iSync. Surprisingly everything was working fine. I got my contacts backuped and calendar marks in sync.
Oh, now I have nice working synchronization. But wait a minute. It's completely manual, needs starting iSync and pressing some buttons on both devices. One night I took my laptop and communicator and gone working to a distant location for a couple of weeks. I remembered that I had a meeting on one of these weeks but no idea on which day and what time. Took a look to my communicator and found... nothing. I forgot to sync my devices. Ok, no problem I have SSH access to my Mac. Unfortunately Apple has decided to make some modifications to iCal version 2 and the calendars are not available as files any more in my home folder. Quick search did not result anything. Now I got a problem.
You know it's not nice at all to call people and ask "when did we actually had the meeting"? It gives a stupid image of you. The lesson learned: always sync your mobile calendars. Also got an idea. Why not sync everything automatically, on multiple places and easily accessible remotely? I would like to see a command line interface for iCal or the calendars as easily readable files. How about automatical synchronization when my phone is available via bluetooth? Yes, I can still press the "accept connection" button in my phone if it for example beeps once when it's needed. Synchronize to my laptop - it has bluetooth as well. Unfortunately it lacks a good calendar. Also 770 lacks a calendar completely and it has bluetooth as well. So could somebody make a good open source calendar which works on my laptop, 770, other possible Linux based systems and synchronizes well with 9500 and Mac via bluetooth or USB? Automatically, if possible? Anybody?
Communicator has a table stand which connects via USB to computer. It has sync button on it. However I have never managed to get it working with OS X. With my Linux laptop it works ok, but never successed to synchronize calendar events. Fortunately my Mac has bluetooth and so has the communicator. The next problem after pairing these two devices was that iSync didn't want to work properly. After googling a while I found instructions how to set up iSync for 9500 and how to install 9500 plug-in to iSync. Surprisingly everything was working fine. I got my contacts backuped and calendar marks in sync.
Oh, now I have nice working synchronization. But wait a minute. It's completely manual, needs starting iSync and pressing some buttons on both devices. One night I took my laptop and communicator and gone working to a distant location for a couple of weeks. I remembered that I had a meeting on one of these weeks but no idea on which day and what time. Took a look to my communicator and found... nothing. I forgot to sync my devices. Ok, no problem I have SSH access to my Mac. Unfortunately Apple has decided to make some modifications to iCal version 2 and the calendars are not available as files any more in my home folder. Quick search did not result anything. Now I got a problem.
You know it's not nice at all to call people and ask "when did we actually had the meeting"? It gives a stupid image of you. The lesson learned: always sync your mobile calendars. Also got an idea. Why not sync everything automatically, on multiple places and easily accessible remotely? I would like to see a command line interface for iCal or the calendars as easily readable files. How about automatical synchronization when my phone is available via bluetooth? Yes, I can still press the "accept connection" button in my phone if it for example beeps once when it's needed. Synchronize to my laptop - it has bluetooth as well. Unfortunately it lacks a good calendar. Also 770 lacks a calendar completely and it has bluetooth as well. So could somebody make a good open source calendar which works on my laptop, 770, other possible Linux based systems and synchronizes well with 9500 and Mac via bluetooth or USB? Automatically, if possible? Anybody?
Thursday, September 28, 2006
Serving your embedded
Usually people think embedded devices are clients for some services such as voice calls, video streaming, short messages and internet. But how about serving with your embedded device.
For example Nokia has a mobile web server for Symbian. It's modified Apache and is available as open source. They say that main target running a web server in your mobile phone is to make your personal mobile website. So what kind of are these personal mobile websites? Some information about you? It can't be anything that spends resources, it it just showing some simple pages. Isn't there any lighter way to show some information about you? I suppose nobody wants to surf to my mobile phone which might not be alwys available. I also thing that nobody wants to make this kind of page available as primary home pages since it's too easy and cheap to set up the pages to a real server.
But wait a minute, how about a whole, fully working web server serving some pages on the Internet. I found a Nokia 770 and Apache intresting combination. 770 has WLAN so it can be set up with wireless access point and get it visible to the Internet. Apache serving some personal web pages, portal or anything you like. How about setting up a server cluster? Multiple embedded devices serving on same address. Easy and cheap redunancy. Let's take a normal 770, it costs about 370 euros. Cheaper than a computer or a real web server.
How reasonable this is? Embedded devices are not any realiable, so anything can go wrong at any time. They does not automatically recover from error situations. You simply should not trust them. But at least serving web pages with your embedded device is really geeky and increases your masculine power. For power users only.
For example Nokia has a mobile web server for Symbian. It's modified Apache and is available as open source. They say that main target running a web server in your mobile phone is to make your personal mobile website. So what kind of are these personal mobile websites? Some information about you? It can't be anything that spends resources, it it just showing some simple pages. Isn't there any lighter way to show some information about you? I suppose nobody wants to surf to my mobile phone which might not be alwys available. I also thing that nobody wants to make this kind of page available as primary home pages since it's too easy and cheap to set up the pages to a real server.
But wait a minute, how about a whole, fully working web server serving some pages on the Internet. I found a Nokia 770 and Apache intresting combination. 770 has WLAN so it can be set up with wireless access point and get it visible to the Internet. Apache serving some personal web pages, portal or anything you like. How about setting up a server cluster? Multiple embedded devices serving on same address. Easy and cheap redunancy. Let's take a normal 770, it costs about 370 euros. Cheaper than a computer or a real web server.
How reasonable this is? Embedded devices are not any realiable, so anything can go wrong at any time. They does not automatically recover from error situations. You simply should not trust them. But at least serving web pages with your embedded device is really geeky and increases your masculine power. For power users only.
Monday, September 11, 2006
Embedded language
What's your embedded language? Which suits best for embedded use. Let's spend a few minutes thinking about it.
What are the options we have? Shortly there are four good candidates. First we have old and traditional C. There are lots of C applications available, it's well known, well supported, effective, Linux kernel is written with it, most system libraries are written with it, everything is good except one thing: it's not a modern laguage. It's missing object oriented features, it has memory leak problems among other problems. However they are all known but badly handled.
Let's make a step better language C++. It has object oriented features, but it's not a object oriented programming language. It's compatible with C, which has lots of benefits but inherits all misadvantages of C. It still leaks memory, no carbage collector, no proper class library, except STL which is a good try and for example Symbian does not have STL at all. And one little thing in Linux: every release of C++ libraries brakes binary compatibly. It's a really problem. Binary ABI for GNU libraries is very unstable. They may change it from a version to another. Have you ever tried to transfer an C++ application binary from machine to another and run it? Also compiling C++ applications takes a lot of more time than similair C application, more complex object oriented applications take even more time. You might say that nowadays computers are fast. They are, but wait until you compile your first big and complicated C++ application. It's not fast at all.
How about the newcomers, let's take Java first. Sun's "build once, run everywhere" ideology is nice! It really works. Java is really object oriented, carbage collector works nicely. Some problems however. Lets ingnore most of them, but take some in the spotlight. First Java versions. There three different versions: micro edition (J2ME) for embedded and resource limited devices, standard edition (J2SE) and enterprise edition (J2EE) for mainframe. Have you ever tried to port for example an application from J2SE to J2ME? It's impossible, or at least very difficult. Mobile phones has J2SE, however every manufacturer has their extensions to J2ME, it really breaks the "build once, run everywhere" ideology. This is however going to change in future versions of J2ME, but still waiting for the day. Should embedded Linux devices use J2SE or J2ME? For example Nokia solution on 770: surprise, no Java support at all! Second big thing is that Java is closed source. You have to have license and solve some issues to get Java for your device. Fortunately Sun has promised to release Java (only parts of J2SE in first phase) as open source. But what's the license, will the whole Java system become eventually free (as speech) and what are the terms and conditions. That will be seen.
Python. A programming language named after Monty Python can't be bad. And it's not. It has quite nice syntax, works well, is object oriented, etc. There's also Python available for example for Nokia 770 (Maemo) and Series 60. It's really suitable for anything, applications runs everywhere without recompiling, just like in Java. The biggest disadvantage: Python is interpreted language. Interpretion is slow, running is slow. Unofortunately I don't have speed measurements, but it's definetly slow on embedded devices. It suits for small applications which does not require a lot of resources or fast calculations. For slight use only as we could say.
So what's the best? I thing system should rely on C, while applications can be C or C++. And light applications can be implemented quickly and easily with Python. Java has problems, you have to choose your way and follow it blindly. It could be the killer, but it's not. Let's see what the future offers for us.
What are the options we have? Shortly there are four good candidates. First we have old and traditional C. There are lots of C applications available, it's well known, well supported, effective, Linux kernel is written with it, most system libraries are written with it, everything is good except one thing: it's not a modern laguage. It's missing object oriented features, it has memory leak problems among other problems. However they are all known but badly handled.
Let's make a step better language C++. It has object oriented features, but it's not a object oriented programming language. It's compatible with C, which has lots of benefits but inherits all misadvantages of C. It still leaks memory, no carbage collector, no proper class library, except STL which is a good try and for example Symbian does not have STL at all. And one little thing in Linux: every release of C++ libraries brakes binary compatibly. It's a really problem. Binary ABI for GNU libraries is very unstable. They may change it from a version to another. Have you ever tried to transfer an C++ application binary from machine to another and run it? Also compiling C++ applications takes a lot of more time than similair C application, more complex object oriented applications take even more time. You might say that nowadays computers are fast. They are, but wait until you compile your first big and complicated C++ application. It's not fast at all.
How about the newcomers, let's take Java first. Sun's "build once, run everywhere" ideology is nice! It really works. Java is really object oriented, carbage collector works nicely. Some problems however. Lets ingnore most of them, but take some in the spotlight. First Java versions. There three different versions: micro edition (J2ME) for embedded and resource limited devices, standard edition (J2SE) and enterprise edition (J2EE) for mainframe. Have you ever tried to port for example an application from J2SE to J2ME? It's impossible, or at least very difficult. Mobile phones has J2SE, however every manufacturer has their extensions to J2ME, it really breaks the "build once, run everywhere" ideology. This is however going to change in future versions of J2ME, but still waiting for the day. Should embedded Linux devices use J2SE or J2ME? For example Nokia solution on 770: surprise, no Java support at all! Second big thing is that Java is closed source. You have to have license and solve some issues to get Java for your device. Fortunately Sun has promised to release Java (only parts of J2SE in first phase) as open source. But what's the license, will the whole Java system become eventually free (as speech) and what are the terms and conditions. That will be seen.
Python. A programming language named after Monty Python can't be bad. And it's not. It has quite nice syntax, works well, is object oriented, etc. There's also Python available for example for Nokia 770 (Maemo) and Series 60. It's really suitable for anything, applications runs everywhere without recompiling, just like in Java. The biggest disadvantage: Python is interpreted language. Interpretion is slow, running is slow. Unofortunately I don't have speed measurements, but it's definetly slow on embedded devices. It suits for small applications which does not require a lot of resources or fast calculations. For slight use only as we could say.
So what's the best? I thing system should rely on C, while applications can be C or C++. And light applications can be implemented quickly and easily with Python. Java has problems, you have to choose your way and follow it blindly. It could be the killer, but it's not. Let's see what the future offers for us.
Monday, August 28, 2006
Mobile Phone Linux
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.
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.
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?
Tuesday, July 25, 2006
Gnome suitability for embedded devices
First thing coming to my mind about the Gnome is resource consuming desktop environment with fancy features and loads of bloat. Fitting Gnome to a embedded Linux device - impossible? Maybe not.
The Gimp Tool Kit (GTK+) has proven it's suitability for embedded devices, also some other parts from Gnome, such as GnomeVFS, GConf, etc. But how about the whole desktop environment? First of all some storage space is needed. At least storage space from 128 MB to 256 MB is required. Then some main memory, let's say 128 MB at least. And last quite powerful CPU, high speed ARM processor could be enough for normal operation, but more powerful x86 processor would be good bet but then we got some power and battery issues. If no problems with the power, choose x86 architechture, otherwise ARM is a better (but slower) bet.
Building up the Linux system and libraries, setting up X server, window manager and finally Gnome desktop. Gnome is quite scalable, it can fit different sized screens but too small is too small. If you're luck enough you'll get Gnome up and running with proper speed and load times. If not, you need optimizations. Everything futile must be removed. And trust me there's lot of things to remove. Starting from applications in the panel, background images, fancy window decorations, etc. and continuing to different components and packages. Test how slight configuration you can get. Then add features back if they're needed.
Now we have only one question left. Why? Gnome is quite usable desktop environment and nice on a desktop computer but how about embedded devices? First of all it's an easy start. You don't have to fight to get usable GUI to the device, no need to reinventing the wheel by implementing your own desktop enviroment. Of course there's other desktops available as well, but Gnome is well known and there's lots of applications for it. You could list a lot of benefits. But there disadvantages as well - Gnome is not designed for embedded use, it uses quite much resources and it's designed to be used with a mouse and a keyboard.
I would not recommend to use Gnome as is. It's possible to use some parts of Gnome in embedded devices or you could use some other GTK+ based desktop system such as XFce. If you still want to use Gnome or want to have quickly an desktop for the device, it's possible to utilize Gnome. It requires some time, resources and care, but can provide some benefits quicker than using a customized solution.
The Gimp Tool Kit (GTK+) has proven it's suitability for embedded devices, also some other parts from Gnome, such as GnomeVFS, GConf, etc. But how about the whole desktop environment? First of all some storage space is needed. At least storage space from 128 MB to 256 MB is required. Then some main memory, let's say 128 MB at least. And last quite powerful CPU, high speed ARM processor could be enough for normal operation, but more powerful x86 processor would be good bet but then we got some power and battery issues. If no problems with the power, choose x86 architechture, otherwise ARM is a better (but slower) bet.
Building up the Linux system and libraries, setting up X server, window manager and finally Gnome desktop. Gnome is quite scalable, it can fit different sized screens but too small is too small. If you're luck enough you'll get Gnome up and running with proper speed and load times. If not, you need optimizations. Everything futile must be removed. And trust me there's lot of things to remove. Starting from applications in the panel, background images, fancy window decorations, etc. and continuing to different components and packages. Test how slight configuration you can get. Then add features back if they're needed.
Now we have only one question left. Why? Gnome is quite usable desktop environment and nice on a desktop computer but how about embedded devices? First of all it's an easy start. You don't have to fight to get usable GUI to the device, no need to reinventing the wheel by implementing your own desktop enviroment. Of course there's other desktops available as well, but Gnome is well known and there's lots of applications for it. You could list a lot of benefits. But there disadvantages as well - Gnome is not designed for embedded use, it uses quite much resources and it's designed to be used with a mouse and a keyboard.
I would not recommend to use Gnome as is. It's possible to use some parts of Gnome in embedded devices or you could use some other GTK+ based desktop system such as XFce. If you still want to use Gnome or want to have quickly an desktop for the device, it's possible to utilize Gnome. It requires some time, resources and care, but can provide some benefits quicker than using a customized solution.
Monday, July 17, 2006
About GPS
Currently I'm on Dublin having a vacation. Thought that navigating through the city could be made easy. Having a Nokia 770 and GPS receiver at the home. The problem: they're at home, I'm in Ireland.
I have been testing GpsDrive and Maemo Mapper with 770. Both of them seems nice, however GpsDrive works better for me. Maemo Mapper has it's benefits and disadvantages. It uses Google maps which are nice, it's designed for mobile use and is lighter but it does not work as well with the GPS receiver and does not have as much features as the GpsDrive.
GpsDrive works well, but is far away from lightweigth and usable mobile application and the current version for maemo is just a dirty hack. It's loosing connection to the GPS receiver after some amount of time and the only thing that helps is to reboot the 770. I'd like to see improved version from both of them. It could be a real killer app. Some preconfured map sets would help end users to utilize them. Caching maps from the Internet - it should be easy as navigating through the map with a cross controller.
As a summary I'd like to use my 770 to locate myself and to see where to go, but didn't remember to take the device with me and secondly didn't wanted to because the software is not too usable yet. I have some ideas to improve the software but unfortunately running out of time. Would be nice from you people to help me out, please improve maemo GPS apps.
I have been testing GpsDrive and Maemo Mapper with 770. Both of them seems nice, however GpsDrive works better for me. Maemo Mapper has it's benefits and disadvantages. It uses Google maps which are nice, it's designed for mobile use and is lighter but it does not work as well with the GPS receiver and does not have as much features as the GpsDrive.
GpsDrive works well, but is far away from lightweigth and usable mobile application and the current version for maemo is just a dirty hack. It's loosing connection to the GPS receiver after some amount of time and the only thing that helps is to reboot the 770. I'd like to see improved version from both of them. It could be a real killer app. Some preconfured map sets would help end users to utilize them. Caching maps from the Internet - it should be easy as navigating through the map with a cross controller.
As a summary I'd like to use my 770 to locate myself and to see where to go, but didn't remember to take the device with me and secondly didn't wanted to because the software is not too usable yet. I have some ideas to improve the software but unfortunately running out of time. Would be nice from you people to help me out, please improve maemo GPS apps.
Thursday, July 13, 2006
EXT4
On the Linux kernel mailing list people has been discussing about forthcoming ext4 filesystem. Some proposed checksums but the idea was abandoned. Not any really good ideas are introduced except from delayed allocation, higher resolution timestamps and support for larger volumes and file sizes, so I thought how about embedded point of view? We have special requirements for example for flash memory. Performance, battery life and such crucial things for embedded devices. For example flash memory has limited amount of write operations for specific section and after that it's died. Is there any needs for filesystem to support safe write/read operations. If your flash memory section dies, you should be able to use the filesystem still. You might get errors and lost some data. Recovery of lost data? Marking bad sectors a better way? Predicting these situations? How would you improve the filesystem? The conversation is ongoing on the Linux kernel mailing list, it needs your contribution.
Thought from the other side, how about desktop and server systems? Is there any special requirements for them, what do you need. Is ext3 perfect? Probably not, so how to improve it? All ideas are welcome.
Thought from the other side, how about desktop and server systems? Is there any special requirements for them, what do you need. Is ext3 perfect? Probably not, so how to improve it? All ideas are welcome.
The grand opening
Greeting, I'm opening a brand new blog about open source software, specially concentrating on Linux from embedded point of view.
A bit of myself. I'm twentysomething Finnish boy, computer activist, had a computer since 1989, intrested about open source, specially Linux, used it for a several years in home and work, working for a company named Nomovok which provides open source based solutions. I'm studying computer science at the university planned to graduate at some point. However computers are not my whole life, I still have a contact to the reality. But that's enough of me, lets get to the business.
About the blog. I'm following Linux kernel mailing list and will pick up some interesting things from it, also intrested about GTK+ and Gnome, discussing about other projects as well, commenting embedded Linux solutions like Nokia 770 and Maemo, gathering infomation also from Slashdot and other news sources.
Hopefully you find this blog interesting. Happy hacking.
A bit of myself. I'm twentysomething Finnish boy, computer activist, had a computer since 1989, intrested about open source, specially Linux, used it for a several years in home and work, working for a company named Nomovok which provides open source based solutions. I'm studying computer science at the university planned to graduate at some point. However computers are not my whole life, I still have a contact to the reality. But that's enough of me, lets get to the business.
About the blog. I'm following Linux kernel mailing list and will pick up some interesting things from it, also intrested about GTK+ and Gnome, discussing about other projects as well, commenting embedded Linux solutions like Nokia 770 and Maemo, gathering infomation also from Slashdot and other news sources.
Hopefully you find this blog interesting. Happy hacking.
Subscribe to:
Posts (Atom)