yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] RainMotorsports:
That is literally just a presentation with no useful information. The kind of information you are looking for is the kind that Samsung sends Cease and Desist letters prior to pending lawsuits on the source over.

There is no partition as you are thinking. This is stored internally on a low level and its NOT meant to be updated by end users or OTA and even the concept of letting it out to service technicians is beyond the intended scope. It was only intended to be written at manufacture time, maybe in factory service or refurbishment. But even Carrier level techs generally do not have any access to this information or related tools.

The raw level of read/write access normally presented to the device, os kernel is a higher level in the storage hierarchy. Access to the lower levels, sensitive areas can only be done, depending on the operation either by things hard coded in the silicon (very low level operations) or in the coded in the firmware (slightly higher level). The PDF you are looking for is going to be 200+ pages usually.

I could be wrong but this is not really any different than what I have had experience with.
[Samsung Epic 4G Touch] prabhu1980:
Not the presentation Boss !!

The JEDEC standard for EMMC .... See the second attachment .. (I uploaded later and u replied so quick ....)

I hope you are terribly wrong and pray that u should be wrong ...

Hard Coded to Silicon .... Too Old Technology Boss .....

Everything should be revisable ...

Please read the N900 Emmc flashing of firmware in my post (Added Later ....)

SFHUB - Request you to read this post ....
[Samsung Epic 4G Touch] RainMotorsports:
Oh wow that might be what we want. At first you had the wrong file.

I know part of the documentation is public, but I am not familiar with what is and is not public. This looks very good though.

You still have to have some basic operations hard coded so that a blank manufactured chip can be initially written to. Since we are trying to read and write the revisable portion of the chips operating instructions these are likely those hard coded/built in commands.

The glossary defines one of the areas we are discussing, however looking through the file seems to skip all but anything we need. There is data in this area that needs to be read and backed up.
[Samsung Epic 4G Touch] prabhu1980:
SFHUB - Waiting for you to feed my thoughts .... Read this Post
[Samsung Epic 4G Touch] sfhub:
JEDEC is the standard the EMMC needs to present. The vendor specific access wouldn't be contained in a JEDEC document. Even if it was standardized, deciphering the firmware code itself would be an incredible chore without documentation. You'd need to reverse engineer almost everything.

It is nice that you are trying to make progress, but IMO there will be very little progress made on replacing the EMMC firmware without Samsung's assistance.
[Samsung Epic 4G Touch] prabhu1980:
Hmm What about the N900 emmc firmware flash ...

May be its possible to access with a USB ....

---------- Post added at 09:35 AM ---------- Previous post was at 09:28 AM ----------

RainMotorSports - Let us hope that this area is not responsible for lockup ... because here we are looking for an workaround for the lockup...

Theory 004:

We have to focus upon the Bad Blocks Management Module which throws an exception .... we need to make this command inactive as the people who are affected during flashing can again reflash ......
[Samsung Epic 4G Touch] globalm:
@sfhub

As a one-time programmer (not android and not recently :D ) I would say your analysis of the issue is spot on.

We should not expect a fix to the eMMC firmware and therefore a work-round is needed.

If I am understanding you correctly, because CWM is statically linked to a 'problem' library then CW wipe operations remain risky even if a 'safe' kernel is installed.

Being fairly new to the Android development world, I want to ask, for my own education, if there is a mechanism to ask CWM developers to note your findings and produce a safe version.

Please correct me if I have it wrong!
[Samsung Epic 4G Touch] sfhub:
=> means static link

-> means bound at runtime

recovery(stock, cwm, etc)=>libext4_utils.a->kernel mmc driver->emmc firmware bug

The bug is all the way on the right.

If you fix emmc, everything to the left is "safe", without recompilation

If you workaround in kernel mmc driver, everything to the left is "safe", without recompilation

If you workaround in libext4_utils.a, then only utilities compiled/linked against the new "patched" libext4_utils.a will be safe.

That is my understanding of the scenario we are looking at, though I could have missed something.
[Samsung Epic 4G Touch] globalm:
So the message from the above scenario is that a safe kernel should mean a safe recovery so no CWM action required. Is that correct?

