[G1 Android Development] Phonekenstein:
Seems that a refurbished G1 I received has 3 blocks stuck and marked in eccUnfixed for some time, pulled the info from command:

cat /proc/yaffs

Issues:

I'm thinking as our G1s are getting older and with ROM flashing abuse we are killing NAND blocks on them fast. Researching at various sites linux-mtd & Yaffs.net, the garbage collector of Yaffs should be marking and removing these if Yaffs was controlling the ECC mode. However since Yaffs G1 android setting relies on NANDecc for marking bad blocks I'm not so sure which is cleaning up and not retiring these blocks, maybe NAND and YAFFS are in disagreements or one has ability to retire these blocks and end this problem. It seems though that while flashing ROMs data is being written on to these areas and after a remount it is evident that something may be wrong.

Experiences:

An app could go missing or a file or folder name with invalid characters may happen or a phones feature may suddenly stop workin such as scanning for wireless networks timing out.

The issue is reproducable on freshly erased partitions via fasboot erase system -w.

If a dev would like to co-ordinate with me I will grant them remote access to a system with said phone connected via usb with adb port redirection/remote adb or desktop access with adb and fastboot and vnc client with vnc server on phone .

Workaround:

Working with xda member Licknuts we tested numerous times with a few ROMs 1.6 and 2.1 and came up with this for a quick work around that basically involves erasing /system via fastboot then in recovery lock /system from being formatted and unmounted after ROM Flashing you then tarball /system partition to /sdcard do a reboot into fastboot and erase system again reboot into recovery and untarball back to /system.

Prerequisite:

A phone that suffers missing apps in /system or odd phone behavior features after fresh ROM flash.

ADB with Fastboot, USB Cable connected to your Phone.

Adapt the procedure bellow for issues stemming from the /data partition.

<Go for it>

Going to have to clear out system as it probably has corruption.

fasboot erase system

Note:::

Hboot spl dictates reboot & some engineer spls have no menu option and engineer spls do not reboot to recovery with an empty partitions when USB cable is connected so disconnect it and reboot then reconnect when in recovery console or just fastboot flash system system.img using HTC 1.6 system.img extracted from their zip.

FYI:::

Haykura sapphire spls (aka: danger spl / death spl) are able to boot to recovery with only radio/hboot/recovery partitions intact as long as it is instructed to do so other wise you get G1 screen with red[fastboot] with USB cable attached (might be the missing safety mode for bricked G1s but not certain).

Anyhow just Reboot to recovery console from menu option or [send][menu][hang] quickly hold [home]

Using adb shell we can lock system partition from being formatted and unmounted by ROM Flash scripts instructions in scripts.

adb shell
mount -a
cd /system

flash ROM and any updates from Recovery console on phone as normal...... and then we tarball the /system partition before it remounts on reboot and corruption happens

While still in adb shell and hanging out in /system, issue these commands to mount the sdcard and create a tarball of /system.

mount /sdcard
tar -cvf /sdcard/system.tar /system
sync
reboot bootloader

in fastboot we erase system again because most likely data will corrupt because the Flashing procedure may have written to bad blocks and when mounted or remounted it will corrupt, this is why we tarballed /system before it happens.

fastboot erase system

then reboot back to recovery console

using adb shell we un-tarball system.tar back to /system mountpoint with YAFFS that supposedly knows about these bad blocks so writing filles out these should be checked and avoided.

Issue these commands:

mount /sdcard
mount /system
tar -xvf /sdcard/system.tar -C /
sync
reboot

reboot as normally would and with some luck files wrote out avoiding those marked bad blocks.

Resolutions and notes:

flash_image and ROM flashing scripts may be flashing directly to device level which does not have YAFFS bad block information and once mounted with a file system, corruption happens from file system having bad block information.

Using sapphire spls (danger spl) we have access to fasboot oem task 28 & fastboot oem task 29 will low level format, repair, report and mark blocks bad but doesn't seem to resolve issues maybe YAFFS doesn't sync or care about the blocks marked in NAND mtd.

Possibly we need a compiled kernel and complete compiled tool set to fully work on Nand device mtd and format tools for Yaffs and scripts to automate some tasks. Seems Nandroid and /system/xbin, /sbin, /system/bin and recovery console tool-sets are limited as well.

*I think and type fast so note that typos may exists hopefully not in coding but elsewhere and if you exist solely to point out grammar and spelling of others on internet forums or broken English of members from other countries, then respect my preemptive "go **** yourself".

If my help aided in getting your phone in working order then give a family member or friend a call or donate some $ to the devs that keep our phones fun to use.