Galaxy Tab 7.0 Plus

[netchip]

If the Tab 7 Plus is like the rest of its exynos brethren, the recovery partition in p6 does nothing - all of the magic occurs in the initramfs of the kernel, which is p5 on the GS2.

It looks from another thread like the device has successfully been rooted? If so, the first order of business should be someone getting dumps of the various partitions.

Also, someone should try installing Heimdall and using the commandline version to do:

heimdall --dump-pit

Heimdall won't talk to a lot of newer Samsung devices, but so far it seems to talk to any Exynos or Hummingbird based device. If Heimdall will talk to your device that's a great sign.

GT-P6210 has recovery partition & it's in use.
Check the stock images.

netchip

 

[garyd9]

If the Tab 7 Plus is like the rest of its exynos brethren, the recovery partition in p6 does nothing - all of the magic occurs in the initramfs of the kernel, which is p5 on the GS2.

I have to be honest and admit you lost me a bit here. I can say that I've overwritten p6 with a custom recovery image, and that's the image it uses when I get into recovery. I had no idea there were tools for dumping the pit either.

Here's what I determined the old-fashioned way (you know.. looking in /proc, checking fstabs, a bit of tinkering..):

 179        1      20480 mmcblk0p1	# /efs
 179        2       1280 mmcblk0p2	# /boot
 179        3       1280 mmcblk0p3
 179        4       8192 mmcblk0p4	# /mnt/.lfs
 179        5       8192 mmcblk0p5
 179        6       8192 mmcblk0p6	# /recovery
 179        7     204800 mmcblk0p7	# /cache
 179        8     786432 mmcblk0p8	# /system
 179        9   13807616 mmcblk0p9	# /data
 179       10     524288 mmcblk0p10	# /preload
 179       11       8192 mmcblk0p11

I'm not sure what p3 or p5 is. This is honeycomb, so /sdcard is actually a link (fuse) to /data/media.

I can tell you that dd's to p6 do result in a perm overwrite of the recovery, though it seems kind of flaky. The image I overwrite is a kernel image with an initramfs embedded. The format of the packing is very similar to the GSII. (In fact, I'm using a modification of a tool created for the GSII to unpack the original recovery, replace the initramfs and repackage it up.)

---------- Post added at 01:36 PM ---------- Previous post was at 01:00 PM ----------

Here's a heimdall print-pit:

Downloading device's PIT file...
PIT file download sucessful

Entry Count: 14
Unknown 1: 0
Unknown 2: 0
Unknown 3: 0
Unknown 4: 0
Unknown 5: 0
Unknown 6: 0
Unknown 7: 0
Unknown 8: 0


--- Entry #0 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 0
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 0
Partition Block Count: 0
Unknown 2: 0
Unknown 3: 0
Partition Name: GANG
Filename: emmc.img


--- Entry #1 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 1
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 0
Partition Block Count: 0
Unknown 2: 0
Unknown 3: 0
Partition Name: BOOT
Filename: boot.bin


--- Entry #2 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 4
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 8192
Partition Block Count: 40960
Unknown 2: 0
Unknown 3: 0
Partition Name: EFS
Filename: efs.img


--- Entry #3 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 2
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 49152
Partition Block Count: 2560
Unknown 2: 0
Unknown 3: 0
Partition Name: SBL1
Filename: Sbl.bin


--- Entry #4 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 3
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 53248
Partition Block Count: 2560
Unknown 2: 0
Unknown 3: 0
Partition Name: SBL2
Filename: 


--- Entry #5 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 5
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 57344
Partition Block Count: 16384
Unknown 2: 0
Unknown 3: 0
Partition Name: PARAM
Filename: param.lfs


--- Entry #6 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 6
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 73728
Partition Block Count: 16384
Unknown 2: 0
Unknown 3: 0
Partition Name: KERNEL
Filename: zImage


--- Entry #7 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 7
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 90112
Partition Block Count: 16384
Unknown 2: 0
Unknown 3: 0
Partition Name: RECOVERY
Filename: recovery.img


--- Entry #8 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 8
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 106496
Partition Block Count: 409600
Unknown 2: 0
Unknown 3: 0
Partition Name: CACHE
Filename: cache.img


--- Entry #9 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 10
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 516096
Partition Block Count: 1572864
Unknown 2: 0
Unknown 3: 0
Partition Name: FACTORYFS
Filename: factoryfs.img


--- Entry #10 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 11
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 2088960
Partition Block Count: 27615232
Unknown 2: 0
Unknown 3: 0
Partition Name: DATAFS
Filename: data.img