The earlier reference, "If the people who compile CWM simply NOOP the "wipe" code in their current source tree, their recoveries should then be safe", refers to a scenario of having a safe CWM wipe even if the kernel is unsafe.

Correct?
[Samsung Epic 4G Touch] musashiro:
were doomed... they can't reproduce the bug... :(

tell them to try it on LPY Open Germany..

please someone suggest that Ken Sumrall talk to Samsung Developers..
[Samsung Epic 4G Touch] sfhub:
It would only be a "safe" kernel if they implement the workaround in the kernel MMC driver. I do not believe they will do this, but if they did, then no further action would be needed in CWM, no recompiles or anything.

I am guessing instead they will put the workaround in libext4_utils.a by removing the ioctl() calls which in turn run the kernel-space mmc driver routines. If this is what they end up doing, then if your existing Recovery was linked with the problematic libext4_utils.a, it will need to be re-linked with the newer libext4_utils.a that has the ioctl() calls removed/replaced.

We won't know for sure which path they took for the workaround until they release the source.

IMO it would be better for them to put the workaround in the kernel MMC driver as it would make the workaround available for any recovery as long as you repack it with the "patched" kernel.

However if you are Samsung and are only concerned about the "official" software you are releasing, putting the workaround in libext4_utils.a results in less code needing to be reviewed because it is at a higher level.

This reference is basically saying if Samsung is going to patch libext4_utils.a, that is already something that people who build custom recoveries should have access to in their source tree, so they can do a simple patch themselves to get rid of the ioctls() used to call mmc_erase(). If mmc_erase() (in the kernel mmc driver) never ends up being called, then you won't trigger the EMMC firmware lockup/superbrick bug.

If you do end up patching the libext4_utils.a library that your Recovery is linked against, then it shouldn't matter which kernel you pack with as the mmc_erase() in the kernel mmc driver wouldn't be called when running wipe data/factory reset.

The "safe" talk above ONLY refers to the wipe data/factory reset option in recovery.

Now there is a separate issue of what update-binary is doing. This is the app that is bundled in update.zip files and interprets the edify install scripts. I wanted to see the source code for that to see what it is doing when someone asks to format a partition, but I haven't been able find the souce code yet. If update-binary is directly calling those ioctls() to jump to the kernel space mmc routines, then even if your Recovery is technically "safe" by linking with the patched libext4_utils library, the update-binary that is run on install still might be dangerous. I stress I don't know this for sure, as I don't know if update-binery is doing calls to the kernel mmc driver code.
[Samsung Epic 4G Touch] nCoder:
Response from Samsung Developers

Just received response from Samsung Developers
[Samsung Epic 4G Touch] sfhub:
EDIT: I think XDA is changing the order of the posts again. I now see the info you were referring to, but it wasn't there when I looked before and it is showing up after your post, instead of before.

Are you referring to some info from a different thread? The info provided for E4GT seems to say they both reproduced the bug and confirmed the fix the put in eliminates the bug.
[Samsung Epic 4G Touch] sfhub:
This is why earlier I was asking for some clear cut examples of people running *stock* recovery on the Note, doing wipe data/factory reset, and getting the EMMC lockup/superbrick situation. Once you introduce other factors like custom ROMs, root, etc. then that can confuse the situation.

On this thread, we isolated stock recovery and stock kernel. The only difference we had was we used an earlier unlocked recovery. We found that stock recovery could cause the superbrick and I think that got Samsung/Sprint's attention.
[Samsung Epic 4G Touch] biliskner:
He makes it sound like "they" will help if we showed them the leaked/rooted software exact steps.

Of all the posts I've read I'm not 100% sure anyone with stock GB going to stock ICS hard bricked. Even those who reset to factory settings didn't seem 100% clear cut that they were on stock (non rooted!). I could be mistaken however, as I'd love for some of the GNotes inside Samsung to get bricked while they were testing, then we'll really see how far they'll go to patch their emmc fw.
[Samsung Epic 4G Touch] Entropy512:
No, it requires vendor proprietary commands that are undocumented.

I disagree that Samsung will fix it in recovery. They already fixed it in the kernel once, but then undid the fix for other devices.

