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
$ 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
Command usage information for the “bootload” program
$ bootload –help
Usage: bootload [OPTION]
Linux to Linux bootloader - (re)boots a TS-7xxx board
to another kernel, OS
image, or raw executable by replacing
the running Linux kernel.
-c, --cmdline=CMD Use CMD as the Linux kernel
-r, --initrd=FILE Use FILE for Linux initial
-s, --initrdsz=SZ Only read SZ bytes from the
-b, --base=ADDR Load the image at ADDR instead
--version Print version and copyright
-h, --help This help
When FILE is
-, reads from standard input.
Report bugs to
Some "one-line" examples of usage:
# Boot a compressed kernel image:
vmlinux.bin.bz2 | bootload -
# Reboot a kernel,
but pass the 1MB running ramdisk to the new one:
-o remount,ro /dev/rd/0 / bootload -c \
"console=ttyAM0,115200 root=/dev/ram0" -r /dev/rd/0 -r
# Boot one of 2 kernels based on the
state of DIO line #7:
if dio_data_get 7; then bootload
vmlinux.backup.bin; else \
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
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
In case its not obvious on how the "bootload" program
accommodates failover, the the below potential configuration
- Have two kernels in the YAFFS2 filesystem: /latest.bin
- By default, symlink latest.bin to /vmlinux.bin.
Symlinking in YAFFS2 should be an atomic operation.
- 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.
- 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.
- 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.