Please use the Q&A Forum for questions &
Read the Forum Rules Ref Posting
Thanks ✟
Moving to Q&A

So, same thing happened to yaworski, and we figured out on gtalk what's going on and how to get around it.

First, by checking rawread / rawwrite commands, we figured out that it's faulty eMMC (in his case), causing nvflash to fail formatting it as a BCT partition (see nvflash --help and "rawdeviceread" and "rawdevicewrite" commands). If you're more experienced, you can use them to figure out where it fails, if it's not the first sector, then you can use the workaround (in yaworski's case if was somewhere around 200 - 300 th sector (4 kB per sector). Open up the flash.cfg file with configurations for the partitions, you should have something like this in there:

[partition]
name=BCT
id=2
type=boot_config_table
allocation_policy=sequential
filesystem_type=basic
size=3145728
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=PT
id=3
type=partition_table
allocation_policy=sequential
filesystem_type=basic
size=4096
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

in which you're wasting 3 MB on BCT which is in fact less than 4 kB, so reduce BCT size to 4096 and a dummy FCK partition over the "bad area"

[partition]
name=BCT
id=2
type=boot_config_table
allocation_policy=sequential
filesystem_type=basic
size=4096
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=PT
id=3
type=partition_table
allocation_policy=sequential
filesystem_type=basic
size=4096
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=FCK
id=15
type=data
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

After that, the --create command (with --odmdata specified) should work (or at least worked in yaworski's case).

nvflash --bct flash.bct --setbct --odmdata 0xXXXXXXXX --configfile flash.cfg --create --bl bootloader.bin --sbk 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX

In the flash.cfg, I recommend removing "filename" attribute for every partition except EBT, and in EBT use ICS patched bootloader (which has fastboot), you can however specify recovery for SOS partition.

When the repartitioning finishes, dump and decrypt the bct from the tablet, then send "nvflash -r --go" to see PASS.

Anyway, several notes:

A) yaworsky used 40960 size for BCT, we weren't trying 4096
B) if the second sector is fauly, put the FCK partition between BCT and PT
C) expand the FCK partition to more than 8 MB (it's 4 MB in the sample config, su double it), if you are stuck in APX mode even after you flash the bootloader (faulty blocks over EBT).
D) if the first sector is faulty, then there is no go

The are no issues with the ROMs, as kernels will skip the FCK partitions (despite it's marked as data ufffff) In any case, as this is an issue with HW, I still recommend returning it for warranty, as it'll happen again sooner or later.

This finally starts to make some sense, thank you. Can you please give more details about what you did?

@lcd047: all we did was just changing size of BCT partition and adding another dummy partition in a way, that the faulty sector in eMMC was inside of that partition. That way nvflash is able to properly format BCT and PT partitions and whole --create operation is also successful (at least in my case was).

I was using EUU files from Image folder. In addition I've put there Skrilax_CZ's bootloader_v8_blue.bin and set this as filename in flash.cfg for EBT partition. All other filename attributes were removed.

Then you just need to make changes to flash.cfg as described by Skrilax_CZ above (red color shows changes in flash.cfg that needs to be done).


The way I've found where is the eMMC damaged was writting content from mmcblk0_start.img file (from Thor's CWM backup) using raw write (place the file inside nvflash folder before). If the eMMC is really faulty then write operation will just hang at some point (in my case it stopped at byte 1179648 - but this is not the faulty one, it is after it). If the write stops just use ctrl+c to exit nvflash and reset tablet by holding power for 5 seconds or use reset switch.

nvflash --rawdevicewrite 0 1664 mmcblk0_start.img --bl bootloader.bin --sbk 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX --go

And then read it back:

nvflash --rawdeviceread 0 1664 test.img --bl bootloader.bin --sbk 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX --go

Use some tool that can show differences between two binary files. I've used Total Commander to do that and just found the first difference and it was at offset 0x100000 (1048576 decimal) which is exactly 1MB.

BTW if you don't have backup of mmcblk0_start then just use any file that is at least 6815744 bytes long. It doesn't matter what the file is as the tab won't start anyway if the chip is damaged without using modified --create command. You can even use some mp3 file . This is just needed to find the first difference between the original file and the one read back from eMMC.

Originally Posted by yaworski

@lcd047: all we did was just changing size of BCT partition and adding another dummy partition in a way, that the faulty sector in eMMC was inside of that partition. That way nvflash is able to properly format BCT and PT partitions and whole --create operation is also successful (at least in my case was).

I was using EUU files from Image folder. In addition I've put there Skrilax_CZ's bootloader_v8_blue.bin and set this as filename in flash.cfg for EBT partition. All other filename attributes were removed.

Then you just need to make changes to flash.cfg as described by Skrilax_CZ above (red color shows changes in flash.cfg that needs to be done).


The way I've found where is the eMMC damaged was writting content from mmcblk0_start.img file (from Thor's CWM backup) using raw write (place the file inside nvflash folder before). If the eMMC is really faulty then write operation will just hang at some point (in my case it stopped at byte 1179648 - but this is not the faulty one, it is after it). If the write stops just use ctrl+c to exit nvflash and reset tablet by holding power for 5 seconds or use reset switch.

