yashsingh1/xdaforums huggingface dataset:
[Galaxy S II Original Android Development] Tungstwenty:
I'm reposting here the same as in this other thread, because I think it's relevant in this context.

--------------------

Guys, even though I was the one advertising this patching mechanism ...

Remember that even if a CWM full factory erase (/data) doesn't end up leading to a brick under a known faulty chip, *that* isn't going to prove it's safe. :D

What does give you the certainty that it's safe is the

knowledge

of what's underneath the patching process so I advise anyone who doesn't feel comfortable or safe to freely ignore what has been shared by these folks and carry on with whatever they think it's best. This is XDA, so no guarantees (at least with regards to what I shared). Each one's brain is there to be used :)

Much in the same way that people that know what's going on know that custom kernel X is safe because that particular source code line has been changed, right?

I can tell you that the file that wiskerp shared:

is indeed SAFE! (unless he replaces it with another file and manages to keep the same URL valid :laugh::laugh::laugh: - that would be an epic prank)

Despite having a pretty reasonable confidence in the detection script on the before / after file, I still personally decompiled the file and had a look at the entire area where the " .... |= MMC_CAP_ERASE " instruction used to be.

Link to a source file with the code already fixed (the additional flag used to be on line 2040): https://github.com/gokhanmoral/siyahkernel3/blob/update4-3.0.y/drivers/mmc/host/mshci.c#L2037

