Qi vs U-boot (was Re: QtMoko v30; UBIFS; can't boot)

[Ivan Matveev]

Hi Gennady!
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 

wget http://www.bsdmn.com/openmoko/uboot/config/environment.in
less environment.in

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
parameter?

> Minimalism? 
1. 
>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.

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

3. 
> Or that nothing except kernel
> parameters may be configured without recompilation? 

What else do we(users, application developers) need?

4. 
> 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?

5. 
> 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
environment.in.
 
> 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
stdlib functions.

In the course of researching the 'no NAND QtMoko' situation I'v tried
the following combinations:

qi-s3c2442-master-hist_3b8513d8b3d9615e.udfu; uImage-v26.bin;
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.

<provocative content>
Still I like Qi better. Small program that does
only 1 thing is the UNIX way 
</provocative content>