yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] mssam:
That's a valid point. However, is this jb release the starting point for him to earn that trust? And who's trust is it that he has to earn? It sounds like he's just condemned in certain people's mind until they feel he's bowed down and asked for their forgiveness enough.

When it comes to rebuilding trust, that's a two way street. If other people from the past are unwilling to work with him to rebuild that trust, that's their right, but don't make it like it's all on him to make everything peachy for everybody.

Whether certain individuals from the past want to work with him or not from this point forward is irrelevant. His current user base wants to work with him and they want him to keep putting out some off the nicest roms available. The fact that he's put out one of the nicest roms available seems to be what the real problem is right now.
[Samsung Galaxy Nexus] eman3316@optonline.net:
I tried the Rom. He just took everything from other Roms and put it in there. Can someone please explain to me the hype and excitement over this?

My question is will he be adding his own tweaks and fixing things that have not yet been implemented in other Roms yet? That is what makes a Rom stand out. Not knocking the dude for what he has put together but just kind of confused about all the excitement. Everything in the Rom I have already seen.

Just scratching my head a little. Anyway, seems like he has a cult following in there. lol
[Samsung Galaxy Nexus] blaine07:
And he can can go back where he came from?
[Samsung Galaxy Nexus] mbh87:
That's all he does. Liquid is the same way. Anything original in Liquid comes from jbird 99% of the time. At least codename doesnt take out vital parts to make you feel like you are downloading a tiny ROM.

People that just kang and dont contribute back will always get **** in the community especially when those guys usually do stupid **** to try and get money out of people.
[Samsung Galaxy Nexus] mssam:
"... It is not as if the original coder asked permission from Google, Samsung, or whoever else to use their code. They made it freely available so anyone can freely modify and release it for free, as well. I think people here need to accept that fact. This is what is so great about open source software. However, if someone is releasing your modified work as their own without giving credit, that is a problem."

Comments anyone?
[Samsung Galaxy Nexus] AmericanCon:
That's exactly what the excitement is all about. No other rom has all these features into one rom. You haven't seen them on Jellybean in all one rom.
[Samsung Galaxy Nexus] Paleryder:
that's exactly right how many times do you say I like CM10 but I also like certain features of AOKP! This gift takes all of our favorites and merges them together very successfully. It is really running very well.
[Samsung Galaxy Nexus] drzplaya1121:
I'm still going to keep asking about battery life. Stock gets me maybe 10 hours with average to heavy use lol
[Samsung Galaxy Nexus] 95Z28:
Well stop. Try it yourself. Your version and my version of "average to heavy use" could be completely different and you'll be left wondering why we get such different results.
[Samsung Galaxy Nexus] airtime82:
not only that but bashing you at the same time....how would you react?
[Samsung Galaxy Nexus] Whogivsachit:
Can a mod lock this thread? It's a constant circlejerk. I understand everyone's concern. But there is nothing that hasn't already been said about his past. Please leave the accusations out until there is proof that he had done wrong with THIS Rom. You can believe that he's a piece of **** or whatever else but don't let it get to the point where you hinder the discussion at hand. It's not fair to everyone who actually want to talk about the Rom. Please make another thread of you want to bash the dev, this is not the place. [End Rant]
[Samsung Galaxy Nexus] xHausx:
Since the ROM is on a different site and we've already had a few issues here I'm going to go ahead and close this. Thank you for letting us know about it, but we already have all the drama we can handle here as is. :)

Thread Closed.
[Galaxy Y GT-S5360 Themes and Apps] mrdoods:
I want to share my music player..

SENSOR MUSIC PLAYER

-changing music without touching your screen

-a built in equalizer (best combination with dsp= superb just try it)

-pause/play by staying your palm front of your screen in 1sec.

And lot more.. just discover it..

Note don't over wipe and wipe.. just wipe and load the music before you wipe again because it makes you trouble..

http://www.mediafire.com/?rb7wwigu6xkdins
[Galaxy Y GT-S5360 Themes and Apps] yabyuh22:
flash via CWM? or just install the APK?
[Galaxy Y GT-S5360 Themes and Apps] nirupom:
Its apk... Install it
[Galaxy Y GT-S5360 Themes and Apps] julieanndondie:
Oh ok

