Talk:Advanced booting

(suasweta: new section)
m (Protected "Talk:Advanced booting" [edit=autoconfirmed:move=autoconfirmed])
 
(One intermediate revision not shown)
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.
-
 
-
== suasweta ==
 
-
 
-
http://acheter-viagra-generique.org/ achat viagra   
 
-
http://viagra-generico-espana.org/ viagra   
 
-
http://achatviagragenerique.org/ generique viagra 
 
-
http:///acheter-viagra-generique.net/ viagra acheter   
 
-
http://comprar-viagra-sinreceta.net/ viagra 50 mg   
 
-
http://bestellenviagragenerika.net/ viagra bestellen   
 
-
http://acquistare-viagra-generico.net/ viagra
 

Latest revision as of 17:01, 8 August 2012

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.