--- Entry #11 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 12
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 29704192
Partition Block Count: 1048576
Unknown 2: 0
Unknown 3: 0
Partition Name: HIDDEN
Filename: hidden.img


--- Entry #12 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 13
Partition Flags: 1 (R)
Unknown 1: 0
Partition Block Size: 30752768
Partition Block Count: 16384
Unknown 2: 0
Unknown 3: 0
Partition Name: FOTA
Filename: 


--- Entry #13 ---
Unused: Yes
Partition Type: 1 (Unknown)
Partition Identifier: 9
Partition Flags: 0 (R)
Unknown 1: 0
Partition Block Size: 0
Partition Block Count: 0
Unknown 2: 0
Unknown 3: 0
Partition Name: 
Filename: 

Ending session...
Rebooting device...

 

[Entropy512]

On other Exynos devices (like the I777 and I9100), there is partition 6 that is labeled recovery, but it does nothing - entering recovery just boots partition 5 with some extra kernel commandline parameters.

It looks like, unlike previous Exynos devices, the Tab 7 Plus actually uses partition 6.

The fact that Heimdall will successfully dump the PIT is a VERY good sign for you - I don't think I've ever seen a situation where heimdall will dump a PIT but won't flash properly but I could be wrong. So most likely you can flash your recovery image using heimdall.

I see stock firmware releases for 3G devices, but probably someone should dump stock kernel, recovery, and system images ASAP for the wifi edition.

I am sooooo damn tempted to get one of these - I would without hesitation if I didn't already have a Tab 10.1.

 

[clubtech]

On other Exynos devices (like the I777 and I9100), there is partition 6 that is labeled recovery, but it does nothing - entering recovery just boots partition 5 with some extra kernel commandline parameters.

It looks like, unlike previous Exynos devices, the Tab 7 Plus actually uses partition 6.

The fact that Heimdall will successfully dump the PIT is a VERY good sign for you - I don't think I've ever seen a situation where heimdall will dump a PIT but won't flash properly but I could be wrong. So most likely you can flash your recovery image using heimdall.

I see stock firmware releases for 3G devices, but probably someone should dump stock kernel, recovery, and system images ASAP for the wifi edition.

I am sooooo damn tempted to get one of these - I would without hesitation if I didn't already have a Tab 10.1.

Sell the 10.1 and get this instead. The device just smokes the 10.1.

Sent from my GT-P6200 using xda premium

 

[garyd9]

The fact that Heimdall will successfully dump the PIT is a VERY good sign for you - I don't think I've ever seen a situation where heimdall will dump a PIT but won't flash properly but I could be wrong. So most likely you can flash your recovery image using heimdall.

I am sooooo damn tempted to get one of these - I would without hesitation if I didn't already have a Tab 10.1.

I'm not convinced that heimdall worked... The partition info it dumped just doesn't make much sense to me and seems wrong, somehow.

As for you getting one of these, it's a really great little tab, and you shouldn't let owning the 10.1 stop you. The 7" tablet fills a massive hole left between the too small phones and too large 10" tablets. I find its the ideal size for reading ebooks, quick games, and taking with me when I am running out. My 10" is an iPad, and I use that, mostly, for taking notes at work, but it's a bit cumbersome to carry with me everywhere. You have to admit, the 10" won't fit in your back pocket.

Anyway, I'd love to see your DD kernel ported here...

Take care
Gary

 

[truelies1]

Any case and screen protector for this? I am planning to buy one, It's really an expensive 7" tablet compared to Kindle Fire.

 

[garyd9]

On other Exynos devices (like the I777 and I9100), there is partition 6 that is labeled recovery, but it does nothing - entering recovery just boots partition 5 with some extra kernel commandline parameters.

Curiosity got the best of me.. I pulled an image of the partition (via dd) and guess what? It's also a zImage. Unlike partition 6, however, there's no "recovery" binary in /sbin. As best as I can determine, it's the "normal" boot zImage file. That would explain why I was able to completely destroy the recovery partition once but still boot normally. (thankfully.)

partition 2 is certainly some kind of specialized bootloader. It appears to also contain the ODIN mode code.

partition 3 also seems to be some kind of bootloader. Perhaps a backup bootloader of some kind? A diff between the two images says they are different, but they appear to be very close. (Actually, the embedded strings within them appear show only a single difference of 1 4 char string.)

Finally, there's partition 11. This appears to be... empty. Nothing but nulls.

