mirror of
git://projects.qi-hardware.com/xburst-tools.git
synced 2024-11-01 16:25:20 +02:00
51ce8bac68
Change to input / pulldown on most GPIO. With no battery and just USB power, this gets us into suspend with 9.5mA at 5V consumption... but Ben Dooks told that we don't put the mDDR into deep sleep yet in the platform pm code, so this should come right down when we have that. The suspend is otherwise real though, PWREN to the PMU goes down, and when we wake the device Qi is able to see it is a resume wake and jumps back into Linux, where we currently die due to issues on s3c6410 platform code getting worked on. Signed-off-by: Andy Green <andy@openmoko.com> |
||
---|---|---|
.. | ||
include | ||
src | ||
tools | ||
6410-partition-sd.sh | ||
build | ||
config.mk | ||
dfu-qi | ||
gta02-qi.ocd | ||
Makefile | ||
openocd-openmoko-debug-6410.cfg | ||
README |
Qi == 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 /boot/uImage-GTA02.bin. 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. 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.