Database Users

Advent Vega system image

The advent vega has started shipping in the UK, hardware is very similar except it does not have 16gb internal memory. A system image has been made available by advent, is this something you can use with the Viewsonic? Videos of the vega show it is very responsive
http://www.myadventvega.co.uk/boot_update_20101119_v1.0.3_dix.zip

mcb00f said:
The advent vega has started shipping in the UK, hardware is very similar except it does not have 16gb internal memory. A system image has been made available by advent, is this something you can use with the Viewsonic? Videos of the vega show it is very responsive
http://www.myadventvega.co.uk/boot_update_20101119_v1.0.3_dix.zip
Click to expand...
Click to collapse
I'd love top get a system update, but that's just a boot.img I think.

I'd be interested in the hardware differences. The picture I saw sure did look a lot like the malata tablets.

The first batch are on their way, i'll keep an eye on the Modaco forums to see whether anyone extracts a system image. I'm still deciding whether to get the VS or the Vega.

This is listed as a full system update, more useful?
http://www.myadventvega.co.uk/softwareImage_v1.02_Vega_Final.exe

mcb00f said:
This is listed as a full system update, more useful?
http://www.myadventvega.co.uk/softwareImage_v1.02_Vega_Final.exe
Click to expand...
Click to collapse
Awesome! thanks - more fun for me!
EDIT: This is actually an nvflash script of some kind. That in itself doesn't bother me, except that it's Windows based.

roebeet said:
Awesome! thanks - more fun for me!
EDIT: This is actually an nvflash script of some kind. That in itself doesn't bother me, except that it's Windows based.
Click to expand...
Click to collapse
Well, I was feeling curious/adventureous tonight... So I figured I'd see what would happen were I to actually run this Vega .exe and Flash one of my Gtabs with it...
I have the Tegra SDK loaded so nvflash works normally, but I was pleased that they seem to have included everything anyone would need in this self extracting/excuting exe... it extracts to $TEMP as;
PowerDesk Pro 7 - C:\_Save\Tegra2-Gtab\Vega-1118-Rom\Files Date: 11/23/2
Name Ext Size Type Date Modified Time Attr
bootloader.bin .bin 937,416 VLC media file (.bin)
clean_steps.mk .mk 8,866 MK File 11/18/2010 3:52 PM a
flash.bct .bct4,080 BCT File 11/18/2010 3:52 PM a
flash.cfg .cfg2,064 Config file 11/18/2010 3:52 PM a
installed-files.txt .txt 29,140 Text Document 11/18/20103:52 PM a
kernel 3,001,816 File 11/18/20103:52 PM a
previous_build_config.mk.mk 187 MK File 11/18/20103:52 PM a
ramdisk.img .img 1,247,868 WinZip File 11/18/20103:52 PM a
ramdisk-recovery.img .img 1,481,495 WinZip File 11/18/20103:52 PM a
recovery.img .img 4,487,168 WinZip File 11/18/20103:52 PM a
system.img .img 115,019,520 WinZip File 11/18/20103:52 PM a
android-info.txt .txt 14 Text Document11/18/2010 3:52 PM a
boot.img .img 4,253,696 WinZip File 11/18/20103:52 PM a
libnv3p.dll .dll 51,712 Application Extension
libnvaes_ref.dll .dll 45,056 Application Extension
libnvapputil.dll .dll 80,384 Application Extension
libnvdioconverter.dll .dll 45,056 Application Extension
libnvflash.dll .dll 77,312 Application Extension
lvds.bat .bat 164 Windows Batch File 11/18/20103:16 PM a
nvflash.exe .exe 151,552 Application 11/18/20103:16 PM a
libnvboothost.dll .dll 43,520 Application Extension
libnvos.dll .dll 94,208 Application Extension
libnvusbhost.dll .dll 44,544 Application Extension
So I Plugged in one of my GTabs and Pwr+ Vol+/- to give it a go and...
C:\Temp>nvflash.exe --bct flash.bct --setbct --bl bootloader.bin --configfile fl
ash.cfg --odmdata 0x000c0075 --create --go
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x17144009417f4317
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: nand
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
sending file: flash.bct
- 4080/4080 bytes sent
flash.bct sent successfully
odm data: 0xc0075
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: bootloader.bin
| 937416/937416 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 1 0
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: MSC
failed executing command 16 NvError 0x120000
command failure: create failed
Press enter to continue:
Actually pretty anti-climactic... I figured I was going to need to restore this tab to factory default but tried a power cycle to see what happens and it booted Normally to TNT original with Launcherpro which is where I had started...
Just figured I'd pass this along and save some else the disappointment :>)

Full image means it has a kernel, system image (.apks) so in theory there should bea lot of material that can be extracted from this and potentially incorporated into TNT Lite or even an all new custom rom.
Even the Vega is lightly skinned from what I have read, so still no vanilla tablet.
Thanks for giving it a try!

mcb00f said:
Full image means it has a kernel, system image (.apks) so in theory there should bea lot of material that can be extracted from this and potentially incorporated into TNT Lite or even an all new custom rom.
Even the Vega is lightly skinned from what I have read, so still no vanilla tablet.
Thanks for giving it a try!
Click to expand...
Click to collapse
Yes, thus why I expected to end up with a virgin Vega install... Once it started and actually ran for a while I was actually surprised that wasn't the final outcome... actually ODD that it seems to have failed on creating Partition 5 of 11 in flash.cfg....
I have extracted the saved files from temp so wouldn't be hard to actually pack a clockworks loadable zip I suppose... but as this was so easy to get this far and I'm no pro at packaging something useful for all... I'll leave that to the experts like Roebeet who have a lot of experience here...
Edit... This sure seems an Easy way to package a Full System restore for folks who wouldn't already have the Tegra development enviroment tools loaded, as everything here seems it could be re-made into a self-extracting/executing Zip Exe that anyone with a PC could use as long as the USB drivers were also packaged into the mess...

Making a signed update.zip with a an install script may work out. All the nessecary seem to be there.
Sent from my DROIDX using Tapatalk

