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

Reply via email to