[Acer Iconia Tab A100] pio_masaki:
Filesystem Table (taken from recovery)

-------------------------------------------------------------------------------

Mount Point Filesystem Device Partition

-------------------------------------------------------------------------------

/system | ext4 | /dev/block/mmcblk0p3

/data | ext4 | /dev/block/mmcblk0p8

/cache | ext4 | /dev/block/mmcblk0p4

/misc | emmc | /dev/block/mmcblk0p5

/flexrom | ext4 | /dev/block/mmcblk0p6

/sdc | vfat | /dev/block/mmcblk1p1

/boot | emmc | /dev/block/mmcblk0p2

/recovery | emmc | /dev/block/mmcblk0p1

/sd-ext | ext4 | /dev/block/mmcblk1p2

cat /proc/partitions gives this:

------------------------------------------------------------------------------

major minor #blocks name

179 0 7815168 mmcblk0

179 1 6144 mmcblk0p1

179 2 8192 mmcblk0p2

179 3 614400 mmcblk0p3

179 4 1253376 mmcblk0p4

179 5 4096 mmcblk0p5

179 6 102400 mmcblk0p6

179 7 10240 mmcblk0p7

179 8 5801984 mmcblk0p8

179 32 31166976 mmcblk1

179 33 31162880 mmcblk1p1

*Note*

While is says /data is EXT4, I think it's actually EXT3, but since it shares with internal SD as /data/media, that may be why it shows EXT4 in some places and EXT3 in others.

EMMC filesystem partitions can't be read by normal means, they don't have a true filesystem.

VFAT is any FAT/FAT32 formatted device, so external SD shows up as VFAT.

I'm pretty certain this is not complete, there are partitions that don't show up under normal usage, so there may be hidden partitions on the device.

Ideas or theories I have and things to try

I'm pretty well convinced we suffer from bad EMMC, that corruption I mentioned in post 2. However, it could also be something as simple as the partitions get scrambled, and while they are there, they can't mount due to being damaged, so I have a few things I wanted to try (hence my request for a loaned or donated bricked A100 for testing in another post I made).

1. DD system and cache partitions, the entire thing, from a working device. (done, I did this on my own tab)

2. DD the image back to a bricked A100, since cache almost always fails to mount, DD cache.img to it (haven't tried yet, don't have a bricked unit)

3. If DD fails, check where it is failing at, it will report records in/out, however DD doesn't handle bad sectors well, and may just hang.

4. If DD fails, and doesn't return a records in/out summary (hangs) attempt fastboot flash cache cache.img (requires a mounting SD card)

5. If DD fails, and external SD is NOT mountable, then ADB Shell is out, and requires launching from adb dd, which I haven't found a way to do yet. (DD would use the image from PC, not SD)

6. If DD is completely out, and fastboot can't flash either, we'll need to work on the partitions directly, using parted or some other tools that can modify the partitions, which is beyond my abilities.

All unsuccessful.

JTAG may or may not work, as it has been mentioned that even JTAG will fail to write to the EMMC with its damaged section. At this point there is only 2 possible methods that may work:

1. Motherboard replacement. Either Acer under warranty (or out of warranty if you can get your case elevated, some users report this being possible) or you replace it yourself. It's not terribly difficult, and I can probably even make a video of it if needed.

2. Someone with a reflow station may be able to remove the EMMC from the board and replace it with a non damaged unit. This place would require a method to read/dump a good chip and be able to write this back to the new one, we can not just NVFlash a system back onto the system. I don't suggest anyone with a hair dryer or heatgun attempt this. The cost for this may be high, but maybe a deal can be worked out of a shop or person is willing to take on this job, as there are TONS of dead A100s around (and A210 appears to be prone to it also, way to go Acer!)

Prevention:

There is currently no way to prevent this, however I have begun modifying Samsung's firmware patch to maybe work with our boards. This isn't something I'm good at, or even know what I'm doing, so it may work, or may not. Information can be found in the newly included link about the brick bug in post 1, however the rundown is this: Every power up (not reboot, power on) the kernel will run a check against the model and revision of the EMMC, if it falls into a given range, then it will attempt to bypass the erase functions of the EMMC firmware so it will, idealy, not write that 32 byte section of 0s causing the EMMC to crash. If it doesn't match, then it does nothing. It's originally written for Samsung devices, of course, so requires reworking for the A100, but it may work, it may not.