nvflash --rawdevicewrite 0 1664 mmcblk0_start.img --bl bootloader.bin --sbk 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX --go

And then read it back:

nvflash --rawdeviceread 0 1664 test.img --bl bootloader.bin --sbk 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX --go

Use some tool that can show differences between two binary files. I've used Total Commander to do that and just found the first difference and it was at offset 0x100000 (1048576 decimal) which is exactly 1MB.

BTW if you don't have backup of mmcblk0_start then just use any file that is at least 6815744 bytes long. It doesn't matter what the file is as the tab won't start anyway if the chip is damaged without using modified --create command. You can even use some mp3 file . This is just needed to find the first difference between the original file and the one read back from eMMC.

can be fully corrected sector:

1. Download h??p://narod.ru/disk/53919831001.a235ea2225f319015f30c009629d2075/BabSector.rar.html
2. Run a501 A.bat
3. run recovery 1.7.3 -> "Mount and Storage" -> "Format /system"(better than twice).
4. Run a501 B.bat

Originally Posted by bsg19071979

can be fully corrected sector:

1. Download h??p://narod.ru/disk/53919831001.a235ea2225f319015f30c009629d2075/BabSector.rar.html
2. Run a501 A.bat
3. run recovery 1.7.3 -> "Mount and Storage" -> "Format /system"(better than twice).
4. Run a501 B.bat

there was no "A.bat or b.bat" the zip

Originally Posted by liftman-

there was no "A.bat or b.bat" the zip

file name - A501 A.bat and A501 B.bat

Originally Posted by bsg19071979

file name - A501 A.bat and A501 B.bat

please forgive me, where those .bat files in the downloaded file, or another download?

Originally Posted by liftman-

please forgive me, where those .bat files in the downloaded file, or another download?

h??p://narod.ru/disk/53919831001.a235ea2225f319015f30c009629d2075/BabSector.rar.html

instead of h??p p to write http

---------- Post added at 06:51 AM ---------- Previous post was at 06:45 AM ----------

Originally Posted by liftman-

please forgive me, where those .bat files in the downloaded file, or another download?

Take a look at this subject, there is a link:

h??p://forum.tegraowners.com/viewtopic.php?f=8&t=563&start=10

---------- Post added at 07:22 AM ---------- Previous post was at 06:51 AM ----------

And here's another link to the Russian:

h??p://4pda.ru/forum/index.php?s=&showtopic=262344&view=findpost&p=1389 8899

Originally Posted by Skrilax_CZ

So, same thing happened to yaworski, and we figured out on gtalk what's going on and how to get around it.

First, by checking rawread / rawwrite commands, we figured out that it's faulty eMMC (in his case), causing nvflash to fail formatting it as a BCT partition (see nvflash --help and "rawdeviceread" and "rawdevicewrite" commands). If you're more experienced, you can use them to figure out where it fails, if it's not the first sector, then you can use the workaround (in yaworski's case if was somewhere around 200 - 300 th sector (4 kB per sector). Open up the flash.cfg file with configurations for the partitions, you should have something like this in there:

[partition]
name=BCT
id=2
type=boot_config_table
allocation_policy=sequential
filesystem_type=basic
size=3145728
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=PT
id=3
type=partition_table
allocation_policy=sequential
filesystem_type=basic
size=4096
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

in which you're wasting 3 MB on BCT which is in fact less than 4 kB, so reduce BCT size to 4096 and a dummy FCK partition over the "bad area"

[partition]
name=BCT
id=2
type=boot_config_table
allocation_policy=sequential
filesystem_type=basic
size=4096
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=PT
id=3
type=partition_table
allocation_policy=sequential
filesystem_type=basic
size=4096
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

[partition]
name=FCK
id=15
type=data
allocation_policy=sequential
filesystem_type=basic
size=4194304
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0

After that, the --create command (with --odmdata specified) should work (or at least worked in yaworski's case).

nvflash --bct flash.bct --setbct --odmdata 0xXXXXXXXX --configfile flash.cfg --create --bl bootloader.bin --sbk 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX

In the flash.cfg, I recommend removing "filename" attribute for every partition except EBT, and in EBT use ICS patched bootloader (which has fastboot), you can however specify recovery for SOS partition.

When the repartitioning finishes, dump and decrypt the bct from the tablet, then send "nvflash -r --go" to see PASS.

Anyway, several notes:

A) yaworsky used 40960 size for BCT, we weren't trying 4096
B) if the second sector is fauly, put the FCK partition between BCT and PT
C) expand the FCK partition to more than 8 MB (it's 4 MB in the sample config, su double it), if you are stuck in APX mode even after you flash the bootloader (faulty blocks over EBT).
D) if the first sector is faulty, then there is no go

The are no issues with the ROMs, as kernels will skip the FCK partitions (despite it's marked as data ufffff) In any case, as this is an issue with HW, I still recommend returning it for warranty, as it'll happen again sooner or later.

1st post, so bear with me. I am attempting this workaround, but I am just sitting here hanging after the "Formatting partition 15 FCK please wait.. done!" portion. In other words it is not proceeding to the PT, EBT, etc. Any thoughts?