[Galaxy Tab 7.7 Android Development] sk806:
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