You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Patrick Georgi cd334e0a98 Pass correct arguments to kernel when booting from USB 10 years ago
bootloader-installer fix fseek argument order 10 years ago
dltool Don't hardcode 0x50000000 for us, but set it as default only. 10 years ago
include Bring in Linux headers as necessary 10 years ago
src Pass correct arguments to kernel when booting from USB 10 years ago
.mtn-ignore New utility 'bootloader-installer'. 10 years ago
Makefile Fix compile time options (USE_USB and USE_LCD) 10 years ago
README Qi for SmartQ branch by 10 years ago Bring in Linux headers as necessary 10 years ago Qi for SmartQ branch by 10 years ago


SmartQ Qi -
Forked from
20100526 -

Notes ( :

This version of Qi is an alternative bootloader to boot via USB OTG cable

You dont have to pack this one in SmartQ5 MagicSD image, Qi just need to be
placed at the End of the SDCard ie ./ /dev/sdb image/qi-xxx

umount all your SD partitions, then execute the script to write on SDCard
Put the OTG cable and SDCard in SmartQ5 and press Middle Button + Reset (or Power)


dltool works (compiled and tested ok with an image provided by mcuelenaere)
kernel-wrap : compile ok but images not working ?!?
qi src : compiled and tested ok : tested ok on a SDHC 8GB


qi : display controller initialized, we can now display 16 bpp data
LCD printf enabled :)


This is a modified Qi bootloader for the SmartQ 5 MID. It can boot from the
external SD card (keep the "move" button pressed and then press "power").

In this release the SmartQ code is integrated in several parts, a future
release may have the code separated so it could be submitted to the original
Qi repository if I find the time to do that. The original README file is
included below for reference, but most information is no longer applicable to
this modified version.

Use "make" to compile. The resulting binary file will be placed on
image/qi-s3c6410-<version>-SmartQ. Look at the script
in order to make a bootable SD card.

-- Roberto Gordo Saez <>

Qi (named by Alan Cox on Openmoko kernel list) is a minimal bootloader that
"breathes life" into Linux. Its goal is to stay close to the minimum needed
to "load" and then "boot" Linux -- no boot menus, additional peripheral init
or private states.

What's wrong with U-Boot, they keep telling people to not reinvent the wheel?

U-Boot is gradually becoming a simplified knockoff of Linux. After using it a
while, it became clear we were cutting and pasting drivers into U-Boot from
Linux, cutting them down and not having a plan to maintain the U-Boot versions
as the Linux ones were changed.

We decided that we would use full Linux for things that Linux is good at and
only have the bootloader do the device init that is absolutely required before
Linux can be pulled into memory and started. In practice since we had a working
U-Boot implementation it meant cutting that right down to the bone (start.S
mainly for s3c2442) and then building it up from scratch optimized to just do
load and boot.

Samsung - specific boot sequence

Right now Qi supports Samsung "steppingstone" scheme devices, but in fact it's
the same in processors like iMX31 that there is a small area of SRAM that is
prepped with NAND content via ROM on the device. There's nothing that stops Qi
use on processors without steppingstone, although the ATAG stuff assumes we deal
with ARM based processor.

Per-CPU Qi

Qi has a concept of a single bootloader binary created per CPU type. The
different devices that use that CPU are all supported in the same binary. At
runtime after the common init is done, Qi asks each supported device code in
turn if it recognizes the device as being handled by it, the first one to reply
that it knows the device gets to control the rest of the process.

Consequently, there is NO build-time configuration file as found on U-Boot
except a make env var that sets the CPU type being built, eg:

make CPU=s3c6410

Booting Heuristics

Qi has one or more ways to fetch a kernel depending on the device it finds it is
running on, for example on GTA02 it can use NAND and SD card devices. It goes
through these device-specific storage devices in order and tries to boot the
first viable kernel it finds, usually /boot/<uImage-device>.bin for example

The default order for GTA02 is: 1st SD primary partition, 2nd primary
partition, 3rd primary partition, NAND kernel partition.

You can disable a rootfs for consideration for boot if you add a file
/boot/noboot-<device>, eg, /boot/noboot-GTA02. This differs from renaming or
deleting the kernel image because updating the kernel package would give you a
working kernel again and allow boot, whereas the noboot indication will remain
until you remove it.

The kernel commandline used is associated with the storage device and partition,
this allows the correct root= line to be arrived at without any work.

If no kernel image can be found, Qi falls back to doing a memory test.

Appending to commandline

You can append to the Qi commandline by creating a file /boot/append-<device>,
eg, /boot/append-GTA02 containing the additional kernel commandline you want.

This means you can affect the boot per-rootfs, but that if you reimage the
rootfs you at the same time define what is appeneded. Because these files are
looked for with the <device> name in them, options can be selected depending on
the device the rootfs is run on.

Initrd support

Initrd or initramfs in separate file is supported to be loaded at given
memory address in addition to kernel image. The ATAGs are issued accordingly.

Interactive UI

Being minimalistic by its nature, Qi has very limited abilities to
interact with a user. On GTA02 the red LED and the vibrator are used
(if the battery is in good condition) to notify user of the following

The LED is turned on either on:
- Successful partition mount
- Successful kernel pull
- Successful initramfs pull

The LED is turned off and vibrator runs briefly either on:
- Fail of kernel pull
- Fail of initramfs pull
- Fail of mount partition
- Skipping of current boot possibility

The LED is turned off either on:
- Start of the kernel
- Start of the mem test
- Start of the kernel pull
- Start of the initramfs pull

If a user presses the AUX button after successful partition mount and
before start of the kernel pull (that is, while the red LED is on),
this boot possibility is skipped (and GTA02 owners can feel
vibration). If a user holds the POWER button just before start of the
kernel, debugging parameters are added to the kernel command line
and a lot of information is output to the screen.

Functional Differences from U-Boot on GTA02

- Backlight and USB is not enabled until Linux starts after a few seconds

- No startup splash screen

- by default there is no boot spew on the LCM

- On GTAxx boots from first uSD ext2 / 3 partition containing
/boot/uImage-<devicename>.bin present, eg, /boot/uImage-GTA02.bin, it checks
first three partitions in turn

- On GTA01 and 02 if nothing is workable on the SD Card, or it is not present,
Qi will try to boot from NAND

- You can disable a partition for boot by creating /boot/noboot-<devicename>,
eg, /boot/noboot-GTA02, it will skip it and check the next partition

- Way faster

- There is no concept of "staying in the bootloader". The bootloader exits to
Linux as fast as possible, that's all it does.