We now have the ability to make all devices with Hummingbird processors into "Super-Dev Phones". I just need a single dead board from each model to locate the proper modification. It can be water-damaged, broken, busted, cracked, smacked, set on fire, chewed on by your dog, dropped, thrown against a wall, or otherwise inoperable. I need a mainboard from each device to make this work.
If you wish to donate a dead device, post here, send a PM, or email me at my username @gmail.com
We can bring this modification to every device with the same processor, we just need to perform analysis before you can set up your device for bootloader development, or resurrect them from a hard-bricked state with nothing but software after a slight hardware mod.
We need to locate the xOM5 pin on following devices before they can be modified into UnBrickable Super-Development devices:
SGH-i896 Samsung Captivate UnBrickable thanks: bulletproof
SGH-i897 Samsung Captivate UnBrickable thanks: bulletproof
GT-i9000 Samsung SGS UnBrickable thanks: Zak Stinson
S8500 Samsung Wave Plans Available thanks: Rebellos
S8530 Samsung Wave II Plans Available thanks: Rebellos
SPH-D700 Samsung Epic 4G Plans Available thanks: James I-----
SGH-i997 Samsung Infuse 4G UnBrickable thanks pdx 528e
SGH-T959 Samsung Vibrant UnBrickable thanks: ChauncyG
SGH-T959V Samsung GalaxyS 4G UnBrickable thanks: bhundven
SGH-T849 Samsung Galaxy Tab 7.0 inch
GT-P1000 Samsung Galaxy Tab UnBrickable Thanks F50+
GT-P100 Samsung Sprint Galaxy Tab UnBrickable
SCH-i800 Samsung Verison/US Cellular Galaxy Tab 7.0 UnBrickable
SHW-M180 Samsung Galaxy Tab
GT-i9010 Samsung Giorgio Armani Galaxy
T839 Samsung Sidekick 4g UnBrickable
SCH-i500 Samsung Fascinate UnBrickable thanks: RootzWiki
SCH-i520 Samsung Droid Charge USB OTG port issue thanks: Clarkkent434
7e ViewSonic ViewPad
R90L200 Pandigital 9" tablet
SGH-i987 Samsung Galaxy Tab 7.0
SGH-T849 T-Mobile Samsung Galaxy Tab 7.0
GT-P1000N Samsung Galaxy Tab 7.0
SGH-i877 Samsung Inspiration
GT-I9020 Google Nexus S GSM - Failed -
GT-I9023 Google Nexus S CDMA - USB OTG port issue - Modification located, but CDMA gets in the way of USB OTG
GT-P1010 Samsung Galaxy Tab 7.0 Wi-Fi 16GB
M9 Meizu
SC-01C NTT DoCoMo Galaxy Tab 7.0
X10 Viliv HSPA 32GB
X7 Viliv HSPA 32GB
SCH-i400 Samsung Continuum
M9300 Kyocera Echo
YP-G1CW Samsung Galaxy S WiFi 4.0 8GB
SGH-T759 Samsung Exhibit 4G
yp-g70 Samsung galaxy s wifi 50 2
YP-G70EW Samsung Galaxy S WiFi 5.0 16GB
YP-GB70NW Samsung Galaxy Player 70 32GB
SCH-I500 Samsung Galaxy S Mesmerize
YP-MB2 Samsung Yepp / Galaxy Touch 32GB
GT-I9088 Samsung Galaxy S
YP-GB1EW Samsung Galaxy Player
16GBH-I909 Samsung Galaxy S Pro Galaxy S
SCH-W899 Samsung phone
SCH-R910 Samsung Galaxy Indulge / Forte\
MID8024-4G Coby Kyros 8"
MID7022-4G Coby Kyros 7"
MID1024-4G Coby Kyros 10.1
Just about anything with a Samsung processor in it.. There's so many
devices. These are the most common ones we are targeting.
Once I have received any of the above boards, I will attempt one of the following tricks to find out where the xOM5 resistor lies. Please understand that there is ALWAYS risk while working on electronics. I have done several of these sucessfully.
Methods for locating modificaton
1. Monitor memory locations in real-time while using the viewmem tool for changes to the OM registers. This only works on a rooted and working device. I can short high from behind a 10kohm pull-up resistor to a low value which is pulled down from a 100kOhm pull-down reistor. This will allow the high to counteract the low and a memory location can be monitored while performing this operation. This leaves the device totally operational and is the best way to perform this type of analysis, but is only accessible on some devices
2. Using overlays and processor pinouts, I can trace out likely locations of the xOM5 resistor, make a modification, and watch the results from the SBL over UART. This leaves the device totally operational.
3. Using relative positioning, I can pick a resistor, make a change and test for proper modifiction. This leaves the device totally operational.
4. Using a multimeter, I can remove the processor from a device and trace out the pins manually. This method is only appropriate for a broken device.
As an additional benefeit, we may be able to port the Nexus S bootloaders to the device, allowing for the latest version of Android to be ported easily to the device... After that, Ubuntu, Apple iOS, WP7, you name it...
Let me get into some of the technical details here... If you're not technical, jump to the end.
----
Pure and simple, this is a hardware exploit which allows direct upload of code to run on the S5PC110/Hummingbird/Cortex A8 platform. Samsung's chain of trust(CoT) model uses hardware to authenticate the Integrated Read-Only Memory (IROM), which authenticates the initial bootloader (IBL), which authenticates the Primitive Bootloader(PBL)... The IROM,IBL, and PBL are all loaded in IRAM, the PBL's job is to initialize Dynamic RAM(DRAM) and authenticate/load the Secondary bootloader(SBL AKA BL3), which loads a kernel, which loads the operating system you see on-screen.
This is a two part hack. We've developed a hardware modification which allows USB download of code. We've also developed the Hummingbird Interceptor bootloader(HIBL) which intercepts the CoT and allows a second, unsigned download. The HIBL uses official code to handle authentication, which jumps to another memory location. It's this memory location where we place our exploit. Our exploit reuses the same code that downloads the HIBL to IRAM, but it initializes DRAM which means you can directly upload a SBL(the final bootloader) to DRAM.
So once again.. really quick... We use a hardware mod to download Rebellos' HIBL, which violates the Chain of Trust, exploits a memory jump and allows unsigned code to run on the processor. All this means you can revive a dead phone easily or try out other operating systems and debug easily, regardless of signature checking on the device.
---------
The first part is the hardware modification so things can be tested without risk. Please help out if you have a dead device. I can make constructive use of it, or you can PM me for instructions. Either way, that old junked device you have can help out millions of people.
Made sticky for the time being
@all
If you don´t have any of the requested stuff please stay away from cluttering the thread, all non related posts such as "great idea!" and so will be deleted and re-incidence could lead to a ban
AdamOutler said:
As an additional benefeit, we may be able to port the Nexus S bootloaders to the device, allowing for the latest version of Android to be ported easily to the device. Apple iOS, WP7, Ubuntu, you name it...
Click to expand...
Click to collapse
So maybe u can run iOS on samsung, or WP7 on iPhone?
Or i misunderstand?
Is my HTC Desire a Cortex-A8 phone or is it not? I didn't know and just NOW found out (after some googleing): "Nope... Some kind of snapdragon cpu".
But I guess not everyone takes the time to look up the cpu of their phone like I did.
I believe if you explicitely list all C-A8 devices (although it seems like a lot of work to do so) you'll receive more bricked phone donations as when you only list the most common ones, because most guys will probably read this post, say "mhh, no my phones not listed here", close their browser tab and forget about that thread, even though they might have a C-A8 phone.
If you want to maximize the donations of bricked phones, list them explicitely in a "searchable" (=search engine friendly) manner.
Just a recommendation, though
akurei said:
Is my HTC Desire a Cortex-A8 phone or is it not? I didn't know and just NOW found out (after some googleing): "Nope... Some kind of snapdragon cpu".
But I guess not everyone takes the time to look up the cpu of their phone like I did.
I believe if you explicitely list all C-A8 devices (although it seems like a lot of work to do so) you'll receive more bricked phone donations as when you only list the most common ones, because most guys will probably read this post, say "mhh, no my phones not listed here", close their browser tab and forget about that thread, even though they might have a C-A8 phone.
If you want to maximize the donations of bricked phones, list them explicitely in a "searchable" (=search engine friendly) manner.
Just a recommendation, though
Click to expand...
Click to collapse
No it's not
Apple A4
Samsung Hummingbird
TI OMAP3
Only phones with the above are from Ol-Sammy, Big Apple, and Google's MOTO . HTC gets their cpu's from Qualcomm which has their own special architecture that's a hybird of Arm v7/v8. But it's closer to v7 so your device can't help them.
Oy, you now have me torn. I picked up a physically broken iphone 4 last weekend and am planning to repair and sell it, but I would love to see this go off the ground.... Decisions, decisions......
AdamiX said:
So maybe u can run iOS on samsung, or WP7 on iPhone?
Or i misunderstand?
Click to expand...
Click to collapse
Let me break this down... This modification means you can NEVER brick your phone. You have to physically destroy it. There's no firmware which can ruin the phone. You simply plug it in and run this tool..
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This tool is still a work in progress. It requires a Linux machine (or linux Virtual machine) in order to run. However, it works, and it works well. This tool will work for:
SGH-i897
SGH-i896
SGH-i9000
SGH-i9010
SGH-i997
GT-P1000
T959... We will need to write another tool for other devices.
What this allows is for debugging of entire operating systems without any risk. For example, I installed BADA Bootloaders to my device last night with one of the guys from the BadaDroid project (they're working on porting Android to Bada). My device totally crapped when it saw that firmware, but it gave detailed logging messages about GPIOs. It would be possible to take that firmware and rewrite it to work with our devices, and it basically eliminates that "what if I screw something up" $600 barrier that prevents porting of other operating systems to our devices.
After I flashed Bada bootloaders with the tool above, I simply pulled the battery out, put it back in, connected to USB, used the tool above and it put my phone back into Odin download mode, at which point I reflashed the device.
We need to spread this mod to all the devices. Currently we have SGH-i897 mod done.
Ace42 said:
No it's not
Apple A4
Samsung Hummingbird
TI OMAP3
Only phones with the above are from Ol-Sammy, Big Apple, and Google's MOTO . HTC gets their cpu's from Qualcomm which has their own special architecture that's a hybird of Arm v7/v8. But it's closer to v7 so your device can't help them.
Click to expand...
Click to collapse
That would mean the Samsung GT-I917 (Focus) wouldn't work because it uses a Qualcomm CPU. So why was it included in the list?
StarbuxMcCloud said:
That would mean the Samsung GT-I917 (Focus) wouldn't work because it uses a Qualcomm CPU. So why was it included in the list?
Click to expand...
Click to collapse
I would ask the OP, could be a mistake, unless it still has a xOM5 pin on board. Which could be possible since it's still a Sammy after all. And Sammy makes parts for Apple too. He didn't put any htc phones in the OP, so only Sammy built phones contain the pin he wants.
StarbuxMcCloud said:
That would mean the Samsung GT-I917 (Focus) wouldn't work because it uses a Qualcomm CPU. So why was it included in the list?
Click to expand...
Click to collapse
You're right, removed from the list. I must have received some misinformation somewhere.
Great job! THIS is xda is all about. Hacking the devices until you cant hack them anymore
but no Samsung Epic 4g love?... Its sprints version of the Galaxy S
ugothakd said:
Great job! THIS is what xda is all about. Hacking the devices until you cant hack them anymore
but no Samsung Epic 4g love?... Its sprints version of the Galaxy S
Click to expand...
Click to collapse
That one should work too, it has the Cortex in it, guess he has to add that one next. Unless CDMA causes issues with his tools..
I have a I9020T Nexus S that a shotty kernel made me loose my baseband and pretty much all phone info including IMEI.
It's pretty much a tiny wifi tablet at this point. That being said I'm not sure I want to part ways with it, but I really don't want to send it off to Samsung.
If you guys have and Ideas on how to fix it, I don't mind using it for testing.
Also may be interested in a PM with instructions on what is needed to get the information you'll need to help develop your work.
Either way, thank you all for the hard work, I think this is an awesome development for our community.
AdamOutler said:
We need to locate the xOM5 pin on following devices before they can be modified into Super-Development devices:
Samsung I9000 SGS
Samsung S8500 Wave
Samsung S8530 Wave II
Samsung SGH-i997 Infuse 4G
Samsung T959 Vibrant
Samsung SGH-T849 Galaxy Tab 7.0 inch
Samsung GT-P1000 Galaxy Tab
Samsung GT-i9010 Girogio Armani Galaxy
Samsung GT-i8350 Omnia 7
Google Nexus S
Apple iPhone4
Just about anything with a CORTEX-A8 processor in it.. There's so many devices. These are the most common.
Click to expand...
Click to collapse
I just want to help out your list by adding some more common phones that use the Cortex-A8 Processor:
Samsung i8910 Omnia HD
All First Gen. iPad types
Samsung T839 Sidekick 4g
Palm pre, Palm pre plus
Palm pixi, Palm pixi plus
iPhone 3GS
Samsung SCH-i520, Samsung Inspiration, Samsung Stealth V, Droid Charge
Most All motorola android phones running 1ghz processors
Nokia N900
Thankx Samsunguy, could you add in the model numbers as well?
For instance, Samsung SPH-D700 Epic 4G should be added to the list (and I'll be hunting down people with a "broken" Epic for the cause).
=]
nubecoder said:
Thankx Samsunguy, could you add in the model numbers as well?
For instance, Samsung SPH-D700 Epic 4G should be added to the list (and I'll be hunting down people with a "broken" Epic for the cause).
=]
Click to expand...
Click to collapse
I updated my list and added common names and model numbers for the devices that had them.
And no problem
Hey Adam,
I've got a motorola droid here (with a broken speaker/microphone cable, so sound etc doesn't work), which uses the OMAP3430 CPU, would you be interested in this?
Might be very handy for debugging the Milestone, which is pretty much the same, but GSM and with a locked down bootloader.
Cheers,
Hobo
s5pc110/s5pv210
Shouldn't the list include s5pc110/s5pv210 based devices only? Cortex A8 is a bit general.
Samsunguy said:
I just want to help out your list by adding some more common phones that use the Cortex-A8 Processor:
Samsung i8910 Omnia HD
All First Gen. iPad types
Samsung T839 Sidekick 4g
Palm pre, Palm pre plus
Palm pixi, Palm pixi plus
iPhone 3GS
Samsung SCH-i520, Samsung Inspiration, Samsung Stealth V, Droid Charge
Most All motorola android phones running 1ghz processors
Nokia N900
Click to expand...
Click to collapse
Thank you. I will review each one for compatibility. They must be based on Hummingbird archetecture... really quickly, I checked the wikipedia on the Droid Charge and it said S5PC110 so that's a go for sure!
Samsunguy said:
I updated my list and added common names and model numbers for the devices that had them.
And no problem
Click to expand...
Click to collapse
I appreciate that, it makes things alot easier
masmalo said:
The Samsung Galaxy Tab 7 Wifi Only GT-P1010 uses the Cortex A-8 too
Click to expand...
Click to collapse
I will add that one. Thanks.
mystichobo said:
Hey Adam,
I've got a motorola droid here (with a broken speaker/microphone cable, so sound etc doesn't work), which uses the OMAP3430 CPU, would you be interested in this?
Might be very handy for debugging the Milestone, which is pretty much the same, but GSM and with a locked down bootloader.
Cheers,
Hobo
Click to expand...
Click to collapse
I'm not sure about Motorola products.. I think they mostly use the Qualcom archetecture... I'll verify to make sure.
Volcacius said:
Shouldn't the list include s5pc110/s5pv210 based devices only? Cortex A8 is a bit general.
Click to expand...
Click to collapse
You may be right, but so far that's all we've found in common with the entire range of processors. don't forget the S5PC100, OMAP and A4.
Related
Samsung Galaxy Tab 10.1 OR Wait for Tegra Three devices?
I would also allow for you to suggest other devices but please only android and please only 10 inch tablets.
Also the new tegra three devices might not be as thin or good-looking as the samsung which i really care about.
The only reason i like tegra is because of the support it has in the android app developing community so please try to keep the suggestions to tegra devices unless you have a good reason to contradict it.
my first priority is looks, build & battery backup. tell me which one has better looks & real battery backup?
I strictly don't "need" a dual sim...so the second sim will always be empty in either case.Selected this as its the best available in my budget...(btw, my budget was rs.15000 but extended to rs.16000 for this phone as it seems to be a good phone for my requirements)
thought about taking htc desire v but after using my friend's desire v i dropped the idea as the touch seems to be missed by phone for a second...but otherwise its a fabulous phone too(earlier was confused b/w desire v & samsung s duos)
I've used samsung wave 3 for a day (another friend's phone) its smooth fast....but the problem is with apps & games....really couldn't find much interesting apps & games on internet.(being bada 2.0)
None of my friend has galaxy s duos so couldn't use it personally (anybody using it?give me a personal review)
I even heard wave3 is going to get tizen os (intel & samsung tie-up which will enable android apps on this phone) but samsung havn't said anything from last 6 months about confirming this...last update about tizen was a prototype phone launched to test tizen for developers. m afraid that suppose i buy wave 3 n samsung dont come up with tizen update then i would left with just the default apps(like samsung always do...they don't care about their existing consumers & come up with new to the new consumers only)
Also, tell me, i know super amoled display is better but does the tft lcd on galaxy s duos matches it so some extent?
I'm really confused. please help me?
Please read Post #2 for background info.
Post #3 discusses safety.
Post #4 lists affected devices and the status of their CyanogenMod ports.
Post #5 details the work needed to support a new device.
This is a work in progress. Please subscribe to this thread to keep up to date. More to follow soon.
Currently Supported Devices
Galaxy S II International (i9100)
Galaxy S II AT&T (i777)
Galaxy S II Epic 4G Touch (d710)
Galaxy Galaxy Note (n7000)
In Short
Brickbug fix by independent developers killed TRIM. Because of this, all devices -affected or not- running 'safe' custom roms end up slowing to a crawl with enough usage.
Samsung's later fix does not inhibit TRIM, but it is widely believed that their fix is incomplete and inadequate. I beg to differ and believe Sammy's fix could well be adequate, and I have good reasons for it. They are summarized in Post #3.
Which Devices Are Known To Be Affected?
Please refer to Post #4.
What To Do?
Make CyanogenMod builds for affected models where the indie fix is replaced with sammy's fix.
CLEARLY LABEL THEM AS DANGEROUS.
Is That Enough?
No, you need to actually invoke fstrim somehow. Android 4.3 and later automatically does so daily when left overnight to charge. You can invoke fstrim manually from a root shell, or just use this app instead. Also, there are scripts you can flash to fstrim on boot.
Are The Builds Safe?
It depends. Not all devices of a particular model known to be affected by brickbug carry the bug. If your device is brickbug-free, then yes, it is safe. You have been running crippled custom roms for ages now and you definitely want these builds to restore the speed and responsiveness of your device.
If your device is affected by brickbug, then it could be safe or not. I suspect yes, but testing is needed. Please refer to Post #3. You are strongly advised NOT TO TRY THESE BUILDS or else your phone could very well die forever. You have been warned.
How Do I Know If My Device Is Affected?
Use this app. Root is requested but not needed for this test. WARNING: Do not trust its verdict! Instead use the reported eMMC model name and the firmware revision (fwrev) to look up your eMMC in this table. Of particular concern is the TRIM bug supposedly present only in MAG2GA eMMCs.
How Do We Test Safety?
I hope some volunteer with an affected device and a partially cracked screen may show up. Also, I have a working Galaxy S2 i9100 display (dead mobo); if someone has an affected fully cracked S2 to donate, that could work. I live in Argentina, but I have friends in the US that come and go.
How Do We Test Performance?
Use Androbench. Make sure you have plenty of free space in your internal memory. Run it on your standard CM before switching to trim-enabled CM. Take a screenshot? Switch, trim the file systems, and rerun.
My Device Is Affected. My Device Is Too Slow. Is There An Alternative For Me To Restore Performance Now? I Do Not Want To Wait For This Project
Yes there is. But involves trade-offs. I will write about it soon.
XDA:DevDB Information
BrickbugAftermath, Tool/Utility for all devices (see above for details)
Contributors
Lanchon
Version Information
Status: Beta
Created 2014-07-21
Last Updated 2014-09-13
The Background
During the early crazy days of the brickbug saga, developers such as Entropy512 struggled to understand what was happening and how to put an end to the long line of dead devices that modders were rapidly accruing. All the while Samsung helped with their usual routine, a mixture of silence, denial and deception.
Developers found the problem: certain perfectly legal commands when sent the the eMMC (the solid state drive inside phones) destroyed the eMMC module. The module made by Samsung includes flash memory, a processor and its software (called firmware). The firmware implements an FTL, a flash translation layer, that emulates something akin to a harddrive atop the flash memory. This firmware had a bug that caused corruption on its own data structures when certain commands were executed. When the processor later accessed these corrupt structures (say, to read the bootloader partition on power on) it stopped responding, and as a result the devices never booted again.
<RANT>This buggy firmware is Samsung's trade secret and opaque to independent developers, and developers could not change it. Samsung had tools to upgrade the firmware and eliminate the bug (we know this because Google engineers were given this tool) but chose not to release it. In all probability Samsung could also reset the dead eMMCs with software, but preferred to screw their customers. I imagine Samsung failed to care about field upgrades and did not include a firmware update route in the module that supported encrypted firmware images. Then releasing a firmware upgrade tool to fix their buggy module would expose their precious secret silly little buggy firmware without encryption. And it seems they rather just screw their customers instead.</RANT>
Developers worked around the bug by making sure a whole class of eMMC commands would never be issued and urged everybody to upgrade their 'dangerous' (standard actually) custom roms to 'safe' (read 'crippled') alternatives.
Samsung later released 'safe' Android updates. But their version of 'safe' only excluded a subset of the of commands excluded by independent developers. The general response of developers was distrust of Samsung and the belief that Samsung's fix was not enough and not 'safe'. This based mostly on a very bad track record by Samsung during the brickbug days, involving technical matters, denials and lies.
TRIM
Flash storage in general (including the eMMC) requires that certain commands be ran regularly in order to keep performance high. If not, under normal usage performance will degrade enormously. (This is a result of so called write amplification and other effects.) As users can vouch, devices like the Galaxy S2, the Galaxy Nexus, and the Nexus 7 were snappy and fast when new; then they gradually became abysmally slow after months of use.
These commands are called DISCARD, ERASE, TRIM or fstrim depending on context and software stack level, but mostly refer to the same core function.
The Brickbug Aftermath
And this is the problem: the brickbug fix that independent developers implemented disable these commands. This means that running a custom rom in the affected devices pretty much guarantees that you will end up with a ridiculously sluggish device given enough time. In effect, these devices severely under-perform when running custom roms due to software issues that can possibly be fixed. With the current state of affairs, I would go as far as considering custom roms useless for these devices.
This project aims to provide a safe TRIM solution for these devices when running custom roms.
This project has to be executed carefully. I expect accusations of recklessness to be thrown at me for reintroducing 'unsafe' roms. And maybe a couple of devices of careless people will die.
But many other devices will find new life and become usable again.
Is It Safe To TRIM A Device Affected By Brickbug?
Maybe. Folklore says no, but there are good reasons to believe it is safe. Testing, possibly destructive, is required.
Indie developers' fix disables all trim and erase commands sent to the eMMC. Samsung's fix converts secure erase and trim requests to their non-secure counterparts and dispatch them. (Trim and erase are essentially the same function using different arguments.) The non-secure versions are what we need for performance. The secure versions are needed for privacy, to actually assure data is deleted from the eMMC, for instance when wiping a phone clean before selling it. (Note that the non-secure commands will typically wipe beyond recovery unless you are the NSA or something like that: the data becomes inaccessible and you would need to side step the FTL controller and access the flash directly to get to it, which requires physically dissecting the module or else hacking the FTL firmware.)
People I have talked to simply doubt that Samsung's fix is enough, maybe for no good reason. Although I am very critical of Samsung on many fronts as other posts in this thread clearly show (to the point of promoting a total boycott of the brand), I will play the devil's advocate in this case and try to convince you that maybe Samsung got it right this time.
There is no question that secure erase and trim trigger the bug and brick the eMMC and thus the device. The question is whether non-secure erase and trim are safe or not. Folklore says no, you be the judge:
Reasons to believe non-secure erase and trim are unsafe:
Samsung showed ineptitude during this whole mess and cannot be trusted.
Secure and non-secure erase and trim commands have frighteningly similar names.
Reasons to believe non-secure erase and trim are safe:
I could not find a single documented case of bricking due to an non-secure command anywhere on the net. I have also talked to Entropy512 the brickbug hero and to the author of the LagFix app and they could not single out any such event.
Samsung investigated the bug in their secret firmware and definitely found it because they fixed it in later versions. Knowing exactly what was wrong with the firmware, and having been shown how indie developers fixed the bug, Samsung decided to implement a different fix that instead converted secure commands to non-secure, presumably because they know that non-secure commands are safe. (But some think it could just be humongous ineptitude.)
They had enough confidence in their fix to push it upstream with enough dedication as to apparently have it mainlined. I am not an expert on linux kernel politics, but this fix apparently made it all the way up into none other than Linus Torvalds git tree. I think this means that all linux kernels everywhere, from desktops to supercomputers, will now have this silly brickbug patch in their kernels. I can only imagine adequate effort has been expended in verifying its effectiveness.
Typically Samsung's stock 4.1.2 androids include the patch (Galaxy S2 I9100 4.1.2 has it for sure), and I could not find accounts of brickings using Sammy's patched stock androids anywhere on the net.
Finally, and more convincingly to me, despite their similar names, secure and non-secure commands are completely different beasts. Six months ago i discussed how a very naive FTL could be implemented in this post with the intention of showing precisely that. If you care to to read the post you will notice that:
Implementations of secure and non-secure erase are extremely different.
The implementation of secure erase is vastly more complicated.
The implementation of non-secure erase is actually a subset of the implementation of write. Thus, if write does not trigger brickbug, so should not non-secure erase.
TODO: Investigate this: CyanogenMod's brickbug page maintainer seems to imply that running LagFix (which trims) while using a patched rom is safe. But is he referring to Samsung's or devs' patch? It should be Samsung's, because if it is devs' then LagFix would not work.
WARNING: There is a different bricking bug called TRIM bug that affects TRIM on a specific eMMC. Apparently it has only been observed on the Nook HD+. (But how can we be sure that it is not in other eMMCs (including brickbug-free eMMCs) if TRIM in these modules has never been massively put to use and tried?) The kernel patch mentioned seems to add support for the eMMC DISCARD command on Samsung moviNAND 4.41+ eMMCs and then choose it over TRIM while doing file system trimming. It is not apparent anywhere that this is a workaround for a bug, but by preferring DISCARD over TRIM it may sidestep a TRIM issue. DISCARD is a new command only featured in newer eMMCs. It is similar to TRIM but enables faster implementations. The patch is Samsung-specific but not specific to any eMMC device. It could be ported to any kernel but wont help unless the eMMC is moviNAND 4.41+. Note that older Samsung eMMCs could be affected by the TRIM bug, although I could not find any information online to support this hypothesis.
Affected Devices
See here for more information.
Which Devices Are Known To Be Affected By Brickbug?
GT-N7000 Galaxy Note (International)
GT-I9100 Galaxy S II (International)
SGH-I777 AT&T Galaxy S II Attain (3G)
SGH-I727 AT&T Galaxy S II Skyrocket (4G)
SGH-T989 T-Mobile Galaxy S II Hercules
Most other Samsung tablets and handsets released in 2011
Amazon Kindle Fire first generation (approximately 50% of units; the rest have unaffected Toshiba eMMCs)
Acer A500 (no official CyanogenMod support)
Nook Color
Which CyanogenMod ROMs Are Known To Include Indie Developers' TRIM-Crippling Brickbug Fix?
Part 1: Recoveries that suppress wiping of eMMC partitions (BOARD_SUPPRESS_EMMC_WIPE)
BOARD_SUPPRESS_EMMC_WIPE
galaxys2-common/BoardCommonConfig.mk
celox-common/BoardConfigCommon.mk
motorola/qcom-common/BoardConfigCommon.mk
(FYI: Recoveries that wipe eMMC partitions non-securely.)
Devices:
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: yes
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: yes
GT-I9100G Galaxy S II (G): no
GT-I9250 Galaxy Nexus (GSM): no
Nexus 7 (2012): no
Amazon Kindle Fire first generation: no
Nook Color: no
Nook HD+: no
Part 2: Kernels that suppress ERASE/TRIM/DISCARD eMMC commands (no MMC_CAP_ERASE)
Each SoC (system-on-chip) has its own set of on-chip peripherals that require specific ad-hoc drivers. Which of these drivers controls the peripheral that is connected to the eMMC is SoC- and board-specific. The indie developers' fix for brickbug entails hacking this driver to make in unable to issue ERASE/TRIM/DISCARD commands by way of removing the MMC_CAP_ERASE capability. I could not find a generic way to know which driver controls the eMMC from sources, so this has to be studied for each case.
XDA's codeworkx (thanks!) provided this info:
Exynos: drivers/mmc/host/mshci.c
OMAP: drivers/mmc/host/omap_hsmmc.c
Kernels and boards:
android_kernel_samsung_smdk4210 (Exynos): yes, but this kernel was abandoned after CM 10.1.
android_kernel_samsung_smdk4412 (Exynos): yes, but only for Mach U1 boards (including i9100 and i777).
android_kernel_samsung_msm8660-common (Snapdragon S3): boards seem to use SDCC1 for the eMMC, including celox, so apparently not.
Devices:
GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G): yes, these are Mach U1 boards.
GT-N7000 Galaxy Note (International) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: maybe; are these Mach U1s?
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: these are celox, so APPARENTLY NOT !!!
GT-I9100G Galaxy S II (G): unknown
Galaxy Nexus (GSM / Sprint / Verizon): unknown
Nexus 7 2012 (WiFi / GSM): no (tested fstrim)
Amazon Kindle Fire first generation: unknown
Nook Color: unknown
Nook HD+ : unknown
Which CyanogenMod ROMs Are Known To Include Samsung's Brickbug Fix?
Fixed kernels:
first implemented fix (MMC_QUIRK_MOVINAND_SECURE)
mainline fix (MMC_QUIRK_SEC_ERASE_TRIM_BROKEN)
Devices:
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: yes (for CM 10.1 and earlier: yes)
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: yes
GT-I9100G Galaxy S II (G): yes
Galaxy Nexus (GSM / Sprint / Verizon): no
Nexus 7 2012 (WiFi / GSM): no
Amazon Kindle Fire first generation: NO !!!
Nook Color: NO !!!
Nook HD+ : no
Which Devices Are Known To Be Affected By WL Bug?
Galaxy Nexus
Which CyanogenMod ROMs Are Known To Include The Fix For WL Bug?
It seems that only 3 kernels include this fix, the Galaxy Nexus, the Nexus Q, and the Qualcomm-based Galaxy S2s.
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: NO !!!
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: yes
GT-I9100G Galaxy S II (G): NO !!!
Galaxy Nexus (GSM / Sprint / Verizon): yes
Nexus 7 2012 (WiFi / GSM): no
Amazon Kindle Fire first generation: no
Nook Color: no
Nook HD+ : no
Which Devices Are Known To Be Affected By TRIM Bug?
Nexus 7 2012
Nook HD+
Which CyanogenMod ROMs Are Known To Include The Fix For TRIM Bug?
These 4 kernels plus these 3 kernels:
android_kernel_samsung_smdk4210
android_kernel_samsung_smdk4412
android_kernel_samsung_jf
android_kernel_samsung_msm8930-common
android_kernel_bn_omap
android_kernel_asus_grouper
android_kernel_htc_msm8960
And I have found these 3 kernels that seem to include the same fix but triggered for specifically singled out eMMC parts. This may be a subset of the 'standard' fix (it may be an older implementation) or may cover devices not covered by the standard implementation. Besides this, nothing else seems interesting.
Devices:
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: yes
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: NO !!!
GT-I9100G Galaxy S II (G): seems to be covered by this eMMC-specific patch
Galaxy Nexus (GSM / Sprint / Verizon): NO !!!
Nexus 7 2012 (WiFi / GSM): yes
Amazon Kindle Fire first generation: no
Nook Color: no
Nook HD+ : yes
Which Devices Are Known To Be Affected By P17 Bug?
Nook Color
Which CyanogenMod ROMs Are Known To Include The Fix For P17 Bug?
It seems that not a single CM ROM includes this fix.
GT-N7000 Galaxy Note (International) / GT-I9100 Galaxy S II (International) / SGH-I777 AT&T Galaxy S II Attain (3G) / SPH-D710 Sprint Galaxy S II Epic 4G Touch: no
SGH-I727 AT&T Galaxy S II Skyrocket (4G) / SGH-T989 T-Mobile Galaxy S II Hercules / SGH-I577 AT&T Exhilarate: no
GT-I9100G Galaxy S II (G): no
Galaxy Nexus (GSM / Sprint / Verizon): no
Nexus 7 2012 (WiFi / GSM): no
Amazon Kindle Fire first generation: no
Nook Color: NO !!!
Nook HD+ : no
How To Add Support For Device
Please refer to Post #4 for more info.
Make sure Samsung fixes are applied to the kernel.
Make absolutely sure Samsung's Brickbug fix is applied or apply it yourself.
Make absolutely sure Samsung's TRIM bug fix is applied or apply it yourself.
Optionally apply Samsung's WL bug fix.
NOTE: My Exynos 4210 kernels do not have a fix for WL because Entropy512 has told me that no 4210 devices exist that are affected with this bug. But I did prepare a patch for it for CM and it is included in the sources of my 4210 TRIM kernels (though not applied). In any case, this bug involves data corruption, not bricking. Entropy512 also said this bug was never observed, but data corruption happened to me several times on one of the Galaxy Nexus I had, and I suspect this bug was the culprit.
Remove indie developers' fixes.
Please tag all changes with BrickbugAftermath in a comment so that they can be easily found and verified if needed.
Enable non-secure wiping of eMMC partitions in recovery.
This can me done by appending these lines to the BoardConfig.mk device file:
# BrickbugAftermath: Enable non-secure wiping of eMMC partitions in recovery
BOARD_SUPPRESS_EMMC_WIPE := false
COMMON_GLOBAL_CFLAGS += -DNO_SECURE_DISCARD(Make sure the NO_SECURE_DISCARD flag is not already added elsewhere in the makefile or its includes.)
Even when using non-secure discard, partition wiping can be unsafe in the following scenario:
-a complete rom is built with partition wiping enabled
-the full rom is installed on a device
-a different kernel is later installed or booted up
-the kernel is MMC_CAP_ERASE enabled (can trim)
-the kernel does not include the MAG2GA TRIM bug patch
-the device is affected by MAG2GA TRIM bug
Revert suppression of ERASE/TRIM/DISCARD eMMC commands in the kernel.
Find out which kernel driver talks to the eMMC and restore its MMC_CAP_ERASE capability.
For example, in the Exynos 4412 kernel you should effectively revert this change.
Build your ROM and give it a really scary name.
Please name your ROM file like this:
this-will-hard-brick-your-device--cm-11-2014XXXX-XXXXX-TRIM-i9100.zip
People flash before reading and a lot of testing is needed before the general safety of these builds can be assumed.
(reserved 1)
(reserved 2)
Fixing the Celox devices
revert suppression of eMMC partition wipes.
affected devices:
* SGH-I727 AT&T Galaxy S II Skyrocket (4G)
* SGH-T989 T-Mobile Galaxy S II Hercules
* SGH-I577 AT&T Exhilarate
https://github.com/search?q="celox-common+BoardConfigCommon.mk"+user:CyanogenMod&type=Code
the kernel on these devices do not suppress ERASE/TRIM/DISCARD
eMMC commands (ie, they support MMC_CAP_ERASE) so fstrim works.
this is safe because the kernel has samsung's brickbug fix applied.
given that ERASE/TRIM commands are already being used with
each nightly automatic fstrim since android 4.3 and proven safe,
there is no need to keep the partition wiping disabled in recovery.
this line:
BOARD_SUPPRESS_EMMC_WIPE := true
should be remove from:
https://github.com/CyanogenMod/android_device_samsung_celox-common/blob/cm-11.0/BoardConfigCommon.mk
in both cm-11.0 and cm-10.2.
these devices have the following Samsung fixes applied:
* brickbug: YES, since CM 10.2
https://github.com/CyanogenMod/andr...mmit/2fdc4e253df2af8490c389a0840febbdec5f5175
* wear leveling data corruption bug: YES, since CM 10.2
https://github.com/CyanogenMod/andr...mmit/16636bd32b80f9d77d5e4e36f30498292810d61b
* MAG2GA TRIM bug: NO
* M8G2FA "P17 corruption" bug: NO
more information:
http://forum.xda-developers.com/showpost.php?p=54295205&postcount=4
MOD EDIT:
This is not a Samsung Device and does not belong to any forums.
can u share it? i really want to use that custom rom looks cool!!! :good: is it stable?
...let me begin with "you don't have a Samsung Galaxy Note 3 N900" as Samsung never employed Mediatek SoCs.
Never.
And considering you have a replica of the thing and managed to boot an Xperia port and have CWM is a miracle by itself and no small amount of skill on your part.
This is fake note 3. Home button is to low
Sent from Galaxy Note series
Fake Note no its a Chinese MTK model not a Samsung model .
If you search Google you may find a forum for MTK6572
Thread closed.
This is not a Samsung Device and may mislead Note 3 users to a point of damaging their device.
Hey there, I recently found out Samsung Galaxy Tab S4 will get a DeX mode and thought about how to get it on the previous flagship tablet of Samsung - Tab S3. I have one and I really think that DeX mode will be a nice thing to have on a tablet with a pen. We all know, that Samsung can add that feature later like it did with S9 camera functions on S8 with last firmware update. So there is the question: is it possible to install a Tab S4 firmware on a Tab S3? They have different screen ratio but that must be all differences out there. Maybe hardware home button also. I read about installing different firmware on Android tablets but often people said something like "the devices must be nearly identical to use the same firmware" and all that stuff. But really, the only thing that is really alarming me is the software buttons on Tab S4. I think they will float there for no reason if it si possible to install Tab S4 firmware on Tab S3. If you know something about a different firmware on Android device, please, tell me. Thanks.
EZGGWP said:
Hey there, I recently found out Samsung Galaxy Tab S4 will get a DeX mode and thought about how to get it on the previous flagship tablet of Samsung - Tab S3. I have one and I really think that DeX mode will be a nice thing to have on a tablet with a pen. We all know, that Samsung can add that feature later like it did with S9 camera functions on S8 with last firmware update. So there is the question: is it possible to install a Tab S4 firmware on a Tab S3? They have different screen ratio but that must be all differences out there. Maybe hardware home button also. I read about installing different firmware on Android tablets but often people said something like "the devices must be nearly identical to use the same firmware" and all that stuff. But really, the only thing that is really alarming me is the software buttons on Tab S4. I think they will float there for no reason if it si possible to install Tab S4 firmware on Tab S3. If you know something about a different firmware on Android device, please, tell me. Thanks.
Click to expand...
Click to collapse
It is possible to flash a firmware from a different device but they have to be of the same hardware chipset. For example, some models of US versions of Galaxy S3 can share each others firmware, but the S4 cannot use the S3 firmware.
But, generally speaking(95% of the time or more) flashing a firmware from a different device results in a hardbricked device. This is mostly due to differences in bootloader and modem. I have a Galaxy S3 SCH-S968C(Straight Talk) that can use the custom ROMs from the SCH-I535(Verizon) because they are virtually the same device BUT the SCH-S968C CANNOT flash the SCH-I535 stock firmware, it results in a hardbricked device, even though they are the exact same device.
There is no definitive answer to your question other than it is "possible" to use another firmware. But it is ALWAYS a special case scenario because you have to research the devices in question to see exactly how similar they are or are not.
There are cases of devices from one country being used in another country by flashing the firmware from the country the device is being used in, but it is not possible on ALL devices.
Sent from my LGL84VL using Tapatalk