Remember, remember, the first of the Note, the ICS release and plot
I know of no reason why the Superbrick treason should ever be forgot
Older forum members and Android users of early Samsung devices may faintly recall the Superbrick fiasco. The events that lead up to Superbrick are long and complex. For the sake of brevity, a tl;dr explanation is that a leaked ICS update for a few carrier variants of the Galaxy S2 i9100 and of the Galaxy Note N7000 caused a permanent brick. This was no ordinary hard brick, as an affected device could not be resurrected via a JTAG and was completely dead and unresponsive. The superbrick affected the eMMC of the device, and hence, repairs could only done with a complete motherboard change.
The Superbrick fiasco, and the accompanying drama that ensued courtesy of Samsung’s attitude towards developers was highlighted in a 13-post series by Andrew Dodd aka XDA Senior Recognized Developer Entropy512 on his Google+. You can find the beginning of this post series here. We highly recommend that readers take some time off and read the full series of posts to gather complete contextual awareness and understand the full gravity of the situation that happened back in 2012-13.
To highlight a few important points, here are a few snippets (with added emphasis) from the posts:
“…In November, Samsung released XWKK5 for I9100 and UCKK6 for I777. Bluetooth HID on these builds would not function with any source-built kernels – only with binaries associated with those builds. Samsung never released another Gingerbread source update for the I9100, even though their binaries showed clear evidence of a functional change to the source. Similarly, I777 UCKK6 source wasn’t released until some unknown time in mid-2012 – I’m fairly certain not until after I9100 ICS was released at best. That’s right – Samsung was violating the GPL with I777 UCKK6 and every I9100 Gingerbread build from XWKK5 (November 2011) until they officially released I9100 ICS (March 2012) – Actually, technically they still are, as Gingerbread source corresponding to those kernels was never released, but it just doesn’t really matter any more…”
“…Around the same time, Samsung launched the Tab 7.0 Plus and Tab 7.7, both based on the same Exynos 4210 SoC found in the GS2….These devices used an Atheros AR6000-series wifi chip. Interestingly, Atheros provides source for these devices under a dual-license, GPL and BSD. (As Atheros holds full copyright to all components of their reference driver, this is legal.) Samsung chose the BSD license for this driver. The end result is, when asked for wifi driver source (which was not present in the source drops for these devices), Samsung replied with “code is dual license GPL or BSD. We choose BSD [over GPL]”…“ – Parent Post
“…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…. – Parent Post
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…
Eventually, Samsung’s “solution” was presented to us. Chainfire was NOT happy with the proposed “solution”, neither was I… It involved no kernel-level protection, and was inferior to what we already had in place with BOARD_SUPPRESS_EMMC_WIPE in CM. In addition they asked us not to distribute the solution and to redirect kernel developers looking for a solution to them!…“
“…Samsung also pretty much refused to discuss any solutions involving bootloaders… The reasoning, which made no sense, was that nearly all of their warranty claims due to custom firmware prior to this eMMC defect were due to bootloader corruption… Of course, this makes no sense, since we wanted to discuss methods of recovering from bootloader corruption, which would eliminate the majority of these warranty costs for Samsung. We were even offering to do the majority of the engineering and solution deployment ourselves, as long as Samsung just gave us some specific small components Dominik and Adam needed!…“
“…Samsung, after “working diligently” for a month, throws a grenade in our faces
In early July, XXLQ5 leaked for the I9100. Within a day, numerous reports of bricks had piled up. Not too long afterwards, XWLPM went live on Kies, and people were bricking left and right with this build too.
Despite claiming to be working diligently on this problem, instead, Samsung took a previously safe device and endangered it!…” – Parent Post
“…So, at this point – It is mid-November 2012, and not a single device affected by Samsung’s defective eMMC has received a kernel fix. While the efforts of the community have damage rates WAY down, as long as Samsung’s official kernels are vulnerable, I’m still going to get a PM every few days from a Superbricked user that needs help whom I cannot help…” – Parent Post
“…In mid-August, I decided to go against better judgement and purchase a Note 10.1 (WiFi variant – GT-N8013). I figured that as it shared an SoC with the I9300, it would be a fairly safe bet…
Now that I had confirmed, both through the nonfunctionality of the wifi driver, and various string comparisons with the backed up stock kernel, that the released sources for any N80xx variant did NOT match the stock kernels (all of them had the same broken wifi driver, and other people who were working with the sources complained about similar issues.), I raised the issue with my contact at Samsung….
They tracked someone down, and that person’s response was: Samsung was under no obligation to provide source that matched the UEALGB build for GT-N8013, as that was not an official build. Yes, that’s right – someone actually dared to claim that the firmware preinstalled on every GT-N8013 unit sold in the United States was a LEAK. This marked the third time someone within Samsung Mobile had blatantly lied to my contact’s face…” – Parent Post
“…So between that, other things (see earlier installments of this saga for many examples), and Superbrick, pretty much all of the Exynos4 maintainers were at the limits of exhaustion with Samsung and especially with Exynos4.
I indicated that the Note 10.1 was going to be my last device, and I was not sure how long I’d be staying with the I777 and N7000, as I was exhausted at this point too.
I was tired of being months behind the rest of the Cyanogenmod team because I worked with devices that had more blobs and more interface breaks in the blobs than any other device
(Except for Tegra3 devices, but people already knew to avoid these unless they were in a Nexus.)…” – Parent Post
“…Near the end [of BABBQ 2012] was Samsung’s developer relations presentation. This was where they promised to improve the quality of reference source code and documentation for Exynos4, in theory alleviating the community’s concerns. The actual presentation content promised little – nearly everything they announced was stuff that already existed technically but was of little to no use due to it being outdated or simply nonfunctional…” – Parent Post
All of this has just been yet another case of Samsung talking and making promises and failing to deliver, just like they’ve been talking and making promises for over a year. Development boards are supposed to be AHEAD of handsets – they don’t need to deal with carrier testing, wireless certifications, or any of the things that are usually notorious for holding back handset updates. Plus their intended target is DEVELOPERS, so they should be the “bleeding edge”. This is what Qualcomm and TI reference source is – It’s the absolute latest, ahead of anything seen on handsets. What we’re getting from Samsung is more than 6 months out of date – ICS for an SoC that was in a handset which launched with ICS in Spring 2012, and which received an official Jellybean update (carrier approvals/wireless certs and all) in early October 2012… But they’re still working on ICS for their reference source???
The series was concluded with a summary post which can be found here. We recommend that all users read it before proceeding.
The starting point of this article was to try and explain why Exynos devices usually lack in terms of AOSP based development when compared to Qualcomm devices. The above mentioned and quoted G+ post series highlighted the difficulties faced by a maintainer of an Exynos device. The post is dated for the time period 2011-2013, so we reached out to a few of the mentioned developers to figure out how the situation currently stands. Afterall, a lot can change in 3 years in the mobile world.
Not for Samsung and its support for AOSP, it seems.
Q: Why do AOSP ROM’s take so long to come for Exynos devices, as compared to say, Qualcomm devices?
A: XDA Senior Recognized Developer codeworkx:
Qualcomm releases always up to date source code which is needed to get all components of their platform working on aosp. See here.
Samsung does nothing.
XDA Senior Recognized Developer Entropy512:
“Qualcomm CAF is vastly superior in terms of traceability to/from OEM releases (I have never seen an OEM device other than a Nexus that wasn’t easily traceable back to a CAF tag at CodeAurora), quality of code, and frequency of updates to Insignal (which has no KitKat for the “Arndale Octa” and nothing newer than ICS for the Exynos4.) In addition to being outdated, there’s absolutely zero traceability between Samsung Mobile’s OEM releases and the Exynos reference source, while all OEMs have a fairly decent amount of traceability back to CAF (HTC and Samsung somewhat less so than others, but still far better than anything Exynos)
Wait, they eventually released JB for the Origen Quad? Not until KitKat was nearly out… And what they called JB was probably close to the useless disaster that was their Gingerbready “ICS”
Exynos3 aka Hummingbird was a completely different story thanks to the Nexus S, but Samsung has made a point of never sharing a chipset between Nexus devices and any of their other devices since then. (Galaxy Nexus was OMAP4 while everything else of that era with a few exceptions was Exynos4, Nexus 10 and the Samsung Chromebook were two of the only Exynos 5250 devices ever to ship, Exynos 54xx switched from Mali GPU to PowerVR along with a whole bunch of other changes so manta was useless for I9500, etc.)”
Q: What is the future of Exynos Development? What steps could Samsung undertake to make themselves more dev-friendly?
A: Codeworkx:
There’s no future. All devs you’ve written to have stopped working on exynos devices a long time ago. Most of them even stopped to work on samsung devices in general.
We’ve asked more than once for source code and nothing happened. They simply don’t care about the community. All they care about is $$$
It is clear that the situation is almost identical to what it was more than 3 years ago. Samsung devices, specifically Exynos based, remain poor examples of showcasing the work of the development community outside of Touchwiz based examples. All development for the device remains largely restricted to modifications to Touchwiz, with the scene of custom ROMs revolving around adding or removing features from Samsung’s closed source OS “skin” through reverse engineering.
This is not to say that Exynos devices get absolutely no support at all for AOSP ROMs. AOSP Roms, like CM and the likes, do eventually land on these devices, but these come after a lot of low level hackery and extreme efforts by maintainers brave enough to devote all their free time fixing what Samsung broke. Even then, the end result is not an AOSP experience the likes of which you’d expect normally, and for this, you can safely blame Samsung.
The wounds of Superbrick are still fresh on those who put together their heart and soul in working towards a broken cause that calls itself Samsung. If you are looking to get a device with the first criterion being custom ROM development and 3rd party ROM developer support, follow along the words of wisdom shared by Codeworkx:
Stop supporting such companies by buying their devices.
Take a sony or nexus device, get quality aosp roms, good community support and simply be happy.
from xda-developers » xda-developers | Samsung, Exynos and AOSP Explained: A Story of Betrayal http://ift.tt/1G1gMao
via IFTTT
Aucun commentaire:
Enregistrer un commentaire