I tried replacing boot.img and system.img, both failed. Then I actually nvflashed my entire device (it wasn't pretty).
There may be tidbits in there we could use, but the devices aren't the same.
Here's one thing interesting -- their settings app has a G-Sensor section. But, it FC's when I try to run it on either TnT Lite or zPad Clean 1.0.

Are you able to grab any system apps such as calendar or contacts? Or do they rely on the framework of the vega?

mcb00f said:
Are you able to grab any system apps such as calendar or contacts? Or do they rely on the framework of the vega?
Click to expand...
Click to collapse
The entire system.img in the the .exe (which is really just an archive file)

roebeet said:
The entire system.img in the the .exe (which is really just an archive file)
Click to expand...
Click to collapse
Well, maybe there's something useful... I'm really surprised as thought these tabs were twins with upgrades... Guess I was wrong... again surprised what I tried didn't hose mine as I guess bootloader is close at least... as it flashed successfully and I still came up... I guess they are running different layout based on partitions failing...
THANX for trying... You Da Man!!!

The vega rom looks pretty fast and it looks like Angry birds run on it
Check out the clip
http://www.youtube.com/watch?v=-3sI1aTpdDs

Does this look quicker/more responsive than the G Tablet running TNT Lite 2?

bootloader.bin version?
jtbnet said:
Well, I was feeling curious/adventureous tonight... So I figured I'd see what would happen were I to actually run this Vega .exe and Flash one of my Gtabs with it...
I have the Tegra SDK loaded so nvflash works normally, but I was pleased that they seem to have included everything anyone would need in this self extracting/excuting exe... it extracts to $TEMP as;
PowerDesk Pro 7 - C:\_Save\Tegra2-Gtab\Vega-1118-Rom\Files Date: 11/23/2
Name Ext Size Type Date Modified Time Attr
bootloader.bin .bin 937,416 VLC media file (.bin)
clean_steps.mk .mk 8,866 MK File 11/18/2010 3:52 PM a
flash.bct .bct4,080 BCT File 11/18/2010 3:52 PM a
flash.cfg .cfg2,064 Config file 11/18/2010 3:52 PM a
installed-files.txt .txt 29,140 Text Document 11/18/20103:52 PM a
kernel 3,001,816 File 11/18/20103:52 PM a
previous_build_config.mk.mk 187 MK File 11/18/20103:52 PM a
ramdisk.img .img 1,247,868 WinZip File 11/18/20103:52 PM a
ramdisk-recovery.img .img 1,481,495 WinZip File 11/18/20103:52 PM a
recovery.img .img 4,487,168 WinZip File 11/18/20103:52 PM a
system.img .img 115,019,520 WinZip File 11/18/20103:52 PM a
android-info.txt .txt 14 Text Document11/18/2010 3:52 PM a
boot.img .img 4,253,696 WinZip File 11/18/20103:52 PM a
libnv3p.dll .dll 51,712 Application Extension
libnvaes_ref.dll .dll 45,056 Application Extension
libnvapputil.dll .dll 80,384 Application Extension
libnvdioconverter.dll .dll 45,056 Application Extension
libnvflash.dll .dll 77,312 Application Extension
lvds.bat .bat 164 Windows Batch File 11/18/20103:16 PM a
nvflash.exe .exe 151,552 Application 11/18/20103:16 PM a
libnvboothost.dll .dll 43,520 Application Extension
libnvos.dll .dll 94,208 Application Extension
libnvusbhost.dll .dll 44,544 Application Extension
So I Plugged in one of my GTabs and Pwr+ Vol+/- to give it a go and...
C:\Temp>nvflash.exe --bct flash.bct --setbct --bl bootloader.bin --configfile fl
ash.cfg --odmdata 0x000c0075 --create --go
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x17144009417f4317
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: nand
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
sending file: flash.bct
- 4080/4080 bytes sent
flash.bct sent successfully
odm data: 0xc0075
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: bootloader.bin
| 937416/937416 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 1 0
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: MSC
failed executing command 16 NvError 0x120000
command failure: create failed
Press enter to continue:
Actually pretty anti-climactic... I figured I was going to need to restore this tab to factory default but tried a power cycle to see what happens and it booted Normally to TNT original with Launcherpro which is where I had started...
Just figured I'd pass this along and save some else the disappointment :>)
Click to expand...
Click to collapse
Did you use the original bootloader.bin from the TNT Releases? Someone had commented earlier that the standard bootloader.bin wouldn't work on the gtab. Even the bootloader.bin that was included in the NVIDIA release didn't work for some reason.

dkhilo said:
Did you use the original bootloader.bin from the TNT Releases? Someone had commented earlier that the standard bootloader.bin wouldn't work on the gtab. Even the bootloader.bin that was included in the NVIDIA release didn't work for some reason.
Click to expand...
Click to collapse
I tried that, and it failed miserably. Boot.img is to blame.
They have the same Tegra2, but I think there are too many other differences to make them compatible. Still, we might be able to rip out some things.

You could split the boot.img and use the kernel. Don't know how much of a gain you could possibly get from it. But no one has been able to figure out how the software is bogging the tab down. The hardware in the gtab is very powerful. In my opinion no one has been able to come anywhere near completing a build of android that does the chipset justice. It maybe because the hardware is bleeding edge or it could be that android itself is just not ready to take advantage. Seeing that the gtab is open to modding and more and more devices based off of the tegra chipset are coming out I feel that it will just be a matter of time before our little tablet will truly shine. I have no doubt either that we have more than enough power for future builds of android.
Sent from my DROIDX using Tapatalk

Just in case there might be anything you can extract and use here roebeet:
New 1.04 system image from Advent Vega: http://www.myadventvega.co.uk/softwareImage_v1.04_Vega_Final.exe
Modaco Custom Rom for the Advent Vega, adding market and GApps as you have done for the VS. May be something ele in there you can use:
http://android.modaco.com/content/a...for-the-advent-vega-1-04-with-online-kitchen/

[Q] Issue with Acer Iconia A500 Flashing Bootloader and Entering Recovery

Alright I did find a forum where this should be posted but due to restrictions I said I would post it here the forum was http://forum.xda-developers.com/showthread.php?t=1622425
I have searched through all that forum and tested every method to try and get my issue resolved.
DEVICE INFO:
Device : Acer Iconia A500
Android version : 4.0.3
Kernal: 2.6..39.4+
Image Version: Acer _AV041_A500_RV03RC01_WW_GEN1
Build Number: Acer_AV041_A500_1.031.00_WW_GEN1
Image P/N: FM.S14A0.00U
Bootloader Version 0.03.12-ICS
Tablet is also Rooted
The issue is that when I attempt to enter recovery it says
" Erasing Cache beofre SD Update...
SD Update cmd: recovery
--update_package=SDCARD: Update.zip
Booting recovery kernal image
Recovery verified failed ... "
I have tried putting an update.zip file on both the internal and external SD card but issue still happens.
The next issue is that when I try flash the bootloader using the information in the above forum It just continously hangs and looking at the cmd output it has an error
Flashing bootloader: ics_boot_unlk_V4.bin ...
Nvflash started
[resume mode]
Formatting partition 4 please wait.. Command Execution failed cmd 13, error 0x12
0002
FAILED!
command failure: format partition failed (bad command)
bootloader status: unknown operation (code: 1) message: flags: 0
Nvflash started
[resume mode]
I have attempted to remove the batch script that formats the partitions but that still doesnt work.
I have attempted the bootloader flash both manually using the CMD and the automatically using the A500APXFlashing tool.
I have tried all issue resolutions in the forums above but still not working
Any help would be great
Thanks in advance
ADDITIONAL INFO:
In the normal operations the tablet works fine it is boots into android ICS without any problems

Issue with Acer Iconia A500 Flashing Bootloader and Entering Recovery
I been having the same problem as you with no soluton.

shenny585 said:
I been having the same problem as you with no soluton.
Click to expand...
Click to collapse
Have you tried all TS in the thread that I linked at the top of my post?

Issue with Acer Iconia A500 Flashing Bootloader and Entering Recovery
Yes I did

Ok well it seems that we need to see can we get a dev to look at this forum to see if there is any resolution.

Sounds like a dodgy SBK
OP: what app did you root woth!?
Sent from my Iconia A500 using Tapatalk 2

Issue with Acer Iconia A500 Flashing Bootloader and Entering Recovery
SBK is right
Used the blackthund3r apx flash utility and the simple method for rooting

shenny585 said:
SBK is right
Used the blackthund3r apx flash utility and the simple method for rooting
Click to expand...
Click to collapse
Try Skrilax's bundle market repo bundle #4 (see his boot loader thread for the URL, input it into the bundle market then choose bundle 4). Press yes to stage for flash when you download
Sent from my Iconia A500 using Tapatalk 2

Issue with Acer Iconia A500 Flashing Bootloader and Entering Recovery
Tried Skrilax's bundle market repo bundle #4 with no result.
The acer usb boot recovery drives disappears when entering download mode bootloader..

blackthund3r said:
Sounds like a dodgy SBK
OP: what app did you root woth!?
Sent from my Iconia A500 using Tapatalk 2
Click to expand...
Click to collapse
Firstly Id like to thank you for the rooting tool made it a breeze.
I have tested my SBK in CMD using the tool form the forum above and it seems to be right
I have tried uninstall and reinstall of Acer drivers to no aval.
Will try the latest post you put up and get back with an update

What is the output upon the initial command where you enter the SBK (when using nvflash manually)?

Skrilax_CZ said:
What is the output upon the initial command where you enter the SBK (when using nvflash manually)?
Click to expand...
Click to collapse
Here is the response after I enter the SBK. Is this the right response
**********************************************************
* Make your choise: *
*(1) HC bootloader with TWRP cwm (touch cwm) *
*(2) ICS bootloader V4 with TWRP-2.1.3-ICS cwm(touch cwm)*
*(3) ICS bootloader V4 with PubRecovery-ICS (BareBones) *
*(4) ICS bootloader V4 with Thor-1.7cwm (touch cwm) *
*(5) ICS bootloader V4 with Thor-1.7.2 NEW cwm(touch cwm)*
* with its compatible recoveries. *
**********************************************************
(1 2 3 4 5):5
Loading bootloader...
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x0380624843c11517
macrovision: disabled
hdcp: enabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 4
device config strap: 0
device config fuse: 0
sdram config strap: 3
sending file: bct.bct
- 4080/4080 bytes sent
bct.bct sent successfully
odm data: 0x300d8011
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: bootloader.bin
| 714981/714981 bytes sent
bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
failed executing command 25 NvError 0x120002
command failure: sync failed (bad data)
bootloader status: partition table is invalid, missing required information (cod
e: 14) message: nverror:0x4 (0x4) flags: 0
**********************************************************
* Press any key when your A500 is in bootloader mode *
**********************************************************
Press any key to continue . . .

blackthund3r said:
Try Skrilax's bundle market repo bundle #4 (see his boot loader thread for the URL, input it into the bundle market then choose bundle 4). Press yes to stage for flash when you download
Sent from my Iconia A500 using Tapatalk 2
Click to expand...
Click to collapse
I have tried that method and it just hangs and doesnt do anything and the tablet says entering download mode not APX mode
Any other ideas?

steokeogh said:
I have tried that method and it just hangs and doesnt do anything and the tablet says entering download mode not APX mode
Any other ideas?
Click to expand...
Click to collapse
Well, the thing is that you have to dump your bct from the tablet and decrypt it with SBK and read odmdata from that. No real guide exists for this, BCT is first 4k bytes from mmcblk0 (w/o partition), and used method is aes. It's 2:46 AM now, so just very basic info:
A) dd if=/dev/block/mmcblk0 of=/sdcard/bct.enc bs=4096 count=1
B) Pull bct.enc to PC
C) Decrypt with AES using SBK as the key (remove the "0x" and join it)
D) odmdata parameter is on 0xFE4 in bct (little endian)
And if you repartition the tablet, you have do it again.
That's what causes the issues, blackthund3r's app uses the most common bct. Seems like we'll have to automate this.

