Andrea Adami wrote: > > But this is critical problem only for boot. In the user space, there is > > a lot of chances to prevent it (udev, mount by ID). > ... > > So it would not be possible. Either mtd0 or mtd2. > > ok, so the only issue could be with pre 2.6.30 kernels / userspaces ?
No. It is generic. It depends on the .config and order of drivers load (it should be stable if it is compiled into kernel and arbitrary for modules). Before my patch[1]: kernel in mtd0 or mtd1 After my patch: kernel in mtd0 or mtd2 > With patched kexecboot I got now get : > > Got device '/dev/mtdblock0' (31, 0) of size 7Mb > Probing /dev/mtdblock0 > FS could not be identified > Can't detect FS type > Got device '/dev/mtdblock1' (31, 1) of size 53Mb > Probing /dev/mtdblock1 > + FS on device is jffs2 > Got device '/dev/mtdblock2' (31, 2) of size 68Mb > Probing /dev/mtdblock2 > + FS on device is jffs2 > Got device '/dev/mmcblk0' (179, 0) of size 489Mb > Probing /dev/mmcblk0 > FS could not be identified > Can't detect FS type > Got device '/dev/mmcblk0p1' (179, 1) of size 486Mb > Probing /dev/mmcblk0p1 > + FS on device is ext2 > Can't read next device line > Found 3 items > + processing 0: angstrom > + processing 1: angstrom > + processing 2: angstrom > * maximum priority 0 found at 0 > + [angstrom > /dev/mtdblock1 jffs2 53Mb] > + processing 1: angstrom > + processing 2: angstrom > * maximum priority 0 found at 1 > + [angstrom > /dev/mtdblock2 jffs2 68Mb] > + processing 2: angstrom > * maximum priority 0 found at 2 This list indicates: - NAND support loads first, PROM support is not (yet) loaded (for example NAND support in kernel and PROM support as module or so). > + [angstrom > /dev/mmcblk0p1 ext2 486Mb] > load_argv: /usr/sbin/kexec, -l, --command-line=root=/dev/mtdblock2 This is the last partition of NAND. > What will happen booting a 2.6.26 kernel? > In fstab we have: > rootfs / auto defaults 1 1 > How will be translated "mtdblock2 (31, 2) of size 68Mb" ? rootfs or /dev/root should be converted to the partition from the kernel command line. Is there available "boot by ID" feature? It may work across all 2.6 kernels. You may have a problem, because the new kernel may see a different partition number. > Finally, I'd like to fix the recipes of kexecboot and nandlogical in > order to respect the new layout. > Perhaps with some version-checking logic? Partition numbering depends on: - kernel version - kernel .config (what is compiled into kernel and what as module) - If both NAND and PROM support are in modules, then it is unpredictable. In worst case heuristic may help: grep kernel (2.6) for strings: "Boot PROM Filesystem" found: NAND smf=mtd1 NAND root=mtd2 NAND home=mtd3 "Boot PROM System" found: NAND smf=mtd2 NAND root=mtd3 NAND home=mtd4 [1] "Boot PROM Filesystem" nor "Boot PROM System" found: NAND smf=mtd0 NAND root=mtd1 NAND home=mtd2 "System Area" not found: Kernel cannot boot from NAND (e. g. hdd boot) In the last case, I am not sure, whether external CF may be hda1 fort spitz. If yes, the same problem affects internal HDD detection. (The order of CF slots changed sometimes after 2.6.26.) > Happily updater.sh relying on 2nd 2.4 kernel still works vanilla. Yes. [1]http://lists.infradead.org/pipermail/linux-arm-kernel/2009-October/002697.html I am not sure, whether it was accepted. If not, I plan to resend it. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus _______________________________________________ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
