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. > > All in all this seems to becoming close to the debian-style initramfs > installer we have wanted for angstrom for a long, long time. Exactly! ;-). > > regards, > > Koen > [] -- Best regards, Paul mailto:[EMAIL PROTECTED] _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