Is this the same as this?

https://play.google.com/store/apps/...51bGwsMSwxLDEsImNvbS56Z3VpLm11c2ljc2hha2VyIl0.

Did you make these?

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

iplaygalaxyy for android
[Galaxy Y GT-S5360 Themes and Apps] Heartlessangel2001:
Awsome... Any senor video player

sent from galaxy Y did i buy this crappy phone
[Galaxy Y GT-S5360 Themes and Apps] rockerblood:
screenshots?
[Galaxy Y GT-S5360 Themes and Apps] evanlocked:
Here ss

sent from ussr v5prototype
[Galaxy Y GT-S5360 Themes and Apps] Aaron061992:
Great!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

A year ago, when i installed its beta build or something like that, it was so basic... must check if more advanced options are added... thanks bro for reminding...:good:
[Galaxy S II Original Android Development] Tungstwenty:
(Reserved)
[Galaxy S II Original Android Development] DaReDeViL:
WOW, << That's one small step for man, one giant leap for "s2 community" >> !!!!! ;)
[Galaxy S II Original Android Development] jlevy73:
Now this is what XDA is all about. Good stuff man, much appreciated!
[Galaxy S II Original Android Development] xky1980:
sorry for my "stupid" question;:confused:

I've a linux notebook, I've connected my device with the usb cable. Now how can I send command to the device? with adb and android sdk?

Tkanks
[Galaxy S II Original Android Development] martintspedersen:
hahaha yes man nice one... i hope that give us some nice ''stock'' roms

ps i was number 500 that hit your thanks button LOL
[Galaxy S II Original Android Development] Tungstwenty:
If you read the requirements section, you'll see it's not likely that it runs successfully on the device itself, due to BusyBox limitations.

Just place the zImage file somewhere on your notebook, along with the script, and run it from a terminal.
[Galaxy S II Original Android Development] xky1980:
Oooohh! So the kernel must be read from the same path of the script, not from the device! OK thanks

Inviato dal mio GT-I9100 con Tapatalk 2

---------- Post added at 09:18 AM ---------- Previous post was at 09:02 AM ----------

I've executed the script with siyah 3.5.2

the result is: The kernel appears to be good (MMC_CAP_ERASE disabled)

So it means that is possible to safely make wipes and nandroid restores from recovery on my XWLPT?

Thanks
[Galaxy S II Original Android Development] jgcaap:
Genius!
[Galaxy S II Original Android Development] gokhanmoral:
great work
[Galaxy S II Original Android Development] rush25:
Amazing work :)
[Galaxy S II Original Android Development] 00raq00:
Did someone test it on S2 with CWM ?
[Galaxy S II Original Android Development] simone201:
Great work dude!! :D

Keep it up ;)
[Galaxy S II Original Android Development] Tungstwenty:
What do you mean?

If you're talking about the detection, there's no such kernel as "CWM" :)

What exists is:

1. stock kernels, with stock recovery (faulty for all 4.0.4 builds so far)

