[Samsung Epic 4G Touch] garwynn:
Samsung is one of the leaders in eMMC technology and participated in the eMMC specification writing, so even if they subcontracted the manufacturing it is extremely unlikely that they wouldn't have the documentation for the firmware. Also, the fix in question was written by Samsung - from what I can tell, one of the developers of Odin.

Although it is mentioned right above, I thought I would include it here so you don't have to jump back to Page 3.

Ken Sumrall - the developer on the Android Team who signed off on this being merged into the common kernel - said the following:

Hope this clears up some of the discussion. Still no response from Mr. Sumrall back on the 3 questions last week - might mean he had to go back to Samsung for answers. (He usually responded the other times in very short order.)

---------- Post added at 08:16 PM ---------- Previous post was at 07:57 PM ----------

First, in order to check against something we need to know what our eMMC's ID information is. Sfhub posted on page 1 (re:

You'll need to write these down or copy in Notepad.

Now, look at the cid string and search for the serial number value. Take the two characters to the immediate left of where the serial number starts and write this down as the manual fwrev.

Next, take a look at this post that originally mentioned the procedure call and definition:

http://xdaforums.com/showpost.php?p=25880674&postcount=13

The matchup is slightly different here because we found that by checking the cid string manually the fwrev field is not populated properly. Assuming it was designed to do so (which the logic suggests) would then lead us to the following:

So to properly identify what is affected:

Model Name (.name) -> VYL00M, KYL00M or MAG4FA

Manu. Firwmare ID Manufacturer ID: --> 0x15

OEM ID: Any ID (easy extrapolation of CID_OEMID_ANY)

Revision Start (Range): The result of cid_rev(0, 0x25, 1997, 1). Converted to numeric would be 37199701.

Revision End (Range: The result of cid_rev(0, 0x25, 2012, 12). Converted to numeric would be 37201212.

So, the ones we have seen match the first 3. The issue becomes the cid_rev amounts. In there, the first one matches (hwrev of 0), the dates are a low and high value. So now we're down to 0x25 (37 decimal) versus the fwrev.

When I did this on my device I got 0x19 (25 decimal). The cid_rev function converts everything to numeric, so why use 0x25 when everything else is numeric? It's not a reach to think that this only factor, when everything else matches, could be a bug in the bugfix.

It would still require the fwrev to report correctly as sfhub mentioned. So we asked about both to Mr. Sumrall - I haven't gotten a response yet.

This gives further support that the fix may be for us - but may not be if the 0x25 is not a programming bug. Hopefully we'll get an answer soon.

---------- Post added at 08:22 PM ---------- Previous post was at 08:16 PM ----------

Have you taken a look at the bitbucket link on the first page? This seems to be a mirror of the current Samsung kernel build. This will give you the source to their eMMC kernel and is what I've been using to research.

If I had a build environment and a spare phone I'd try making that change and recompiling the kernel to see if it works. Maybe something that another person with the resources could pull off.

BTW, I noticed you're on the Note forums a lot. Think you can ask for people to dump the cid information mentioned in the post above and either send to you or post here? I want to see if I can find that 0x25 fwrev in the cid string. My guess is I won't - but I need a bigger sample size than one device to even get close to confirmation.