Technologic Systems Logo
Search Icon
Customer Area | Contact Us |Cart Icon
  16525 East Laser Drive
Fountain Hills, AZ 85268
Phone (480) 837-5200
Fax (480) 837-5300
info@embeddedARM.com

Home > Software > Solutions for ARM > Linux Bootloader

 

Linux Boots Linux with Linux Bootloader

arrow

Technologic Systems has developed a Linux application named "bootload" that allows booting of Linux and other OS kernels from within Linux itself. The "bootload" program is compatible with any TS-7000 ARM computer. This tool is the ideal complement to the Technologic Systems' super fast bootup solutions for the TS-7000 series SBCs, which use an extremely fast (under 2seconds Linux Fastboot solution), small (it fits in the 443 bytes of empty space in the MBR of the flash chip) and flexible power-on Linux bootloader.

When used together, the Linux fast boot solution and the Linux “bootload” program provide, in a single Bootloader solution, all the facilities of the full-featured Linux OS and the simplicity and speed of the traditional embedded bootloaders (uBoot, RedBoot, etc..), delivering high flexibility and total system control in a 100% Linux-based small-footprint embedded solution.

Some of the possibilities include:

  • Safe and atomic kernel updates by using kernels stored on the YAFFS2 flash filesystem.
  • Auto-select a fallback kernel and root filesystem in case of botched field update or hardware watchdog expiry. A Linux shell script can control what gets passed as kernel command line arguments.
  • Boot Linux kernels and other operating systems via wget command (FTP, HTTP, etc..), TFTP, ZMODEM serial, NFS, USB flash dongle, etc...

How To Use It

The “bootload” program is a Linux user-space program. However, it requires a kernel module "bootloader.o" to be installed using "insmod" prior to invocation. No kernel patches or in-source modifications are required though:

$ insmod -f bootloader.o

The Technologic Systems' version of Linux (Linux for ARM on TS-7200 series) uses a special device driver at /dev/misc/bootloader to accommodate the hooks needed by the "bootload" program to allow Linux to act as a bootloader and boot other Linux kernels and operating systems.

Command usage information for the “bootload” program follows:

$ bootload –help
Usage: bootload [OPTION] FILE
Linux to Linux bootloader - (re)boots a TS-7xxx board to another kernel, OS
image, or raw executable by replacing the running Linux kernel.

General options:
-c, --cmdline=CMD Use CMD as the Linux kernel boot args
-r, --initrd=FILE Use FILE for Linux initial ramdisk
-s, --initrdsz=SZ Only read SZ bytes from the initrd file
-b, --base=ADDR Load the image at ADDR instead of 0x218000
--version Print version and copyright information
-h, --help This help

When FILE is -, reads from standard input.
Report bugs to <support@embeddedARM .com>

Some "one-line" examples of usage:

# Boot a compressed kernel image:
bunzip -c vmlinux.bin.bz2 | bootload -

# Reboot a kernel, but pass the 1MB running ramdisk to the new one:
mount -o remount,ro /dev/rd/0 / bootload -c \
"console=ttyAM0,115200 root=/dev/ram0" -r /dev/rd/0 -r 0x100000


# Boot one of 2 kernels based on the state of DIO line #7:
if dio_data_get 7; then bootload vmlinux.backup.bin; else \
bootload vmlinux.bin; fi

How To Get It

Both files are available for downloading at the Technologic Systems' ftp server:

In addition, the , "bootloader.o" kernel module as well as the the "bootload" application itself are installed on the default onboard YAFFS2 NAND flash Linux filesystem (/dev/mtdblock/3) of all Technologic Systems' ARM embedded computer (TS-7000 series) shipped after Dec 1st, 2006.

Linux Bootloader Benefits

The new Technologic Systems Bootloader is totally Linux-based, enabling much more control over the system through all the standard Linux utility commands from inside the bootloader itself. Meanwhile, it delivers fast bootup time, as short as 1.1 seconds, and small footprint, not only meeting the requirements of the real-world embedded systems, but also delivering additional flexibility and power. After all, it is Linux booting Linux.

The “bootload” facility may be useful for kernel developers, since they now have a faster way to test kernels without rebooting the whole system. In case a fast bootup solution is not being used, developers benefit from the use of the “bootload” program given that the time spent with firmware loading will be saved.

Also, the new Bootloader solution allows the use of standard shell scripts for the programmatic selection of appropriate kernels, Linux initrd's, and kernel command line arguments for maximum flexibility. Click on the link below and find out how the TS-7400 takes advantage of these features in order to provide multiple booting options via Linux shell scripts:

Embedded System Upgrade in the Field

Technologic Systems' customers doing kernel modifications and concerned about safe field updates may want to have failover kernels which this functionality should squarely accommodate. Combined with using the hardware watchdog(s), this should allow for the utmost in product reliability.

For example, by default the "linuxrc-mtdroot" sample startup script included on the TS-7400 initrd will look for a file in the YAFFS2 NAND flash filesystem named "/vmlinux.bin" and attempt to load and boot it. You can modify the kernel command line parameters or image file by editing and changing the respective line in this startup script. Since the kernel is now a simple file in the YAFFS2 filesystem, it is possible to atomically and safely field update the kernel from, e.g., ftp with a command such as:

wget ftp://my.company/newvmlnx.bin && mv newvmlnx.bin /vmlinux.bin

In case its not obvious on how the "bootload" program accommodates failover, the the below potential configuration illustrates this:

  1. Have two kernels in the YAFFS2 filesystem: /latest.bin and /knowngood.bin.
  2. By default, symlink latest.bin to /vmlinux.bin. Symlinking in YAFFS2 should be an atomic operation.
  3. Before you start feeding the watchdog in application code, your application re-symlinks /knowngood.bin to /vmlinux.bin. Feeding the watchdog in your own application code is always better, because letting the kernel do it automatically could defeat the point of the watchdog.
  4. If your watchdog expires and the board resets, the system will boot /knowngood.bin. Your application can do some sort of self-check and if all seems well, resymlink /latest.bin to /vmlinux.bin and then bootload the /latest.bin kernel directly. Application code can change behavior based upon what /vmlinux.bin points to (/knowngood. bin vs. /latest.bin) which says whether or not the last reset was caused by the watchdog. If you wanted to be really careful, only make /latest.bin the default by symlinking it in after 15 minutes of proper system operation.
  5. Before graceful shutdown, your application could reset the symlink back to /latest.bin to avoid the double-bootload and software self-check that would be caused otherwise-- or you could just leave it in to always precede the invocation of your application with a product specific self-check.

For more information, contact a Technologic Systems engineer.