[Q] Interfacing manually with internal MMC / internal moviNAND issue

---

Two SGS Captivates. The internal MMC (moviNAND, 16Gb) of one works, while the other doesn't.

On the defective unit, the MMC continuously responds to CMD1 (SEND_OP_COND) with the busy flag -- ie: never finishing internal initialization.

Boot logs between units shows no discernible difference (debugging enabled).

Changing kernel/bootloader/rom shows no difference. MMC never finishes internal initialization.


Questions:

1. Is there a way to manually interface with the MMC and send it commands from user mode, outside of the kernel?
2. What might cause the internal MMC to never finish its internal initialization?
3. What possible causing files/registers survive a kernel/bootloader/rom change, and can they be read/modified from user mode?


Any input is appreciated.

Thanks!


PS: Do not suggest re-partitioning, factory reset, or microwave .

Captivate uses OneNAND, not eMMC or MoviNAND.

Have you tried my i897 KB2 Heimdall One-Click with bootloader flashing enabled?

http://files.teamkomin.com/files.php?dir=Captivate%2F

Originally Posted by AdamOutler

Captivate uses OneNAND, not eMMC or MoviNAND.

Have you tried my i897 KB2 Heimdall One-Click with bootloader flashing enabled?

http://files.teamkomin.com/files.php?dir=Captivate%2F

Hey there.

Yes, the "dysfunctional" phone is able to boot into the OS (OneNAND is fine), but its MoviNAND (internal eMMC/SD, 16Gb) stays silent/dead.

Yes, countless kernels/partition files/bootloaders/roms were tried.

The issue is that the the eMMC will never finish its internal initialization and always responds to CMD1 with the "busy flag" set, making further data requests impossible.


EDIT: I see that the SBL has something called "mmctest". How can one trigger/launch/interface with it?

Although many of the SGS 1 variants used a oneNAND of either 1GB or 512MB to house firmware information, I have found that portions of the internal storage have been segmented for CSC scripts and other various tasks the device will use. I'm working with a few developers for more access the to the EMMC zones via JTAG to determine if all of these "partition bricked" devices are actually gone for good as they have been claimed in the past and up until this point, or possibly resurrectable by overwriting valid EMMC info into the corrupt zones. The team and I already have access to full EMMC chip infrastructure on newer Galaxy S II devices and things like the Galaxy Player 5 but I'm pushing them to develop more for older devices with these problems as well for useful data recovery tactics on devices that may be not boot, but still allow access via JTAG. This would allow me to back up any part of the chip (pictures, music and videos or anything else) for advanced data recovery in scenarios when an onboard USB controller is bad, display module is bad or their is a PMIC issue.

Time will tell if this is a fixable issue but good luck to you if you can figure out a way to run a script to clean up corrupt EMMC zones!

Originally Posted by raz123

Questions:

1. Is there a way to manually interface with the MMC and send it commands from user mode, outside of the kernel?
2. What might cause the internal MMC to never finish its internal initialization?
3. What possible causing files/registers survive a kernel/bootloader/rom change, and can they be read/modified from user mode?

1. SBL commandline accessible through UART. Or modified SDHCI driver inside of kernel (you can find drivers in /drivers/mmc/ /arch/arm/plat-samsung /arch/arm/plat-s5p /arch/arm/s5pv210) AFAIR, you can also build kernel with enhanced MMC debugging (MMC_DEBUG / DEBUG_MMC define in config file, also some additional debug macros inside of drivers).
2. HW damage like broken soldering or damaged moviNAND chip.
3. I'm pretty certain that none.

This seems relate to my Tmobile Vibrant problem. In the recovery mode it report moviNand open fail then moviNand checksum confirmation fail
The Vibrant now has 0 internal storage space. The format command or even the *2767*3855# command have no effect. I'm running 2.2 now flash via ODIN with no internal space.