So, this is my revised partition table for the GT-P6210:

 179        1      20480 mmcblk0p1	# /efs
 179        2       1280 mmcblk0p2	# /boot
 179        3       1280 mmcblk0p3      # ???? this appears to also be a bootloader
 179        4       8192 mmcblk0p4	# /mnt/.lfs
 179        5       8192 mmcblk0p5	# ???? normal boot kernel?
 179        6       8192 mmcblk0p6	# /recovery
 179        7     204800 mmcblk0p7	# /cache
 179        8     786432 mmcblk0p8	# /system
 179        9   13807616 mmcblk0p9	# /data
 179       10     524288 mmcblk0p10	# /preload
 179       11       8192 mmcblk0p11     # ????? it's all nulls.

Not sure if any of this will be useful, but it's fun digging.

 

[Entropy512]

The Heimdall dump you posted looked good to me - The partition numbers displayed are one higher than the partition numbers seen by Linux for some reason.

e.g. partition 7 in the PIT dump is mmcblk0p6

Your partitions look almost identical to a GS2.
SBL1/SBL2: Secondary bootloader, one of these is a backup in case the other gets corrupted. However anyone who has killed their SBL1 does not seem to be able to get any benefit from SBL2. You are correct that these are for download mode - and also booting the device. Corrupt these and you can hardbrick.
EFS: This is where the IMEI of 3G devices is stored, among other things
PARAM: - param.lfs (mmcblk0p4) - Stores the initial boot logo and some other stuff. Corrupting this MIGHT make your device unbootable - but it seems like Exynos devices are more resilient
KERNEL: - zImage (mmcblk0p5) - self-explanatory
RECOVERY: - Another zImage in mmcblk0p6 - I've never seen this actually used on any other device
I forget what's in p7/p8 - need to hurry and get out the door
p8 - /system
p9 - /data
p10 - "hidden" on the GS2. It seems to contain backups of the AT&T-installed apps on the I777.

 

[Entropy512]

Of course there is.. It is your baseband version.

Um, how can you have a version for that which does not exist? A wifi-only device doesn't have a cellular radio, therefore won't have a baseband chip, therefore won't have a baseband version.

This isn't a Qualcomm MSM where the baseband bootloads the main applications processor - it's the other way around, so if there is no baseband hardware, there isn't going to be baseband firmware.

 

[Entropy512]

I'm not convinced that heimdall worked... The partition info it dumped just doesn't make much sense to me and seems wrong, somehow.

As for you getting one of these, it's a really great little tab, and you shouldn't let owning the 10.1 stop you. The 7" tablet fills a massive hole left between the too small phones and too large 10" tablets. I find its the ideal size for reading ebooks, quick games, and taking with me when I am running out. My 10" is an iPad, and I use that, mostly, for taking notes at work, but it's a bit cumbersome to carry with me everywhere. You have to admit, the 10" won't fit in your back pocket.

Anyway, I'd love to see your DD kernel ported here...

Take care
Gary

The portability is tempting - on the other hand, the ZAGGFolio keyboard on the 10.1 is REALLY nice, and the 10.1 is good for ease of use when I'm not carrying it.

I'd drop the 10.1 in a heartbeat if there were a 10" Exynos-based Tab.

As to DD porting - I don't know if that's going to be necessary. You seem to have the technical, analytical, and research skills it takes to move forward with development here on your own, with just a few tips regarding "samsungisms" to get you started.

Situations like this are why I try to make my git repo as clean and understandable as I can - so a developer for another device with similar architecture is able to move forward without having to reinvent the wheel. This frees them up to make new discoveries, and EVERYONE benefits. Remember - much of what initially went into Daily Driver came from Ninphetamine on the I9100 because Netarchy and Ninpo were similarly open about their developments and kept a clean git repo.

Keep in mind that other than some small tweaks to xdandroid's userland (GPS libs), the Samsung Infuse was my first major foray into Android development and I bought that device in late June. Fortunately the Infuse community was close-knit and had a high degree of developer communication/cooperation - we didn't have the prima donnas some communities have. It made for a great learning experience.

Tips going forward: While you've already been messing around in the initramfs to try and get recovery working, I suggest extracting a clean one from a zImage and posting it up to github. Then make commits as you integrate CWM.

Similarly, take your stock kernel sources and commit them to github BEFORE you make any changes. From there, do the requisite cleanups and .gitignores (see my repo for examples) and then start doing development. You should be able to "git am" quite a few of my patches against Daily Driver. As you go forward, try to (as I mention in my kernel thread) keep a "one feature = one commit" rule - or worst case "one feature = 2-3 commits" if you find yourself having to fix stuff after public testing. Avoid commits with multiple features at all costs. In fact, if you do get a multi-feature commit somewhere, try for your future sanity to split it up.

