[Galaxy S III Original Android Development] Arifcatalyst:
CyanogenMod on SGH-I777

If there was any obvious conclusion to be made from ICS on the GT-I9100, it was that manufacturer skins do not last. After getting I9100 ICS firmware running on the I777 (primarily by reverse-engineering the swapped mic channels on this device, which took most of a weekend of work...), it was obvious that Touchwizz reverted many of the benefits of ICS. Parts of the firmware were "new", parts were "legacy Gingerbread", and the constant discontinuities was jarring. At the same time, I had been following the I9100 CM work by +Daniel Hillenbrand and +Guillaume Lesniak fairly closely. When I9100 kernel source went live, I coordinated fairly closely with +Atin M . It wasn't long before I was helping Atin get the I777 device tree up and working on Teamhacksung's github account, and shortly afterwards, I777 nightlies started. My Touchwizz days were nearly over. Within a week or so, I was running CM9 and working on fixing various issues. It wasn't long before I had full access to Teamhacksung's github account, and some time not long after that, I was in CM's private channel as a maintainer. I think this was around the time that CM started taking off in popularity with I9100 users too, as many people were highly unsatisifed with the jarring inconsistencies of ICS Touchwizz, and CM9 was far more robust than CM7 was in fairly short order (at least on I777... Maybe CM7 on I9100 was in better shape, but in many cases, it takes 1-2 CM releases before device commonalities are properly identified and leveraged... See the evolution of galaxys2att->i777 standalone tree -> i777 inheriting from galaxys2-common)

I must admit, some of my first encounters with some members of the CM team were less than pleasant. Fortunately I had positive experiences with Daniel and Atin, and eventually I buried the hatchet with those I hadn't gotten along well with (in places other than their skulls. ;) ) - Around then, CM was also actively working on improving their developer relations structure, which was something that was, at the time sorely needed. More work still needs to be done (As can be evidenced by some discussions on our Google Groups account regarding the issue of new features and the fact that coding something new and having it rejected can be frustrating), but good progress is being made. This reminds me, some parts of the wiki need serious update/cleanup...

One of the early annoyances I remember, once a team of I9100/I777 kernel developers had licked the cpufreq problem (not fixed by Samsung until I9100 Update7) was GPS. People were getting position fixes when only two satellites were being reported as received, neither of which were locked. Anyone who is familiar with GPS knows this is impossible - 3 sats is the absolute minimum for a 2D (lat/long without altitude) lock, 4 is needed for 3D. Having a 3D lock with only 2 sats = clearly wrong. After a week of reverse engineering and dumping the SV stats structures being returned by the GPS HAL, eventually the problem was identified. https://github.com/CyanogenMod/andr...jellybean/overlay/include/hardware/gps.h#L273 - Samsung had added an extra field to the SV stats structure, breaking the GPS HAL interface defined by Android, for no good reason at all. (This field is always zero on I9100/I777. It MIGHT contain a constellation type used by multi-constellation GNSS receivers like that in the N7000 - but why? There is no provision for any app to use this information, nor is there any place it is needed by Samsung's frameworks... It just breaks the interface...) More frustrating is, while Daniel had already requested that Samsung at LEAST document interface changes by providing header files for their HALs, we didn't even receive that. As a result, I had to spend a week of evenings just identifying the presence of that goddamned field. Similarly, Daniel spent a huge amount of time trying to figure out the meaning of a bunch of undocumented RIL response codes with no assistance.

One of the few positive things was getting hardware accelerated video decoding working using the reference source at Insignal. To this date, this is the ONLY thing from Insignal that has actually functioned properly on phones. HWComposer always has been and still is broken, libcamera works for preview and fails on capture, etc...

The XDA Elite Recognized Developer Program

As I mentioned, for various reasons, XDA started their ERD program, to begin "tiering" the various RDs by skill level, ethics, willingness to document/share their work, etc. One of the benefits of being an ERD that was announced fairly quickly was that we were eligible for 2-3 devices of our choosing per year. This was around April 10th - I started a thread in the ERD forums to ask what others were considering. The forums are private, so I'll keep the summary short. Two things were clear:

1) Nearly everyone was frustrated with Samsung at this point for various reasons, but it was "the evil we knew"

2) Many people were watching Sony closely. Sony had been doing some GREAT things in terms of developer relations, but people were uneasy for two reasons:

a) Sony as a whole had a fairly bad track record of doing NASTY things to their customers - See the CD Rootkit fiasco, and OtherOS on the PS3.

b) The positive behavior of Sony Mobile was considered highly anomalous for Sony due to the Ericsson influence over that division. It was questionable whether Sony would keep things up now that they had purchased Ericsson's share of the joint venture.

That said - the ERDs were watching Sony very closely, in a good way... A number of us were hopeful that they would continue their good work in going "above and beyond" with opensource community relations to repair the reputation of the company as a whole. This will become important later, in a future post...

Picking up a GT-N7000

