Getting started with Embedded Linux: Part Eleven - Connecting with the target -

Getting started with Embedded Linux: Part Eleven — Connecting with the target


We are continuing our series on how to get started using Embedded Linux. The previous installments can be found on the Open Mike blog.

In the last installment, we showed how to build a Linux kernel on a Raspberry Pi Single Board Computer (SBC), as well as build it on a much faster development system. There are some advantages to building on our target system, namely that we are using development tools and the environment on the target. When we develop on another system, we have to use cross compilers and a copy of the target environment, which makes this somewhat more complex. But a cross-development environment is usually much faster than an embedded target, with much more disk and memory space. With many embedded Linux projects, it simply isn't possible to build on the target.

We copied the kernel from the development system and wrote it to the SDcard which we inserted in the Raspberry Pi. This worked, but it is awkward to move the SDcard from the development system to the target, run some tests, then move it back when we want to make changes, then back to the target when we want to test these changes. Happily, the Raspberry Pi and almost all target boards have a way to talk with the outside world, either over a serial port or ethernet. We'll use this to transfer files from the development system to the target, and even control the target from the development host.

Network setup on the Raspberry Pi

The Raspbian distribution for the RPi comes with a complete set of network tools preinstalled. On the RPi console, enter the command “ip addr show ”. You should see something like the following:

$ ip addr show1: lo:   mtu 65536 qdisc noqueue state UNKNOWN     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00    inet scope host lo       valid_lft forever preferred_lft forever2: eth0:   mtu 1500 qdisc pfifo_fast state UP qlen 1000    link/ether b8:27:eb:bc:d0:81 brd ff:ff:ff:ff:ff:ff    inet brd scope global eth0       valid_lft forever preferred_lft forever   

This tells you that the board is connected to the network and that the address for the external connection, eth0, is That's the address my DHCP server assigned to the board. You will likely have a different address. I added the following line to the /etc/hosts file on my development system so that I could use the name “rpi” instead of using the full IP address: raspberrypi rpi

Ssh, rsh, rlogin and telnet to connect to a target

SSH stands for Secure Shell and it is the standard way to connect to remote systems using an encrypted connection. SSH is a collection of programs including ssh and scp . It is installed by default on the Raspberry Pi and we will use it to connect to the target by entering the following command on our development host:

$ ssh pi@


$ ssh pi@rpi

You will be asked for the password for user “pi”. If you have not changed it, it is “raspberry”. . Once this is accepted, you will be in a bash shell on the target. You can do anything from this shell that you would be able to do from the Raspberry Pi console. (You can also set up your target with a shared key so that you bypass the prompt for a password every time you connect.)

The first time that you use ssh, you will be asked to verify that the system that you are connecting to is the one you intended. You can answer “yes”. If you happen to use ssh to connect to a system using the internet and you get this message unexpectedly, say after you have previously verified the system identity, there can be a couple reasons. One is that you are not connecting to the system that you intended, worst case, because someone has intercepted the connection. More likely is that the keys on the remote system have been regenerated.

By default, ssh starts a terminal session running bash. If you add a command at the end of the line, this command will be run on the remote system and then terminate. For example:

$ ssh pi@rpi df      pi@rpi's password: Filesystem     1K-blocks    Used Available Use% Mounted onrootfs           6240824 4518044   1387688  77% //dev/root        6240824 4518044   1387688  77% /devtmpfs          219768       0    219768   0% /devtmpfs              44788     224     44564   1% /runtmpfs               5120       0      5120   0% /run/locktmpfs              89560       0     89560   0% /run/shm/dev/mmcblk0p5     57288   25688     31600  45% /boot$ 

SSH will also allow you to run graphic programs remotely if you specify the “-X” option on the ssh command. The program will be run on the target, but the window will be displayed on your host system.

RSH is a package including the rsh and rcp programs. Similer to ssh, rsh allows you to connect to a remote system over ethernet. The difference, and the reason that RSH is not usually installed by default in most distributions, is that no encryption is done on the data you enter or that returned by the remote system. You may find that rsh is an alias for ssh where it is not installed. The command to connect using rsh is similar to that for ssh, except that you must specify the user id in a command line option:

$ rsh -l pi rpi

Similar to rsh, rlogin will also allow you to connect to a target:

$ rlogin -l pi rpi

Telnet is an older method of communicating with another system either over a serial line or over a network. It has fallen into disfavor in most applications, since all communication is in plain text, while SSH encrypts all messages. For development using an embedded Linux system connected to your development system, there is little reason to be concerned about someone monitoring your communications. Telnet is a much simpler program and since it doesn't have to encrypt or decrypt messages it uses fewer CPU resources, which may be important for low performance targets. An embedded Linux system which does not have enough CPU power or memory to run SSH can easily support telnet. You might have to install the telnet package on your development host, since by default most Linux distributions do not install it.

Both ssh and telnet allow you to control a target system from your host, even one which does not have a display or console attached. Or, as happened while writing this article, when the display abruptly stops working.

Copying files using ssh and rsh

The ssh package contains a command, scp, which allows you to copy files between your development host system and a remote system. It works similar to the cp command, but allows you to add the name of a remote system. Let's copy the kernel.img file which we built in the last installment to the /boot directory of our Raspberry Pi target:

$ cd ~/linux/arch/arm/boot
$ scp Image
pi@rpi's password:
Image 100% 6226KB 778.3KB/s 00:00

The last line will be updated as the transfer is performed, telling you how much data has been copied and how long it will take to complete the transfer.

After copying the file to /tmp on the RPi, we can use the shell we opened to the RPi target to copy it to the /boot directory:

$ sudo cp /tmp/Image /boot/kernel.img

We could not copy the file directly to /boot on the Raspberry Pi because it is owned by root. The Debian distribution which is installed on the Raspberry Pi does not have a password for root, so the only way that you can copy the file is to use the “sudo” command shown above.

Like ssh, the data is encrypted before being sent and decrypted on the receiving end. Especially on low performance targets, this can make data transfer slow.

The rsh package includes the rcp command, which is similar to scp except that the data is not encrypted. This means that it is more efficient than scp and can support faster data transfer, even on a low-performance target system. You will need to install it on the Raspberry Pi target:

$ sudo apt-get install xinetd rsh-server

You also need to modify the /etc/hosts.equiv file to contain a line like the following:

$ sudo cat “ ” >> /etc/hosts.equiv

Replace and with the hostname of your development system and your userid.

On the host system, we can now use rcp in the same way we used scp above:

$ rcp Image rpi:/tmp 

Notice that we don't need to specify the user id or enter a password whenusing rcp.

Talking to the target isn't the most exciting thing in the world,but when you can't, it can be one of the most frustrating. Now thatwe can connect to the target, enter commands, and transfer files,we can move on to the topic of the next installment: application development.

3 thoughts on “Getting started with Embedded Linux: Part Eleven — Connecting with the target

  1. “Thank you so much for the series Getting started with Embedded Linux. It is very well written and very useful for newbies like me. I hope you keep expanding this. I subscribed to your blog too. Thanks again for a great Job.”

    Log in to Reply
  2. “Excellent engineering documents!! nI wanted to make a request about writing a basic recipe for building a program, that is written in C, and comprises a few files that are sitting on the local computer (in my case a Linux host running Ubuntu) running the

    Log in to Reply
  3. “My request was for a bitbake recipe (for a program written in C, in files residing on the Linux host computer, that runs the cross compiler)nnThanksnTeklike”

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.