trying Qi

HackCandy hackhell.candy at
Fri Jan 30 22:40:29 CET 2009

Hi Andy/Werner,

As far as I have seen from the threads,
We are going to use QI fully burying U-boot.

So, Bootloader going to be used is: Qi
Method to switch between distros: Not AUX button 
			(with vibrate indication)

1) If bootloader is going to be Qi and if we have multiple distros in SD
(and if we are going to use Menu option for distro selection using a minimal
then the first partition should contain the Kernel + minimal rootfs, so that
Qi can pull
it and present to the user for selection. Otherwise, (say some other distro
is present) 
user will not have an option to select. It straight away boots off from the

Note: Qi checks for the kernel in SD card P1, P2, P3 and finally NAND.

So it mandates the SD P1 to contain Kernel + minimal rootfs.

2) Also, the above case works well if the SD contains Kernel + minimal
partition alone and no other distro partitions. That is, Qi will pick the
SD P1 Kernel & Minimal FS, and present a UI to the user which contains the
only boot option.

3) If we make the Kernel + minimal RFS in the flash, we need to change the
of Qi to look into NAND first and then SD P1, P2 and P3. Will that be

If we are going to place the Minimal Kernel + RFS inside the NAND flash, Can
identify it properly? {Because there will be two kernels as well as 2
(one minimal and the other jffs2 which contains a distro)}

I am confused. :(

Sorry if something seems stupid.

- HHC.

Werner Almesberger wrote:
> Andy Green wrote:
>> I've been heading towards being able to mass-build different configs on
>> a new multicore build machine here.  Various changes need making but
>> it's coming in sight now.
> Great ! No better way to catch those pesky build issues early.
>> So I added this config to the tree as
>> arch/arm/configs/gta02-micro_defconfig
> Cool, thanks !
>> The initramfs business causes the build to die
>> ~  /projects/openmoko/kernel/linux-2.6/scripts/
>> Cannot open '/home/moko/
> Yup, that one's always a nasty site-specific dependency. One way
> to make it a bit less ugly would be to set it to something like
> $(INITRAMFS_ROOT) and then pass the actual location via an
> environment variable.
>> Yeah.  But the priority is zero until there's a use case for, eg, GTA02
>> build without Glamo or whatever.
> I actually turn off the whole Glamo from time to time when building
> for my GTA02 with sick uSD. So that path already gets exercised.
> But yes, the next round of kernel diet can wait a little.
>> What we need next then is a modest static or small set of lib dependency
>> app or script that does the actual menu and touchscreen action.
> Yup. Any takers ? Now the barrier of entry should be pretty low
> and there's a nice weekend ahead ... :)
> - Werner

View this message in context:
Sent from the Openmoko Kernel mailing list archive at

More information about the openmoko-kernel mailing list