A few days after the aforementioned thread +Gary D sent me a PM on XDA. He was one of the kernel developers who got screwed by the Tab 7 Plus AR6k "**** you opensource developers!" fiasco documented in my first post in the saga. He was frustrated with Samsung after that mess, and offering his N7000 at a great price. I decided to make this my first use of the new ERD perk.

After I got it, I started to work on finishing the CM10 bringup work for that started by +Guillaume Lesniak and mauimauer. Guillame had started the work, but bricked his device on his first attempt to flash CM10, at a minimum clobbering his SBL. We both assumed it had something to do with the funky usage of an I9220 leak on that device... Little did we know that this was a harbinger of doom... The bringup effort went quite well, and I had the device in pretty good order after just over a weekend of work (Remember - this device is an I9100 with big screen and stylus, plus Guillame had gotten most of the rough legwork done.)

The Nightmare Begins

After all this, on April 23, I got a PM on XDA from gokhanmoral (developer of SiyahKernel) that would change everything. It would usher in a new period of frustration and pain for many users, a combination of exhaustion and frustration for platform developers working with Samsung devices, and would ultimately result in the complete elimination of any trust the community had in Samsung, driving multiple ERDs formerly loyal Samsung developers/users to seek "anyone but Samsung" for their next device.

At this point, I am going to split my posts between two "plotlines" - the saga of pain and suffering Samsung's defective hardware inflicted on many developers and users, and "all the rest of the BS we still had to deal with". I'm going to focus, initially, on the "Superbrick nightmare".

This is a continuation of https://plus.google.com/u/0/101093310520661581786/posts/6kzdh1bTK4p

Now, first, after thinking more, I do need to mention one thing that occurred before that fateful PM from +Gökhan Moral on XDA...

