Hello,
On Sun, 17 Feb 2008 12:23:48 +0100
Koen Kooi [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Sokolovsky schreef:
| Well, I sent RFC on that:
|
http://lists.linuxtogo.org/pipermail/angstrom-distro-devel/2008-February/001776.html
| So yes, this is 2nd stage kernel+initramfs solution, replacing a
kernel | loaded by 1nd stage bootloader (be it haret, HH.org
bootloader, | anything else) [some time ago I proposed to consider
NAND bootstrap | loader as 0th stage, so I assume that numbering]. At
the same time, | bootloading (actually, interactive selection)
functionality is made to | be transparent and used only if no root=
was specified on kernel | commandline. So actually, it's a drop-in
replacement for production | kernel too, which fact RFC above
emphasizes and exploits.
Let me see if I understand it correctly:
[]
Well, let me reword it differently, as all it is done with
cross-unification in mind:
1. 1st-level bootloader is tasked with one and only simple task:
to load and run Linux kernel. In particular, flash-based bootloaders
will need to load it either from dedicated flash partition or from a
rootfs if they are smart enough from that.
2. That kernel which they load is actually a kernel bundled with
initramfs-bootmenu-image.
3. It first checks if kernel command is a bad from a known bad
bootloader, in which case it ignores it. Otherwise, if root= is
specified, rootfs is booted from that location. All builtin kernel boot
options are supported, plus consistent extension syntax for other
options (like loopback boot).
4. Otherwise (no root= or cmdline from bad 1st stage bootloader), it
shows interactive menu listing of all available block devices with
supported file systems. These include: ext2, jffs2, and for vfat -
loopback images in the root directory. Also, NFS option is given.
5. Once user selects location, it checks if /boot/zImage (sic) exists,
and if so, kexecs to it with appropriately constructed root=. If
no /boot/zImage exists, it just uses that rootfs directly
(switch_root's to it).
6. To support booting from various filesystems, this new kernel should
have initramfs itself to pull up needed modules. Also, to support
extended boot syntaxes (loop e.g.), it should be initramfs-uniboot
itself. Then, interactive selection is just a small module of it, and
the whole thing can be just bundled with initramfs-bootmenu-image, or
in other words, bootloader and production kernel is the same zImage!
Notes: On step 5, special param is passed on the command line, to avoid
recursive kexec invocation and force switch_root behavior for
production kernel.
* on (non-hx4700) bootldr machines /boot/zImage will hold kernel +
initramfs that kexecs a different kernel
So we have devices without dedicated root partition? Live and
learn. ;-D So yes, this is another reason why bootloader and production
kernel should be the same file. So, initially /boot/zImage will be
loaded in bootloader mode, and will allow to select actual boot
location. But without any accidental gaps in that - no I can boot from
flash and CF, but not SD. And if user selects flash boot, it will
kexec very itself, but this time in production kernel mode.
* on hx4700 the kernel partition holds kernel + initramfs that kexecs
a different kernel (/boot/zImage?)
Yes.
* on angelboot (read: zaurus) machines the kernel partition holds
stripped down kernel + initramfs that kexecs a second kernel (with
more dirvers) with a bigger initramfs which kexecs a third kernel to
boot into final userspace
If Zaurus people will be so kind to adopt solution above, then yes. (I
once again want to stress fact that I personally dropped my efforts of
reviving LAB with the idea for us all to make a common ultimately
flexible solution). Then yes, to overcome kernel partition size
restriction, an adhoc initramfs can be used with the only task to boot
big kernel from flash, and that kernel can be one with
initramfs-bootmenu-image bundled, offering all the choices above.
* we leave u-boot machines alone for now, since most u-boots are quite
sensible nowadays.
Yep, but that of course will work for it too. My ultimate goal would be
to engineer a Ultimate Rule Them All bootloader which would do only
point 1 from the above, and thus will be small and easily portable.
Marcin: is that the same idea you had for angelboot machines, or will
we repartition flash and put in our own rescue filesystem?
I already approached discussing this with Z people, and regret to say
that we didn't find too much understanding, from my point of view this
seemed like they want to re-make their own wheel of special,
small, but sacred size gifted/burdened upon them by Gods of The Old
Vendor ;-).
Well, I'd like to draw attention that it all works now (kexec support
added 2 days ago, jffs2 loading debugged yesterday), and has zero
machine affinity in it, so we can start working together on
optimizing/elaborating it.