...
mov r3, #0x1a80
str r2, [r5,#0x15c]
movt r3, #6
ldr [B]r1[/B], [r5,#0x188] -> load previous value of caps
str r3, [r5,#0x160]
mov r3, #0
ldr r2, [r4,#0x30]
[COLOR="Green"]orr [B]r1[/B], r1, #0 -> [B]no longer OR'ing with [COLOR="Red"]0x400[/COLOR] as it was before[/B]
[/COLOR]str r0, [r5,#0x16c]
orr [B]r1[/B], r1, #9 -> OR'ing with 0000 1001 (bits for MMC_CAP_SDIO_IRQ and MMC_CAP_4_BIT_DATA)
str [B]r1[/B], [r5,#0x188] -> storing the updated value of caps
mov r0, r7
str r2, [r5,#0x164]
ldr r2, [r4,#0x28]
str r3, [r4,#0x24]
...

The code for this shared XWLPT kernel is now safe and apart from that 1 byte, it's stock (will still give a yellow triangle though, since the Samsung signature is no longer valid, so make sure to use the appropriate triangle removal method of flashing with root to avoid having it in the first place).
[Galaxy S II Original Android Development] whiskerp:
Held my breath and did a Cache wipe, Dalvik cache wipe and CWM Restore using this XWLPT patched kernel on my insane eMMC chip S2. All is well :)

The reason I have gone back to XWLPI is because XWLPT has poor battery life. I think that it's probably down to the WiFi which is a lot more aggressive than the XWLPI one. I think that it searches a lot more and is much more inclined to switch to a stronger AP, but this stops it deep sleeping. Anyway, after 8 hours daytime use on XWLPI I would expect my battery to be at about 70% - on XWLPT it's nearer 50%.

Peter
[Galaxy S II Original Android Development] Tungstwenty:
Siyah 4.0 is now up-to-date with the latest Samsung sources and it works fine on 4.0.4 ROMs (as well as 4.0.3, CM9, CM10/JB, ...). So if you'll be using a non-stock kernel (even if just because of the patched byte), you might as well go for one that includes CWM, support for other features, battery tweaks, etc.

The only reason for not using a custom kernel might be if you don't want root at all.

Also, in addition to Siyah there are several other kernels already updated for 4.0.4, it's just a matter of reading their release notes to see if that's the case (and to make sure they don't have the cap_erase problem).
[Galaxy S II Original Android Development] majkicimo:
Hi,can anybody tell me ,if is it safe to make a full wipe in cwm with factory reset on new version of syiah,when if I have LQB 4,0,4 offic. rom?thx
[Galaxy S II Original Android Development] Tungstwenty:
Yes, it's safe.

Just make sure you have replaced the kernel you have with Siyah, and reboot again into recovery, before you do the wipe.

You have the stock kernel that came with the LQB rom?

- Flash the Siyah kernel with Odin

- Reboot the device

- Now you can go to recovery any time you want and do the wipes with no problems

Just don't do any wipes (including on the settings menu) until you have a safe kernel installed and have rebooted.
[Galaxy S II Original Android Development] majkicimo:
Thank you very much,wiping without hb

=tapatalk=
[Galaxy S II Original Android Development] darkcossack:
Pardon my noobness, but is the fixed kernel above rooted?

If it is not rooted, is there a safe way of installing cwm once the above kernel is installed?

My thanks in advance, and thanks for your work!
[Galaxy S II Original Android Development] whiskerp:
No, it is the stock kernel with one byte changed from 0x01 to 0x00 to disable the dangerous function which can damage the emmc chip.

You can easily root it using Method 1 in http://xdaforums.com/showthread.php?t=1746794.

I have myself tested cache wipe, Dalvik cache wipe and restore using this modified kernel and CWM touch recovery and have had no problems. My phone has the faulty eMMC firmware.

Peter

---------- Post added at 09:13 AM ---------- Previous post was at 09:07 AM ----------

I have tested Siyah 4.0.1 and it seems to have some issues with the "back" touch button being unresponsive. I've gone back to my patched 4.0.4 XWLPT stock to try to fix the battery issues - I think it may be down to some push features being enabled as well as some polling which were not on my XWLPI system. I did a factory reset for 4.0.4 and am still trying to get it back as it was. :)

I think that the battery is a lot better now and if it remains so, i will stay with patched XWLPT. I have rooted it using http://xdaforums.com/showthread.php?t=1746794 method 1 and even My Backup Pro works properly now (it used to only save/restore program data under a CF-Root, but now works with this version of rooting. I have Busybox updated using Stericson's 1.20.2).

Peter
[Galaxy S II Original Android Development] Entropy512:
You can't fix the stock kernel as it will trigger a signature verification failure - If it doesn't get detected as a properly signed binary you may as well build from source. Even this small modification causes the kernel to be considered "custom" - so if it's going to be "custom" then you should just build a kernel from source.

Also you can't be entirely sure that this fix actually fixed the problem - if the wrong code segment is detected and patched, you've introduced a bug somewhere else and still have a dangerous kernel.
[Galaxy S II Original Android Development] Tungstwenty:
True.

My main goal was indeed to detect kernel safety, but it turns out that pretty much all 4.0.4 kernels that come out are unsafe.

Patching them or changing in any way will of course make them not signed and trigger the yellow triangle.

So, as soon as the updated 4.0.4 i9100 kernel sources came out, patching is not the best way to proceed but rather compile the stock sources with that single change. Or use one of the custom kernels already available, being it a closer-to-stock one such as SpeedMod, a feature-packed like Siyah, or really any of them provided they're up-to-date for 4.0.4 and they're ERASE-free.

As for the N7000, I'm not sure whether updated kernel sources are available. If so, the same applies. If not, the offset presented can perhaps be a useful starting pointer, even if it's not followed blindly and one decompiles a bigger chuck of code around that area to make sure it's the part setting mmc->caps for the internal sdcard.

I hope that updated sources are available for the Note as well (and other variants also) and thread is now completely obsolete - that would be a good sign :)
[Galaxy S II Original Android Development] Entropy512:
N7000's 4.0.3 release had blobs and kernels (Update3) more similar to the I9100 4.0.4 release (update7 sources). As a result, unlike I9100, N7000 kernels based on the initial ICS source release didn't "break" when 4.0.4 showed up.

I777 has always been able to use I9100 sources with very minor hacks - for months we exclusively used I9100 firmware releases and source-built kernels with very small modifications. We've never been able to use I9100 binaries. The I777 UCLE5 release has a dangerous kernel, but UCLE5 just sucks all around so almost no one uses it.
[Galaxy S II Original Android Development] whiskerp:
I have unpacked the XWLPU kernel and made it "eMMC safe" by clearing the MMC_CAP_ERASE flag found using Tungstwenty's script and then repacked it. It is available here: http://dl.dropbox.com/u/46833344/Kernel_XWLPU_eMMC_safe.7z. I am running it myself and have done a CWM cache wipe with no problem.

Peter
[Galaxy S II Original Android Development] cdaarif:
Hay tnx gyz for make a safe kernel LPT/LPU.tar but im confuse that which is betterstable kernel/rom by benchmark result/battery life/users experience?

Sent from my GT-I9100
[Galaxy S II Original Android Development] whiskerp:
LPT/LPU are very similar and only built a few days apart but I definitely think LPU is better. I am using it with the XEULPA UK CSC and the amazingly good BVLP7 modem. Battery life is better on LPU I think.

Peter
[Galaxy S II Original Android Development] Chenglu:
thanks for share

https://github.com/xiaolu/galaxys2_kernel_repack
[Galaxy S II Original Android Development] igos2:
Can anyone post a patched (mmc_cap_erase disabled) XWLPX stock kernel?

Using Tapatalk2 on my GT-I9100
[Galaxy S II Original Android Development] whiskerp:
I have tried to make one using the script I used for LPT and LPU but it won't boot. Sorry.
[Galaxy S II Original Android Development] Phil3759:
Look here: http://xdaforums.com/showthread.php?t=1877270

Stock LPX with minimal edits to add CWM6 and patched MMC_CAP_ERASE
[Galaxy S II Original Android Development] whiskerp:
Thank you!
[Galaxy S II Original Android Development] shoey63:
Which tools did u use to edit and repack? (your help would be greatly appreciated)
[Galaxy S II Original Android Development] whiskerp:
See here http://xdaforums.com/showpost.php?p=29722657&postcount=50

But... although it works for LPT, LPU, it seems to cause a problem for LPX which won't boot.

I used Okteta to edit the "piggy" file. The location to edit is found by the checking tool in the first post in this thread.

Peter
[Galaxy S II Original Android Development] Tungstwenty:
@Phil3759,

Your kernel is compiled from source, rather than unpacked, patched code and initramfs and repacked. Right?

@wiskerp,

Since the script isn't working, for some reason, perhaps one of the other existing packaging methods might be needed. I believe they need a toolchain and will recompile only the wrapper code that packs all the parts together (I've sent you a PM the other day). I never tried it myself, though.
[Galaxy S II Original Android Development] Phil3759:
No, not recompiled from sources, rather unpacked and patched + edit of ramdisk

Big files are padded
[Galaxy S II Original Android Development] Phil3759:
I have amazing news

Good news: I elucidated the mystery of loosing the possibility to format internal sd from within Settings / Storage / Format USB with my JB stock patched kernels

Bad news: It is caused by patching the binary sequence to avoid brick bug :eek:

Now, we are stuck... until Samsung release the source for JB :p

Detailed Info:

After repacking new leaked JB kernels for i900/n7000, internal sd could no more be formatted from phone (Format USB storage)

After revising all my code, I noted that even a simple unpack / repack of stock kernel without any modification, still causes the issue. So, it was restricted to my unpack / repack process

I tried changing mkbootimg, recompiling it, using third party scripts, same result.

I finally decided not to patch the binary sequence for emmc_cap_erase to try it: Stock kernel, unpacked and repacked worked

I tried my kernel, unpack / repack with editing initramfs but no patching for emmc_cap_erase: Again, it WORKS

Conclusion: the binary sequence is no more linked absolutely to the emmc_cap_erase. As xda Elite developer Entropy512 said, Samsung added probably a workaround for the brick bug without patching emmc_cap_erase. However, without their source code for JB, no one can assert it at 100%

I am a bit hesitant: continue to binary patch (I know your answer Entropy512) knowing it probably add bugs (bad idea I think), or let users go stock unpatched and pray when using leaked firmware?

Any help from the OP?
[Galaxy S II Original Android Development] Tungstwenty:
I'll try to look a bit more into the details of this and what might have changed between ICS and JB. We don't have official kernel sources for JB but we do have the ones from S3 successfully running on our device with e.g. Siyah 5.0

My guess is that the official S2 sources will be identical for the most part.

Meanwhile you can read some new info on CAP_ERASE in my post here: http://xdaforums.com/showthread.php?p=34230857
[Galaxy S II Original Android Development] Phil3759:
Many thanks for taking the time to look at it when you can (well, couldn't sleep with this in mind, so woke up...)

I read your post you linked above.

I also assume they fixed it from your evidence. Also, Entropy512 tends to that idea.

I still have one thing that makes me wonder: what did they change in the way internal sd card is formatted so that when we patch the mmc_cap_erase, we can no more format internal sd from settings / storage / format USB?

I tried to patch a stock kernel without altering its ramdisk. The result is same for internal sd not being able to format from phone.

The interesting part is that from stock recovery 3e, on the patched kernel, I can still wipe data and factory reset. So, their recovery seems not to call the mmc_cap_erase I guess while they do to format internal sd?
[Galaxy S II Original Android Development] Tungstwenty:
Hi Phil, I finally looked at this stuff.

Please check my post on the other thread: http://xdaforums.com/showthread.php?p=34933643#post34933643

There's not a direct solution, but hopefully that info might help understand what's likely to be going on. Let me know if something is not clear.
[Galaxy S II Original Android Development] shoey63:
Hi Tungstwenty. I would like your opinion/knowledge. If "wipe via secure discard suppressed. .." is present in an update binary or recovery, does the format command default to "non-secure" erase, or "traditional" format?
[Galaxy S II Original Android Development] Tungstwenty:
I don't know what code is being executed by the update binary / recovery, as I haven't looked into that.

But judging from some posts + the printed message, I'd say that those binaries will invoke the regular discard function on the kernel (mmc_blk_issue_discard_rq) instead of the secure one (mmc_blk_issue_secdiscard_rq).

On the new JB stock kernels, the bad (?) chip types are detected and even if a secure discard is requested, the normal one will be used instead. Samsung is assuming that it's only the secure erase that cause the bricks, not the regular one.

When the kernel has been patched (or built from modified sources) to not have MMC_CAP_ERASE enabled, both the normal and the secure discard will not do anything and return an error "not supported".

This error can in turn be ignored or logged as a warning by the recovery / update binary, or handled as a fatal error and the user informed that the format failed (such as the situation Phil3759 mentioned).
[Galaxy S II Original Android Development] shoey63:
Thanks for your informative reply.:)
[Galaxy S II Original Android Development] cowbutt:
FYI, it looks as though the recent Orange UK and T-Mobile UK stock ROMs still have MMC_CAP_ERASE enabled:

$ ./check-kernel-MMC_CAP_ERASE.sh

###############################################
# #
# GT-I9100 Kernel MMC_CAP_ERASE bug detection #
# By Tungstwenty - xdaforums.com #
# Tungstwenty@gmail.com #
# #
###############################################

Detecting safety of kernel: zImage
Kernel: Linux version 3.0.31-889555 (dpi@DELL224) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri May 31 18:58:34 KST 2013

1 ocurrences of the bad code signature
0 ocurrences of the good code signature

***************
!!! WARNING !!!
***************

The kernel appears to have MMC_CAP_ERASE *enabled*, which is dangerous on many devices

Unpacked kernel code stored at: zImage_unpacked
The unsafe instruction can be found at offset 0x006cbe48

==================== Disassembly of the instruction ====================
If you want to check the disassembly make sure CROSS_COMPILE is correctly set and exported
========================================================================

*** Instructions for patching ***

- Choose one of the existing unpack/repack scripts
- Unpack the kernel code, initramfs, etc.
- Do a binary edit of the unpacked code
- At offset 0x006cbe48, replace "01 ?b 8? e3" with "00 ?b 8? e3" - change just the first byte to 00
- Repack the kernel, including the changed code and all original contents
- Re-run this script to confirm that the newly generated file no longer has MMC_CAP_ERASE enabled

This was from I9100XWLSY_I9100TMULS8_TMU.zip from sammobile.com which was released on 4 July 2013. Disappointing.
[Samsung Galaxy Player 4.0, 5.0] sukso96100:
White Beam Kernel for Galaxy Player 4.0 YP-GB1(KOR) and YP-G1(INTL)

Hello there, I'm glad to Release latest version of my kernel :)

it can be have less features then other kernel in this SGP 4.0 and 5.0 forum

if you have any problems while you using this kernel OR want to send me feedback,

send them via email, fascbook, google+, twitter, my blog and etc.

Latest Version of this Kernel : #23 (2012/08/01)

This kernel woks on Galaxy Player 4.0 YP-GB1(KOR) and YP-G1 (INTL), May not or never works on other version of Galaxy Player

If you are using other version of Galaxy Player DO NOT flash this kernel.(except when you are brave)

Features

Based on YP-GB1 2.6.35.7 Gingerbread kernel source

-LiveOC (You can set OverClock value in percent(%) → to set overclock value in percent, install NSTools from play store

-Voodoo Sound driver v10

-init.d support

-Scheduler : CFQ, Deadline, Noop, SIO(default), VR, BFQ(v1r1)

-Read ahead tweak

-Max touch point limit : 10points

-Custom bootlogo

-CWM Recovery (Added from SteveS' kernel source)

-Standard bootanimation support

-CPU Governors : conservative, userspace, powersave, ondemand, performance, SmartassV2(default), lulzactive

-Tiny RCU

-jhash3

-Kernel compression : LZMA

Changlogs

20120801(#23):

Updated jhash2 to jhash3

Enabled Tiny RCU

Using LZMA compression

20120731(#21):

Added lulzactive CPU governor, set smartassV2 as default

*My Kernel(WhiteBeam Kernel) was verified that works on YP G1(INTL)

thanks to S_m_O_k for test it on YP-G1 INTL

20120730(#20):

Added BFQ i/o scheduler (v1r1)

20120729(#19):

from this version, this kernel is compiled with KRKPG initramfs

20120727(#16):

Added SmartassV2 CPU Governor

20120726:

Added Standard bootanimation support

20120725:

Fixed T-DMB problem

20120724:

Added CWM recovery from SteveS' kernel source

20120723:

First release on here

How to install(with Odin3)

-Download Kernel from dowmload URL.

-turn off your device first, then get it in Download mode.

-Open Odin3

-Select the Kernel file in 'PDA' section

※DO NOT touch any option in Odin (Make sure Re-Partition, Flash lock, Phone EFS clear, and Phone bootloader aren't checked)

-Click 'Start' to flash kernel

How to uninstall(with Odin3)

-Download stock KRKPC kernel from here

(OR Download stock KRKPG kernel from here if your using KRKPG firmware)

-turn off your device first, then get it in Download mode.

-Open Odin3

-Select the Kernel file in 'PDA' section

※DO NOT touch any option in Odin (Make sure Re-Partition, Flash lock, Phone EFS clear, and Phone bootloader aren't checked)

-Click 'Start' to flash kernel

Download:

WBK_YP-GB1_YP-G1-INTL_GB_20120801(Latest Version)

WBK_YP-GB1_GB_20120731

WBK_YP-GB1_GB_20120730

WBK_YP-GB1_GB_20120729B

WBK_YP-GB1_GB_20120727

WBK_YP-GB1_GB_20120726

WBK_YP-GB1_GB_20120725

WBK_YP-GB1_GB_20120724

WBK_YP-GB1_GB_20120723

Source codes

Kernel | initramfs(KRKPC) | initramfs(KRKPG)

CREDITS

SteveS, Superqurio, Ezekeel, morfic

Do it at your own risk, i have no responsible if your device damaged after flash kernel
[Samsung Galaxy Player 4.0, 5.0] zaclimon:
It looks nice but don't make a thread on each new version.
[Samsung Galaxy Player 4.0, 5.0] klin1344:
^^ this.

Sent from my One S
[Samsung Galaxy Player 4.0, 5.0] sukso96100:
sorry, i will be careful next time when i submit new thread
[Samsung Galaxy Player 4.0, 5.0] Neodymium:
썩소님

쓰레드 매번 새로 올리시지 마시고 에딧/딜릿 눌러서 수정하시면 되겠슴당 고객님.ㅎㅎ

xda에 용감한 한국어 등장!
[Samsung Galaxy Player 4.0, 5.0] sukso96100:
이미 아까 #23 릴리즈부터 그렇게 하고 있지요 허허허허

그리고 이미 zaclimon 님께서 새 버전 올릴때 쓰레드 새로 만들지 말라고 예기 해주셨어요 허허허허

근대 갑자기 한글이라니 ㅋㅋㅋ
[HTC One X] Mr. Ruz:
Sorry, because this has probably been asked before. Do the ROMS on this forum work on the AT&T HOX or should I stay on that forum. Thanks
[HTC One X] BenPope:
No, the phones are completely different.
[HTC One X] Mr. Ruz:
Okay, I thought that they were but just double checking. Thanks!
[Member-Found Deals] NOFSBIGE:
Meritline has the Samsung Galaxy S3 Otterbox Defender case [meritline.com] for $29.99 with free shipping when using coupon code: MLC725HN

http://www.meritline.com/otterbox-samsung-galaxy-iii-defender-case---p-82645.aspx?source=s2010

Otterbox Samsung Galaxy S III Defender Case

Manufacturer Part # 77-21086

The Defender Series case for the Samsung Galaxy S III provides rock-solid protection so you don’t have to worry about accidents and oopsies. The Defender Series offers three layers of protection along with a holster. The polycarbonate inner layer snaps around the device and features a built-in screen protector that prevents scratches and smudges while retaining the sensitivity of the touchscreen. Memory foam pads cradle the device inside the case to provide additional shock absorption. The outer layer has a rugged silicone membrane that absorbs bumps and drops without compromising usability of the device. A holster with a rotating belt clip that doubles as a viewing stand is also included. The Samsung Galaxy S III Defender Series case is sure to give you rock-solid protection so you can stay active and on-the-go.

Features:

- Foam sound-isolating ring over microphone

- Sound is transmitted through case

- Added bump, drop, and shock protection

- Sleek, slim fit to Galaxy S III

- Full use of camera and touchscreen

- Silicone plugs provide access to all ports

- Includes holster style swivel belt clip

Package Contents:

- Otterbox Samsung Galaxy S III Defender Case - Black

- Holster

Return Policy

Satisfaction 30 days Return Policy:

Return for refund: 30 days from invoice day

Return for replacement: 30 days from invoice day
[Member-Found Deals] phzi:
Pure Fail.

System is unable to apply discounts to the following items in your shopping cart:

0004537-001	Otterbox Samsung Galaxy S III Defender Case

Possible reasons:

- The coupon code is invalid or has expired

- You have redeemed the coupon code in your previous order

- The coupon code has reached the maximum redemption limit
[Member-Found Deals] KRAZYADROIDMASTER:
That sucks!!!

I was going to buy one getting the phone soon.
[Member-Found Deals] Thoragh:
I did not buy one from there, but the price is still $34.99 instead of the regular $49.99 for that case. It appears that Ground shipping is free even without a coupon code at least when I entered in a Texas zip, like I said though I did not complete the checkout just noticed those few things while I was there. Did verify that the code appears to no longer be valid though.
[Member-Found Deals] NOFSBIGE:
Awww man well 34.99 is still a great deal!
[Member-Found Deals] KRAZYADROIDMASTER:
Yes it is.
[Member-Found Deals] ElKompaAndres:
33.18@ amazon

http://www.amazon.com/gp/aw/d/B0085...ef_=sr_1_1&sr=8-1&t=slickdeals&tag=slickdeals
[Member-Found Deals] Daf.:
Ye amazon are always good especially when it comes to otterbox cases, I got mine from them