[Discontinued]- Stock GT-P6800 *Rooted, Deodexed and Zipligned*

Status
Not open for further replies.
Search This thread

sk806

Senior Member
Jan 30, 2005
1,973
1,441
Rye, New York
Hey Everyone. I just wanted to let all of you know that I am very sorry about the screw-up on my part that led to damage of a few users devices. The error was all mine and it is inexcusable. Please know that I take this very seriously, to the point of losing sleep over it. As I have stated many times, I would like to pay for the cost of the bricked users JTAG repairs. Please just PM me.

I also want to apologize for my defensive attitude over the course of the past couple of days. I have never screwed up like this on these forums and I wasn't sure how to handle it.

There is some good news that has come out of this, however. I have been working with Task650 of GT 10.1 fame, an amazing dev and person, I might add, and we have come up with a beta ROM that I am running now that will be safe to flash and better than the original ROM I posted in terms of speed, stability and overall performance. I plan to have a private beta, and will ask for testers in a separate thread after Task650 and I have made sure that everything is OK and it is ultra-safe...

I have been humbled a great deal through this experience, and I believe it will make me a better developer. I have already learned a lot from Task and all of your posts, and I hope that I will be able to earn your trust with smooth, stable and innovative ROMs to come.

Steve
 
Last edited:

jamaljmys

Senior Member
Dec 16, 2007
911
48
everything gone well
installation completed
but when restart device nothing happened

device cannt switch on :eek:

what happend?
 

ftgg99

Account currently disabled
Mar 20, 2010
8,778
2,019
Well this is certainly mate... i seem to have a brick as well.
 

sk806

Senior Member
Jan 30, 2005
1,973
1,441
Rye, New York
Whoah....

People are getting bricked? WTF? Works fine on mine. I will remove right away. Is it working for others? To the solution, let me get this clear, you flash and the device wont even turn on at all? Also, please let me know what build you are coming from.

Thanks, and i am so sorry for any problems. Lets get this fixed.

Steve
 

sk806

Senior Member
Jan 30, 2005
1,973
1,441
Rye, New York
OK

So, flashed again, still fine. THe issue must be with the couple/few people's devices that bricked, or the installation process was messed up in some way. BTW, am NOT saying its anyone's fault, just saying that there must be something unique to your tab, or how you installed that caused the problem. So, if anyone has been "bricked", please let me know the following:

1. You did a full wipe, right?

2. You flashed on galaxy tab 7.7 wifi and 3g, not the wifi-only version, correct?

3. Where are you located and what was your build before flashing?

I am not asking these questions to be rude or defensive, I just want to know what's going on. I have had thousands (over 10k) of people download and flash my ROMS (search "Magnolia" in XDA), and have NEVER had anyone brick their device on my ROMs. I am known and respected by most or all U.S. developers for Verizon, so I am not some hack.

Thanks.

Steve
 

sk806

Senior Member
Jan 30, 2005
1,973
1,441
Rye, New York
One last question...

Can you power on while holding down the Volume up key simultaneously? I am guessing, no, but thought I'd check. I just dont see how a device can be bricked when there is no firmware/radio, etc. being flashed. Not saying it can't, but it's weird...

EDIT - Try removing the SIM, too.
 
Last edited:

knights.JayTana

Senior Member
Jun 27, 2011
1,200
616
Davao City
Dont get me wrong dude... i already downloaded your ROM, but reading through the thread makes me think twice of flashing... Sorry if my post offended you... ill be traveling this afternoon so i cant risk flashing now because i need my tab... Anyway Thanks for the effort of this ROM...
 

sk806

Senior Member
Jan 30, 2005
1,973
1,441
Rye, New York
Dont get me wrong dude... i already downloaded your ROM, but reading through the thread makes me think twice of flashing... Sorry if my post offended you... ill be traveling this afternoon so i cant risk flashing now because i need my tab... Anyway Thanks for the effort of this ROM...

