- Aug 17, 2011
- 197
- 93
Well the only issue left in the ports I'm working on is drivers. Every time I load a driver something screws up and hangs at boot. I'm thinking the best path is making a custom kernel to load my new setup.
CWM development
- Thread starter Biotic
- Start date
leeb
Member
- Jul 16, 2011
- 463
- 21
WAKE UP Everybody!!! 
I have recently bought a 7" pad with 4.03 AND a 3e version of CWM (branded by InfotMIC, of all people!)
(known as 'updater')...
Long-story-short, I am attempting to get it to work on another 4.03 so that the system can be saved/restored and:
I have successfully:
stripped the original 64-byte header,
gunzipped it
and cpio'ed it into a temp directory,
then modified the recovery.fstab from the version that had ONLY ONE WORKING device... the external TF (as /dev/block/mmcblk1p1).
Unfortunately, once re-assembled, the resulting UPDATER file is not being loaded by the boot-sd sequence.
I can only believe that it is caused by the saved-off 64-byte header is 'wrong' now, and thus it refuses to install it.
MY problem is that I do not know how to modify/generate that header to make it happy...
Any thoughts/ideas, anyone?
beggingonmyknees.jpg
EDIT:
I'd like eventually, to use Tuzz' 4.0.1.5 instead (which has more functions and loads fine but little else) but cannot breach the 'modified-wont-install' issue.
EDIT2:
I have finally remembered how to rebuild the images... now to get it complete!
I have recently bought a 7" pad with 4.03 AND a 3e version of CWM (branded by InfotMIC, of all people!)
(known as 'updater')...
Long-story-short, I am attempting to get it to work on another 4.03 so that the system can be saved/restored and:
I have successfully:
stripped the original 64-byte header,
gunzipped it
and cpio'ed it into a temp directory,
then modified the recovery.fstab from the version that had ONLY ONE WORKING device... the external TF (as /dev/block/mmcblk1p1).
Unfortunately, once re-assembled, the resulting UPDATER file is not being loaded by the boot-sd sequence.
I can only believe that it is caused by the saved-off 64-byte header is 'wrong' now, and thus it refuses to install it.
MY problem is that I do not know how to modify/generate that header to make it happy...
Any thoughts/ideas, anyone?
beggingonmyknees.jpg
EDIT:
I'd like eventually, to use Tuzz' 4.0.1.5 instead (which has more functions and loads fine but little else) but cannot breach the 'modified-wont-install' issue.
EDIT2:
I have finally remembered how to rebuild the images... now to get it complete!
Last edited:
leeb
Member
- Jul 16, 2011
- 463
- 21
I have completed the changes for the NAND-based EGL25BL (Tiny) and am satisfied with the results. The only possible remaining change would be to save the internal 2g 'Local-disk' portion...
I consider it acceptable as is, particularly since I can do a save to Windows OR Linux now...
IDEALLY, Id like to make saving it an OPTION... but I have another 'MMC-based with ramdisk and kernel 'elsewhere' to finish up first.
Not accessing ramdisk/kernel properly prevents the rest of the backup...
Otherwise, Im quite pleased with it!
I consider it acceptable as is, particularly since I can do a save to Windows OR Linux now...
IDEALLY, Id like to make saving it an OPTION... but I have another 'MMC-based with ramdisk and kernel 'elsewhere' to finish up first.
Not accessing ramdisk/kernel properly prevents the rest of the backup...
Otherwise, Im quite pleased with it!
