The wget tool is extremely common and will probably already be present on most systems.

To obtain the wget tool on a deb based system (E.g. Debian or Ubuntu) install the wget package using:

sudo apt-get install wget

To obtain the wget tool on an rpm based system (E.g. Fedora) install the wget package using:

yum install wget

The debootstrap command is the primary tool required to create the target system. It obtains all the necessary packages from a Debian package repository and unpacks them in the correct way. The tool is based on standard UNIX shell functionality which makes it portable and straightforward to use.

To obtain the debootstrap tool on an deb based system (E.g. Debian or Ubuntu) install the debootstrap package using:

sudo apt-get install debootstrap

To obtain the debootstrap tool on an RPM based system (E.g. Fedora) is more complicated as there is generally no RPM package available. The following steps will manually install the Debian package onto a RPM based system. Firstly create a temporary working directory:

$ mkdir work 
$ cd work

Obtain the debootstrap package from the Debian archive. The archive pool contains the .deb package files to obtain, care should be taken to use the most recent version from the pool. The archive pool is available from numerous mirrors. To obtain the package from the master repository:

$ wget http://ftp.debian.org/debian/pool/main/d/debootstrap/debootstrap_1.0.7_all.deb

Once the correct package has been obtained it is installed by unpacking the Debian package with the ar tool and using tar to extract debootstrap. The tar operation will require suitable privileges.

$ ar -xf debootstrap_1.0.7_all.deb
$ TARFILE=$(pwd)/data.tar.gz
$ cd /
$ zcat < ${TARFILE} | tar xv

This will place the debootstrap tool in /usr/sbin which must be in the users path for the tool to operate correctly.

If the system is to be accessed by NFS the server must have the tools installed.

To install the NFS server and tools on a deb based system (E.g. Debian or Ubuntu) install NFS server package using:

sudo apt-get install nfs-kernel-server

To install the NFS server and tools on an RPM based system (E.g. Fedora) install the NFS utilities package using:

yum install nfs-utils

This method is the simplest of the three and consists of creating a directory and configuring the NFS server to serve it.

This method requires that suitable networking is available and configured. It is common for the serving machine to also be configured to serve as a DHCP server. A full explanation of configuring the networking is not presented here but it is necessary to know the IP addresses of the client machine and for the client machine to be able to obtain these values for NFS to operate correctly.

The first step is to create a directory on the host which will be served using the NFS protocol to the client system. The directory should be created somewhere with at least a gigabyte of space free. The directory will be served using the NFS protocol and must be somewhere suitable. A possible directory might be /export/debian. Inside a users home directory is not usually suitable.

# mkdir /export/debian

Once a suitable directory has been created it must be added to the NFS exports. This is achieved by adding a line to the /etc/exports configuration file. The format of the configuration line is fairly straightforward and simply lists the directory to export, the network address to export it to and options to control the export. The /etc/exports file format and options is detailed in the exports manual page. The IP address or the network range that will be assigned to the client must be known.

A suitable alteration to the /etc/exports file for a network with the IP addresses 192.168.1.xx would be:

$ echo '/export/debian 192.168.1.0/24(rw,no_root_squash,async)' >>/etc/exports

Once altered the new export can be enabled with the exportfs command

$ exportfs -a

The export can be checked with

$ exportfs
/export/debian    192.168.1.0/255.255.255.0

This method is useful for platforms where a hard drive is practical but there is no easy way to perform a standard OS install using the Debian installer.

Firstly a suitable hard drive of at least ten gigabytes size must be acquired. For most Simtec Electronics platforms this would involve using a 2.5 inch hard drive connected using a standard 44way cable. One straightforward way to connect these hard drives to the host for bootstrapping is to use a USB connection.

Figure 1. USB connected 2.5inch hard drive

Irrespective of how the drive is connected to the host it will have a device node. This can usually be found in the system message log, this can typically be acquired using the dmesg command.