Skrilax_CZ said:
Well, the thing is that you have to dump your bct from the tablet and decrypt it with SBK and read odmdata from that. No real guide exists for this, BCT is first 4k bytes from mmcblk0 (w/o partition), and used method is aes. It's 2:46 AM now, so just very basic info:
A) dd if=/dev/block/mmcblk0 of=/sdcard/bct.enc bs=4096 count=1
B) Pull bct.enc to PC
C) Decrypt with AES using SBK as the key (remove the "0x" and join it)
D) odmdata parameter is on 0xFE4 in bct (little endian)
And if you repartition the tablet, you have do it again.
That's what causes the issues, blackthund3r's app uses the most common bct. Seems like we'll have to automate this.
Click to expand...
Click to collapse
Thanks for the further TS but I cannot seem to find the files you mention above.
Would you be able to give me more broken down steps to try fix this? Thanks
Also I saw that blackthund3r has released a new version of the tool. It mentions in the post some of the things you mention in yours is the tool now updates to automate the process you were talking about.
Sent from my HTC Desire HD A9191 using XDA

Skrilax_CZ said:
Well, the thing is that you have to dump your bct from the tablet and decrypt it with SBK and read odmdata from that. No real guide exists for this, BCT is first 4k bytes from mmcblk0 (w/o partition), and used method is aes. It's 2:46 AM now, so just very basic info:
A) dd if=/dev/block/mmcblk0 of=/sdcard/bct.enc bs=4096 count=1
B) Pull bct.enc to PC
C) Decrypt with AES using SBK as the key (remove the "0x" and join it)
D) odmdata parameter is on 0xFE4 in bct (little endian)
And if you repartition the tablet, you have do it again.
That's what causes the issues, blackthund3r's app uses the most common bct. Seems like we'll have to automate this.
Click to expand...
Click to collapse
Hmm. Well the tool has ADB already integrated. If you have a copy of the bct decryption utility (its download link is currently down AFAIK) then I would happily work with you in producing the updated version of the flash tool to support this. I can easily get dd etc for windows and script the production of the data. Assuming the SBK is correct we should even be able to read raw bytes from the flash and produce the mmcblk0_start from APX Mode.
Would this help us? http://git.chromium.org/gitweb/?p=chromiumos/third_party/cbootimage.git
Sent from my Iconia A500 using Tapatalk 2

steokeogh said:
Thanks for the further TS but I cannot seem to find the files you mention above.
Would you be able to give me more broken down steps to try fix this? Thanks
Also I saw that blackthund3r has released a new version of the tool. It mentions in the post some of the things you mention in yours is the tool now updates to automate the process you were talking about.
Sent from my HTC Desire HD A9191 using XDA
Click to expand...
Click to collapse
I haven't worked on this yet but I would be interested in doing so. The decryption iirc is done with openssl. I'll look around and let you know when I find the steps. What we can do so far:
A) use a terminal emulator or adb shell to run
Code:
dd if=/dev/block/mmcblk0 of=/sdcard/mmcblk0_start bs=4096 count=1
B) copy /sdcard/mmcblk0_start to your PC
Sent from my Iconia A500 using Tapatalk 2

blackthund3r said:
Hmm. Well the tool has ADB already integrated. If you have a copy of the bct decryption utility (its download link is currently down AFAIK) then I would happily work with you in producing the updated version of the flash tool to support this. I can easily get dd etc for windows and script the production of the data. Assuming the SBK is correct we should even be able to read raw bytes from the flash and produce the mmcblk0_start from APX Mode.
Would this help us? http://git.chromium.org/gitweb/?p=chromiumos/third_party/cbootimage.git
Sent from my Iconia A500 using Tapatalk 2
Click to expand...
Click to collapse
Well, sp3dev posted a way here (for linux / cygwin):
http://forum.xda-developers.com/showthread.php?t=1514951
The openssl cmd is:
Code:
openssl aes-128-cbc -K $SBK -iv 0 -d -in $FTMP -out $FOUT
About the decryption, in short:
I believe .NET AES decryptor is this: http://msdn.microsoft.com/en-us/library/system.security.cryptography.aes.aspx
Set initialization vector to all zeroes, and the key:
If your SBK is "0x09A81E00 0xD4531301 0x3B1AF703 0x9A052103" it becomes 09A81E00D45313013B1AF7039A052103.
Haven't tried the .NET way yet. But it works when the ouptut isn't just some random crap, say I dunno: 0xFD0 - 0xFDF should be all zeroes for instance?

Skrilax_CZ said:
Well, sp3dev posted a way here (for linux / cygwin):
http://forum.xda-developers.com/showthread.php?t=1514951
The openssl cmd is:
Code:
openssl aes-128-cbc -K $SBK -iv 0 -d -in $FTMP -out $FOUT
About the decryption, in short:
I believe .NET AES decryptor is this: http://msdn.microsoft.com/en-us/library/system.security.cryptography.aes.aspx
Set initialization vector to all zeroes, and the key:
If your SBK is "0x09A81E00 0xD4531301 0x3B1AF703 0x9A052103" it becomes 09A81E00D45313013B1AF7039A052103.
Haven't tried the .NET way yet. But it works when the ouptut isn't just some random crap, say I dunno: 0xFD0 - 0xFDF should be all zeroes for instance?
Click to expand...
Click to collapse
Aha! That's the openssl command I was thinking of. I'll look into .Net cryptography and see if I can write a function for it but it might be easier to just script the Unix tools as-is. I'll play with it now and get back to you on it
EDIT: I get a bad decryption error with my SBK / openssl / mmcblk0_start
Sent from my Iconia A500 using Tapatalk 2

blackthund3r said:
EDIT: I get a bad decryption error with my SBK / openssl / mmcblk0_start
Click to expand...
Click to collapse
Your mmcblk0_start is probably not containing an even number of blocks, AES 128 work on blocks of 16 bytes (128 bits).
So if the size of the file is not a multiple of 16 bytes the decryption will fail in the end.
Decrypting like that will technically give an incorrect result as not all data is encrypted.
In the BCT the first block (of 16 bytes) is a hash for the following 4064 bytes, and since we are using cipher block chaining including this in the decryption will mess up the decryption of the second block (which should have been the first block). But in this case we probably do not really care about the 2nd block.

PIT file method to revive your phone from a MMC_CAP_ERASE brick

