[[image:Screenshot-Qi.png|frame|Qi Boot messages]] Qi is a lightweight replacement for the [[U-Boot]] bootloader with everything that doesn't assist "loading" and "booting" Linux stripped out. Distributions provide tar.gz-images of their root file system, that can be uncompressed on a MicroSD-card and Qi boots stable that distribution just by inserting the MicroSD in your freerunnner. E.g. changing the distribution from [[SHR]] to [[QtMoko]] can be done just by replacing one MicroSD (SHR) with an other MicroSD card (QtMoko) without using the boot menu.

* actively developed (u-boot on GTA02 is deprecated)<br/>ATM qi is not developed, but supported, but main u-boot branch is really developed

+

* easier configuration, more robust and predictable actually it needs to be recompile to change kernel parameters, nothing really robust or predictable

+

* SD and SDHC cards supported properly with partitions of any size as in u-boot

+

* kernel size is detected by checking the start of the kernel image, so large (>2M) kernels are supported without tweaking or loading more than needed procedure of changing kernel size in u-boot is not 'tweaking', just configuration

+

* Very fast, simple boot direct to Linux

+

+

===Disadvantages of Qi===

+

* No boot menu -> you have to press keys to boot from sd for example

+

* Impossible to change kernel parameters for NAND without recompilation.

+

* Bootlog disabled by default

+

* If any error happens, you should decode LEDs, in u-boot you can just read message

+

* Complete non-flexible setup. Impossible to change default behavior without recompilation, so if it is compiled to boot from nand, you always have to press key to boot sd.

+

* Bootloader unique to openmoko, while U-Boot is universal widely used software, so methods

+

of working with other devices are applicable to openmoko, like newer patches.

+

* u-boot supports dfu so you can flash anything anywhere, qi doesn't support it, so qi is useless without NOR u-boot.

+

===Requirements===

===Requirements===

There is a [[Neo1973|GTA01]] build of Qi, but using it without a debug board is not recommended because Qi itself does not support DFU, so updating or going back to U-Boot is a difficult process.

There is a [[Neo1973|GTA01]] build of Qi, but using it without a debug board is not recommended because Qi itself does not support DFU, so updating or going back to U-Boot is a difficult process.

[[Freerunner|GTA02 Hardware]] has NOR U-Boot always available, so updating to Qi is safe to try it out.

[[Freerunner|GTA02 Hardware]] has NOR U-Boot always available, so updating to Qi is safe to try it out.

+

+

{{Note|The below Qi are for Openmoko. E.g. for SHR - use Qi from the SHR directory if newer.}}

===Download===

===Download===

−

*GTA01 -> qi-s3c2410

+