Definitely not offended, sorry if I came off that way. I just wanted to clear up that it is apparently a VERY small minority (2 users, that I know of, and one other who bricked cooking his own ROM and then came here to state that he was bricked for some reason) that seem to have this issue, and, in fact, samsung tabs seem to have the "wont turn on issue" anyway, so I am not sure if it's the ROM, the devices, or what. I just don't like the dissemination of potentially misleading statements, intentional or otherwise.

Thanks again for your post.

Steve
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 9
    Hey Everyone. I just wanted to let all of you know that I am very sorry about the screw-up on my part that led to damage of a few users devices. The error was all mine and it is inexcusable. Please know that I take this very seriously, to the point of losing sleep over it. As I have stated many times, I would like to pay for the cost of the bricked users JTAG repairs. Please just PM me.

    I also want to apologize for my defensive attitude over the course of the past couple of days. I have never screwed up like this on these forums and I wasn't sure how to handle it.

    There is some good news that has come out of this, however. I have been working with Task650 of GT 10.1 fame, an amazing dev and person, I might add, and we have come up with a beta ROM that I am running now that will be safe to flash and better than the original ROM I posted in terms of speed, stability and overall performance. I plan to have a private beta, and will ask for testers in a separate thread after Task650 and I have made sure that everything is OK and it is ultra-safe...

    I have been humbled a great deal through this experience, and I believe it will make me a better developer. I have already learned a lot from Task and all of your posts, and I hope that I will be able to earn your trust with smooth, stable and innovative ROMs to come.

    Steve
    5
    Sk806: I'm planning to buy a GT7.7 and if i do then i will try to get ICS working on it. But i don't want to repeat the problem you encountered, so can you please explain in more detail what you did wrong and where exactly should the boot.img be flashed on GT7.7? Thanks in advance.

    EDIT: Ok i found your explanation there > http://xdaforums.com/showpost.php?p=22612808&postcount=67
    Just to confirm, you flashed the boot.img to mmcblk0p2, correct?
    And the correct place is mmcblk0p5, correct?

    Hey guys,
    I'm building a deodexed stock ROM for my 6810 (wifi) and it looks like its going fine... i studied Task650's Galaxy Task 14 ROM (with his permission...thanks bro) and i've been flashing the boot.img (stock; ripped from my Nandroid backup) to "/dev/block/mmcblk0p3". I've been holding off on releasing the ROM cuz like poisike said... i don't want the same thing happening too even tho things are running good after a flash...

    EDIT: I changed my updater-script to use mmcblk0p5 and all is well... i hope

    steve

    what exactly happened in technical way? iam fully confused and cannot understand. i mean how can that happen?

    OK, here's what happened. Just as a preface, this is not intended as an excuse. I have assumed all repsonsibility for my screw up, and I am simply stating the facts so that people can understand and learn from my mistake:

    I put the ODIN tar.md5 into disxda's kitchen, with a modified edify page for the 7.7, built a working folder, and then moved the appropriate csc files, etc. into their places. I then deodexed the ROM, rooted it, put an init.d dummy folder in place(empty at that time), so that I could hopefuly get it working with a ramdisk I was messing about with. NOTE: The ramdisk in the ROM I released, and the ROM I am going to start beta testing today DID/WILL NOT have this very experimental ramdisk, but the standard, disxda "dummy" one that the kitchen generates. If I get comfortable with the ramdisk, and someone like pershoot is willing to help, I may do so.

    But, to get back to what happened, I then did a generic covert update-scriipt to updater-script (edify) within the kitchen and made some minor adjustments like "ui print" commands, and grouping permissions in a way I like to work. I then tried to flash in recovery, and was given a Status 7 error when the kernel tried to flash. Ok, so now I know that there is something format/partition related with my script, so I am guessing tha the generic script from the kitche does not work. I look and it has a generic "MTD" command for system, and I figure that's not gonna cut it. Fine, when you have rebooted your device into recovery, a file caled "last_log" is created in /cache/recovery/. this gives you a list of the partitions on the device and what they are called. In the 7.7's case, it looks like this:

    0 /tmp ramdisk (null) (null)
    1 /efs ext4 /dev/block/mmcblk0p1 (null)
    2 /boot emmc /dev/block/mmcblk0p5 (null)
    3 /recovery emmc /dev/block/mmcblk0p6 (null)
    4 /cache ext4 /dev/block/mmcblk0p7 (null)
    5 /system ext4 /dev/block/mmcblk0p9 (null)
    6 /data ext4 /dev/block/mmcblk0p10 length=-16384
    7 /preload ext4 /dev/block/mmcblk0p11 (null)
    8 /emmc vfat /dev/block/mmcblk1p1 (null)

    So, I need to know the system partition and the boot partition (and later the data one, but not necessarily on a stock ROM). I get the system one in "mccblk0p9" and put that in the mount command in the beginning of the script. Then I flash this one, it goes all the way to kernel flash, and I get another ststus 7 error, saying the command I used for flashing the kernel, based on my HTC experience doesn't work:

    "package_extract_file("boot.img", "/tmp/boot.img");
    write_raw_image("/tmp/boot.img", "boot");

    As you can see, all this is doing is flashing the kernel to the boot partition, which also houses the bootloader. Apparently, Samsung devices require you to be more specific than "boot", so, I looked at my last_log file, saw that the second partition is the boot partition, and then I had a brain fart and wrote the script to flash the kernel to "mmcblk0p2", even though it CLEARLY said "mmcblk0p5" for the boot partition. Now, this was just a pure stupid error, partition 2, mmcblk0p2, it makes no sense, I know, there's no correlation between what a partition is called and what "number" it is, but it just was one of those things where your brain does something it thinks is right and doesn't catch itself. However, things got worse, when I checked this partition, mmcblk0p2, with dd, and it informed me that it was called, boot. What I DID NOT DO, was dd the rest of the partitions, which I SHOULD HAVE DONE!!! It was just cockiness, "Oh, I've done this hundreds of times...", that is the explanation for this lack of diligence. When I did check all the partitions with dd after the debacle, it told me that mmcblk0p5 is called kernel, as well as boot, so I obviously should have been using this one, rather than mmcblk0p2, which is the bootloader only on samsung devices, I see.

    The worst part however, is the fact that I flashed this ROM with the kernel flashing to mmcblk0p2, and it worked just fine on my tab. I flashed it a couple more times with some script mods, used it for a while, and it was always OK. I wish to god I bricked my device then and spatred others the pain, but, unfortunately, it didn't happen that way...

    As you can see above, a bricked user has reported that Samsung received his device and is saying that the motherboard is fried. Now, this seems much more extreme that what I was expecting (screwed up bootloader, just a jammed up boot process since boot.img is in the wrong place), but I will assume that the Samsung guy knows his stuff and give you my GUESS as to how this could happen. In my experience, a burned board is a result of an overclocked CPU or a power surge of some sort through a mains charger. I am going to exclude the second possibility, and guess that, for these users' devices, when the device tried to boot up, the kernel, which regulated CPU frequency, was not read properly, which let the CPU fly off the handle and fry the board...

    I have nothing to prove that this happened, and I am perfectly willing to listen to others' explanations, but this is what occurred to me. The moral of the story is the same, however, ALWAYS BE DAMN SURE ABOUT YOUR PARTITION NAMES IN TYOUR UPDATER-SCRIPT!!!

    Anyway, I am releasing the ROM Task650 and I put together last week for beta testing in another thread today. If you are interested, please PM me, and I will send you a link. And, yes, it flashes the kernel to mmcblk0p5 and, yes, I have flashed it about 20 times with no issues whatsoever, been over all of the logcats through boots and all seems fine. It also has init.d working, via a slick little script written by Task650, even without a decent kernel, plus other tweaks that Task has shown me for these tablets.

    I have been playing with it all through the weekend, and it is awesome, and will only get better, once I figure out how to hide that damned screenshot button in the statusbar (I love smali coding, so am looking forward to it), and do some theming and start to add more init.d scripts (only a couple are in there now).

    Anyway, hope this helps.

    Steve
    1
    Whoah

    Ok, well i was going to suggest you increase your heap size, but i guess not... ;). I havent seen these errors, i was getting invalid opcode and classpath errors. Looks like you addressed classpath, too. Switching up the api worked for me. Ill dig into these logs and see what i can do. Also feel free to snag mine from the ROM should you wish.

    Probably be tomorrow, as I'm wiped out and am having a crappy day as a dev.

    Steve

    Thanks sk806, but I still encounter a lot of issues. Using baksmali 1.3.0 and 1.3.3, also smali 1.3.0 and smali 1.3.3, but both ended up with the same result:

    Code:
    java -Xmx512m -jar baksmali.jar -a 13 -d ../framework -x Ebook.odex
    Error while disassembling method Landroid/security/MessageDigest;->getInstance(Ljava/lang/String;)Landroid/security/MessageDigest;. Continuing.
    org.jf.dexlib.Code.Analysis.ValidationException: class Landroid/security/Sha1MessageDigest; cannot be resolved.
            at org.jf.dexlib.Code.Analysis.ClassPath$UnresolvedClassDef.unresolvedValidationException(ClassPath.java:535)
            at org.jf.dexlib.Code.Analysis.ClassPath$UnresolvedClassDef.getClassDepth(ClassPath.java:543)
            at org.jf.dexlib.Code.Analysis.ClassPath.getCommonSuperclass(ClassPath.java:383)
            at org.jf.dexlib.Code.Analysis.RegisterType.merge(RegisterType.java:275)
            at org.jf.dexlib.Code.Analysis.AnalyzedInstruction.mergeRegister(AnalyzedInstruction.java:185)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.propagateRegisterToSuccessors(MethodAnalyzer.java:451)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.setPostRegisterTypeAndPropagateChanges(MethodAnalyzer.java:431)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.analyzeInvokeDirectCommon(MethodAnalyzer.java:3067)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.analyzeInvokeDirect(MethodAnalyzer.java:3016)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.analyzeInstruction(MethodAnalyzer.java:861)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.analyze(MethodAnalyzer.java:213)
            at org.jf.baksmali.Adaptors.MethodDefinition.addAnalyzedInstructionMethodItems(MethodDefinition.java:378)
            at org.jf.baksmali.Adaptors.MethodDefinition.getMethodItems(MethodDefinition.java:300)
            at org.jf.baksmali.Adaptors.MethodDefinition.writeTo(MethodDefinition.java:132)
            at org.jf.baksmali.Adaptors.ClassDefinition.writeMethods(ClassDefinition.java:338)
            at org.jf.baksmali.Adaptors.ClassDefinition.writeDirectMethods(ClassDefinition.java:307)
            at org.jf.baksmali.Adaptors.ClassDefinition.writeTo(ClassDefinition.java:151)
            at org.jf.baksmali.baksmali.disassembleDexFile(baksmali.java:205)
            at org.jf.baksmali.main.main(main.java:293)
    opcode: invoke-direct
    CodeAddress: 28
    Method: Landroid/security/MessageDigest;->getInstance(Ljava/lang/String;)Landroid/security/MessageDigest;

    Also trying:

    Code:
    java -Xmx512m -jar baksmali.jar -a 13 -d ../framework -c :am.jar:android.policy.jar:android.test.runner.jar:apache-xml.jar:bmgr.jar:bouncycastle.jar:com.android.loc                                                                                                              ation.provider.jar:com.google.android.maps.jar:com.samsung.device.jar:com.yamaha.android.media.jar:core-junit.jar:core.jar:ext.jar:framework.jar:ime.jar:input.jar:j                                                                                                              ava.awt.jar:javax.obex.jar:libvtmanagerjar.jar:minimode.jar:monkey.jar:pm.jar:seccamera.jar:sechardware.jar:secmediarecorder.jar:sec_feature.jar:services.jar:sqlite                                                                                                              -jdbc.jar:svc.jar:twframework.jar -x Ebook.odex
    Error while disassembling method Landroid/security/MessageDigest;->getInstance(Ljava/lang/String;)Landroid/security/MessageDigest;. Continuing.
    org.jf.dexlib.Code.Analysis.ValidationException: class Landroid/security/Sha1MessageDigest; cannot be resolved.
            at org.jf.dexlib.Code.Analysis.ClassPath$UnresolvedClassDef.unresolvedValidationException(ClassPath.java:535)
            at org.jf.dexlib.Code.Analysis.ClassPath$UnresolvedClassDef.getClassDepth(ClassPath.java:543)
            at org.jf.dexlib.Code.Analysis.ClassPath.getCommonSuperclass(ClassPath.java:383)
            at org.jf.dexlib.Code.Analysis.RegisterType.merge(RegisterType.java:275)
            at org.jf.dexlib.Code.Analysis.AnalyzedInstruction.mergeRegister(AnalyzedInstruction.java:185)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.propagateRegisterToSuccessors(MethodAnalyzer.java:451)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.setPostRegisterTypeAndPropagateChanges(MethodAnalyzer.java:431)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.analyzeInvokeDirectCommon(MethodAnalyzer.java:3067)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.analyzeInvokeDirect(MethodAnalyzer.java:3016)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.analyzeInstruction(MethodAnalyzer.java:861)
            at org.jf.dexlib.Code.Analysis.MethodAnalyzer.analyze(MethodAnalyzer.java:213)
            at org.jf.baksmali.Adaptors.MethodDefinition.addAnalyzedInstructionMethodItems(MethodDefinition.java:378)
            at org.jf.baksmali.Adaptors.MethodDefinition.getMethodItems(MethodDefinition.java:300)
            at org.jf.baksmali.Adaptors.MethodDefinition.writeTo(MethodDefinition.java:132)
            at org.jf.baksmali.Adaptors.ClassDefinition.writeMethods(ClassDefinition.java:338)
            at org.jf.baksmali.Adaptors.ClassDefinition.writeDirectMethods(ClassDefinition.java:307)
            at org.jf.baksmali.Adaptors.ClassDefinition.writeTo(ClassDefinition.java:151)
            at org.jf.baksmali.baksmali.disassembleDexFile(baksmali.java:205)
            at org.jf.baksmali.main.main(main.java:293)
    opcode: invoke-direct
    CodeAddress: 28
    Method: Landroid/security/MessageDigest;->getInstance(Ljava/lang/String;)Landroid/security/MessageDigest;
    1
    Possibly difference in build. I notice that every different build has a slightly different framework, app, csc, and properties files. although a bit late, you can probably compare the two different build.prop for those two different units.

    I'll post my build.prop for XXLA4 in a bit.

    ---------- Post added at 05:58 PM ---------- Previous post was at 05:58 PM ----------



    Then jtag is your only friend... for now. make a jig cable with 3 100ohm resistors or 1 x 300 ohm resister and join up pin 4 and 5, see if it force-boots into Odin mode.

    I am not sure how the build difference issue would work, as, in theory, if your device is fully wiped, the ROM would just replace everything...if recovery is not wiping properly (as eznow mentioned above), it could be a factor, although bricking seems a bit extreme). Not dismissing this, just saying, it seems odd. I have noticed that some 10.1 ROMs for wifi+3g have several carrier specific files in csc, so it may be something to do with that. I'll ask around and see...

    As I mentioned before, for those two or three posters from yesterday who seemed to have followed the instructions, and got bricked, I am willing to work something out with paying for you to use JTAG (if you flashed after the issue was posted, sorry, but I can't help you...). Even though I clearly stated that this was to be flashed at your own risk and that I had only tested it, I feel this is fair.


    I am also looking to see how to remove the back cover and pull the battery (which I will test on my own tablet first), as a battery pull seems to work in many cases...
    Steve
    1
    how he got unbricked? i mean what method he used?

    JTAG, I believe....