Avoid rebasing commits pushed to a public repo at all costs - NEVER do it for a major branch, it may be OK for a "side project" branch that no one uses (like the siyah_deltas branch I had on github for easier reading for a while).

Last, and few kernel devs do this - If you revert a commit using "git revert", add documentation on why you did it to the commit message.

 

[truelies1]

Seen this?

Thinking about snagging it myself.....just waiting.

It's about $20. For Antireflective thing, I don't know it's good or not, I used one before, it's not 100% transparent, the screen will not clear.Maybe this one is good? http://www.amazon.com/gp/product/B005UOVQ9K/ref=ox_sc_act_title_6?ie=UTF8&m=A127GCSIQ9QZ6G I used skinomi before, install is a little difficult, but works good.

Does this one has IPS screen?

 

[garyd9]

As to DD porting - I don't know if that's going to be necessary. You seem to have the technical, analytical, and research skills it takes to move forward with development here on your own, with just a few tips regarding "samsungisms" to get you started.

My main stumbling block with anything android related is that I have a personal distaste for java. (Of course, I also have a distaste for C# and any other interpreted or semi-interpreted langauge.)

Tips going forward: While you've already been messing around in the initramfs to try and get recovery working, I suggest extracting a clean one from a zImage and posting it up to github. Then make commits as you integrate CWM.

I'm paranoid. I have "clean" (pre-modified) images from both bootloader partitions, the normal boot kernel/initramfs and the recovery kernel/initramfs. I didn't bother with /system, but I made a signed update.zip from the original release that overwrites the entire /system partition. I've actually used that already when I deleted the entire /system/app directory..

I've sent you a PM with other comments...

 

[Entropy512]

That's the nice thing about kernel work - no java! Java rapidly makes me want to self-facestab.

If you REALLY want an urge to self-facestab - try smali. That's why I leave that crap to the ROM devs in almost all cases. I tried my hand at it for the sake of learning the black voodoo magic that is userland, but for the most part - gonna stick to kernels with the exception of NFC hacking on the I777.

 

[wtherrell]

What page? 7+ not listed ion OP. 306 pages, don't know which has our device.

 

[wtherrell]

Guys its been fun! I dont think the GT7+ is going to ge5t all the development love that it deserves. hence I am going to send it back and buy a kindle fire, which tho it is inferior, its not $200 inferior and it does have developer support

I disagree. Tried Kindle Fire-Too locked in to Amazon and the Acloud. Just a slightly glorified Kindle e-reader. Returned it.

Next tried a Nook Tablet. Plenty of storage but also locked in media-wise, unless you want to root and that seems to destabilize it, I am told. Locked bootloader so I didn't see much future. Media sound volume too low to hear to be practical. Email, Calendar apps stink. Returned it as well.
Now escalated to GT7+.
YGWYPF.
When will people ever learn?

 

[Entropy512]

The GTP6210 will probably get less development than the Fire, due to its price range not being in "hacktoy" range - but it needs far less development to begin with, as it's a native Honeycomb device, while the Fire needs MAJOR work just to make it a usable device.

Overall, longterm, it is highly unlikely the Fire will provide a better user experience than the Tab 7 Plus - 7Plus has superior hardware and native Honeycomb, and likely ICS coming soon.

 

[dbdynsty25]

Overall, longterm, it is highly unlikely the Fire will provide a better user experience than the Tab 7 Plus - 7Plus has superior hardware and native Honeycomb, and likely ICS coming soon.

Totally agree, however, at least my wife doesn't get 2-3 SODs on her Fire each day like I do on my GTP. So frustrating. Can't find one in stock at a Best Buy near me for an exchange so I'm just patiently waiting.

 

[shadejinx]

@dbdynasy25, do you have setCPU or similar installed on your wife's tab? I only ask because I never got an SoD in 2 weeks of pretty constant use until I created a "Screen Off" profile in SetCPU. After I removed that profile, the SoDs vanished.

 

[garyd9]

I've had my 6210 since Nov 4th, and I haven't yet had a single SOD. In contrast, I went through THREE different GT 10.1's which all had problems... (terminal SOD, constant crashes, etc.) I had almost given up on having a stable android tablet until this 7+ came along.

 

[chrisrotolo]

yeah I think SETCPU needs a screenoff for a certain amount of time. just set your profile to say 100mhz min and 1000mhz max when screen is off and press power 4-5 times fast,.. actually dont do that your device will likely get sleepy.