AmigaOne_Linux_Bootloader_Specification

AmigaOne Linux Bootloader Specification

Preface

This documents describes the bootloaders available on the AmigaOne platform to boot Linux. Furthermore a common rule set is specified based on the usage and restrictions of the bootloaders, which can be used to implement corresponding Debian bootloader packages. These bootloades packages should largely free the user from manual intervention, whenever an installation is made bootable or the boot configuration is changed due to system upgrades.

Available Bootloaders for the AmigaOne

1st Level Bootloader

U-Boot

The U-Boot firmware itself can also be used to boot a Linux system on the AmigaOne by either loading a boot image from a PReP partition or from a TFTP server. Booting Linux from a PReP partition is only possible for MBR partitioned harddisks (at least for U-Boot v1.1.4). This could be useful for users that want to have their Linux installations on a separate harddisk. However it requires a separate boot partition for every different boot image. Futhermore U-Boot doesn't provide any boot menu for this approach, which makes it hard for the user to quickly choose and boot a system.

Unfortuately U-Boot imposes some restrictions to the other second level bootloaders described here, as they all use U-Boot's bootm code to actually boot Linux:

1. if compressed, the boot image needs to be smaller than ca. 2MB
2. uncompressed images need to be smaller than ca. 16MB

2nd Level Bootloader

AmigaOS4 slb_v2

This bootloader comes with AmigaOS4.x and supports booting a Linux system given the following restrictions are met:

1. a single image is used to boot the system:
   This results from the fact that only one image file can be specified in the configuration file. Thus a kernel image and a initramfs image have to be combined into a single multi-file U-Boot image.

2. the configuration file and the boot image are on the same boot partition
   The bootloader only searches for the first Linux partition with an /boot/a1boot.conf configuration file. Thus all boot images need to reside on this partition. Likewise every Linux installation needs to add a boot entry to the /boot/a1boot.conf file, as no other configuration file is parsed.

3. the boot partition is the first Linux partition on the first harddisk and comes after the AmigaOS4 boot partition
   The bootloader only seems to scan for Linux partitions after it found a first AmigaOS4 partition. Therefore the best approach is to put the Linux boot partition right after the AmigaOS4 Workbench partition, which is usually the first partition on the first harddisk.

4. the boot partition is formatted as ext2 or ext3 filesystem
   The bootloader can read ext2/3 filesystems with a fixed inode size of 128 bytes. Support for larger inode sizes in the ext2/3 filesystem was added in kernel 2.6.10 and thus succeeds the slb_v2 bootloader. Most distributions configure mke2fs (in /etc/mke2fs.conf) to create 256 bytes inodes by default nowadays, thus the inode size has to be explicitly forced for the file system of the boot partition:

   ~~~~~~
   $ mkfs.ext3 -I 128 /dev/sdxy
   ~~~~~~

   Other block sizes or filesystem features like dir_index, ext_attr, filetype, large_file and resize_inode don't seem to confuse the bootloader. Features like extent, flex_bg and journal_dev haven't been tested so far. However they are either ext4 specific, or generally not enabled by default in /etc/mke2fs.conf.

As mentioned above the slb_v2 reads a single configuration file, where every non-commented line is a separate boot entry. A boot entry itself is specified in this format:

; Comments start with a semicolon
boot-entry-name /path/to/bootimage kernel option1 option2 option3...

The <boot-entry-name> should not contain any spaces or tabs, as parts of it would otherwise be interpreted as path to the boot image or kernel options. While the bootloader does not seem to restrict the length of the boot entry name in the configuration file, the name should not be longer than approximately 60 characters. Nevertheless this should be enough to give the boot entry a unique name. For example:

Debian-Squeeze-3.2.0-0.bpo.4-book3s.amigaone+-recovery-sda5

Where:

• "Debian" is the vendor of the installed distribution,
• "Squeeze" is the distribution's release codename,
• "3.2.0-0.bpo.4-book3s.amigaone+" is the kernel version used to boot the installation,
• "recovery" is an optional part, which specifies a runlevel used for system recovery and
• "sda5" is an another optional part used to distinguish installations, if there are multiple installations of the exact same distribution.

Alternatively a release number may be used instead of the release codename:

Ubuntu-10.04-3.2.0-0.bpo.4-book3s.amigaone+

Least but not least the number of displayed boot entries is limited to around 16 entries, because the booloader doesn't scroll the list. However it allows to select invisible boot entries.

ub2lb

ub2lb is also known as "parthenope" for ACube Systems' Sam boards.

To be continued...

Things to consider:

• Use root filesystem UUID as name for subdirectory?
• Use dpkg-divert to rename kernel images to subdirectory?
• Can the System.map and kernel config file be found on booting?
• Can the vmlinuz file be found on a kexec event?