Random thoughts:

I would not want the changes to slow down the bootup time for a regular user. 
So by default no scanning for stuff (if it incurs a time penalty to the bootup
process).  Any extra features (made available to developers) that might incur a
time penalty should be enabled by a developer (because they would be off by
default).  Simple turn it on and off flags in Non-volatile storage for the
feature sets, they don't need to be configurable within the loader itself, but
they must be overrideable in some fall-back mode.  Corrupted data must have a
mechanism to be easily detected (CRC/checksum) and easily overridden (via USB
or MMC card) when in fall-back mode.


Having a fall-back mode that can always be enabled by some hardware keypress
during bootup.  The only thing this keypress would do for a regular user (who
was not actually trying to load an alternative would be a slower bootup
process).  If it exhaustively tried to work USB and secondary MMC to provide
bootup data in priority to the primary MMC.


Let the community write the boot loader they want, but provide them a way to
work on it (documentation, example, easier development lifecycle, ability to
recover their device).

Comment 2 Frantisek Dufka (reporter) 2009-12-04 10:48:09 UTC

(In reply to comment #1)
> Random thoughts:
> 
> I would not want the changes to slow down the bootup time for a regular user. 
> So by default no scanning for stuff (if it incurs a time penalty to the bootup
> process).

Agreed. Currently the procedure is more or less like this (PCMIIAW):

1. NOLO after some initialization checks if flasher is waiting on USB
- if yes it allows device flashing or changing various flags and parameters
(r&d mode, serial console, watchdog flags,..) stored in config partition. It
also allows to load custom kernel and boot it with custom kernel command line
supplied by flasher command line parameter
http://lists.maemo.org/pipermail/maemo-developers/2009-November/022673.html

-  if flasher is not connected it scans config partition for various flags,
prepares parameters for kernel (ATAGS) loads kernel from hardcoded kernel
partition (named "kernel" /dev/mtd2) and jumps to it


The proposed change is to:
1. add extra config parameter (cmdline) that is passed to kernel just like
flasher -b does, it should be settable via flasher just like other parameters
are. We could ser root device here or any other kernel parameter.

2. add config parameter (kernel) that should point to kernel image (full image
name or even just device partition name like
nand:kernel,nand:mtd2,mmc1:part1,mmc0:part3)

> Simple turn it on and off flags in Non-volatile storage for the
> feature sets, they don't need to be configurable within the loader itself, but
> they must be overrideable in some fall-back mode. 

Yes, exactly. flasher is the fallback mode. You could always change flags over
USB before kernel is booted so you can always revert them to boot default
configuration.

In Openmoko Neofreerunner phone the Qi bootloader was searching all the
partitions on card and internal memory for the kernel. Then if it found kernels
on card it booted them, if not started the boot process from internal memory.
Kernel options could be passed to the kernel during boot using the text file in
the same directory with kernel. Booting from certain partitions with could be
locked using the empty file with specific name. More information about this
boot process can be found at http://wiki.openmoko.org/wiki/Qi
I think that method was flexible and easy to use (generally the end user only
had to unpack the root file system on the card and everything was already
configurated, and if someone wanted to change something then he knew what he
was doing and it was no problem for him to edit a text file). A good idea would
be to make some configuration in bootloader to chose if we want to scan all the
cards of disabling it and only booting from internal memory to speed up the
boot process.

In addition I have some difficulties booting the original Maemo 5 system from
mmc card. I think even if we had an ability in bootloader to boot from memory
card the original system could not boot anyway. I've described problem at
http://talk.maemo.org/showthread.php?p=412045 . Help on booting the original
system from card would be very appreciated.

> With removing of initfs with maemo 5 there is no suitable place for changing
> the boot sequence and booting other linux distributions except hooking into
> rootfs (/sbin/preinit) which is not ideal (too late, needs Maemo rootfs to be
> OK to boot other system).
Using either eMMC-stored initrd/initramfs (Why does everybody call it initfs
here? Is it block-based initrd or cpio-based initramfs archive?) is somewhat
hacky. It needs the eMMC card to be fully working and undamaged, so if you wipe
all data out of it, you won't boot. It will most likely be .. how they call it?
"Bricked"?

The point here is if Nokia _wants_ to have this part opened as well. I
understand the marketing reasons for allowing to boot Maemo OS only, at least
for the moment.

I have to apologize for my poor knowledge about boot procedures on non-x86
devices, the following might not be the best solution, but it's worth
considering.
First - I'm not sure how exactly is OMAP3 involved in booting, I've tried
looking for whitepapers about this, the only thing I found was a nice diagram
mentioning the "Boot / Secure ROM", nothing more. Anyway, I suppose it simply
boots from MMC/SD based memory.
In ideal world, here could be a separate (for example NOR-based) memory
containing the bootloader (I shouldn't call it BIOS, right?). Since we don't
want to store a separate batery for it, it'd have to be mostly read-only - it
could load configs from some partition (on the internal eMMC card?) and boot
using information in them. If the config partition is not found, it can start a
hardcoded boot procedure, like "boot from SD first, continue on to eMMC". Or
even simplier - omit the config partition completely, hardcode the sequence and
use some sort of button combination to invoke the boot menu (possibly featuring
things like PXE, ..). The key part here is - this bootloader can be eventually
closed-source, it doesn't have to know anything about filesystems, it only
_chainloads_ SD/eMMC. That means you can put u-boot or anything else on the SD
card, just like you do with x86 bootloaders on classic HDDs in desktop PCs.
Same applies to eMMC - closed-source NOLO could be there and (I believe) nobody
would care as long as he can safely boot from his SD card, even if the eMMC
contains all zeros.

> In Openmoko Neofreerunner phone the Qi bootloader was searching all the
> partitions on card and internal memory for the kernel.
I remember u-boot there, the device had one small NOR memory (containing older
version of u-boot) used for rescue operations (ie. zeroed NAND) and a primary
NAND memory with it's own bootloader (newer, easily updatable version of
u-boot). Normal boot invoked just the NAND, however it was possible (using
special button combination) to boot from NOR and write the rescue bootloader to
NAND / boot from SD card / etc. It's a bit "geeky" approach, I know.

Now to the realistic world - I don't expect any large manufacturer to do this
anytime soon, the exception might be real computer-based systems instead of
smartphones.
So the simple (and probably fastest) solution here is to make NOLO boot from
the SD card (if it's bootable) using chainloading (ie. start
u-boot/Qi/your_asm_app there) and, if it's not possible, load the Maemo kernel
directly, another chainloading here is probably useless. It would be done only
when booting the SD card, no slowdown for classic Joe.
How to check if a device is bootable? I saw Qi scanning for SD card partitions,
trying ext2 filesystem. Wouldn't it be better to use the so-called bootloader
fingerprint (IIRC it was 0xAA55 on IBM PC) to indentify a bootable card?

I don't know how much is this chainloading/chainbooting slower, it wasn't
really noticeable using LILO on x86. I also have no idea why Freerunner didn't
use this method instead of hardwiring button combinations to NOR boot.
I might have as well skipped something like "OMAP instruction set makes exec()
impossible", "it takes 5 minutes" or similar thing, though I haven't found
anything. Again, I'm no ARM developer, so the whole idea might be just junk.

Comment 5 Quim Gil 2009-12-07 09:12:45 UTC

The scope of bugs.maemo.org are bugs and only very specific and no-brainer
enhancement requests. This report contains a feature request that is too
generic for bugs.maemo.org. Please post this problem and propose your
solution in Maemo Brainstorm instead:
  http://maemo.org/community/brainstorm/

More information: http://wiki.maemo.org/Maemo_brainstorm

Comment 6 Frantisek Dufka (reporter) 2009-12-07 10:53:25 UTC

(In reply to comment #5)
> The scope of bugs.maemo.org are bugs and only very specific and no-brainer
> enhancement requests. This report contains a feature request that is too
> generic for bugs.maemo.org.

Well I see that most comments are like this (Hello N900 users, welcome to Maemo
:-) but the original request is very specific and relatively easy to do. The
first request - kernel command line stored in config partition could be in
tenths line of code. The complexity of second one depends on how/when/where mmc
initialization is done, if we are lucky it can be quite easy too.


> Please post this problem and propose your
> solution in Maemo Brainstorm instead:
>   http://maemo.org/community/brainstorm/
> 
> More information: http://wiki.maemo.org/Maemo_brainstorm


IMO this is too technical for Brainstorm. Even here most comments are deviating
from 'few minor tweaks' into 'pie in the sky' thing.

This was originally about few tweaks to NOLO not new bootloader.

If it is realistic to switch to different and open bootloader then this is
different topic and as such it could use some wider discussion indeed. Please
post this problem and propose your solution in Maemo Brainstorm :-) I hope it
doesn't kill this bug/enhancement though.

BTW, I wonder why I cannot REOPEN this bug. I see only
Leave as RESOLVED MOVED
Mark bug as VERIFIED
Mark bug as CLOSED

Comment 7 Eero Tamminen 2009-12-10 19:18:26 UTC

> It is also possible to flash eMMC image from inside NOLO so MMC code is there

AFAIK:
- during Fremantle development a lot of earlier bootloader functionality
  was dropped because most of same functionality was also in kernel and
  it needed updating for Fremantle (nobody wants to maintain two different
  code bases for the same functionality).
- eMMC flashing isn't done by the bootloader, it starts kernel & minimal
  user-space system to do the eMMC flashing.

I think you need kexec to boot a kernel from eMMC.

If kexec works (I don't know), you might e.g. be able to append a small initfs
to kernel image which would do the work.  Initfs partition might be used for
this too, I don't think it's currently really used for anything[1].

[1] But according to internal bug 143346, initfs may go away in some next year
Fremantle release to get slightly more space for the rootfs.

Comment 8 Frantisek Dufka (reporter) 2009-12-11 11:25:32 UTC

(In reply to comment #7)
> - eMMC flashing isn't done by the bootloader, it starts kernel & minimal
>   user-space system to do the eMMC flashing.

OK, then we are not lucky with feature #2, what about #1 kernel command line?

> 
> I think you need kexec to boot a kernel from eMMC.
> If kexec works (I don't know)

I tried with previous kernels (770/2.6.16-N8x0/2.6.21) and failed. It needs
patching for kexec feature itself and then extra patching for saving ATAGS
received from bootloader and passing it to new kernel again and then it still
did not work for me, it simply hangs when booting new kernel until watchdog
reboots it. I had no serial console working at that time so it was impossible
for me to debug. Either it was some stupid bug or there are issues with
hardware being left in state that new kernel doesn't like or something.

I agree that kexec is the way if we can get it to work.

> you might e.g. be able to append a small initfs
> to kernel image which would do the work.

This is not supported on ARM architecture in general. That would need support
from bootloader or changes in kernel. See links in
http://lists.maemo.org/pipermail/maemo-developers/2009-December/022754.html

>  Initfs partition might be used for
> this too, I don't think it's currently really used for anything[1].
> 
> [1] But according to internal bug 143346, initfs may go away in some next year
> Fremantle release to get slightly more space for the rootfs.
> 

Indeed. I know that initfs currently lies there unused but it is just a matter
of time when it goes away (Harmattan most probably). I feared it might even go
away with some Fremantle update and you just confirmed my fears. And BTW, jffs2
and mtdblock is not enabled in default kernel so it would need users to flash
different one just to have bootmenu in initfs.

Well, OK, this looks more hopeless that I thought. Requested feature #1 would
be very useful for setting root device name but then we would need also some
usable filesystem in kernel. Currently there is only ubifs and the rest is as
modules. I wonder why. Stock system needs both fat and ext2 for eMMC anyway so
having it in kernel is not wasting any space. It would even save both some RAM
(as each inserted module has some extra overhead) and some tiny rootfs
diskspace too.

So can I fill "put ext2 and vfat into kernel" enhancement here in bugzilla or
does every little enhancement need to feel the Brainstorm pain?

As for dual boot in general I understand now that we need to think big and go
to Brainstorm with "Allow booting alternative systems out of box" idea but that
looks like very long run.

Comment 9 Eero Tamminen 2009-12-11 11:49:31 UTC

(In reply to comment #8)
> (In reply to comment #7)
> > - eMMC flashing isn't done by the bootloader, it starts kernel & minimal
> >   user-space system to do the eMMC flashing.
> 
> OK, then we are not lucky with feature #2, what about #1 kernel command line?

I asked about this, let's see...


> > I think you need kexec to boot a kernel from eMMC.
> > If kexec works (I don't know)
> 
> I tried with previous kernels (770/2.6.16-N8x0/2.6.21) and failed.

These are known not to work, I was mainly wondering about Fremantle kernel.

When I asked about this some months ago, it was "supposed" to be supported by
Fremantle kernel, nobody just hadn't tested whether it works (as it's not a
feature needed by Fremantle).


> > you might e.g. be able to append a small initfs
> > to kernel image which would do the work.
> 
> This is not supported on ARM architecture in general.
> That would need support from bootloader or changes in kernel.

AFAIK there should be support for it at least when Fremantle kernel image is
"flashed" to RAM.  Don't know about when it's on flash.  And how much space
there's left of kernel image partition...


> And BTW, jffs2 and mtdblock is not enabled in default kernel so it would
> need users to flash different one just to have bootmenu in initfs.

Right, UBIFS wouldn't fit to initfs partition, it's base size is quite large.

But if there's enough space on kernel partition, you might be able to append
RAM file system to kernel image that's loaded at the same time as kernel.


> Well, OK, this looks more hopeless that I thought. Requested feature #1 would
> be very useful for setting root device name but then we would need also some
> usable filesystem in kernel. Currently there is only ubifs and the rest is as
> modules. I wonder why. Stock system needs both fat and ext2 for eMMC anyway
> so having it in kernel is not wasting any space.

I think the kernel developers appreciate the flexibility.  When they're
modules, you can give a RAM file system to use which has newer or debug
versions of the modules.  Then there's also the question of kernel partition
size.


> As for dual boot in general I understand now that we need to think big and go
> to Brainstorm with "Allow booting alternative systems out of box" idea but
> that looks like very long run.

Is it really such a big problem to have the bootmenu on the rootfs?

Kernel bootup doesn't take that long and with UBIFS the rootfs mounting is
*much* faster than with JFFS2.  If you're mostly booting from eMMC (with
kexec), there shouldn't even be much possibility of something going wrong with
the UBIFS rootfs.  Only thing you lose is some seconds on startup and in normal
use one shouldn't need to boot the device that often... Right?

Comment 10 Frantisek Dufka (reporter) 2009-12-11 14:16:48 UTC

(In reply to comment #9)
> These are known not to work, I was mainly wondering about Fremantle kernel.
> 
> When I asked about this some months ago, it was "supposed" to be supported by
> Fremantle kernel, nobody just hadn't tested whether it works (as it's not a
> feature needed by Fremantle).

That's good news. Thanks. Will try eventually. Got N900 two days ago :-)


> AFAIK there should be support for it at least when Fremantle kernel image is
> "flashed" to RAM.  Don't know about when it's on flash.

as far as i understand it (links in my previous comment) the zImage format for
ARM simply does not support embedded ramdisk so it needs support in bootloader
to either load them separately or from one image archive is specific format
(not zImage)

> But if there's enough space on kernel partition, you might be able to append
> RAM file system to kernel image that's loaded at the same time as kernel.

See above. BTW what is the flasher syntax to load ramdisk and boot it? Flasher
help has no hint that this may be even possible, maybe something like

./flasher-3.5 --initfs=cramfsimage --kernel=zImage  --boot="root=/dev/ram0 rw
initrd=???????"


> Is it really such a big problem to have the bootmenu on the rootfs?

Well, IMO it is bad enough to try something else. Few reasons:

It should be as failsafe as possible. People doing e.g. apt-get upgrade
removing busybox will kill booting from rootfs AND any other system completely.
It was quite hard to unconsciously break initfs. And then you could still
reflash just the initfs, boot from mmc and recover anything important left in 
rootfs - no need to reflash whole rootfs.

When there is no initfs the rootfs is basically degraded into role of 256MB
initfs i.e. you should always think twice before touching it or other systems
will not boot. Also when system update comes it may break dual booting too.

The aim is simply to have alternative system completely independent from system
in flash. pre-Fremantle initfs was not ideal either but better than current
state.

Another reason is to have internal flash free for other usage - think about
swapping to UBI volume (not there yet but doable) when booting main system from
eMMC. 256MB is good enough for swap and may be faster than swapping to mmc and
additionally it would take off the i/o load from eMMC speeding it further.