[Samsung Epic 4G Touch] sfhub:
I was able to confirm with chris41g and T.C.P that the update-binary, included with both the CM9 and AOKP ROM update.zip files, was compiled against ICS source code.

This means that this update-binary can potentially trigger the EMMC firmware lockup/superbrick bug if "format()" is used in the Edify install script. Both CM9 and AOKP updater-script format("/system") as part of their installs.

This explains why they brick so often with the bluelight-only style brick, it is because the format("/system") elicits the lockup when make_ext4fs() is called on the /system partition and eventually results in an mmc_erase(). With a boarked /system, you are left with the blue-light special and ODIN will hang on factoryfs.img.

The other style of brick is the one that hangs on the logo. That one is caused by Wipe Data/Factory Reset from an "unsafe" cWM Recovery. Just as above, the "unsafe" CWM Recovery would have been compiled against the ICS libext4_utils.a and make_ext4fs() would be called on /data and /cache. Eventually that would lead to mmc_erase() being called. With a boarked /data, you are left with a phone that hangs on the log and ODIN will hang on data.img

As an aside, I now believe the main "unsafe" Recovery we were dealing with was CWM Touch fake-flashed onto the ICS kernel. I don't have the source code for CWM Touch, but I believe it was compiled against the ICS libext4_utils.a. I am not sure if Rogue CWM repacked with an ICS kernel was compiled against ICS sources, but the version that Steady checked into github was not.

Now previously I recall discussions where it was determined that GB source/kernels also had mmc_erase() and it was an open question why, if both GB and ICS had mmc_erase(), Recovery Wipe Data/Factory Reset would brick one but not the other. Well we finally got the answer to that, the GB version of make_ext4fs() from libext4_utils.a did not perform the ioctl() calls which would eventually lead to mmc_erase() being called, while the ICS version of libext4_utils.a had the ioctl() calls.

Now if you've been following closely so far, you may be wondering why if the update-binary that is bundled with both CM9 and AOKP ROM update.zip files is using the ICS version of libext4_utils.a (that makes the ioctl() calls which lead to mmc_erase()) it doesn't brick when run under a GB-kernel/CWM. Both ICS and GB have mmc_erase() functionality so it should brick both right?

Well I wondered the same thing, went digging a little, and believe have found the answer.

It turns out that even though the GB kernel MMC driver has mmc_erase() the ioctl() calls that would eventually lead to mmc_erase() being called were ifdef'd out. So if you had an "unsafe" update-binary which made the ioctl() calls, they would NOT result in mmc_erase() being called when the ROMs update.zip was run under a GB kernel/recovery.

Previously the discussion centered around MMC_CAP_ERASE as the explanation, which I believe is a red-herring. This is neither a pre-processor directive nor a direct control mechanism. It is a bit field used to specify whether an MMC device supports the capability of doing erases. It was not ifdef'd out of GB so the functionality was still there.

The actual conditional compile was on the ioctl() function for mmc cards, which was basically disabled under GB kernels. This is how I came to that conclusion:

Notice in the kernel config file Samsung provided, both CONFIG_MMC_DISCARD and CONFIG_TARGET_LOCALE_NTT are disabled.

.config

# CONFIG_MMC_DEBUG is not set
[B][U]# CONFIG_MMC_DISCARD is not set[/U][/B]
CONFIG_MMC_UNSAFE_RESUME=y
# CONFIG_MMC_EMBEDDED_SDIO is not set
# CONFIG_MMC_PARANOID_SD_INIT is not set

# CONFIG_MACH_C1_NA_SPR_EPIC2_REV00 is not set
# CONFIG_TARGET_LOCALE_EUR is not set
# CONFIG_TARGET_LOCALE_KOR is not set
[B][U]# CONFIG_TARGET_LOCALE_NTT is not set[/U][/B]
CONFIG_TARGET_LOCALE_NA=y

Now if you look at the mmc block device driver, due to the kernel config above, the ioctl() function call in the function table is left unpopulated. This basically means ioctl() calls are not supported for the mmc device (based on E4GT GB source, don't know about other platforms).

drivers/mmc/card/block.c

static const struct block_device_operations mmc_bdops = {
.open	= mmc_blk_open,
.release	= mmc_blk_release,
[B][U]#ifdef CONFIG_MMC_DISCARD[/U][/B]
.ioctl	= mmc_blk_ioctl,
[B][U]#endif[/U][/B]
[B][U]#if defined(CONFIG_TARGET_LOCALE_NTT)[/U][/B]
#if 0 //def CONFIG_MMC_CPRM
.ioctl	= mmc_blk_ioctl,	//int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long); in blkdev.h
#endif
[B][U]#endif[/U][/B]

Now when the "unsafe" update-binary from CM9/AOKP is paired with a GB kernel the wipe.c from libext4_utils.a will try and make these calls:

system/extras/ext4_utils/wipe.c

int wipe_block_device(int fd, s64 len)
{
u64 range[2];
int ret;

range[0] = 0;
range[1] = len;

ret = [B][U]ioctl(fd, BLKSECDISCARD, &range);[/U][/B]

if (ret < 0) {
range[0] = 0;
range[1] = len;
ret = [B][U]ioctl(fd, BLKDISCARD, &range);[/U][/B]
}
return 0;
}

I believe that both those calls have basically been disabled because ioctl() calls are not supported in the mmc block device driver under the GB kernel (for E4GT EL29 GB kernel source).

So what does that all mean?

I believe GB systems are doubly "safe". The kernel will not execute mmc_erase() even though the functionality is there because the ioctl() call entry point from user space to kernel space has been disabled and also GB recovery and GB update-binary never even attempt to make the ioctl() calls.

That explains why, if you pair an "unsafe" update-binary from the CM9/AOKP ROM update.zip with a GB kernel, it is still safe.