Summary: in many cases this allows to revive (not really repair!) your N7000 (and some other samsung devices) after an emmc brick and should be relatively easy to follow. The method uses PIT files.
Note: This thread is rather old now (2012).
Please note that the emmc brick bug should be triggered only by a combination of a few conditions:
an old samsung ics kernel (from Ice Cream Sandwich versions 4.0–4.0.4, see wikipedia)
wiping or formatting by custom software, usually an old cwm of that time (especially an often used file called CWM.ZIP)
most important: an older emmc chip (or firmware).
All affected devices should be covered by the thread, some got patched PIT files, some could not be supported (see below).
Some insights here (as part of this thread)
after the problem had been analyzed by the community and Samsung, all those parts got fixed to prevent the problem for the future.
In case only one of the conditions is not true, the brick should not happen.
So if you have more current hardware (somewhat newer than note1) or current software (newer than ics), the bug will not happen.
So, as an example, S3 or Note 3 should be safe because both hardware and software are fixed.
Especially, all current roms or recoveries should be safe.
If you have a brick nowadays, it's very very unlikely it's an emmc brick. Instead you probably have some other problem.
So in most cases, don't look here, unless you are using rather old devices and rather old software.
Note: this is a living post, it will change while progressing. If you want to refer to it, please make a reference to the whole thread (this link).
Don't directly link to the attached files, as they will go away, when I update the files or their names from time to time.
Note: You should generally post in the correct thread (please look in my signature)
Note: I will answer PMs which are of general interest relating to one of my topics (please look in my signature) publicly in the thread (quoting your interesting paragraphs).
It's sad the following has to be said in such big letters, but there are still people not reading anything and therefore failing seriously:
Please, please, please:
Read this multiple times and try to understand all aspects before using anything of this thread.
If you have questions, read it again!
If you have questions, read it again!
...
If you have questions, read it again!
If you have questions, read it again!
If you don't know exactly what you are doing, you may HARM your device seriously or even DAMAGE it for all times (e.g. meaning motherboard has to be changed with >150EUR).
If you are a noob, then please ask someone with more knowledge to assist you, but ignore those blowhards/bigmouths which will probably do more harm to your phone than you would.
If you have questions, read first post again and again and also read the whole thread!
Most questions are asked several in this thread and are already answered in this first post. Others are answered later in the thread. You should also use the search function before asking something a second time.
Please don't waste my time with superfluous questions already answered in the thread only because you are too lazy to search for it!
It took much much time to write this down and describe most aspects. So, please take a similar amount of YOUR time to read it carefully.
Certainly, my descriptions will not be perfect, so if you are SURE your question is NOT answered HERE, then you are welcome to ask in the thread. But don't expect a quick answer. I am usually very busy with other things and I am doing this only to help other people. I definitely don't generate any profit from this...
Please don't quote this post (in it's entirety), because it's very long and will disturbe all other readers. Instead post without a quote or extract some of the text you are referring to. I think this should be common sense...
You can find the former first post of this thread at post #9...I switched it with this continuously updated post, which I hope is more understandable for the users of this method.
-------------------- manual method and tools for using adb
I think forest1971's thread is better for the description of and questions about the manual method which I used first to revive my own phone. Looks like we developed the same thing at the same time. I started this thread before I read his (I also wasn't an active user of xda before).
Along the way our threads started to be companions to each other.
forest1971's thread has some useful tools for using in adb. Some of these will be useful for procedures described here.
But please read on, because I think the PIT file method is easier for most users with kind of standard emmc bricks.
It's less error prone, because you don't have to calculate the numbers yourself (my pit generator script did it already).
However, the manual method can do more, especially if you have special cases.
-------------------- find begin and end of bricked area
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You should write down two numbers:
* where emmc_find_brick_start.zip freezes -> BRICK_START
* where emmc_find_brick_end.zip freezes -> BRICK_END
I have reports, that the stock recovery doesn't show the output of the scanners, so you should probably install a custom recovery first (see forrest1971 's thread).
-------------------- patched pit files
I finally hacked a perl script, which generates a set of PIT files for me.
But because I cannot test the PITs on my phone (because I need it):
==> NO GUARANTY <==
Say you have a situation like this:
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
^ ^
| |
BRICK_START BRICK_END
(? = bad blocks)
The repartitioning should leave a hole in the partition table around the bricked area.
Therefore the bricked area will lie fallow (i.e. not accessed) after the repartitioning.
Code:
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
(? = bad blocks)
The calculation is done like the following (Example: N7000_16GB) with X being the size of the HOLE:
Code:
16GB original (Q1_20110914_16GB.pit)
FACTORYFS 548864 ->Fo 1744896 ->Fs
DATAFS 2293760 ->Do 4194304 ->Ds
UMS 6488064 ->Uo 23232512 ->Us
HIDDEN 29720576 ->Ho 1048576 ->Hs
16GB MMC_CAP_ERASE patched
FACTORYFS FoX = Fo+X unchanged
DATAFS DoX = Do+X unchanged
UMS UoX = Uo+X UsX = Us-X
HIDDEN unchanged unchanged
The PITs are named like that:
N7000_16GB_Q1_20110914--patched--brick-between-281-and-2428-MB--FACTORYFS-moved-by-2048-MiB
This PIT is for the N7000 with 16GB and derived from the file Q1_20110914.pit.
Here, the HOLE is from 281 MB up to 2428 MB (MB = 1000000 bytes) which is 2147 MB or 2048 MiB (MiB = 1024*1024 bytes) in size.
So the following relations have to match: BRICK_START >= 281 MB and BRICK_END <= 2428 MB
Note that these numbers are rounded, so if your brick lies exactly on this border, it is possible that your aprtitions are not brick free after the repartitioning.
So to be sure this would be safer: BRICK_START > 281 MB and BRICK_END < 2428 MB
In the example all partitions from FACTORYFS up to the "big" partition (here UMS) have their beginning moved by 2048 MiB.
The "big" partition is shrinked by the same amount, so it ends at the same block as before the repartitioning.
Therefore the following partitions (only HIDDEN in this case) remain unchanged.
All partitions before the first moved partition (FACTORYFS) remain also unchanged.
I recently added more starting partitions for the brick (XXX-moved-by-...).
As a rule, all partitions from this starting partition up to the "big" partition are moved by the size of the HOLE.
All partitions in front of the starting partition and all partitions after the "big" partitions remain unchanged.
Code:
case FACTORYFS-moved-by-...
before: ...-|-FAC?OR??S-|??ATAFS-|-UMS------------------------------------|...
after: ...-| ? ?? ??|-FACTORYFS-|-DATAFS-|-UMS---------------------|...
\ /
------+-----
|
HOLE
case DATAFS-moved-by-...
before: ...-|-FACTORYFS-|D??T?FS-|-UMS------------------------------------|...
after: ...-|-FACTORYFS-| ?? ?|-DATAFS-|-UMS------------------------------|...
\ /
-+-
|
HOLE
(? = bad blocks)
The PIT file will repartition the phone automatically when flashed using Odin, but the moved partitions will not be formatted after that.
If you flash a partition in Odin, you will also put a valid file system on this partition(because the partition image also contains the file system).
For all other partitions, you have to format those partitions, before you can use them.
At least the data partition should be formatted
The revived phone does in nearly no user noticeable way differ from a stock phone afterwards.
You just have a smaller internal sd (called "big" partition above) and you cannot flash a stock pit file again (this would revert the phone to the bricked state).
ATTENTION: different recoveries and ROMs mount external and internal sdcard on varying directories.
I also had the following problem:
I couldn't format my internal sdcard with the cm9 recovery. I think it's too big for the mkfs.vfat tool of current cm9. So I installed another recovery, formatted the internal sd (I thought).
This erased all my current backups and downloads, because in reality it was my external sd. Fortunately I had a backup of the external sdcard from before rescuing my phone.
So, you may want to create a backup of your external sdcard first.
Then double check which is your internal sdcard (the UMS partition) and which is your external sdcard.
Or you could remove the external sd completely. But think about when to remove it, because you might need it for some files (e.g. to use the emmc partition scanner).
-------------------- backup
before messing with the partition table, everyone should make backups of all partitions that can be accessed.
-------------------- efs backup
The most important backup is the efs partition, which very crucial, it includes your IMEI number, bluetooth MAC etc., and without this individual information, your phone cannot be used as a phone again.
For most supported phones, you can do this via adb:
Code:
dd if=/dev/block/mmcblk0p1 of=/mnt/sdcard/efs.img
please look at forrest1971's thread for details about using adb.
If your phone uses another partition number for efs, then use this instead of the "1" in mmcblk0p1.
Perhaps you have to mount your sdcard first, to be able to save it there.
Then you should copy the backup to your PC (the recovery should have the option to mount usb).
-------------------- backup files from internal sd before repartitioning
the repartitioning will clear all data in the affected partitions, so all data in your big partition (internal sd etc.) will be lost.
You can try to backup your data, if the partition is accessible. The different methods below may have different success, depending which parts of your phone are usable.
* you can use aroma file manager, which is a full fledged gui file manager which starts standalone by being flashed in CWM. So it should be completely independent (sorry, I could not test it for this kind of backup myself).
For the following possibilities you should first ensure, you have a working recovery with working adb support.
Mount your external sd in recovery (which might be /emmc or /sdcard, please check), to be able to copy files.
* you can use QtAdb to copy files to your PC:
* you can use adb pull to copy any files or directory tree to your PC, e.g.:
adb pull /emmc/. emmc
* you can use tar from adb to archive files to a file on sdcard:
adb shell tar cvjf /sdcard/emmc.tar.bz2 /emmc/.
* you can use a copy command in adb shell to copy files to a folder in sdcard:
adb shell cp -ra /emmc/. /sdcard/emmc.backup
Note: you will loose file attributes and owner information if emmc is formatted with ext2/ext3/ext4, because vfat cannot handle these.
This may matter for system and some app related files.
-------------------- recommended procedures for "standard" cases
"standard" in this sense are pits that only affect FACTORYFS, DATA, CACHE or internal SD (UMS/USERDATA etc.).
All other partitions need special considerations and are not handled in this section!
Note these are from theory only. My phone is running now and I don't want to brick it again, only for testing the procedure.
Therefore the procedure is *NOT* tested (by me) and may contain problems which I didn't expect!
So be "careful with that axe, Eugene!"
Note, there are always multiple ways to reinstall the phone.
phase "find brick"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* flash emmc_find_brick_start.zip, note where it freezes -> BRICK_START
* flash emmc_find_brick_end.zip, note where it freezes -> BRICK_END
phase "flash pit and ROM"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a known good ROM via Odin (especially not a faulty stock ICS ROMs)
phase "check partitions"
* reboot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* check the partitions (see section "checking all partitions" below)
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format cache
* format data
* format internal SD (if it fails read below)
phase "start ROM"
...
After formatting or wiping data you can probably also boot into the ROM and format the internal sd from there (again: keep the external sd removed, to not format the external sd instead of the internal sd unintentionally).
You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
I would recommend a cyanogen ROM though, if you can live with some features missing from stock ROM.
Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).
It may be easier to take a custom ROM with a better custom recovery, but it has to be flashable via Odin (tar file).
A second method is via recovery using a custom kernel:
phase "find brick" like above
phase "flash pit and kernel"
* (re)boot to download mode (hold Vol-Down + Home + Power until you arrive there [20-30 seconds], then Vol-Up)
* flash a patched PIT in Odin
* flash a custom kernel with a good recovery (e.g. cm9 safe kernel) via Odin (which will increment the flash counter! -> yellow triangle -> warranty lost until you reset the counter)
phase "check partitions" like above
phase "restore partitions"
* switch off the phone (something like "power off" in recovery)
* remove external sdcard (to be sure not to format it afterwards)
* boot into recovery (hold Vol-Up + Home + Power until you arrive there [20-30 seconds])
* format system
* format cache
* format data
* format internal SD
phase "install ROM"
* install the zip of the ROM
phase "start ROM"
...
So you generally install the ROM like usual, the only difference is to restore all the partitions moved by the repartitioning with the patched PIT.
This is neccessary because all changed/moved partitions don't have a valid file system or content after the repartitioning.
For some partitions this can be done by a simple format (cache, data, internal sd).
Others need true contents (e.g. system, kernel, recovery can be restored by installing a rom/kernel/recovery).
In other cases (non-standard situations) you need to restore a backup (efs, if you have one) or some generic contents (param, sbl1/2).
EFS is the most critical one, because it contains information unique to your own phone. Also see the efs section in this post.
I assume SBL1/2 are needed by the boot process (secondary boot loader), but I never tested this. I don't even know where to get these boot loaders (which probably have to be installed with the PIT via odin, because they are involved in the boot process).
You may find other important information in the thread, please read it completely before asking the same things over and over again.
There may also be useful information and experiences from users.
I try to incorporate useful information in the thread starter, but my time is often very limited.
Also, some information may not look valuable enough for me to integrate it, but it may be valuable for you.
...suggestions or corrections welcome!...
-------------------- checking all partitions for bricked blocks
After repartitioning some partitions may still have bricked blocks inside (because of moving brick or choosing a wrong pit etc.).
Bricked blocks in any partition will lead to random freezes when these blocks are accessed in any way.
So you should check all your partitions after repartitioning to be sure.
With both methods below, you can check the partitions even before formatting any of them.
You can do this with my emmc partition scanner, which is flashed via recovery (this doesn't really flash, it only uses the scripting of the updater mechanism of the recovery, also called edify script).
You can also do it manual via dd commands in adb, but this is much slower.
Use commands like this, using the partition block device in the if=... argument:
adb shell dd if=/dev/block/mmcblk0p1 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p2 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p3 of=/dev/null
...
adb shell dd if=/dev/block/mmcblk0p9 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p10 of=/dev/null
adb shell dd if=/dev/block/mmcblk0p11 of=/dev/null
etc.
If any of these freeze the phone (or reboots the phone or doesn't come to an end even after an hour), you probably (still) have bricked blocks inside the according partition.
-------------------- pit.str for DataWorkshop
For those who want to edit their own patched pit file, I made a structure definition file (pit.str) for an open source multi-platform tool (java) called DataWorkshop, which allows looking at binary data in structured form.
The tool is not very comfortable when it comes to copy/paste etc. but you can edit the values (just put the cursor at the correct digit before typing the number).
Please ask (PM), if you are interested in this.
-------------------- PITs for other devices
Because Samsung doesn't fix their kernels (thinking their software doesn't have the problem) there is a growing number of affected devices.
Look at the attached files, which devices are currently available.
If pits for your device aren't available yet, please send me a stock PIT and tell me which partitions are bricked (or BRICK_START and BRICK_END, and if you know, which partitions are usually bricked for your device).
I'll look what I can do...
I will add comments for special cases below.
-------------------- device i9250 - experimental PITs
I added i9250 PITs which are very experimental, because I don't know how some details of it's stock PIT affect the result. May be it breaks everything, so beware.
I added this especially for Shanava, who said to be able to recover even from a hard brick.
His brick is in userdata.
So this will probably revive the internal sd (is it userdata?) and reinstalling a ROM shouldn't be necessary, only formatting userdata.
But I also added system and cache as possible starting partition for the brick, then you have to install a ROM and format cache accordingly.
-------------------- devices not supported/supportable
i9000, i9300 (and similar):
These devices have a different PIT structure.
The structure for each partition entry doesn't include an offset, so I don't know a way to define a gap for skipping the bricked blocks.
Inserting an unused partition changes the partition numbers after it, which shouldn't work.
-------------------- FOR-EXPERTS-ONLY packages
DO NOT USE one of the packages with "FOR-EXPERTS-ONLY" in it's name unless you are REALLY REALLY sure how to handle/restore/initialize all the affected partitions, often meaning you were involved in the discussion leading to these files or you read this VERY carefully.
These packages contain files to be used by those who have special problems and want to take the risk to try them.
They are only documented by the corresponding discussion (somewhere in this thread).
note: this is a living post, it changes while progressing. If you want to refer to it, please make a reference to the whole thread, beginning at the first post.
Don't directly link to the attached files, as they will go away, when I update the files and their names from time to time.

Let's hear it....

ok I wait. ..

Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S

RavenY2K3 said:
Forgive me for being skeptical but, Join date Feb 2011, and this is only your second and very open ended post?...... Hmmmm :S
Click to expand...
Click to collapse
That's why I said "Let's hear it....". Like, I am very curious because I noticed the same thing you did. I hate doubting people, but sometimes you have to.

hg42 said:
go straight ahead to the final solution (see next post)...
Click to expand...
Click to collapse
andreww88 said:
Let's hear it....
Click to expand...
Click to collapse
errr

I very much doubt it. But lets hear your version of "The curious case of Benjamin eMMC bug"

panyan said:
errr
Click to expand...
Click to collapse
Why did you quote me?

Repartitioning around the bad blocks
This is the former first post of this thread...I switched it with a continuously updated version, which is more understandable for ths users of my pit method.
-----------------------snip -------------------------------------
Hi everyone, especially those with an ICS brick,
last week I jumped straight into a MMC_CAP_ERASE brick.
Sadly, I knew very well what not to do with a LPY kernel on my phone (wiping etc.).
But one weak moment (touching "wipe data/factory reset" in CWM), and then a moment later a flash (pun!) going through my brain, telling me "wow, now the phone will be bricked, right?".
Well I rebooted the phone and thought to be a lucky man, because the system booted correctly.
But after about a minute the SGN started to get FCs in android.*.acore and Google Play etc. I looked with a root file manager and found that the /data partition wasn't mounted.
So I got the BRICK!
After some days of analysing and thinking about the situation, I found a way out of the dilemma. I think, I will not bother you with all the details of these days, but go straight ahead to the final solution...
(this was planned as the second post in the thread, but the dynamic community inserted many post in between, so I added it here sorry, my fault)
---- cut ----
This is a rewrite in english of my report at a german forum:
ICS Brick, Samsung Galaxy Note N7000, Erfahrungsbericht
www.handy-faq.de/.../249283-ics_brick_samsung_galaxy_note_n7000_erfahrungsbericht.html
My brick created bad blocks in the phone's flash memory.
I got I/O-Errors when attempting to read or write those blocks.
My SGN was still able to boot into recovery and all kinds of kernels/recovery.
Odin was able to flash boot loaders, kernels, modems and CSCs.
But flashing a factory_fs stopped at the very beginning.
I found, that any access to some blocks inside /system and also ANY access to /data left an inaccessible phone and I had to restart it.
For all of the following I needed access to some tools (mainly e2fsck and parted).
As I had completely deleted my system partition before (formatting it), I had no single useful tool around, so the recovery had to provide any of those.
The stock recovery e.g. of KL8 engineering kernel doesn't provide such tools, so I had to find a better one first.
I found all this packed in the Thor kernel, but would not recommend it, because it's closed source.
You may use the tools from forrest1971, see below under "manual method".
One of my attempts to get around those bad blocks, was to create a bad blocks list which can be used by the ext4 file system, I tried this command:
e2fsck -c /dev/block/mmcblk0p9 (which is the /system partition)
Click to expand...
Click to collapse
This failed, because to find out which blocks are bad, e2fsck tries to read them and gets stuck by doing so.
I could have created a list manually, but because the data partition was corrupted starting at it's first block, this bad blocks list wouldn't work here anyway.
At the end, my solution was to recreate the partition scheme, leaving a big hole at the space where /system (893MB) and /data (2147MB) resided before:
Code:
before: - ...-|-FAC?ORYFS-|??ATAFS-|-UMS------------------------------------|...
after: + ...-| ? ?? |-FACTORYFS-|-DATAFS-|-UMS---------------|...
(? = bad blocks, + working, - = not working still bad blocks inside)
In order to not access those bad blocks, I could not move these partitions, but instead I had to delete them first and recreate them at another place afterwards.
So I needed a backup of them first (fortunately I always have 7 Titanium backup levels around).
Here is a log of my steps (but see below in the blue sections for other probably easier procedures):
Code:
I managed to access the device via [I]adb shell[/I]...which is another story for itself...
Then I started [I]parted[/I] with the flash device:
~ # parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
print
As a greeting I got some error messages about the GPT layout, which parted wanted to fix:
[QUOTE]Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? f
f
f
Warning: Not all of the space available to /dev/block/mmcblk0 appears to be
used, you can fix the GPT to use all of the space (an extra 2048 blocks) or
continue with the current setting?
Fix/Ignore? f
f
f
this was the partition scheme before implementing the workaround:
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 281MB 1174MB 893MB FACTORYFS
10 1174MB 3322MB 2147MB ext4 DATAFS
11 3322MB 15.2GB 11.9GB fat32 UMS
12 15.2GB 15.8GB 537MB ext4 HIDDEN
then I deleted the partitions 9=FACTORYFS=/system, 10=DATAFS=/data and 11=UMS=/sdcard(internal) and recreated them starting at the former start of the internal sdcard partition (11) leaving the former space of the /system and /data partitions unused:
(parted) rm 11
(parted) rm 10
(parted) rm 9
(parted) mkpartfs primary ext2 3500 4400
(parted) mkpartfs primary ext2 4400 7000
(parted) mkpartfs primary fat32 7000 15.2G
(parted) name 9 FACTORYFS
(parted) name 10 DATAFS
(parted) name 11 UMS
now I upgraded both new ext2 partitions to ext4:
~ # tune2fs -j /dev/block/mmcblk0p9
tune2fs -j /dev/block/mmcblk0p9
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # tune2fs -j /dev/block/mmcblk0p10
tune2fs -j /dev/block/mmcblk0p10
tune2fs 1.41.11 (14-Mar-2010)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.
~ # e2fsck -fDp /dev/block/mmcblk0p9
e2fsck -fDp /dev/block/mmcblk0p9
/dev/block/mmcblk0p9: 11/439776 files (0.0% non-contiguous), 71701/878907 blocks
~ # e2fsck -fDp /dev/block/mmcblk0p10
e2fsck -fDp /dev/block/mmcblk0p10
/dev/block/mmcblk0p10: 11/317440 files (9.1% non-contiguous), 26386/634765 blocks
and this is the final partition layout:
~ # parted /dev/block/mmcblk0 print
parted /dev/block/mmcblk0 print
Model: MMC VYL00M (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 210MB ext4 CACHE
8 264MB 281MB 16.8MB MODEM
9 3500MB 4400MB 900MB ext3 FACTORYFS
10 4400MB 7000MB 2600MB ext3 DATAFS
11 7000MB 15.2GB 8217MB fat32 UMS msftres
12 15.2GB 15.8GB 537MB ext4 HIDDEN
This configuration works so far (one complete day now).
I can install firmwares and restore backups via recoveries.
Also flashing via Odin should work (not tried yet).
I currently can only imagine one standard procedure which will not work, that is creating a new partition scheme, e.g. via Odin (PIT file) or may be a CWM script.
I think/hope this will not occur too often...

-- naturally, it's much faster to insert those short messages than rewriting a long german post in english.
Next time I should write the main text prior to posting anything, I think...
sorry...

WoooooooOOOOOOoooooooowwwww!!!!
YeeeeeeEEEEEEaaaaaAAAAAaaaahhhhhh!!!!!!
You are the man, bro.

man has a few posts but are worth a lot. .. thanks for share with us

And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Is the damage so serious? Is it physical??

Interesting Read, this should be of a great help to those bricked without warranty.

straycat said:
And... I just wonder it couldn't be possible to recreate the whole partition table with an appropiate tool like GNU/Linux "parted" or so?
Click to expand...
Click to collapse
you *can* indeed try to recreate the standard partition scheme (I did it very early with a PIT file in Odin and also tried formatting those partions etc.), but this doesn't work because *accessing* those blocks in any way is the *real* problem.
Is the damage so serious? Is it physical??
Click to expand...
Click to collapse
yes, you can't even fix the bad blocks with the usual JTAG equipment.
I was told by a technician from a good repair center that a fix could eventually be possible by directly reprogramming the flash chip in some way (JTAG again), but no one tried yet, because this would cause several hours of work...
usually they swap the whole motherboard instead (which is >250EUR)

Thanks, hg42.
I really apreciate your efforts and to share with us.
I'm not a superbriked note owner but I follow with great interest those posts.
Again, thank you, man.

Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Thanks anyway for your efforts!
Sent from my GT-N7000 using Tapatalk 2

Zamboney said:
Wow man, that seemed really simple and straight forward. Next week well learn how to copy a file in Android, now that will be much trickier...
Click to expand...
Click to collapse
LOL, you're right, at the end I also thought, that's really simple
but, at least...I had several problems to solve before getting adb up and running properly with root permissions and having the necessary tools at hand (inside adb).
I think this was mainly because I wiped my /system before.
But, it's easy to be wise after the event.

hmm, I tried to export this partition scheme to a PIT file (using heimdall-frontend), but I got a file that is exactly equal to the one I flashed last via Odin, which was Q1_20110914_16GB.pit.
So I assume the PIT file is one way only?
A PIT file would probably allow even unexperienced users to unbrick their phones.

This is the same method here:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
Although your post I found easier to read.

[GUIDE] Rooting s3 mini from Linux with heimdall

Hey.
Just wanted to share my rooting experience.
My girlfriend just bought her S3 mini few days ago - and because Samsung Dive sucks balls (can be erased by doing factory reset), I felt the need to root, so cerberus anti-theft (http://cerberusapp.com, try it out, its awesome) could be written to /system (which requires root & survives factory resets).
Because I use Ubuntu Linux, I couldn't use Odin. Also from what I've read Odin reflashes whole phone, including bootloaders, recovery images and so on.
Because I've had XXALJL build originally in my phone, I've used this uk rooted rom as my rooting source.
Also, because the baseband is identical, I only flashed the system image, where /system/bin/su resides.
If you have a different baseband than your rooted image, this guide will not help you and you probably need to either: a) use odin to reflash everything. b) use your brain to figure your what to flash and where.
So here we go!
Flashing
I'm using ubuntu 12.10, 64 bit:
Code:
[email protected]:~/Downloads/rooted# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.10
DISTRIB_CODENAME=quantal
DISTRIB_DESCRIPTION="Ubuntu 12.10"
Code:
[email protected]:~/Downloads/rooted# uname -a
Linux cyrix 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
The only thing you should be concerned about is whether you're using 32 or 64 bit OS.
I've used heimdall 1.3.1, because 1.3.2 has issues and I didn't want to risk. Perhaps 1.3.2 or 1.4-RC1 would work just fine too, but I've used 1.3.1 and that did work for me.
Get heimdall 1.3.1 from http://www.glassechidna.com.au/products/heimdall/ (choose 32 bit (i386) or 64 bit (x64) debian package appropriately). Install those. And lets get down to bussiness.
I RECOMMEND RUNNING ALL COMMANDS FROM ROOT USER
Some guides recommend rebooting your pc after heimdall install (it inserts some udev rules). I didn't do that (completely forgot), but do it, just to be on a safe side.
So first step is to determine what partition identifier does your system partition has. Put your device into download mode (power off. Then hold vol down + home + power & click vol up once).
After doing that, connect your usb cable to computer and run:
Code:
# heimdall detect
It should say:
Code:
Device detected
If it doesn't - none of the following commands will probably work.
Then - lets see what our PIT (partition information table? not sure about the acronym) looks like:
Code:
# heimdall print-pit
What we are looking for is system partition. Mine looked like this:
Code:
--- Entry #21 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 20
Partition Flags: 5 (R)
Unknown 1: 5
Partition Block Size: 524288
Partition Block Count: 2457600
Unknown 2: 0
Unknown 3: 0
Partition Name: SYSTEM
Filename: system.img
From this we can see that our partition identifier is 20.
So extract the downloaded .rar ROM file, then again, extract rooted.tar and go into that directory. And lets flash our system image (around 900mb).
If everything is fine it should look like this:
Code:
[email protected]:~/Downloads/rooted# heimdall flash --20 system.img
Heimdall v1.3.1, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...
Checking if protocol is initialised...
Protocol is not initialised.
Initialising protocol...
Handshaking with Loke...
Beginning session...
Session begun with device of type: 131072
Downloading device's PIT file...
PIT file download sucessful
Uploading SYSTEM
100%
SYSTEM upload successful
Ending session...
Rebooting device...
Re-attaching kernel driver...
Do not touch your PC while flashing. Do not move the phone. Do not fiddle with the cables. Hold your breath and wait. If all is fine, the phone should turn off itself. Wait until you get charging screen, then turn it back on.
You should have supersu installed. You can also install terminal emulator and try running su to make sure you have the root.
Congrats on having root!

Great tutorial! Thanks a lot, from a fellow Linux user!

Hi dudes,
I have mi SGS2 soft bricked and I'm trying to recover it.
I've already opened a post here.
The thing is that I have discovered Heimdall by chance.
Fed up with the errors from Odin I decided to try in Linux.
I think my System partition is missing.
Find attached my result for heimdall print-pit.
Hope you can help me.
Regards,
Mario.

thanks for remaind me about heimdall, that was long time since heard about this tool. :beer:

Thanks! (But should I backup something first?)
Thanks, exactly what I was looking for
One quick question: by rooting with Heimdall (on Linux), will I loose all my apps/accounts ? (It will take ages to recover them all..)
(also, where could I get updated as new Heimdall-friendly firmwares become available?)
Thank you again for your time.
arturaz said:
Hey.
Just wanted to share my rooting experience.
My girlfriend just bought her S3 mini few days ago - and because Samsung Dive sucks balls (can be erased by doing factory reset), I felt the need to root, so cerberus anti-theft (http://cerberusapp.com, try it out, its awesome) could be written to /system (which requires root & survives factory resets).
Because I use Ubuntu Linux, I couldn't use Odin. Also from what I've read Odin reflashes whole phone, including bootloaders, recovery images and so on.
Because I've had XXALJL build originally in my phone, I've used this uk rooted rom as my rooting source.
Also, because the baseband is identical, I only flashed the system image, where /system/bin/su resides.
If you have a different baseband than your rooted image, this guide will not help you and you probably need to either: a) use odin to reflash everything. b) use your brain to figure your what to flash and where.
So here we go!
Flashing
I'm using ubuntu 12.10, 64 bit:
Code:
[email protected]:~/Downloads/rooted# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.10
DISTRIB_CODENAME=quantal
DISTRIB_DESCRIPTION="Ubuntu 12.10"
Code:
[email protected]:~/Downloads/rooted# uname -a
Linux cyrix 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
The only thing you should be concerned about is whether you're using 32 or 64 bit OS.
I've used heimdall 1.3.1, because 1.3.2 has issues and I didn't want to risk. Perhaps 1.3.2 or 1.4-RC1 would work just fine too, but I've used 1.3.1 and that did work for me.
Get heimdall 1.3.1 from http://www.glassechidna.com.au/products/heimdall/ (choose 32 bit (i386) or 64 bit (x64) debian package appropriately). Install those. And lets get down to bussiness.
I RECOMMEND RUNNING ALL COMMANDS FROM ROOT USER
Some guides recommend rebooting your pc after heimdall install (it inserts some udev rules). I didn't do that (completely forgot), but do it, just to be on a safe side.
So first step is to determine what partition identifier does your system partition has. Put your device into download mode (power off. Then hold vol down + home + power & click vol up once).
After doing that, connect your usb cable to computer and run:
Code:
# heimdall detect
It should say:
Code:
Device detected
If it doesn't - none of the following commands will probably work.
Then - lets see what our PIT (partition information table? not sure about the acronym) looks like:
Code:
# heimdall print-pit
What we are looking for is system partition. Mine looked like this:
Code:
--- Entry #21 ---
Unused: No
Partition Type: 2 (EXT4)
Partition Identifier: 20
Partition Flags: 5 (R)
Unknown 1: 5
Partition Block Size: 524288
Partition Block Count: 2457600
Unknown 2: 0
Unknown 3: 0
Partition Name: SYSTEM
Filename: system.img
From this we can see that our partition identifier is 20.
So extract the downloaded .rar ROM file, then again, extract rooted.tar and go into that directory. And lets flash our system image (around 900mb).
If everything is fine it should look like this:
Code:
[email protected]:~/Downloads/rooted# heimdall flash --20 system.img
Heimdall v1.3.1, Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...
Checking if protocol is initialised...
Protocol is not initialised.
Initialising protocol...
Handshaking with Loke...
Beginning session...
Session begun with device of type: 131072
Downloading device's PIT file...
PIT file download sucessful
Uploading SYSTEM
100%
SYSTEM upload successful
Ending session...
Rebooting device...
Re-attaching kernel driver...
Do not touch your PC while flashing. Do not move the phone. Do not fiddle with the cables. Hold your breath and wait. If all is fine, the phone should turn off itself. Wait until you get charging screen, then turn it back on.
You should have supersu installed. You can also install terminal emulator and try running su to make sure you have the root.
Congrats on having root!
Click to expand...
Click to collapse