2. CF-Root, which is just the stock kernel code but with stock recovery replaced by CWM, root included, etc. (but it's still the original kernel code and it still has he bug)

3. custom kernels built by kernel developers from source, which unless they forgot to do so, has the source code changed to be safe

If you're asking about item no 2, I *think* Chainfire changed the code of the CWM version he included in the package to make it safer, but the kernel is still vulnerable and flashing a .zip file in recovery (which could run some code it might include) is still potentially unsafe.
[Galaxy S II Original Android Development] whiskerp:
This is a great piece of work. I have attempted to build a patched kernel for XWLPT but I'm a bit of a noob at hacking zImage.

I set up the repack-zImage.v6 scripts and unpacked the kernel. I am a bit concerned about the error however:

repack-zImage.sh -u
Separating gzipped part from trailer in 'piggy.gz+piggy_trailer'
Trying size: 4184870 6277305 5231087 4707978 4969533 5100311 5165700 5133005
5116657 5108483 5112570 5114614 5113592 5114103 5113847 5113975 5114039 5114071
5114055 5114047[COLOR="Red"]/usr/local/bin/repack-zImage.sh: line 284: [: : integer expression expected[/COLOR]

padding check (may take some time): 1

Found uncompressed ramdisk.
Detecting padding (may take some time): 1
Unpacking initramfs
4300 blocks
4300 blocks

Success.
The unpacked files and the initramfs directory are in './zImage_unpacked'.

However I persevered and found and patched the byte in "piggy" using okteta and then repacked the kernel by doing:

repack-zImage.sh -3 -p
Creating piggy.gz
Padding './zImage_packing/piggy.gz' to 5114048 bytes (+1)
Assembling zImage
Successfully created './zImage_packing/zImage'
Generated file: './zImage_packing/zImage.tar'

This checks out OK as having been patched OK.

./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
gzip (pos = 18101)
Kernel: Linux version 3.0.15-I9100XWLPT-CL941023 (dpi@DELL169) (gcc version 4.4.3 (GCC) ) #3 SMP PREEMPT Fri Jul 27 18:08:15 KST 2012

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

The kernel has been patched by this method to disable MMC_CAP_ERASE and should now be entirely safe

but sadly gets stuck at the boot screen :(

Does anyone know what I have done wrong and might be able to help? I'll share the kernel if I can get it built.

Peter
[Galaxy S II Original Android Development] 00raq00:
If we can detect brick bug in kernel and know what must be changed so why we can't fix stock kernel? If we can fix stock kernel my question is did someone do that and test it with fake cwm and wipe?
[Galaxy S II Original Android Development] darth_mickrig:
Did you use this script here http://xdaforums.com/showthread.php?t=901152 ? I used that one and asked tungstwenty for help. He discovered, that that one was faulty. I have my own kernel build now but still couldn't test it.
[Galaxy S II Original Android Development] whiskerp:
Safe version of XWLPT stock.

I have now rebuilt this and it works! :) and it is available at the Dropbox link below.

http://dl.dropbox.com/u/46833344/Kernel_XWLPT_eMMC_safe.tar

Does someone else want to check this out? I re-did the build above after fixing two unassigned variables in repack-zImage (fixed build files below)

http://dl.dropbox.com/u/46833344/repack-zImage.v6-fixed-scripts.tar.gz
[Galaxy S II Original Android Development] darth_mickrig:
Did you already test CWM Wipe?
[Galaxy S II Original Android Development] Tungstwenty:
After having the detection, I was also trying to get it to work using exactly that same repacker script, which darth_mickrig tipped me about.

I also found it has some errors, not only in the line you mentioned but also in the packing when using "-3" so that piggy can be edited directly rather that its inner blocks in separate files (which would require subtracting something from the offset displayed by my script).

wiskerp, I'm glad you had it sorted out already. I didn't have a chance to properly testing my patched+repacked zImage from one of the 4.0.4 versions (was planning on testing it despite the fact that I'm running a 4.0.3 ROM) so your feedback is great.

The repack-zImage.v6 script appears to no longer be maintained and its author doesn't post on XDA for a while now, but I'll try to see if I can reach him to know whether he's ok with updating that script for newer kernels in addition to fixing the existing bugs. It might work properly in other shells / bash versions, who knows...

In the meantime, I was also asked by a couple of N7000 guys to make the detection work for their kernels, which apart from the "really stock" ones have a different compression - lzma/xz instead of gzip on the outer layer. On the inner parts (initramfs) it's also not working correctly, so I'll need to check it out. CF-Root, for instance, uses a different compression than the base stock, probably so that the additional payload fits the partition size.

Oh, one note:

Keep in mind that despite being a patch on the stock kernel, the yellow triangle will appear and the counter will be incremented if you flash the patched version through Odin. It's no longer properly signed by Samsung.

Kudos to wiskerp for beating me to share a patched version :highfive:. I had already done the repackaging and was waiting to get home to flash and try it out to see if it would boot before posting it :)
[Galaxy S II Original Android Development] crazy_4_and1:
Has Entropy512 seen this , it might be important to him as he is/was supposed to talk to Samsungs engineers about diagnosis and solving the problem ( I know this is not solving already bricked devices , but is incredibly valuable to all of us who have not bricked , but are in danger of doing so ) ?
[Galaxy S II Original Android Development] whiskerp:
Did a CWM Dalvik cache wipe! No problems :)
[Galaxy S II Original Android Development] pellen:
So it's just to flash the LPT ROM and then directly after flash your fixed LPT kernel and your safe? I've always used CF-root when rooting previously, is there any smooth method for rooting by not flashing a kernel that hasn't been fixed?
[Galaxy S II Original Android Development] Stileth:
See guide in my signature. Method 1.

Odoslané z GT-I9100 cez Tapatalk 2
[Galaxy S II Original Android Development] Dharam_Maniar:
Hey Tungstwenty,

Just some time back, I was trying out my new kernel...

Built from update7 source, and I did a wipe in CWM...

MMC_CAP_ERASE bug is present in update7 sources...I hadn't even flashed the leaked 4.0.4 ROM or anything...was on 4.0.3 ROM, and update7+CWM wipe screwed my /data partition..

had to repartition it manually using parted...
[Galaxy S II Original Android Development] Tungstwenty:
I have posted on the thread "Samsung working on Emmc brick fix", which he seems to follow.

I didn't get any feedback yet, but I think first I'll improve the script so it also works on the N7000 stock-ish kernels (CF-Root also) and perhaps after that I'll PM him. By then we should already have out collection of patched 4.0.4 kernels for I9100 I guess.
[Galaxy S II Original Android Development] Tungstwenty:
The CF-Root zImage can also be patched in the same way as wiskerp did, it's just a matter of checking if the repacker script works also with the contents Chainfire added to the original kernel "package" (it's sort of a zip file with smaller parts within). I think it still needs some corrections and improvements to deal with newer kernels, xz compression, etc. (the repacker script is originally from almost 1 year ago)

