Practical Linux Forum (Mi, 03.05.2006)

Minimum, Single Threaded HTTP/TCP/IP implementation for boot loader

von Yutaka Niibe (National Institute of Advanced Industrial Science and Technology, Japan)

Mittwoch, 03.05.2006, Saal 11B, 17:00-18:00 Uhr

In our project porting GNU/Linux to M32R processor [2], we developed a boot loader named 'g00ff' (Go off!). Initial implementation only supported booting from compact flash. Adding support of loading kernel through network, our development speed improved very much.

The development of embedded system typically requires two machines, host machine and target machine. We cross-compile software on host machine for target machine. Development process goes like this:

(1) Change the source code of kernel on host machine (2) Compile it on host machine (3) Copy the kernel to target machine (4) Then, reboot the target system to test new kernel

The process (3), copying the kernel to target machine, could be removed, if a boot loader supported the feature of loading through network. I succesufully implemented this feature of loading through network, and our development has been accelerated.

For Intel x86 architecture, there are etherboot [3] project. It support booting using TFTP or NFS (Basically, it assumes local area network). I choose HTTP for download protocol, because HTTP servers are more common, and downloading can be through wide area network.

For the development of boot loader, there are restrictions and constraints. First of all, it is not normal user process program on UNIX. It runs 'free standing' environment, it should not depend on many runtime libraries. Because it is the first 'application' for an architecture, the requirement by a boot loader should be minimum. For porter who wants to run GNU/Linux on his/her architecture, what s/he wants to hack is Linux and/or GCC, not a boot loader. So, boot loader implementation should be minimum and portable enough.

For embedded system, there is Redboot [4] project. But it's on eCos, a embedded operationg system, where eCos requires C++. The task of porting eCos for some specific architecture is easier than porting Linux itself, but still, it requires many work, mostly similar but different duplicate of work, such as semaphore, context switch, and interrupt handling.

We don't need full feature of operating system for boot loader, and it should not. If porting boot loader needed as many work as porting Linux, it would be able to be stopper in the porting process. With portable and minimum boot loader, we can test Linux very early in the porting process.

For our boot loader, it is single threaded application, based on polling. No semaphore, no context switch, no interrupt handling, even though we support TCP/IP. The protocol stack implementation is somewhat special, because it is crafted for this paticular purpose, that is, loading kernel. It does some 'layer violation' in the coding, to be minimum and single threaded.

As it's portable enough, I'm now thinking using this protocol stack for forthcoming GRUB 2 [5].

LINKS: [1] M32R g00ff of current: http://www.gniibe.org/software/m32r-g00ff-20060107.tar.gz

[2] GNU/Linux on M32R Project: http://www.linux-m32r.org/

[3] Etherboot: http://etherboot.sourceforge.net/

[4] Redboot: http://ecos.sourceware.org/redboot/

[5] GRUB 2: http://www.gnu.org/software/grub/grub-2.en.html

Über den Autor Yutaka Niibe:

GNU Emacs developer (1991-1995), PLIP driver maintainer (1993-1998),
and Linux SuperH maintainer (1999-2001).

He is a chairman of NPO, the Free Software Initiative of Japan.