Talk:Advanced booting
(→all-inclusive: new section) |
(Undo revision 46049 by 109.186.40.225 (Talk) spam) |
||
Line 8: | Line 8: | ||
As for pre-caching initfs before flashing - this may not be strictly needed, maybe everything important is already cached, it is added just in case. We want to prevent situation where we are erasing/flashing /dev/mtd3 and bme or dsme causes some (both read or write) I/O and jffs2 driver becomes confused since we just erased mtd3 or completely rewrote it with different data. | As for pre-caching initfs before flashing - this may not be strictly needed, maybe everything important is already cached, it is added just in case. We want to prevent situation where we are erasing/flashing /dev/mtd3 and bme or dsme causes some (both read or write) I/O and jffs2 driver becomes confused since we just erased mtd3 or completely rewrote it with different data. | ||
- | |||
- | |||
- | |||
- |
Revision as of 06:26, 16 December 2011
Great someone is documenting this, thanks :-) Few random comments:
cp -a /mnt/initfs initfs is not best idea, you will copy also unneeded stuff in proc, sys, dev, tmp ... and you may also miss hidden stuff under some such mount point (/dev), safer is
mount -t jffs2 /dev/mtdblock3 initfs.orig cp -a initfs.orig initfs
As for inplace editing, this is somewhat safe with Diablo. With older 2MB big initfs the danger was real. With just few (5-10?) edits of linuxrc file one may end with partially written (truncated) linuxrc and no way to fix it.
As for pre-caching initfs before flashing - this may not be strictly needed, maybe everything important is already cached, it is added just in case. We want to prevent situation where we are erasing/flashing /dev/mtd3 and bme or dsme causes some (both read or write) I/O and jffs2 driver becomes confused since we just erased mtd3 or completely rewrote it with different data.