Anyway, if all you want is root, you can flash pretty much any custom kernel out there, let it boot once so it installs the SU binary and the associated management app, and after that you can flash even the stock kernel and you won't lose the su - which is in /system and therefore not affected by the active kernels, although the custom kernels as a bonus will bother changing /system to give you SU if you don't have it already (auto-root).

Now, if after getting root you chose:

- A truly stock kernel: you'll have a vulnerable kernel and stock recovery only (so "smaller risk" of brick)

- CF-Root kernel: still a vulnerable kernel but with CWM recovery apparently changed to be no riskier than the stock recovery (still "small risk")

- A patched stock kernel: stock recovery only, but no risk of brick since the faulty command is blocked by the kernel and never sent to the emmc chip

- A patched CF-Root kernel: also no risk, but has CWM recovery

- A custom kernel: lots of other features, which change from one to the other, and most of them should be safe (can be checked with the developers, since they build it from source)

EDIT:

Oh, if you mean flash in 1 go with already the final kernel you want (a patched stock, a patched CF-Root, a custom kernel) you can use MobileOdin for that. Just select the original ROM file, and before flashing go to the kernel entry and select an alternate source for it. It will all be flashed in one go and when it boots it will already be with the final kernel you want.
[Galaxy S II Original Android Development] Tungstwenty:
Right. The fact that it's built from sources instead of using the binary shipped by Samsung, doesn't make it safe :)

Devs still need to make sure they edit the problematic source code line so it's build without MMC_CAP_ERASE enabled, else it's the same problem as the ones shipped by Samsung. Custom kernels therefore *should* be safe, but ultimately always check the appropriate dev thread to see if that's indeed the case. Most of them are, likely all of them.

If you didn't have a permanent brick and still managed to edit the partitions in order to go around the area that was damaged, you were lucky - it could have been much worse :D
[Galaxy S II Original Android Development] Dharam_Maniar:
So you mean, to solve the problem we need to change

mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;

to

mmc->caps |= MMC_CAP_SDIO_IRQ;

??

And yeah, I was super lucky, I managed to survive with just a little smaller internal sd-card...phew...
[Galaxy S II Original Android Development] Tungstwenty:
Exactly, that's the change you need to do.

There are actually 2 occurrences of that - one for the internal sdcard (

mshci.c

) and another for the external sdcard (sdhci.c)

