Communicating to a serial interface of an embedded Linux device using kermit

I have used kermit for connecting to serial interfaces for several years and it has always worked as expected. Even for sending a kernel image to U-Boot using the zmodem protocol (yes, it took ages, but there was no Ethernet) has worked quite well.

Recently, a friend that is new to embedded Linux ask me how to connect to a serial interface, so this is a small and simple guide on how to do it.

Just as an intro, a summary of what is kermit taken from the Fedora repo:

C-Kermit is a combined serial and network communication software package offering a consistent, medium-independent, cross-platform approach to connection establishment, terminal sessions, file transfer and management, character-set translation, and automation of communication tasks.

If you have Fedora, CentOS, SuSE or other rpm based distribution

If you have Debian, Mint, Ubuntu or other deb based distribution

Create the configuration file .kermrc in your home directory. These parameters are normally right for most systems. I’ve used it for SH4 and ARM based devices:

The most important parameters here are the line parameter that indicates the serial device and the speed parameters that is it’s baud rate. If you have an USB-to-serial interface converter your device will be /dev/ttyUSBx where x is normally 0, but it depends on how may USB-to-serial converters you have. The same happens if you have a normal serial cable, except that your device will be named /dev/ttySx, where x is normally 0.

Add your user to the dialout group in the /etc/group file

Logout and login again. This is needed since the group to which a user belongs are assigned when the user logs in.

Open a shell and execute kermit. The output should be something like this:

By default, kermit searches the file .kermrc in your home directory. If you have several kermit config files (may be because you have several boards configured differently), you can specify it:

kermit /home/paguilar/.custom_kermrc

If there are problems like the wrong serial interface, you may see a message like this one:

You can also have this problem if there is a lock file. This error happens if you try to access the serial interface whilst another process is already using it. It can also happen if you kill a previous kermit session when it was connected to the serial interface.
In these cases you have to remove the lock file and execute kermit again.

Assuming that everything went right and you happily used a busybox shell or similar you can disconnect from kermit by typing Ctrl-\ + q

Just to be clear, the escape control sequence is Ctrl and backslash at the same time, then you enter the desired character.
For example, if you are in your board’s shell, for connecting to the kermit shell just type Ctrl-\ + c, then enter connect to go back to your board’s shell.

That’s it.

Running MySQL with <16MB memory in an ARM processor

In many small embedded systems it doesn’t make much sense to have a powerful Relational Data Base Management System (RDBMS) such as MySQL because there is only one application that access the database or one that writes and one/many that reads. In these cases, the best option is SQLite that is may be the widest used embedded database.

However, small systems are getting more complex and even when there are only few MB of memory and few MHz (in my case 64MB and 210MHz respectively), there could be several applications accessing the database simultaneously. For example, several C programs writting and several PHP script reading and writting (through a built-in web server such as Busybox’s httpd or lighttpd).
In these cases SQLite starts to have issues handling the concurrence even if you configure it for using Write-Ahead-Log (WAL) instead of the default rollback journal.

I was curious about the minimum requirements I would need to run MySQL in an small embedded system just to see if it was technically feasible. I gave it a try and I managed to run it in an ARM Atmel AT91SAM9260 with only 64MB.
In fact, MySQL was running exactly in 13.58MB:


The first thing was obviously building MySQL for my ARM processor. I didn’t find any easy method, but this procedure worked for me. It’s based on this guide written by nonoo.

The most imporant thing when cross-building MySQL is that you have to build first a native MySQL and then cross-build MySQL for your target. This is necessary because MySQL, for building some pieces of itself, it uses binaries generated on-the-fly.

First, let’s export common environment variables that make our life easier:


Package: libncurses 5.7

Configure, build and install the only requirement:

Package: MySQL 5.5.37


Download MySQL and copy it these two directories:

Compile the host version. In my case I have an AMD 64 bits processor. Choose the one that fits your host:

Now we can start to cross-build MySQL:


Create the CMake toolchain file mysql-src-arm/build/mysql_at91sam9260.cmake:

Create and run the script mysql-src-arm/BUILD/doconfig:

Prepare to build

Create the script mysql-src-arm/BUILD/domake:

The above script copies a couple of files before building. THis is needed everytime because MySQL will try to run the auto-generated binaries for ARM, but we need to execute them in our host (x86). Not doing this gives these errors:


Copy the following ncurses include files generated when building ncurses inside the client/ directory, otherwise the building process won’t find them:

and edit the file by modifying how the above files are included:

Run domake. If you’re lucky it will finish successfully at the first try.

If you have the following error

copy all executables from mysql-src-x86/BUILD/extra to mysql-src-arm/BUILD/extra and mysql-src-arm/extra.
Run domake again.

If you still have problems and get this error:

Copy mysql-src-x86/BUILD/scripts/comp_sql to mysql-src-arm/scripts/comp_sql.
Run domake again.

At this point you should have built it successfully.


It will install in the usr/local/ directory inside the $ROOTFS.

Add the mysql user and group in your target board. If you have more users than root, you have to adapt it by changing the user and group id:

Edit /etc/passwd

Edit /etc/group

and create the required directory

Now you can run MySQL’s install script:

Now that you have the MySQL server binary in your rootfs you can execute it, but if you have less than 128MB, it will refuse to start.

You need to configure it properly (my.conf) to use as less memory as possible. I made several tests and the best configuration in which I managed to make it work is the following:

Some of the parameters have hard-coded minimums and MySQL will refuse to start if you set a smaller number or simply ignore it and start with it’s default.

Notice that some of these options reduced significantly its functionality. For example, I was not interested in a TCP/IP server, everything runs inside the embedded device, so I set the skip-networking option.

Play around with the different options to fit your needs.

With this configuration I was able to run MySQL and to have several clients connected writing and reading simultaneously without any memory issues. Even the processor behave nicely when there were only few simultaneous writes and reads.

Have fun!

Installing the wireless USB adapter Edimax EW-7811Un in an embedded device

Recently, I needed to install and configure a Wireless 802.11/b/g/n USB Adapter in an ARM-based device that runs a 2.6.35 Linux. The adapter was an Edimax EW-7811Un.

There are several wireless USB adapters that run under Linux, you can have a look at the official site here for supported devices and their chipsets. However, this list is far from complete and out-dated.
Of course, the chipsets listed in this site are the ones inside the mainline kernel, but several vendors provide drivers that for one reason or another are not part of the mainline kernel and we have to compile them out-of-tree.

This was my case because I’m using an old 2.6.35 kernel and the 8192cu.ko driver was not part of the mainline kernel. It was included in the 2.6.39 under the name rtl8192cu.ko.

The Makefile provided is for compiling for an i386 based processor, so I created this small patch for compiling for an AT91 ARM processor. You could do the same by just changing the CONFIG_PLATFORM_ARM_AT91 by the one that defines your processor.

As you can see from the above patch, I’m using the kernel provided by buildroot as the sources for building the driver, but you can change the KSRC variable as you need.

Now you can build the driver with the ARCH and CROSS_COMPILE environment variables according to your platform and toolchain. In my case, I have an ARM processor (an AT91SAM9 from STMicroelectronics).

For testing quickly the driver in your embedded device you can copy it to the rootfs and insmod’it:

I’ve been using this driver for several months and it is quite stable using different WPA encryption methods with b/g wireless networks.

That’s it!