The thing is:
1) Vendor kernel trees are almost NEVER synced to AOSP - it's frequent that Samsung kernels for non-Nexus devices are missing patches present in AOSP kernel trees for Nexus devices
2) The failure mode described for that bug is different from ours - the failure mode in question wouldn't cause eMMC blocks to become unwritable.
3) It's a fix for the Galaxy Nexus, which never encountered this particular bug, which is more evidence that the patch in 4.0.4 is unrelated to Superbrick
(and as I understand it - your latest releases are still exhibiting Superbrick behavior)
Thanks for the reply.
Trying to address #1 by asking those who can submit bug reports to Sammy - at least on the E4GT leaks - to do so. Since I don't have any direct contact with their dev teams I can only speculate at best. What you mentioned is plausible - but if they merged the changes to roll up to 4.0.4 on the E4GT they had to merge from somewhere. I can't see it in the original 4.0.4 (r1.1 and above only) so it is possible that this was missed.
However, there is a way to bypass their kernel build - and I've been trying to look into that now. Those that take the kernel source from AOSP and include should have the fix - and at the least we should see the fwrev if populating correctly. If we verify that it's in and still don't see this then it's a strong indication that something is still not right.
For the AOSP kernel I'm still hoping we'll get something back from Mr. Sumrall. Since he got the code originally from Samsung I'm hoping he's taking the notes back to them.
#2) I'm going to give a little on this given I'm the amateur among professionals.
If a Google SE - with 20+ years experience (based on his LinkedIn profile) and extensive knowledge on his OS - says this would corrupt the file system to an uncorrectable point I have to give credence to it. The fact that the fix came from Samsung and he applied it would also suggest he's had at least some, if not extended, dialogue with their dev team on this issue.
Please don't misunderstand this as trying to dismiss your credentials either. It's why I didn't believe that it's a physical issue to begin with - and I was always taught in my college classes that short of physical damage it's feasible to fix it.
So here's where I think it stands: It's feasible but the sure-fire solution hasn't been developed yet. I think that would involve modifying the eMMC's embedded controller firmware and without specs on that we're speculating at best whether that's even possible or not. We have a hint in the code that the workaround was the best they could do, which would suggest the controller's firmware either cannot be modified at all or easily. There may be a way to manipulate the controller to get the desired effect - but that will probably have to come from Samsung unless they release the specs to the public.
Sorry for the long post - I believe it too is unlikely that it's impossible... but I can believe that with eMMC specifications around 3 years old and apparently Sammy not conforming to that (as mentioned in the code fix) that it is plausible that they simply haven't found a way to fix it permanently yet.
#3 has been bugging me for a while because I know it's not the AOSP that I'm looking at. I've gotten from the AOSP changelog that it's there - I'm just linking to a bitbucket that had it - but I haven't been able to get repo to work from my office to pull the AOSP repository. And yes, there are multiple reports of file system corruption on the Nexus - took me less than 5 minutes to find similar examples by searching.
Still working on this and if I don't see it there it would explain a lot. It may end up waiting until Samsung releases their source to confirm.
---------- Post added at 06:16 PM ---------- Previous post was at 06:12 PM ----------
BTW I'm an electronics engineer, but I don't have access to the documentation, or to the right tools, and also I don't have the soldering skills to try to develope an UnbrickableMod.
Didn't realize that several of you are EEs - just you were the first to come out and say it. I think having documentation or specs would go a long way to getting past speculation and into a solution. Doubt it will happen though unless Samsung decides it's worth getting the community involved to try and get a permanent fix designed. (Best guess is that they don't want to release the IP associated with the eMMC and embedded controller specifications)
Hope I'm not patronizing you guys. I'll just say I know I'm the amateur here and just using the grey matter between the ears as I was taught to do and trying to figure this out. To me it shows promise - and in the absence of any other solution it doesn't hurt to use this as a good point to better understand both the problem and possible ways to solve it.
Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