https://github.com/Entropy512/kerne...59551eaf5afc3d68f2da96b0249937bd5e13#L10L1873 - From I9100 Update4 to M250S Update4, they enabled MMC_CAP_ERASE in the kernel. (Or they disabled it going the other way, we don't know Samsung's internal code heritage)

https://github.com/Entropy512/kerne...c93ac639898f957103c35c32a649b41840bd#L21L1873 - Same for N7000 Update3.

https://github.com/Entropy512/kernel_galaxys2_ics/commit/d069cc5cb9f0fd9409ea10d4037e4c0e68701b8e - Evidence they were aware of a problem and tried to fix it (without success, they only disabled TRIM, but not ERASE. These are closely related but different - TRIM will automatically erase blocks when files are deleted, ERASE will only erase blocks when a partition is explicitly wiped.

Yes. The JEDEC eMMC standard is useless for our current situation - all it specifies, related to our predicament, is that vendor proprietary extensions are allowed. It does not document these extensions. We need documentation of the specific extensions.

http://xdaforums.com/showthread.php?p=26705073#post26705073

I don't have the link to the Sprint documentation readily at hand - could you provide that to the Samsung guy?

Looks like his response was at:

http://innovator.samsungmobile.com/...Id=1&selectedSequence=00dgu030000~&viewMode=2
[Samsung Epic 4G Touch] garwynn:
Just posted a reply on that site. Also asking any of those with contacts inside Samsung USA that worked on the E4GT build to see if you guys can contact Mr. Panasiuk through internal channels and explain what's going on - and more importantly how to patch it. Hope that might help them believe what we're trying to say and get this resolved for the Note owners in Europe.
[Samsung Epic 4G Touch] satur9ine:
FE26 rdf has posted. Fingers crossed that the EMMC brick fix is included!
[Samsung Epic 4G Touch] garwynn:
Honestly I'm not surprised to see the rdf - but I'm really wondering if we'll get a leak. If what thirdcoastraised said is true and Sprint may be under the gun it might help them to leak it to us and let us test it.

...And yes, that should contain the fix - in fact, based on timing that should be the OTA sent to Sprint over the weekend.
[Samsung Epic 4G Touch] prabhu1980:
An incorrect downloaded lpy firmware can reproduce this bug..

I mean flash without md5 check. ..

Try this. ... I bricked mine that way. ..

Stuck at factoryfs.img forever...
[Samsung Epic 4G Touch] sfhub:
As long as you agree with the analysis of *where* a workaround *could* be placed, I'm open to the workaround being in either location, which is why I listed them both. One can agree with the analysis without agreeing on the conjecture of where the workaround will end up being placed. The 2nd part of the analysis, if you agree with the areas where the workaround *could* be placed, is that we already have control over libext4_utils.a and people who are compiling CWM recovery are pulling that file in from CM source code. It isn't in the kernel source that Samsung provides us. So we could actually ensure that our Recoveries never end up calling the ioctl() that switch to the kernel-space mmc driver and in turn trigger the EMMC firmware lockup bug.

The main reason I'm leaning towards them fixing it in libext4_utils.a is because the dialogue we had with Mr. Sumrall focused on that change being the difference between GB and ICS. If they looked at that change without any prior knowledge of the issue (ie the person who commented out the code for mmc_trim was not involved), the easiest change is to go back to the way it was in GB, which had the kernel enabling mmc_erase() in the mmc driver and libext4_utils.a not calling it. At least for us, they seemed to have made the change relatively quickly after getting contacted by Garwynn (and I believe Ken). They also needed to make the change in a relatively short time frame to make it into the OTA ICS release. If they made the change in the kernel MMC driver, the code review would likely have taken longer since it is at a lower level. The libext4_utils.a change is more isolated, at a higher level, and a known difference between GB and ICS being pointed out to them by an Android developer as the likely trigger for the EMMC firmware lockup people are seeing in ICS but not in GB.

I looked at the change you mentioned and it is a strange change. While it does disable the trim function, they just commented out 4 lines with no comment or documentation. Personally I might do that if I was experimenting but never on an official checkin. How is one supposed to know why you just commented out 4 lines of code? It is also strange to see C++ style comment notation in the linux kernel. Usually it is all C code and C-style comment notation.

