An Introduction to Embedded Linux Development, Part 3

Part 3 explores different scenarios for updating and/or replacing the root filesystem, the kernel image or even the bootloader on our embedded development system.
Replacing the Kernel and Root Filesystem

Various reasons exist for changing the kernel and/or root filesystem. Compiling in new hardware support, updating existing driver modules or adding new capabilities to the root filesystem are examples.

As you may have noticed above, before boot the kernel image and root filesystem, both compressed, are on the same partition, /dev/mtd2. Before shipping, the vendor placed the kernel image and the romfs for the root filesystem into the same compressed file, image.gz, which then was flashed into the /dev/mtd2 partition in Flash memory. We retain this approach, so that updating either the kernel image or the root filesystem involves reflashing both.

Let's look at how these software components are put on the LBox. To update software, the LBox makes use of a uClinux utility called netflash. In order to use this utility, a kernel must be running on the LBox. Further, the workstation must have the tftp (trivial FTP) daemon running, because netflash relies on that. It is outside the scope of this article to cover the installation of tftp, but most distributions have some sort of package management tool that allows one to install tftp, which is part of the larger netkit package. As of this writing, the current version is netkit-tftp-0.17, which can be found here. In recent years, security concerns have led us to avoid FTP and its variants in favor of sftp. You also may need to change firewall rules or turn off the firewall on the workstation. Consequently, we strongly recommend prudent paranoia; that is, tftp should be used when you are networked to the LBox only, not to the Internet itself. (See the section called "NFS Mounting" in Part 2 of this series for more details.)

The netflash utility allows us to transfer a file from the host computer by way of the network connection and save it in the flash memory on the target device. The command is entered on the LBox. For example, to retrieve a synopsis of its parameters and options, enter netflash -h to get a help screen.

One option we use is the -b option, which prevents automatic rebooting after the flashing operation is complete; otherwise, the LBox reboots when netflash completes. The -b option therefore provides a layer of protection should we suddenly realize the software component we just flashed was the wrong one or one that doesn't work. We also note that the netflash utility complains if you try to load a file larger than the partition you are trying to flash. The failure messages are not always informative, however. For example, it merely may provide a usage synopsis when it fails for some underlying cause, even though the syntax was okay.

So, from where do we get the image.gz file? This is accomplished on the workstation, where we use the tool chains that come with LBox. Recall that these use uClinux for kernel and root filesystem configuration. The uClinux directory hierarchy descends from the uClinux-dist directory node we installed on the workstation in Part 2 of this series. We assume that is our working directory when giving relative pathnames below. As necessary, we also use absolute pathnames.

To change the kernel and/or root filesystem, we must run make menuconfig or make xconfig as root from the uClinux-dist directory. This command presents a high-level GUI from which we can choose "Target Platform Selection" to open a new lower-level GUI. The lower-level GUI then allows us to configure the kernel, the vendor settings or both. The GUI at this level is somewhat non-intuitive. In particular, after making a selection, the Next button does not become active. Instead, after making our selection, we must close the lower-level GUI, returning to the original high-level GUI. We then choose the Save and Exit button, whereupon we are presented with a new GUI for making kernel and/or vendor setting modifications.

We suggest that for the first time through, no changes be made. Then, after the make xconfig step has been completed, enter make dep and make all. These result in writing the new image.gz file to both the images subdirectory and the tftpboot directory. The latter is accessed by the LBox using netflash.

When we are sure that all has been done correctly, we can enter the following command on the LBox--for example, by way of minicom--to update the kernel image:

netflash -knrb /dev/mtd2 tftp_server /tftpboot/image.gz

where tftp_server is replaced with the IP address of your workstation.

Recall that the /dev/mtd2 device corresponds to the joint kernel/root filesystem partition. Also, as noted above, we use the -b option to prevent automatic reboot after completing the update of the flash memory.

If you have trouble using the netflash utility, here are some things to check:

  • Make sure the file you are flashing actually exists in /tftpboot. Then, confirm that the /tftpboot directory permissions are 777 and the image.gz file permissions are 666.

  • Check that the tftp daemon is running. On the workstation, enter the command netstat -a | grep tftp.

  • Ensure that the network interface between the LBox and host computer is working properly.

  • Ensure that no firewall rules are preventing the file transfer by tftp.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Embedded Linux Development, Part 4

Ashish's picture

Hello,

When will the next and final installment of this series,
i.e, Part 4 of this article, be available ?

Thanks.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState