7.2 Disk Devices
Manipulating disk devices for use in embedded Linux devices is similar to what you do in Linux workstations or servers. In the following, we will concentrate on only those aspects that differ from conventional disk manipulations. I encourage you to consult other documents discussing Linux system maintenance in general, such as Running Linux, to get the rest of the details.
A CompactFlash (CF) card is accessible in Linux in two ways: either as an IDE disk, when plugged in a CF-to-IDE or a CF-to-PCMCIA adapter, or as a SCSI disk, when accessed through a USB CF reader. In practice, it is often convenient to use a USB reader to program the CF card on the host while using a CF-to-IDE or a CF-to-PCMCIA adapter in the target to access the device. Hence, the CF card is visible as a SCSI disk on the host, while being seen by the target as an IDE disk. The fact that the same CF card can be accessed through two very different kernel disk subsystems can be problematic, however, as we'll see during the configuration of LILO for a CF card in Chapter 9. Of course, there would be no problem if a CF device would always be accessed through the same disk subsystem.
To access the CF card through a USB CF reader on the host, you must have kernel support for USB storage devices. Most distributions are shipped with USB device support built as modules. Therefore, all you have to do is load the appropriate USB modules and SCSI disk drivers on your host:
# modprobe usb-storage # modprobe uhci # modprobe sd_mod
Though the uhci module is used in this example, some systems, such as Apple's systems, require usb-ohci instead. Once the modules are loaded, you can now look at the appropriate entries in /proc to see your CF reader. For example, this is how the SanDisk SDDR-31 reader I have on my PC host is seen by the SCSI subsystem:
# cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: SanDisk Model: ImageMate II Rev: 1.30 Type: Direct-Access ANSI SCSI revision: 02 # cat /proc/scsi/usb-storage-0/0 Host scsi0: usb-storage Vendor: SanDisk Corporation Product: ImageMate CompactFlash USB Serial Number: None Protocol: Transparent SCSI Transport: Bulk GUID: 078100020000000000000000 Attached: Yes
In this case, because the reader is the first device on the SCSI bus, it can be accessed as /dev/sda. Therefore, I can partition, format, and mount the CF card the same way I would partition, format, and mount a conventional SCSI disk:
# fdisk /dev/sda ... # mkdir /mnt/cf # mke2fs /dev/sda1 # mount -t ext2 /dev/sda1 /mnt/cf
The partitions you put on the CF card and the use of the various partitions depends largely on your target. If your target is an x86 PC derivative, you can use a single partition. If your target is PPC using the U-Boot bootloader, you need to have a few small partitions to hold kernel images and one large partition to hold your root filesystem. This is because U-Boot can read CF device partitions and the data on those partitions, but it does not recognize any filesystem organization. Hence, kernel images must be written to raw partitions to be loadable by U-Boot. We will discuss example uses of CF cards as boot devices in Chapter 9.
7.2.2 Floppy Disk
If you intend to use a floppy disk as your main storage device for your embedded Linux project, have a look at the "Putting them together: Making the diskette(s)" section of Tom Fawcett's Linux Bootdisk HOWTO, available from the LDP. Tom explains in detail how to create a bootable floppy using either LILO or the kernel alone. Although you do not need to read other sections of the HOWTO, the instructions assume that you have created a RAM disk image containing your root filesystem. See Chapter 8 for an explanation of how to create this RAM disk image.
We will not discuss the use of floppy disks in embedded Linux systems any further, because they are very seldom used in production systems and because the Linux Bootdisk HOWTO already covers the issues involved quite well.
7.2.3 Hard Disk
When configuring a hard disk for use in an embedded Linux system, the most convenient setup to bootstrap the target is to attach the hard disk destined for the target to the host's own disk interface. In this way, the target's hard disk can be manipulated directly on the host.
If the host already has one IDE disk that is seen as hda, for example, the target's IDE disk may be seen as hdb or hdc, depending on the host's setup. We can then format and mount this drive as we would any other hard disk. The only difference, however, is that the target's disk, seen on the host as a secondary disk such as hdb or hdc, will very likely be seen as hda on the target. This poses certain problems when configuring bootloaders. We will discuss these issues further in Chapter 9.