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
___
Openmoko community mailing list
community@lists.openmoko.org