pminervini said:
Thanks, exactly what I was looking for
One quick question: by rooting with Heimdall (on Linux), will I loose all my apps/accounts ? (It will take ages to recover them all..)
(also, where could I get updated as new Heimdall-friendly firmwares become available?)
Thank you again for your time.
Click to expand...
Click to collapse
This only rewrites /system partition, while all your apps/accounts are stored in /data. So in theory you shouldn't lose things. However I do recommend you always backup your stuff with `adb backup` before doing this. You can never be too sure.
As for new firmwares - no idea. OTAs should probably work.

Thanks For the other Debian guys out there, I've just found out "adb" comes available for Sid ( packages debian org /sid/android-tools-adb -- there is a similar package in the Ubuntu repos) and requires MTP mode with USB debug on: bernaerts dyndns org /linux/245-ubuntu-precise-install-android-sdk
While the backup goes on (I'm doing "adb backup -apk -shared -all -f 08062013.ab", hope it's right), I'm looking for the right image file.
May this one fit? "Android 4.1.2 XXAMD3 official firmware"
www hotfile com /dl/209515302/bd1d1a3/I8190XXAMD3_I8190OXAAMD3_DBT.zip.html
UPDATE: no it's not, i should look for something fitting GT-I8190N; checking what I can do from OTA..
UPDATE 2: I've found this file: GT-I8190N-BTU-I8190NXXALL6-1356151513.rar ; I'm going to try to push its system.img with heimdall *crossed fingers*
Thank you again for all your help, you're awesome!
arturaz said:
This only rewrites /system partition, while all your apps/accounts are stored in /data. So in theory you shouldn't lose things. However I do recommend you always backup your stuff with `adb backup` before doing this. You can never be too sure.
As for new firmwares - no idea. OTAs should probably work.
Click to expand...
Click to collapse