I think maybe in the long run they may put in code like they did with MMC_QUIRK_INAND_CMD38 to conditionally do the erase if the fwrev supports it or is broken, but my guess is, being under the gun to produce a fix for the e4gt, they will opted to place the workaround in libext4_utils.a
[Samsung Epic 4G Touch] sfhub:
I don't know if I would really refer to it as documentation, but this is the post I was referring to. thirdcoastraised has provided information in the past that is pretty accurate, so I assume he has a source in Samsung or is involved in the testing process.

http://xdaforums.com/showthread.php?p=26465085#post26465085
[Samsung Epic 4G Touch] sfhub:
Ok, I have now verified that update-binary also makes the call to make_ext4fs() in libext4_utils.a just like Wipe Data/Factory Reset in Recovery.

That means if your ROM update.zip has packaged in an ICS-based update-binary prior to workaround, just like recovery, it is also susceptible to the superbrick issue if your edify install script uses "format()"

http://androidxref.com/source/xref/bootable/recovery/updater/install.c#241

This could explain why some platforms have issues flashing ROMs which issue a format() and others don't have issues with format(). It would depend on which update-binary (GB-based or ICS-based) was included in the update.zip

Many of the E4GT ROMs are still using the update-binary that came with the GB OTA releases. These update-binary executables would have been linked against the GB libext4_utils.a and thus would be safe to run format. This probably explains why Calks format_all never bricks. It has likely been packaged with a GB-based update-binary, so when format is initiated in the edify script, update-binary calls the old make_ext4fs() which doesn't make the ioctl() to switch to the kernel mmc driver and erase the partition.

Other platforms may have started packaging the ICS-based update-binary and thus running format() from their edify scripts are just as dangerous as running wipe data/factory reset. This might explain why other platforms are seeing the brick for factoryfs.img (/system) instead of (/data) like us. Their ROM install scripts *may* be doing a format() of /system in their install scripts (which then ends up making the ioctl() calls to kernel-space mmc_erase) On E4GT, early on, we switched to using Calks format_all and running the install in an GB-based recovery so everything was GB-based including the format(). The few times when people made mistakes is when they used the ICS recovery to do wipe-data/factory reset, at which point their /data encountered the superbrick issue.

If AOSP, AOKP, CM etc. ended up building their own update-binary from ICS source (at least initally, before the bricking started happening, and the procedure switch to flash calks format_all on a GB-based recovery), rather than using the GB-based update-binary, then those update-binary executables would have ended up being linked with the new make_ext4fs()/libext4_utils.a and eventually would make the ioctl() call to initiate the kernel mmc driver mmc_erase() function. This *might* explain why the bricks were often associated with AOSP, AOKP, etc., whereas stock ROMs usually didn't have an issue.
[Samsung Epic 4G Touch] Entropy512:
I don't think the question was appropriately phrased to Mr. Sumrall. Filesystem corruption like he describes is one thing - it's easy enough to fix, just reformat.

However, the symptoms we have been seeing are:

1) Parts of the eMMC are becoming inaccessible, to the point where they cannot be written to in any way, shape, or form. This goes way beyond filesystem I/O errors - a reformat would fix those.

2) This includes attempting to rewrite corrupted bootloaders using JTAG recovery methods.

Is there any chance you could send me the contact info for this person, as I've been fairly "down in the dirt" with the hardbricks incurred on other devices.
[Samsung Epic 4G Touch] azyouthinkeyeiz:
Q: Can inserting 32 Kb of zeros corrupt a file system?

Certainly - as mentioned by Mr. Sumrall, it just depends on where the insertion was made.

/*In this case in the low-level bootloader firmware*/

Q: Why couldn't JTAG, with its bit blast, at least reset the values and allow it to go ahead?

The answer, as far as I can tell, is simply that the support is not available at a driver and/or eMMC controller level to handle this type of operation. This is either because the embedded controller chip simply cannot do so or the driver has not been designed to use those instructions as of yet. As a result, all it can do is throw an error in frustration. It might be possible down the road but not now. So instead of waiting for this to come Samsung implemented a workaround to the WL logic to avoid it corrupting the filesystem.

That's why he clarified with