*GTA01 -> [http://people.openmoko.org/andy/ qi-s3c2410]

−

*GTA02 -> qi-s3c2442

+

*GTA02 -> [http://people.openmoko.org/andy/ qi-s3c2442]

====New Versions====

====New Versions====

Line 29:

Line 83:

====Unstable and Experimental Versions====

====Unstable and Experimental Versions====

−

These are the lastest versions from svn.

+

These are the latest versions from svn.

Download from either the Neo1973 or NeoFreerunner directory.

Download from either the Neo1973 or NeoFreerunner directory.

Line 43:

Line 97:

===Installation===

===Installation===

−

The installation should be flashing like (do it in DFU mode of NOR u-boot):

−

# dfu-util -a u-boot -R -D qi-s3<version>.udfu

−

depending on the file you downloaded. The file you use for flashing is depending on the hardware (see section 'Download'). In detail you have to go through the following procedures:

See [[Flashing the Neo FreeRunner]] for more details on flashing your phone.

+

See [[Flashing the Neo FreeRunner]] or [[Flashing the Neo 1973]] for more details on flashing your phone.

===Features===

===Features===

Line 68:

Line 117:

===Use Case===

===Use Case===

−

If you want to install [[Android]] on you OpenMoko you can use Qi. The [[Android on Freerunner]] kernel image can be more than 2MB in size. The UBoot environment that comes with your FreeRunner is only able to boot a kernel 2MB in size or less. Qi support kernel images greater than 2MB out of the box.

+

If you want to install [[Android]] on you OpenMoko you can use Qi. The [[Android on Freerunner]] kernel image can be more than 2MB in size. The UBoot environment that comes with your FreeRunner is only able to boot a kernel of 2MB in size or less. Qi support kernel images greater than 2MB out of the box.

+

+

====NAND Memory as Backup-OS====

+

Qi boots from MicroSD partition e.g. from a ext2-Partition. If your root filesystem on your SD get corrupted you can boot another distribtion from NAND memory (e.g. removing SD card).

+

+

====NAND Memory as Home-Directory====

+

You can use Qi if you want to exchange the distribution on your Freerunner just by exchanging the MicroSD card.

+

If you do not use the NAND memory as an backup distribution you can mount the NAND-memory as a home-directory or as documents. This helps to keep all the personalized data on the freerunner/mobile phone when you exchange distrubtion via exchanging MicroSD-card.

===Limitations===

===Limitations===

−

* no DFU-Mode - USB is not initialized at all (but you can always boot from NOR http://wiki.openmoko.org/wiki/Boot#Log_into_U-Boot_in_the_NOR_Flash )

+

* no DFU-Mode - USB is not initialized at all (but you can always boot [http://wiki.openmoko.org/wiki/Boot#Log_into_U-Boot_in_the_NOR_Flash from NOR])

−

* no boot menu (but you can always boot from NOR http://wiki.openmoko.org/wiki/Boot#Log_into_U-Boot_in_the_NOR_Flash )

+

* no boot menu (but you can always boot [http://wiki.openmoko.org/wiki/Boot#Log_into_U-Boot_in_the_NOR_Flash from NOR])

* FAT partitions are ignored

* FAT partitions are ignored

Line 135:

Line 191:

===Choosing a Kernel===

===Choosing a Kernel===

−

If a user presses the AUX button after successful partition mount and

+

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). So press power, release power, press aux, wait for vibration, release aux.

−

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).

+

On versions newer than Jan 18 if a user holds the POWER button just before start of the kernel,

On versions newer than Jan 18 if a user holds the POWER button just before start of the kernel,

Line 144:

Line 197:

===Boot Menu===

===Boot Menu===

−

Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi. This does not exist yet (it's already implemented for some Angstrom-supported devices and for Zaurus, so porting should be relatively easy).

+

Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi.

+

Such system is already implemented for some Angstrom-supported devices and for Zaurus (see [http://projects.linuxtogo.org/projects/kexecboot/ kexecboot]).

+

Since 2009-11-16, a such project was initialized by Marc Andre Tanner. The project is called [http://www.brain-dump.org/projects/qi-bootmenu/ qi-bootmenu].

Dedicated code for openmoko has its [http://git.openmoko.org/?p=qi.git;a=summary own Git repo].

+

+

git clone git://git.openmoko.org/git/qi.git

+

+

Qi is also [http://gitorious.org/0xlab-bootloader maintained on gitorious].

+

One can also just use strings(1) on the .udfu file to get an idea of where Qi currently looks for files.

One can also just use strings(1) on the .udfu file to get an idea of where Qi currently looks for files.

Line 172:

Line 234:

on the rootfs in question, put in there

on the rootfs in question, put in there

loglevel=8

loglevel=8

−

and you'll see the messages on boot. If it's NAND right now you need to edit the default commandline in Qi for gta02.

+

and you'll see the messages on boot.

+

+

If it's NAND, according to [http://www.mail-archive.com/community@lists.openmoko.org/msg39256.html] you need to copy the uImage-GTA02.bin under /boot/ directory also under NAND and then create /boot/append-GTA02 there as well. The other way, as that guide does not seem to work per se (fix this wiki if it should work and works for you) is to edit the default commandline in Qi for gta02 and recompile Qi.

===/boot-Partition===

===/boot-Partition===

Line 190:

Line 254:

== Testing speed improvements ==

== Testing speed improvements ==

+

+

This measurement is inappropriate. Modern qtmoko boots under 1 minute with any bootloader,

:: This can be improved a lot by using the quiet option on the kernel command line !!!!!!!!!

* 1:18 Openmoko 'please wait' splash

* 1:18 Openmoko 'please wait' splash

* 1:31 desktop animated splash

* 1:31 desktop animated splash

* 2:38 finished booting

* 2:38 finished booting

+

Why 1'20 min from OM splash to end of boot here

+

and only 1'00 for the Qi version ???

+

Qi has no relation to this !!!!!!!!!

Booting identical setup with Qi flashed over uBoot:

Booting identical setup with Qi flashed over uBoot:

Line 210:

Line 286:

* 1:54 finished booting

* 1:54 finished booting

−

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the fist stages up until init (kernel finished establishing itself) to be faster.

+

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the first stages up until init (kernel finished establishing itself) to be faster.

Qi is a lightweight replacement for the U-Boot bootloader with everything that doesn't assist "loading" and "booting" Linux stripped out. Distributions provide tar.gz-images of their root file system, that can be uncompressed on a MicroSD-card and Qi boots stable that distribution just by inserting the MicroSD in your freerunnner. E.g. changing the distribution from SHR to QtMoko can be done just by replacing one MicroSD (SHR) with an other MicroSD card (QtMoko) without using the boot menu.

actively developed (u-boot on GTA02 is deprecated)ATM qi is not developed, but supported, but main u-boot branch is really developed

easier configuration, more robust and predictable actually it needs to be recompile to change kernel parameters, nothing really robust or predictable

SD and SDHC cards supported properly with partitions of any size as in u-boot

kernel size is detected by checking the start of the kernel image, so large (>2M) kernels are supported without tweaking or loading more than needed procedure of changing kernel size in u-boot is not 'tweaking', just configuration

If you want to install Android on you OpenMoko you can use Qi. The Android on Freerunner kernel image can be more than 2MB in size. The UBoot environment that comes with your FreeRunner is only able to boot a kernel of 2MB in size or less. Qi support kernel images greater than 2MB out of the box.

You can use Qi if you want to exchange the distribution on your Freerunner just by exchanging the MicroSD card.
If you do not use the NAND memory as an backup distribution you can mount the NAND-memory as a home-directory or as documents. This helps to keep all the personalized data on the freerunner/mobile phone when you exchange distrubtion via exchanging MicroSD-card.

If the kernel is found on uSD, Qi assumes the rootfs to be on the same partition as the kernel. In case of boot from NAND, it assumes that rootfs is also on NAND (just as u-boot does). See below for help with an extra /boot-partition. The default rootdelay is 1 second.

Kernel images, Qi will look for (can be in either uImage (u-boot image) or zImage format, file name should still be uImage-GTA0[123].bin)

/boot/append-GTA0[123]

Additional kernel arguments. All arguments should be on the first and the only line separated by spaces, for example: "loglevel=8 rootdelay=5 " . Make sure you have an extra space after the last argument (space is no longer needed if the version is from 31 Jan or older)!

Since SHR (and perhaps other distributions as well) ouput log messages during resume which slow down the resume process by ca. 3 seconds it make sense there to append the following settings to /boot/append-GTA0[123]:

loglevel=1 quiet

The disadvantage of this speedup is that you won't see any lifesign of your phone until it starts the graphical user interface after adding these files, though.

Qi will try to mount each SD partition as ext2 / 3, if that succeeds it will look for the kernel as /boot/uImage-GTA02.bin. If that is found, it'll be fetched, its CRC is checked and then it's booted into with a generated kernel commandline.

Because Qi has no private stored state, it infers and composes a suitable kernel commandline on each boot.

One of its tasks is to scan NAND memory using the U-Boot dynparts rules to determine the start offset of the NAND partitions on this device, from that it forms the mtdparts kernel parameter that sets Linux's view of NAND partitioning.

The other thing it does is mount the "identity" partition and get from there the globally unique MAC address for the USB over Ethernet function instead of the random one that is otherwise used (If this doesn't work (like with a GTA01) you may use kernel-commandline parameters g_ether.dev_addr= and g_ether.host_addr= for the mac in device and host mode of the usb-ether module).

A short press on the power button is enough to make Qi start booting. In a few seconds the backlight will be lit, but the kernel will not spew any console messages unless something is wrong. It may take up to 2 minutes (depends on distribution) until X is started during which there will be no visual feedback. Please be patient.

You can force debug messages on the LCM console by holding in the power button before Linux starts.

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). So press power, release power, press aux, wait for vibration, release aux.

On versions newer than Jan 18 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.

Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi.

Such system is already implemented for some Angstrom-supported devices and for Zaurus (see kexecboot).

Since 2009-11-16, a such project was initialized by Marc Andre Tanner. The project is called qi-bootmenu.

You can just hold in the power button, this automatically appends verbose debugging to the kernel commandline (loglevel=8).

If you always want verbose "dmesg" type debugging messages, you can do it like this:

[1]
If it's SD Card boot, just create a text file, e.g., for a GTA02 use

/boot/append-GTA02

on the rootfs in question, put in there

loglevel=8

and you'll see the messages on boot.

If it's NAND, according to [2] you need to copy the uImage-GTA02.bin under /boot/ directory also under NAND and then create /boot/append-GTA02 there as well. The other way, as that guide does not seem to work per se (fix this wiki if it should work and works for you) is to edit the default commandline in Qi for gta02 and recompile Qi.

If you have a separate partition for /boot, so that your kernel and rootfs are not in fact on the same partition, you will need to append a root= entry on the kernel commandline to override the default action of trying to use the partition where the kernel came from as the rootfs.

Add this in /boot/append-GTA0[123]:

root=/dev/mmcblk0p2

for a rootfs on the second partition.

Note that a default Debian installation puts the kernel straight in the root of /dev/mmcblk0p1, not in a boot subdirectory, expecting u-boot to mount it as /boot. In order for Qi to recognise this, create a boot subdirectory with a symlink to the kernel.

This can be improved a lot by using the quiet option on the kernel command line !!!!!!!!!

1:18 Openmoko 'please wait' splash

1:31 desktop animated splash

2:38 finished booting

Why 1'20 min from OM splash to end of boot here
and only 1'00 for the Qi version ???
Qi has no relation to this !!!!!!!!!

Booting identical setup with Qi flashed over uBoot:

0:00 power button held down

0:06 backlit black

0:13 please wait booting... (only this text on console for next 38 seconds)

0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi)

0:54 Openmoko 'please wait' splash

1:05 desktop animated splash

1:54 finished booting

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the first stages up until init (kernel finished establishing itself) to be faster.

Use Case

If you want to install Android on you OpenMoko you can use Qi. The Android on Freerunner kernel image can be more than 2MB in size. The UBoot environment that comes with your FreeRunner is only able to boot a kernel 2MB in size or less. Qi support kernel images greater than 2MB out of the box.

Both the lack of DFU and the boot menu are planned to be addressed by the backup / recovery rootfs.

FAT is not supported because it can't provide a rootfs, and Qi wants the kernel to come from the rootfs.

Defaults

If the kernel is found on uSD, Qi assumes the rootfs to be on the same partition as the kernel. In case of boot from NAND, it assumes that rootfs is also on NAND (just as u-boot does). See below for help with an extra /boot-partition. The default rootdelay is 1 second.

Files

/boot/uImage-GTA0[123].bin

Kernel images, Qi will look for (can be in either uImage (u-boot image) or zImage format, file name should still be uImage-GTA0[123].bin)

/boot/append-GTA0[123]

Additional kernel arguments. All arguments should be on the first and the only line separated by spaces, for example: "loglevel=8 rootdelay=5 " . Make sure you have an extra space after the last argument (space is no longer needed if the version is from 31 Jan or older)!

/boot/noboot-GTA0[123]

make Qi skip this partition

Speed up kernel resume for SHR

Since SHR (and perhaps other distributions as well) ouput log messages during resume which slow down the resume process by ca. 3 seconds it make sense there to append the following settings to /boot/append-GTA0[123]:

loglevel=1 quiet

The disadvantage of this speedup is that you won't see any lifesign of your phone until it starts the graphical user interface after adding these files, though.

Boot Order

Qi GTA02 Booting order

SD Partition 1

SD Partition 2

SD Partition 3

NAND

Memory Test

Qi will try to mount each SD partition as ext2 / 3, if that succeeds it will look for the kernel as /boot/uImage-GTA02.bin. If that is found, it'll be fetched, its CRC is checked and then it's booted into with a generated kernel commandline.

Kernel Commandline Generation

Qi commandline composition

Because Qi has no private stored state, it infers and composes a suitable kernel commandline on each boot.

One of its tasks is to scan NAND memory using the U-Boot dynparts rules to determine the start offset of the NAND partitions on this device, from that it forms the mtdparts kernel parameter that sets Linux's view of NAND partitioning.

The other thing it does is mount the "identity" partition and get from there the globally unique MAC address for the USB over Ethernet function instead of the random one that is otherwise used (If this doesn't work (like with a GTA01) you may use kernel-commandline parameters g_ether.dev_addr= and g_ether.host_addr= for the mac in device and host mode of the usb-ether module).

LED and Vibrator Signals

AUX LED is turned on either on:

Successful partition mount

Successful kernel pull

Successful initramfs pull

AUX 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

AUX 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

One Blue shine every ~10 second: did not find any valid kernel to boot

About four RED shines per second: kernel panic.

Booting

A short press on the power button is enough to make Qi start booting. In a few seconds the backlight will be lit, but the kernel will not spew any console messages unless something is wrong. It may take up to 2 minutes (depends on distribution) until X is started during which there will be no visual feedback. Please be patient.

You can force debug messages on the LCM console by holding in the power button before Linux starts.

Choosing a Kernel

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).

On versions newer than Jan 18 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.

Boot Menu

Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi. This does not exist yet (it's already implemented for some Angstrom-supported devices and for Zaurus, so porting should be relatively easy).

README

Tips, Tricks, Tweaks

General troubleshooting

Qi does not bring up the LCD backlight. If the backlight is lit, it means you have succeeded to boot into Linux.

If nothing else is happening or there is a panic, enable debugging messages as described below.

Enabling console messages

You can just hold in the power button, this automatically appends verbose debugging to the kernel commandline (loglevel=8).

If you always want verbose "dmesg" type debugging messages, you can do it like this:

[1]
If it's SD Card boot, just create a text file, e.g., for a GTA02 use

/boot/append-GTA02

on the rootfs in question, put in there

loglevel=8

and you'll see the messages on boot. If it's NAND right now you need to edit the default commandline in Qi for gta02.

/boot-Partition

If you have a separate partition for /boot, so that your kernel and rootfs are not in fact on the same partition, you will need to append a root= entry on the kernel commandline to override the default action of trying to use the partition where the kernel came from as the rootfs.

Add this in /boot/append-GTA0[123]:

root=/dev/mmcblk0p2

for a rootfs on the second partition.

Note that a default Debian installation puts the kernel straight in the root of /dev/mmcblk0p1, not in a boot subdirectory, expecting u-boot to mount it as /boot. In order for Qi to recognise this, create a boot subdirectory with a symlink to the kernel.

SD Initialisation

If you don't specify loglevel=8 in append-GTAXX, and booting fails with a "VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)", the SD card needs a little bit more time to initialise.

0:13 please wait booting... (only this text on console for next 38 seconds)

0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi)

0:54 Openmoko 'please wait' splash

1:05 desktop animated splash

1:54 finished booting

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the fist stages up until init (kernel finished establishing itself) to be faster.