Not long after I had finished reverse-engineering micswap on the I777 in order to allow running I9100 firmwares on that device with minimal changes, the first I777 ICS leak surfaced. It was somehow obtained by DesignGears, and he went to great lengths to whip the community into a frenzy, hoping we might get some NFC goodness (the only thing we were missing for I777 ICS at that point.) The leak was announced on RootzWiki's front page as an Odin One-Click... Now, as many of you are aware, Odin One-Click leaks almost always have bootloaders, and flashing bootloaders was (up to this point) the only way one could hardbrick one's device. The RW announcement had NO such warning along those lines, so I posted a warning on the XDA thread that people might want to wait until the tars were extracted from the one-click and bootloaders removed. DG immediately jumped in and started whining about how I was a horrible donation whore trying to get his precious donations. (Reality: I had already received $150+ in donations the previous week making I777 leaks irrelevant. Oh, and that is HIGHLY atypical for XDA donations, I usually see less than a third of that in a month and unlike DG, I don't care much about donations.) Later that night I posted a bootloader-free version, and DG posted on Twitter how "oh Entropy already flashed it" - DG was apparently completely unaware of tar extraction techniques such as FennyFatal's script at http://pastebin.com/xWLEdCyC (back then the process was more manual - but yes, you could get stuff from One-Clicks without flashing and dumping.) It got pretty nasty, and a week later DG tweeted whining about how ungrateful the XDA I777 community was and how they should be worshipping him for leaks... Anyone familiar with the I777 knows that AT&T firmwares are always steaming piles of ****, and as I'd mentioned, I'd already made I777 leaks irrelevant. (An I9100P official release got us the NFC bits we needed.)

People still wanted to play with the leaks though, so task650 did a CWM repack of the UCLC5 (I think...) kernel. That's when things got nasty... People started hardbricking when flashing from the CWM-repacked leak back to CM10 or AOKP. Back then, we thought it was an error in CWM, and either way, the repacked leaks were pulled. Strangely, Task had never hardbricked while testing his work, including multiple AOKP/leak flashes. We would learn the reality of it soon enough... But to end my rant, DG wanted the I777 community to worship him, but all he brought them was their first taste of a new nightmare...

Now, getting back to that PM... On April 23, GM sent me a message saying that he had rebased SiyahKernel on the SHW-M250S ICS source code. While he hadn't had any problems (sound familiar???), after he released Siyah 3.1rc6, piles of reports of hardbricks started coming in... Probably at least 30 within hours...

The ERD community springs into action

This was BAD... And it was weird. There was something horrible lurking in those sources, and we didn't know what. I posted to the ERD private forums to start talking about the situation... It was our chance to shine.

Lots of theories went around... GM's first guess, and mine, was that it lied in some changes to the MMC voltage regulator code. However, on further inspection, it looked like these changes were bugfixes, and also I think they didn't even apply to the internal eMMC.

Another thing that looked fishy to us was the addition of an MMC_CAP_ERASE capability flag to mshci.c - but back then we dismissed that as the flag was present in Gingerbread... (We were wrong on this one... dead wrong...)

This commit also seemed strange - it looked like someone had tried to fix some sort of erase/trim related problem (and obviously failed...) - https://github.com/Entropy512/kernel_galaxys2_ics/commit/d069cc5cb9f0fd9409ea10d4037e4c0e68701b8e

We started spooling up +Adam Outler and +Dominik Marszk to try and start working on a way to bring these devices back... But then the worst of the news came in... Users were reporting that attempts to repair these devices via JTAG were failing - these devices were DEAD and totally unrepairable. Someone talked to Josh Groce of MobileTechVideos and he confirmed that he was receiving devices that were unrepairable without replacing the eMMC chip (which was not practical - that thing is a tiny little BGA and only 1-2 people have ever successfully replaced it...) Also, some people were reporting a different "bricking" pattern, where the bootloader/kernel was intact, but the data partition was unusable and the chip would hang if an attempt was made to read from/write to it...

Edit: The above is where I began using the term "superbrick". A "softbrick" could be recovered using Odin or by flashing a proper firmware package with CWM. Traditional "hardbricks" (corrupt bootloader) could be fixed via JTAG. This was different, the eMMC itself was totally trashed and parts of it unusable, with NO method whatsoever of repair.

Eventually XDA posted a warning - http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/ (Yes, people had been bricking left and right on N7000 ICS leaks, not just that I9220 leak...)

It was a bit frustrating... We knew I9100 Update4 was safe, and all leaks up to that point had been safe, but something NASTY was lurking in the M250* sources and in I777/D710/N7000 ICS leaks. It did seem to somehow be connected to erasing/wiping, as it usually happened when someone did something in recovery that would wipe/format a partition.

Even worse... Official ICS launched for the N7000 with XXLPY. We thought Samsung would never let a horrible bug like this get into a released kernel, but we were wrong... I nominated a new theme song for XXLPY - "Bodies" by Drowning Pool.

This post is getting to be longer than I expected... I thought Superbrick would be a 2-parter, but now it's at least going to be 3. In my next post, I'll get to where a hero is found, one who shed the light on the situation and gave us the knowledge we needed to begin protecting ourselves from the nightmare.

This is a continuation of https://plus.google.com/u/0/101093310520661581786/posts/Drq9uJbkGfq

So... This was really bad. Samsung really shafted its customers, as official N7000 ICS was rolling out and devices were dropping right and left. We were starting to lose hope, since Samsung up to this point had been utterly silent on the issue and had just popped out an official release that was killing devices right and left.

On May 9, sfhub and garwynn from the Epic 4G Touch community noticed a Galaxy Nexus (tuna) kernel commit that seemed semi-related at https://android.googlesource.com/kernel/omap/+/cea631bdac53f85cc3bfd720da04f726aae33eaa ... It touched on wear leveller bugs in VYL00M, KYL00M, and MAG4FA fwrev 0x25. Now, the described symptoms didn't sound like our problem, but it was the closest lead that we had. People started checking their flash models and fwrevs, and all affected devices had one of the above flash chips, however fwrev was 0x19. Now, this led to confusion - 0x19 is 25 decimal...

garwynn started trading emails with Ken Sumrall of Google, who committed the above patch to the tuna kernel. For a while, it was a classic case of "talking past each other". Ken did explain some earlier behaviors people had been seeing when trying to figure out their fwrev... Eventually, after we had collected more data, garwynn explicitly described what was going on, in detail, to Ken: We were seeing damage happen during wipes/formats, and all devices affected had fwrev 0x19. The response was the post that changed everything, and allowed us to begin saving thousands of devices from getting damaged: http://xdaforums.com/showpost.php?p=26255080&postcount=159 - Ken even had a potential method to repair these damaged devices, although it was proprietary and he needed permission from Samsung to share it.

We spent a while trying to figure out why Gingerbread was safe despite MMC_CAP_ERASE being present. We eventually got the answer:

http://xdaforums.com/showpost.php?p=26521643&postcount=293

Gingerbread recoveries didn't do a low-level erase operation, ICS recoveries did. This gave us all the information we needed to properly protect devices - both by removing MMC_CAP_ERASE from kernels we had source for, and removing the erase commands from as many recoveries and update-binaries as we could, which was eventually implemented in CM9 by topprospect (Skyrocket maintainer - he had Superbricked his Skyrocket at this point) - http://review.cyanogenmod.org/#/c/17326/

In addition we had somewhat more information on the recovery process - it was dangerous (at this point, we assumed this was due to clobbering the bootloader, we'd learn more later...), and Samsung was highly unlikely to release the information. This did not surprise anyone involved.

So, at this point, Ken had saved our asses... After explaining our issue in detail, he was able to provide us with the information we needed to protect our devices. Ken Sumrall, if you ever read this - you are a hero to thousands of Galaxy S2 and Galaxy Note owners.

Eventually, in early June, +Daniel Hillenbrand reached out to one of his contacts at Samsung ( https://plus.google.com/u/0/111398485184813224730/posts/21pTYfTsCkB ), and they finally became officially aware of the issue. With that, I will conclude this post. I'm not sure if the next one will be today, or in 2-3 days. I need to make dinner!

.