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===

===Defaults===

Revision as of 21:07, 1 February 2009

Qi is a replacement for the uBoot bootloader reduced to the core bootloader functions.

About Qi

Requirements

GTA02 Hardware is recommended over GTA01, since GTA02 does have a fallback u-boot in nor that provides DFU-Mode. Qi does NOT provide DFU-Mode so GTA01-Users will have no (easy) way to flash their device!

Features

booting from primary SD partitions (1st, 2nd or 3rd)

booting from NAND

configuration by files in /boot

automatically choose correct kernel for device hardware

ext2/3 are supported

symlinks are supported

Limitations

no DFU-Mode

no boot menu

FAT partitions are ignored

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

Boot Order

SD Partition 1

SD Partition 2

SD Partition 3

NAND

Memory Test

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.

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

Enabling console messages

[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 Partition for /boot, you will need to add a argument for the kernel to know which partition is 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.

About Qi

Requirements

GTA02 Hardware is recommended over GTA01, since GTA02 does have a fallback u-boot in nor that provides DFU-Mode. Qi does NOT provide DFU-Mode so GTA01-Users will have no (easy) way to flash their device!

Features

booting from primary SD partitions (1st, 2nd or 3rd)

booting from NAND

configuration by files in /boot

automatically choose correct kernel for device hardware

ext2/3 are supported

symlinks are supported

Limitations

no DFU-Mode

no boot menu

FAT partitions are ignored

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

Boot Order

SD Partition 1

SD Partition 2

SD Partition 3

NAND

Memory Test

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.

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

Enabling console messages

[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 Partition for /boot, you will need to add a argument for the kernel to know which partition is 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.