And the answer was- it's corrupting the low-level firmware that handles EMMC, which makes the partition inaccessible.

The intent has not been written at that level to correct that with jTag.

Both of your questions are answered in the two quotes.
[Samsung Epic 4G Touch] sfhub:
This is the part I don't understand about this answer. If they cannot permanently patch the EMMC firmware (presumably because it is not writable), how is the 32kb of zeros corrupting that same unwritable firmware. If the firmware is kept on EMMC it should be writable though I find it difficult to believe the EMMC firmware (essentially the "OS" handling the blocks on the EMMC is being stored on the regular EMMC itself, subject to wearlevel algorithms)

If that stuff about the firmware was just miscommunication and we are back to talking about filesystem corruption, I can write 32KB of zeros to any of the filesystems just using "dd" and "/dev/zero". These can be repaired by reformating the partition. There is some "special" corruption or damage going on here, IMO.

It may be that the bug they are fixing is causing all this. I just cannot picture the mechanism yet with the descriptions being given.
[Samsung Epic 4G Touch] nabbed:
Dear Mr. sfhub,

There is a new sheriff in town. Or soon will be.

It's going to be either Evo LTE or some kind of a variation.

Can we count you to provide hacking/unlocking support for this puppy?
[Samsung Epic 4G Touch] sfhub:
Probably not any time soon. I have turtle DNA in my family tree and move very slowly between phones :(
[Samsung Epic 4G Touch] azyouthinkeyeiz:
That's what I had started to suppose in the post I removed. It would have to be binary inserts between the software and firmware that corrupted. Otherwise, re-formating would correct it. But, if it went into panic, it could have locked down the partition, and like garwynn suggested the controller hasn't been defined.

Also, there was a certain subset of variables that had to have been met during initial custom development of our device, that would have had the same consequences. We would have had at least one, and I don't think I ever heard of a similar brick before ICS. It could be an issue with this bug and the conversion between two different kernels, which is likely since it is the ICS recovery intents that are borking the partition.

---------- Post added at 07:23 PM ---------- Previous post was at 07:21 PM ----------

/Epic
[Samsung Epic 4G Touch] sfhub:
But even if name, manfid, and oemid match, presumably the reason they give a revision start/end range is because it is actually being used to limit which revisions get the patch. Given that, our fwrev is 0x0 and they provided 0x25. Bitwise shift those over 32 bits and 0x0 still won't be within the range of 0x25.

Am I missing something?

If the wrote range like this, then it would make more sense why it would apply to our phones:
[Samsung Epic 4G Touch] azyouthinkeyeiz:
I wonder what the control group and test group in their lab is? You said the scope was incomplete? It could include a higher range?
[Samsung Epic 4G Touch] sfhub:
BTW according to linux kernel documentation, manfid is "Manufacturer ID", not "Manufacturer Firmware ID"

http://www.kernel.org/doc/Documentation/mmc/mmc-dev-attrs.txt

Also they mention a restriction on fwrev and hwrev of "SD and MMCv1 only". Is it possible we don't have MMCv1 and that is affecting what information the kernel is providing for fwrev and hwrev? I'm grasping at straws a little bit here, because based on folks' responses, it still doesn't sound like any of our EMMC falls into the range they are talking about. If the information provided by the kernel is accurate, we all seem to have the same EMMC revs, just with different manufacturing dates.
[Samsung Epic 4G Touch] sfhub:
I mentioned that only as a possibility to rationalize the scenario where they put out a fix to address the corruption we are seeing, but for some reason it doesn't seem to be being applied to our EMMC units based on the information provided by our kernels and their table.

I didn't mean I unconditionally knew their scope was incomplete. Another explanation could be that their fix has nothing to do with the /data corruption we are seeing. That is also a reasonable explanation why the fwrevs don't match ours.
[Samsung Epic 4G Touch] azyouthinkeyeiz:
I think this is what I'm leaning towards. It just doesn't fit to me.

I wonder if anyone has a bricked device, sitting in a drawer, that we could set up sending it straight to Samsung to research? We've contacted care for warranty replacements and repairs, but I wonder if our issues have been properly notated and reviewed as such?

I can risk bricking it, but I have to have the phone in a matter of days, not weeks.