usb 5-5: new high speed USB device using ehci_hcd and address 12
usb 5-5: configuration #1 chosen from 1 choice
scsi5 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 12
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 5:0:0:0: Direct-Access     Generic  USB Disk         9.02 PQ: 0 ANSI: 2
sd 5:0:0:0: [sdd] 78140160 512-byte hardware sectors (40008 MB)
sd 5:0:0:0: [sdd] Write Protect is off
sd 5:0:0:0: [sdd] Mode Sense: 03 00 00 00
sd 5:0:0:0: [sdd] Assuming drive cache: write through
 sdd: unknown partition table
sd 5:0:0:0: [sdd] Attached SCSI disk
sd 5:0:0:0: Attached scsi generic sg3 type 0

Once a drive is available it must be partitioned. The chosen layout is largely dependant on usage. The simplest layout is one large root partition and a swap partition of a suitable size (128MB to 256MB). If ABLE is being used to start the OS from the drive there are no limits on the partitioning scheme as long as a DOS disc label is used and the root filesystem lies within the first 128GB. A separate boot partition can be used if desired.

parted /dev/sdd 
GNU Parted 1.7.1
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel msdos                                                    
(parted) unit mb                                                          
(parted) print free                                                       

Disk /dev/sdd: 40008MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End      Size     Type  File system  Flags
        0.00MB  40008MB  40008MB        Free Space        

(parted) mkpart primary ext2 0 39880                                      
(parted) mkpartfs primary linux-swap 39880 40008                          
(parted) print 

Disk /dev/sdd: 40008MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start    End      Size     Type     File system  Flags
 1      0.00MB   39880MB  39880MB  primary                    
 2      39880MB  40008MB  128MB    primary  linux-swap        

(parted) quit

parted /dev/sdd mklabel msdos mkpart primary ext2 0 39880 mkpartfs primary linux-swap 39880 40008

Once a partition table has been written the device will be rescanned and the newly created partitions will be available. The partition names can typically be retrieved using dmesg command once more.

sd 5:0:0:0: [sdd] Attached SCSI disk
sd 5:0:0:0: Attached scsi generic sg3 type 0
sd 5:0:0:0: [sdd] 78140160 512-byte hardware sectors (40008 MB)
sd 5:0:0:0: [sdd] Write Protect is off
sd 5:0:0:0: [sdd] Mode Sense: 03 00 00 00
sd 5:0:0:0: [sdd] Assuming drive cache: write through
 sdd: sdd1 sdd2

Once suitable partitions have been created a filesystem must be placed on them. The filesystem must be readable by the bootloader so a kernel can be retrieved from it. ABLE supports several filesystems but the EXT2 system is best for this application.

$ mke2fs -O dir_index,has_journal,sparse_super  /dev/sdd1
mke2fs 1.40.2 (12-Jul-2007)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
4833280 inodes, 9663996 blocks
483199 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
295 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

The parameters of the created filesystem can be found with the tune2fs command. The UUID of the filesystem should be noted as it will be required later in the bootstrap process.

$ tune2fs -l /dev/sdd1
tune2fs 1.40.2 (12-Jul-2007)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          9669e340-5254-4cb1-a2d8-fc4ec0d0835c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed directory hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              4833280
Block count:              9663996
Reserved block count:     483199
Free blocks:              9467258
Free inodes:              4833269
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1021
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Fri Dec  7 11:38:55 2007
Last mount time:          Fri Dec  7 13:35:27 2007
Last write time:          Fri Dec  7 13:35:27 2007
Mount count:              1
Maximum mount count:      36
Last checked:             Fri Dec  7 11:38:55 2007
Check interval:           15552000 (6 months)
Next check after:         Wed Jun  4 12:38:55 2008
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:		  128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      e9836175-d901-4253-a630-f584d39e5fcc
Journal backup:           inode blocks

If a swap partition was created that should also be formatted at this point. The UUID of the swap partition should be noted as it will be required later in the bootstrap process.

$ mkswap /dev/sdd2
Setting up swapspace version 1, size = 423620 kB
no label, UUID=ebe8f79f-509b-4eb3-9c3a-f0e97b7a8c1c

Once the filesystem has been created it should be mounted somewhere convenient on the host system e.g. /mnt.

$ mount /dev/sdd1 /mnt