After a weekend trying to revive the I8190N (at least it was raining..) I tried to sum up my problem with Heimdall here:
forum xda-developers com/showthread.php?t=2317198
pminervini said:
Thanks For the other Debian guys out there, I've just found out "adb" comes available for Sid ( packages debian org /sid/android-tools-adb -- there is a similar package in the Ubuntu repos) and requires MTP mode with USB debug on: bernaerts dyndns org /linux/245-ubuntu-precise-install-android-sdk
While the backup goes on (I'm doing "adb backup -apk -shared -all -f 08062013.ab", hope it's right), I'm looking for the right image file.
May this one fit? "Android 4.1.2 XXAMD3 official firmware"
www hotfile com /dl/209515302/bd1d1a3/I8190XXAMD3_I8190OXAAMD3_DBT.zip.html
UPDATE: no it's not, i should look for something fitting GT-I8190N; checking what I can do from OTA..
UPDATE 2: I've found this file: GT-I8190N-BTU-I8190NXXALL6-1356151513.rar ; I'm going to try to push its system.img with heimdall *crossed fingers*
Thank you again for all your help, you're awesome!
Click to expand...
Click to collapse

Is there any way to make Phone to original Samsung phone with heimdall? Unroot, Stockrecovery etc?

arturaz said:
Just wanted to share my rooting experience....
Click to expand...
Click to collapse
Thank you, arturaz!
Why did I waste so much of my valuable lifetime by trying to get Odin to work on XP/W7 in a VBox?
Gonna donate to Benjamin now. He really deserves a beer or two
BTW: heimdall can be found in the Debian testing branch now. Look out for "heimdall-flash" (Don't be confused by some "heimdal"-packages [only one 'L'], which are something completely different)

Hey I'm using Linux Mint 32bits, I wonder if I can use the ubuntu 32 version for the software Heimdall ? if so, which one ?
Thanks

I'm not sure I understand the question.

Hello,
lov8 said:
Hey I'm using Linux Mint 32bits, I wonder if I can use the ubuntu 32 version for the software Heimdall ?
Click to expand...
Click to collapse
because linux mint and fork ubuntu I would say yes
lov8 said:
if so, which one ?
Click to expand...
Click to collapse
????

Fred6681 said:
Hello,
????
Click to expand...
Click to collapse
Ah! I have the version 1.4 RC1 from the Linux mint repository. I hope this version is stable enough. I will give it a try in a few days .. :-/

Alternatively you can root your phone by flashing a custom recovery using heimdall, then going in recovery mode and installing supersu.
Tested with heimdall 1.40 and TWRP custom recovery, worked fine.
You have just to pay attention and find the right partition id for flashing "recovery.img".

Why no solution to "Device not detected" ?!
Im using Ubuntu 13.10 64, the S3 Mini is in download mode but not seen by Heimdall... any solutions?
Thanks

ateap0tist said:
Why no solution to "Device not detected" ?!
Im using Ubuntu 13.10 64, the S3 Mini is in download mode but not seen by Heimdall... any solutions?
Thanks
Click to expand...
Click to collapse
Which version of heimdall are you using?

Clostry said:
Which version of heimdall are you using?
Click to expand...
Click to collapse
Heimdall v. 1.4

Can you post the output of this commands? With phone in download mode attached ofc.
Code:
lsusb
heimdall detect --usb-log-level debug

heimdall tar gz error
When I try to load the system.img file (from cm10.2_golden.maclaw.20140118.ODIN_TWRP.tar.md5) from heimdall, before beginning to flash, I get the following error: Tar header contained an invalid file size.
I tried to load the uncopressed file too, then the file cm10.2_golden.maclaw.20140119.zip not for odin and I get the same error, what am I doing of wrong?
Thanks

[Q] Help! Screwed up my TPT!

Well, I was all happy to have rooted. Installed Titanium and when going to remove Lenovo system apps (bloatware), the window had all the boxes checked. So I unchecked what I didn't want and clicked go. Guess what, I uninstalled everything, damn. So now, I turn off the tablet, go into recovery mode to factory restore, cleared cache, now all I get is the never ending Lenovo boot logo. Anyone? How can I restore back using the external storage option in the recovery menu. I have a ROW. Thanks.

you do have a backup in CWM right? (before messing around you always make a backup)
did you try to restore?
If you do not have a backup here is mine(ROW ICS):
http://we.tl/Nb9qAKSlXm
The link is deleted automatically on feb 9.
It should work just fine.
If not then you can try using Nvflash. I can provide images of partitions that you need..

berbecverde said:
you do have a backup in CWM right? (before messing around you always make a backup)
did you try to restore?
If you do not have a backup here is mine(ROW ICS):
http://we.tl/Nb9qAKSlXm
The link is deleted automatically on feb 9.
It should work just fine.
If not then you can try using Nvflash. I can provide images of partitions that you need..
Click to expand...
Click to collapse
Thanks for your help.
No, never got to install CWM. I was under stock ICS rooted when all of this happened. What's next?

Anyone?

well i think that you can not install cwm if your tpt is not booting.
But you could try to see if adb is working.
If not you can use nvflash to restore your partitions.
Since you have the ROW version of the tablet your bootloader should be unlocked, and allow you to use nvflash to restore the partitions to your tpt.
if you need the partitions just let me know.
http://forum.xda-developers.com/showthread.php?t=1745450&highlight=nvflash

berbecverde said:
well i think that you can not install cwm if your tpt is not booting.
But you could try to see if adb is working.
If not you can use nvflash to restore your partitions.
Since you have the ROW version of the tablet your bootloader should be unlocked, and allow you to use nvflash to restore the partitions to your tpt.
if you need the partitions just let me know.
http://forum.xda-developers.com/showthread.php?t=1745450&highlight=nvflash
Click to expand...
Click to collapse
I do need the partitions.
Thanks very much for your help and patience.

did you try to see if nvflash is working?
first you should try and see if it works.
i was thinking that if you use nvflash to flash only the recovery partition then you would have cwm recovery on the tpt and the use it to restore a backup.
i am going to upload the partitions soon.(about 1 hour max).:good:

here is the recovery image.
try it an see what happens.
these are the rest of the image files(2-10):
http://we.tl/cQQ0G2s2RD
NOTE: the 04.ebt.img is the file provided in the nvflash thread not my backup.use it with nvflash like descibed in the thread.
more image files (11-16):
http://we.tl/7vJ49hs0id.
image no. 15 is not there because it is the user data(sdcard).
2. BCT StartSector=0 NumSectors=1024 Boot Configuration Table
3. PT StartSector=1024 NumSectors=512 Partition Table
4. EBT StartSector=1536 NumSectors=1536 Bootloader Table
5. GP1 StartSector=3072 NumSectors=512 ?
6. SOS StartSector=3584 NumSectors=1536 Recovery
7. LNX StartSector=5120 NumSectors=2048 Kernel
8. APP StartSector=7168 NumSectors=196608 Applications in System/ROM
9. CAC StartSector=203776 NumSectors=230400 CAChe
10. MSC StartSector=434176 NumSectors=512 ?
11. PIA StartSector=434688 NumSectors=131072 Pre-Install APK
12. SEC StartSector=565760 NumSectors=5120 ?
13. USP StartSector=570880 NumSectors=35840 ?
14. PDA StartSector=606720 NumSectors=5120 ?
15. UDA StartSector=611840 NumSectors=3234816 User Data (/sdcard)
16. GPT StartSector=3846656 NumSectors=512 ?

berbecverde said:
here is the recovery image.
try it an see what happens.
these are the rest of the image files(2-10):
http://we.tl/cQQ0G2s2RD
NOTE: the 04.ebt.img is the file provided in the nvflash thread not my backup.use it with nvflash like descibed in the thread.
more image files (11-16):
http://we.tl/7vJ49hs0id.
image no. 15 is not there because it is the user data(sdcard).
2. BCT StartSector=0 NumSectors=1024 Boot Configuration Table
3. PT StartSector=1024 NumSectors=512 Partition Table
4. EBT StartSector=1536 NumSectors=1536 Bootloader Table
5. GP1 StartSector=3072 NumSectors=512 ?
6. SOS StartSector=3584 NumSectors=1536 Recovery
7. LNX StartSector=5120 NumSectors=2048 Kernel
8. APP StartSector=7168 NumSectors=196608 Applications in System/ROM
9. CAC StartSector=203776 NumSectors=230400 CAChe
10. MSC StartSector=434176 NumSectors=512 ?
11. PIA StartSector=434688 NumSectors=131072 Pre-Install APK
12. SEC StartSector=565760 NumSectors=5120 ?
13. USP StartSector=570880 NumSectors=35840 ?
14. PDA StartSector=606720 NumSectors=5120 ?
15. UDA StartSector=611840 NumSectors=3234816 User Data (/sdcard)
16. GPT StartSector=3846656 NumSectors=512 ?
Click to expand...
Click to collapse
Great, thanks. I'll give it a shot.

All files are downloaded. Thanks again.
Can't understand the instructions here: http://forum.xda-developers.com/showthread.php?t=1745450
Tablet is seen and installed in device manager (apx) (red think light on) and bootloader seems unlocked, what now?
Detailed instructions ? On the page you sent me it seems that the instructions posted are not pertaining to my situation.

well...
using nvflash you can restore all the partitions on the tablet.
first you must start nvflash, the instructions are quite staight.
" nvflash -w --bl 04.EBT.img --go "
after this you should be able to continue to the next step restore the recovery partition.
(if the 04.ebt.img file is in the same folder as the nvflash, if not you must specify the path, but it is easyer to copy it to the same folder)
you must use the download command
in your case to restore the recovery partition you should use :
" nvflash -r --download 6 6.sos.img "
this will download from the computer the 6.sos.img file to partition no.6 on the tablet, in our case no.6 is the recovery.
after that you should have the CWM recovery, because when i made the backup i had the CWM recovery.
and then try to restore a backup.
another option is to restore the partition that contains the files you deleted.(or all the partitions i provided.)
but that is more complicated since i do not know what partition are we talking about.

berbecverde said:
well...
using nvflash you can restore all the partitions on the tablet.
first you must start nvflash, the instructions are quite staight.
" nvflash -w --bl 04.EBT.img --go "
after this you should be able to continue to the next step restore the recovery partition.
(if the 04.ebt.img file is in the same folder as the nvflash, if not you must specify the path, but it is easyer to copy it to the same folder)
you must use the download command
in your case to restore the recovery partition you should use :
" nvflash -r --download 6 6.sos.img "
this will download from the computer the 6.sos.img file to partition no.6 on the tablet, in our case no.6 is the recovery.
after that you should have the CWM recovery, because when i made the backup i had the CWM recovery.
and then try to restore a backup.
another option is to restore the partition that contains the files you deleted.(or all the partitions i provided.)
but that is more complicated since i do not know what partition are we talking about.
Click to expand...
Click to collapse
Whenever i run nvflash or any command I get the following: pic attached...
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

thisis the nvflash i use and it is working.

berbecverde said:
thisis the nvflash i use and it is working.
Click to expand...
Click to collapse
So many thanks. Worked like a charm. :laugh::laugh::laugh::good::good::good:

Hey,
maybe some of you could help me by my question:
Is it possible to flash a US nandroid Backup to a WE device?
My problem is, that I did not backed up anything and installed CM 9 by Koshu.
Now, I lost the CM9 zip-file, my device is wiped and the links provided by Koshus post are dead
So... right now I got a 64Gb TPT with nothing but CWM and no android version to flash.
I would be really glad if someone could just give me a hint for a solution because I don't know what to do anymore...
Thank you very much in advance for any hint!

not sure it is a good idea to mix the 2 versions.
you should ask someone for a CWM backup.

Thank you very much for your quick answer.
Could anyone provide me at least ZIP-File of CM9 for the Tablet by Koshu?
Maybe I found a solution to restore the original Lenovo-System:
...Try this instead. Assuming you have adb set up and functioning here (none of this will work if you don't.) Also, have USB Debugging turned on and have your TPT set for Charge Only.
Go here: http: // download . lenovo . com / slates / think / tablet1
Download the correct zip for the version of software you're currently running (ThinkPadTablet_A310_02_0039_0086_US.zip is the latest OTA for the 32GB USA Model.)
Open that up and extract the install-recovery.sh file from recovery\etc folder inside of that zip.
Copy that to your android-platform-tools directory (if you don't have that folder added to your path in system variables.)
Open up a command prompt and change to the android-platform-tools folder (if you don't have that folder added to your path in system variables.)
Run the following commands:
Code: [Select]
adb push install-recovery.sh /data/local
adb shell
su
mount -o rw,remount /system
cat /data/local/install-recovery.sh > /system/etc/install-recovery.sh
dd if=/system/recovery-from-boot.p of=/dev/block/mmcblk0p1
Power off your TPT.
Power on your TPT.
Let it boot fully then power off your TPT again.
Power on your TPT while rapidly hitting Vol +
With luck, you'll be booted back into the stock recovery.
Click to expand...
Click to collapse
What do you guys think about this solution? If someone could provide me a working ROM (like CM9) I could connect via adb and get the stuff right.
Thank you in advance for your help!