And then what happens?

Now that we know how to get an executable image into the Dreamcast, we need to know exactly how to use this capability to boot and run Linux. To answer this question, we need to cover a bit more background.

Traditionally, Linux kernels are not self-booting. Instead, they depend on a bootloader to establish a stable system state, gather information about the host platform, and then feed this information to the kernel. Many Linux setups also include decompression code in the bootloader, which speeds the overall boot process by reading a compressed (instead of full-sized) kernel image from slow, cheap media like floppy disks. On a typical Linux PC setup, the bootloader is called LILO or Grub. In an embedded setting, the bootloader is called whatever you choose to name it.

Briefly restated, the customary boot process in a Linux-based environment goes like this . . .

1. A bootloader is given initial control of the host system from the host's BIOS or boot firmware, or the bootloader is the system's boot firmware.

2. The bootloader drags the kernel image into memory and decompresses it.

3. The bootloader then jumps into the decompressed memory image, which contains a Linux operating system kernel.

4. The kernel initializes itself, mounts a root directory, loads device drivers, initializes hardware, and starts running applications.

Now that we know all of this, the contents of the executable image on the CD become a little clearer. The image must contain a bootloader and the Linux kernel, and we must arrange the image so that the bootloader gets control at the end of the Dreamcast's boot process, finds the Linux kernel, and transfers control to it.

Linux vs. applications

You might think that getting the Linux kernel booting and running is the end of the story. It turns out, however, that it is only the beginning; once the kernel is running, it needs applications to tell it what to do. If this statement sounds strange, then you probably have missed one of the fundamental ways that general-purpose, desktop-style operating systems differ from their embedded counterparts.

On the desktop, an operating system only coordinates interactions between applications. In embedded systems, the operating system and application code are often one in the same, because the two are bound so tightly together that distinguishing between them is impossible, or at least impractical.

Linux is a general-purpose, desktop-oriented operating system. As such, we must have applications available for it to run. We will produce such an application — a shell — towards the end of this article.

Linux vs. filesystems

If you wander through Linux's startup code (this could be the subject of a future article, if anyone expresses any interest), you end up with the kernel looking for an executable file called “init” to load into memory and run. This not only implies that we need a program named init, it also means that we need a filesystem to retrieve it from.

You are probably aware that the Dreamcast does not include a hard disk, which would be an obvious place to put files. You may not be aware, however, that most PC workstations also lack hard disks — at least until the operating system gets around to initializing the machine's IDE or SCSI controller hardware, that is. So Linux must already have a means of emulating a filesystem at startup, or it wouldn't be of much use in a workstation-class personal computer. Of course, we all know that it is.

To emulate a filesystem when no filesystem-oriented hardware is avalable, Linux uses a ramdisk: a memory structure that masquerades as a disk partition. A workstation bootloader loads a ramdisk image from the computer's disk hardware at boot time, and passes its address to the Linux kernel. The kernel reads device drivers for the workstation's disk controllers from the ramdisk, then begins talking to the physical disk drives. Once the “real” disk interface is working, the memory allocated for the ramdisk is discarded.

A ramdisk can provide all the disk-oriented facilities that Linux requires. (Although a ramdisk device can facilitate writing of data files, those files are lost at system shutdown because the original ramdisk image is re-read from the boot media at the next startup.) Consequently, there is no need for a hard disk at all if the host system has enough ramdisk memory to store all the programs and device drivers that the system needs. This is the approach we will take on the Dreamcast.

What you need to build Linux for the Dreamcast

You must have root access on a true Linux or other Unix-like workstation in order to build your own Linux-on-Dreamcast system, because the setup process requires construction of special files called device nodes that have no equivalent representation in a non-unix-like environment.

You also need a CD-R burner that can write a multisession CD using the CD/XA data track (mode 2, form 1) format. Support for this configuration is widespread in all but the least expensive CD-R burners and programming software. Note that the Dreamcast's GD-ROM drive cannot read a CD-RW disk, but it can read a CD-R disk produced by a CD-RW burner.

Finally, you need the list of files found in Figure 1. The standard GNU distributions are available from the Free Software Foundation's website or a mirror site, and other other software is available from the locations mentioned in the figure. The extensive list of patches required is simply my way of helping to automate the configuration and setup process.

• binutils-2.11.2.tar.gz — The linker, assembler, and object management utilities.
  
• gcc-3.0.1.tar.gz — The GNU Compiler Collection. Contains the C/C++ compiler.
  
• glibc-2.2.4.tar.gz — The GNU C runtime library.
  
• busybox-0.60.1.tar.gz — Small, embedded versions of common Unix utilities.
  
• kernel-sh-linux-dreamcast.tar.gz — Linux kernel for the Dreamcast.
  
• sh-boot-20010831-1455.tar.gz — Linux bootloader for the Dreamcast.
  
• binutils-2.11.2-sh-linux.diff — Patches for binutils.
  
• gcc-3.0.1-sh-linux.diff — Patches for gcc.
  
• glibc-2.2.4-sh-linux.diff — Patches for glibc.
  
• busybox-0.60.1-sh-linux.diff — Patches for Busybox.
  
• kernel-sh-linux-dreamcast.diff — Patches for the Linux kernel.
  
• sh-boot-20010831-1455.diff — Patches for sh-boot.

• Part 1: Introduction
  
• Part 2: And then What happens?
  
• Part 3: Building the tools
  
• Part 4: Building a Dreamcast Linux kernel
  
• Part 5: Building the Dreamcast boot CD

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.