Qi vs U-boot (was Re: QtMoko v30; UBIFS; can't boot)
imatveev13 at nm.ru
Tue Dec 28 04:04:12 CET 2010
Lets burn some linux.org.ru style flame!
> > > > I don't want to go back to u-boot.
> > >
> > > I disagree - going to Qi is going back, going to u-boot is going
> > > forward :)
> > I like Qi's minimalism, automatic setup of many options and text
> > config files.
> "Automatic" setup is done by person who provide you with Qi. If
> someone start supply u-boot_env with distros, u-boot setup will be
> equally "automatic".
As always with "automatic" someone has to build the mechanism. Qi has
it already. Why shell I bother with u-boot numerous(poorly documented)
options? I know u-boot is more configurable, but I just want to boot.
If I start developing an FR kernel I'l learn u-boot ways. A regular user
wold like a bootloader as configurable as grub, not a set of cryptic
scripts we have with u-boot.
> It's also possible to setup u-boot like qi, 'read kernel first from sd
> part 1, boot if loads, then try from sd part 2, boot if loads, then
> from nand'. All with 10 lines in config file. Just noone need it.
No one needs the good stuff :).
> What 'text config files' in Qi you talking about? Does it have config
> files at all? If you mean ability to append kernel parameters this not
> like u-boot config files, only 1% of that flexibility.
I think if I
I will see much more than 1% of kernel parameters in the file.
Can you give an example of a valuable non kernel parameter bootloader
>You mean that Qi works only on Freerunner, has no support
> to anything else?
I do agree that Qi is not as supported as u-boot(thank you for
your advice on u-boot, sincerily). We shell spread word on Qi to make
it more popular and supported and make it an embedded grub.
> Or that you need to use NOR u-boot to flash
> something to NAND as qi can't do it?
Decision to have 2 bootloders(NOR and NAND) in FR was a wise one
and was a result of experience with neo1973 that was easy to brick by
flashing a bad bootloader. With this design one of the bootloaders can
afford to be minimalistic.
> Or that nothing except kernel
> parameters may be configured without recompilation?
What else do we(users, application developers) need?
> Or that it can't display anything on screen so you have to decode
> errors by amount of blinks?
If you press power button at the right moment you will have
loglevel=8. You will see kernel debug, not bootloaders. Why should a
user care? Does every FR user have to develop a bootloader?
> Or that it adds 'quiet' kernel options by default, so you
> can't see boot logs?
See 4. on power button.
> > I'v tried u-boot just to be shure.
> > Didn't edit environment.in because don't know what to put there.
> You must edit it to boot, mine is only example suitable only for my
> custom setup.
Well, I must edit environment.in. How shell I know what do I put there?
I'm no u-boot expert. Can you provide the catch all u-boot config? That
wold be a good u-boot advocacy.
> > From http://wiki.openmoko.org/wiki/U-boot-gena2x:
> > A press on the power button. FR emits a barely audible click and
> > then nothing, the screen stays blank.
> This only may happen if you battery discharged or 'default' boot way
> is not setup properly. Try menu with power+aux like described on wiki.
The battery was full. There was no u-boot setup whatsoever only sample
> I think qi is NOT reading u-boot_env, so you just had different Qi
> version before.
I'm waiting for Radek's comment on this. Qi's sources are not easy, no
In the course of researching the 'no NAND QtMoko' situation I'v tried
the following combinations:
qtmoko-debian-v26.jffs2; did boot OK
qi-v28.ubifs.udfu; uImage-v28.bin; qtmoko-debian-v28.ubi; didn't boot
qi-v30.udfu; uImage-v30.bin; qtmoko-debian-v30.ubi; didn't boot
> > > I think it is also possible to make such config that appends
> > > kernel params load from file on external fs, like in qi, but who
> > > needs this...
> > I think its not external fs that matters but u-boot_env
> > format.
> Seem i didn't describe my idea very well. I think it's possible to
> write such env for u-boot, that will read text 'append' portion of
> kernel params like qi does. So, you'll have similar fun of editing
> text files with kernel options, like you have in Qi.
Please tell me how to do this! I have no religious bind to Qi. To hell
with minimalism, let us all use the bootloader that is standard, smart,
configurable and well supported.
Gennady I admire yours contribution to the community. Please do not be
offended. I was frustrated by FR suddenly not booting.
Still I like Qi better. Small program that does
only 1 thing is the UNIX way
More information about the community