Wherever the volume is mounted this is where the basic system bootstrap will be performed.

The procedure outlined here is fairly straightforward, however the Section A.1, “mkdiscimage” shell script has been provided which will perform these steps and those in sections Section 4, “Bootstrap basic system” and Section 5, “Minimal configuration of the basic system” without user interaction.

Constructing a virtual disc consists of several steps. The general approach is:

The creation of the virtual disc image with the dd command is straightforward. The image should be large enough to contain the base system, 512MB is a suitable minimum size.

dd if=/dev/zero of=virtdisc bs=1M count=512

The virtual disc image must then be partitioned. This is most easily achieved with the parted command. The older fdisk command could be used but is not covered here. As with a real disc the partition layout is largely arbitrary but should consist of at least a root partition and a swap partition. The Example 2, “Partitioning a USB attached hard drive with parted.” shows how this is achieved for a physical disc.

The partitioning of the image created previously might be performed with:

parted --script virtdisc mklabel msdos mkpart primary ext2 0 384 mkpartfs primary linux-swap 384 512

This will create a 384MB root disc and a 128MB swap partition within the 512MB image.

The next step is to use the loopback mount system to create a block device from the virtual disc file. This is achieved with the losetup command. This operation requires superuser privileges.

# losetup -f
/dev/loop0
# losetup /dev/loop0 virtdisc

Next a device node must be made for the root partition of the virtual disc. We can achieve this using the device mapper system. The device mapper requires us to know the start and length of the partition on the loopback device. This information is available in the partition table but is not easy to calculate by hand. To aid with this the lspartab script has been provided (see Section A.2, “lspartab”). When run on the loopback device node created in the previous steps two partitions are listed:

# lspartab /dev/loop0
1 32 749920 131
2 749952 250112 130

the first partition is the root partition (type 131), the second is the swap (type 130).

The device mapper requires a “table_file” to construct the device. A “table_file” is a sequence of values specific to the mapping being performed. A linear mapping is required and the entries of the appropriate “table_file” are:

For the root partition a linear mapping of the loop device is required. The mapped device in this case should always start at logical sector 0. From this a dmsetup command can be constructed.

For the previously listed partition table of the virtual disc a linear mapping from sector 32 for 749920 sectors, where a sector is 512 bytes is indicated. The command would be:

# dmsetup create virtdisk1 --table "0 749920 linear /dev/loop0 32"

If this is successful it will create a new device node /dev/mapper/virtdisk1 that can be used as if it were a real partition on a real disc.

If the device mapping has been successful the newly created device can be used to create a filesystem upon the same as with a physical disc. The steps to create a filesystem and get its UUID can be found in the previous section.

Once the filesystem has been created it should be mounted somewhere convenient on the host system e.g. /mnt.

$ mount /dev/mapper/virtdisk1 /mnt

Wherever the volume is mounted this is where the basic system bootstrap will be performed.

For systems where the root filesystem will be mounted using NFS over the network an entry must be made in the filesystem table for the root mount, a suitable entry would be:

echo "192.168.1.1:/export/debian / nfs defaults 0 1" >> /mnt/etc/fstab

The root filesystem is now ready to be booted.

For systems where the root filesystem is mounted on an attached hard drive an entry must be made in the filesystem table for the root mount. Using the partitioning outlined earlier the line would be:

$ echo "UUID=9669e340-5254-4cb1-a2d8-fc4ec0d0835c / ext3 defaults,errors=remount-ro 0" >> /mnt/etc/fstab
$ echo "UUID=ebe8f79f-509b-4eb3-9c3a-f0e97b7a8c1c none swap sw 0 0" >> /mnt/etc/fstab

The root filesystem is now ready to be booted by the target system. The disc must be unmounted and attached to the target system as appropriate.

$ umount /mnt

A virtual disc is very similar to the physical disc, an entry must be made in the filesystem table for the root mount. Using the partitioning outlined earlier the line would be:

echo "/dev/sda1 / ext3 defaults,errors=remount-ro 0" >> /mnt/etc/fstab
echo "/dev/sda2 none swap sw 0 0" >> /mnt/etc/fstab