The one that MUST be patched is mshci.c. The other can be left active since the external sdcards don't have faulty controllers (unless Samsung also sells sdcards, that is :laugh:). And even if they did, the worst case scenario would be a damaged plastic nail, not an entire device.
[Galaxy S II Original Android Development] Siberian Tiger:
Hi guys i don't want to advertise the kernel just to share my experience.

I'm running XWLPT 4.0.4 firmware

and i flashed Galaxian kernel .

I made a factory reset,qipe cache and dalvik and i had no problems ;)

Thanks to tungstwenty for spotting the problem and to luqqic for the kernel :)

Sent from my GT-I9100
[Galaxy S II Original Android Development] Dharam_Maniar:
Ok, thanks a lot mate... :)

You are seriously doing a great job :)
[Galaxy S II Original Android Development] yadabwoy:
+1 genius , thanks im sure this will save many lives lol
[Galaxy S II Original Android Development] umberto1978:
Mmhhhhh... The fact is: i compiled my own kernel and modified those two lines of code by the way showed above but if i run script to check if kernel is safe i receive an error

The script can't recognize bad lines of code nor good lines.

Tungstwenty, what do you think about this?

And thanks for your hard work :)

Inviato dal mio GT-I9100 con Tapatalk 2
[Galaxy S II Original Android Development] Tungstwenty:
I think it's normal, I mention that in the OP.

I included in the script the detection of 2 ARM code sequences that are found in Samsung's stock kernels - one for the block with the bad logic (from 4.0.4 kernels) and the other for 4.0.3 ones where the ORR r?, r?, 0x400 instruction is missing (correctly).

The script will count how many occurrences exist of each of the 2 patterns. It will only output a conclusion if it finds a single occurrence of one of the patterns, and none of the other.

It it detects 0 occurrences of both, more than one, or one for each, etc. it will display "... unkown ...".

The reason for this is that depending on the compilation environment (toolchain, optimizations, etc.) the resulting ARM code even from the same source code can be different, and it will not fit the patterns I found in Samsung, which are pretty constant.

It doesn't mean the kernel is not safe - you have the sources and can check for yourself.

Since it's a non-issue knowing if custom kernels are safe (it's just a matter of validating the source or asking the dev), there's no point in trying to include an always-growing number of ARM bytecode patterns. If the stock kernels start failing the detection, then I can include additional ones to cover everything from stock, which is where a detection is in fact needed.
[Galaxy S II Original Android Development] umberto1978:
you are right (consider that i never doubt about of this :D )

In fact i have tried to test zImage from siyah 3.4.1 and from SpeedMod K3-30

the virdict is the same error as my own kernel (0 occourrence from both sides, bad and good) and "safety" for siyah zImage.

I taked a look at SpeedMod patch and ive noticed he added " ;// " to the bricking lines on mshci.c and sdhci.c files

something li the following

mmc->caps |= MMC_CAP_SDIO_IRQ;// | MMC_CAP_ERASE;

While i have used another method, removing at all the command, obtaining the following

mmc->caps |= MMC_CAP_SDIO_IRQ;

By your knowledge am i wrong removing the part of the line code in the manner above?
[Galaxy S II Original Android Development] Tungstwenty:
That's a really 101 question, it's basic C coding :). The result is exactly the same, as the // ... part is a comment just so people reading the code can know what was there, or an explanation, etc.

Don't feel intimidated by my comment, on the contrary. Starting from no knowledge at all on C coding and still compiling on your own (which I assume from you mentioning "I used another method") is really the only way to start learning the ropes ;). Well done!
[Galaxy S II Original Android Development] umberto1978:
Thanks for encourage me and for the answer: i let you know that i don't feel intimidated at all by your comment, it meaning that i have a lot to learn about all environment.

I like XDA :D

1: studying

2: understanding what reading

3: share experience

4: deal ideas with someone more experienced

5: reaching a goal

BTW a very long interesting road :good: and thanks again
[Galaxy S II Original Android Development] cdaarif:
Sorry english isn't my 1st language & im a noobz too. So i can't play with a emmc buggy kernel or its script for unpack/repack & flash it. Coz its so dangerous for me. Can u plz make a XWLPT.tar/cwm kernel without emmc bug for noobz like me/us ?

Sorry for my bad English

Sent from my GT-I9100