The root filesystem is now ready to be booted by the virtual machine. The filesystem should be unmounted, the device mapper device removed and the loopback mount undone.

# umount /mnt
# dmsetup remove /dev/mapper/virtdisk1
# losetup -d /dev/loop0

The NFS boot method means the kernel image must be retrieved from the network. Using the ABLE bootloader this is a simple operation using a commandline similar to this:

(tftpboot)vmlinuz-2.6.23-simtec1 init=/bin/sh root=/dev/nfs nfsroot=192.168.1.1:/export/debian,rsize=1024,wsize=1024 ip=dhcp console=ttySAC0,115200

The vmlinuz kernel image should be copied from the root filesystem boot directory into the TFTP server directory on the host.

The IP address of the NFS server should be substituted in the command line as well as the correct export directory. The rsize and wsize options are important and omitting them will result in a series of error messages and no shell running. The ip=dhcp will cause the kernel to obtain its IP parameters from a DHCP server, obviously this can be altered to use a fixed ip address if required. The Documentation/nfsroot.txt file in the kernel sources has more details.

The console argument sets the serial port as the console. The parameter sets the baud rate to 115200 which is the ABLE default.

The hard drive should be physically attached to the development platform and power applied. Once ABLE has started the drive should be detected and be available. There should be a section of the ABLE boot message showing the drive detection and the partition with the root filesystem.

hda: ST94813A: ATA PIO mode 4
hda: Diagnosing disc drive: ok
(hda) 37GB
(hd0) on ((hda1):ext2)
(hd1) on (hda2)

From this the appropriate device to use to access the root filesystem can be deduced. The kernel can then be booted with a command such as:

(hd0)/boot/vmlinuz-2.6.23-simtec1 init=/bin/sh root=/dev/sda1 console=ttySAC0,115200

The system can be started with the qemu emulator. Generally no additional bootloader is required (although ABLE can be run within qemu if desired). The kernel to boot must however be provided this can either be retrived from the Simtec Electronics website or copied from the boot directory in the virtual disc.

A suitable command line to start the virtual system in single user mode would be:

qemu-system-arm -M simtecbast -kernel vmlinuz-2.6.23-simtec1 -append "init=/bin/sh root=/dev/sda1 console=ttySAC0,115200" -nographic ./virtdisc

The most straightforward method for NFS based systems is to create an ABLE shell script on the TFTP server. This allows the boot parameters to be altered by editing the script on the server.

The script will contain a boot line similar to that constructed in the single user Section 6.1, “NFS root”.

#!/bin/sh
(tftpboot)vmlinuz-2.6.23-simtec1 root=/dev/nfs nfsroot=192.168.1.1:/export/debian,rsize=1024,wsize=1024 ip=dhcp console=ttySAC0,115200

Once the script has been created ABLE can be configured to run it at startup by setting the boot.cmd non volatile variable to “(tftpboot)nfs-etch.sh” and then saving the variables with nvsave.

>boot.cmd="(tftpboot)nfs-etch.sh"
>nvsave

The bootloader configuration to boot from a disc drive is best achieved by setting the ABLE bootloader to run a script from the boot directory directly from the drive, this allows for the boot parameters to be changed from the running Debian system simply by editing the file.

The script will contain a boot line similar to that constructed in the single user Section 6.2, “Disc drive”.

#!/bin/sh
(hd0)/boot/vmlinuz-2.6.23-simtec1 root=/dev/sda1 console=ttySAC0,115200

Once the script has been created ABLE can be configured to run it at startup by setting the boot.cmd non volatile variable to “(hd0)/boot/able.sh” and then saving the variables with nvsave.

>boot.cmd="(hd0)/boot/able.sh"
>nvsave

Generally the emulated machine aproach removes the need for a seperate bootloader as the kernel image can be readily retrived by the host system.

A suitable command line to start the virtual system in multi user mode would be:

qemu-system-arm -M simtecbast -kernel vmlinuz-2.6.23-simtec1 -append "root=/dev/sda1 console=ttySAC0,115200" -nographic ./virtdisc