[Teclast X98 Air 3G] verbage:
Partitioning failure during flash process; possible hardware error or not?

Hi all,

Long posting here, but I'm trying to give as much info upfront so we don't have a posting volley of tiny snippets. Here's the scoop.

I have an Air III (Android only, not dual-boot) that I am trying to rehabilitate, but it's seems to be stuck in a weirdish state, and I'm looking for guidance. I am wondering if maybe the flash rom has gone bad. I had set this tablet up about a year ago using sikke1's rom, and my folks have been using it since then without incident. However, recently, after putting it to charge, when they went to put it on, it did not fully boot, but ended up at a text-based, two-line EFI shell screen (details below). So they sent it back to me for fixing.

First thing I noticed on trying to boot it is was that there was a tiny mouse cursor arrow on the screen during boot. I don't remember seeing this when I set the tablet up for them a year ago, but maybe I'm just not remembering? Another odd thing is that if the tablet is actually off, and I plug it into my PC, it actually starts to boot. I would expect it to just show me the battery charging screen, not start booting, but then again, maybe that's what it did a year ago, and I am just not remembering this? These are just ancillary observations--here's the real meat.

I mentioned that the boots fails at a two-line EFI shell screen, and then maybe 30 seconds or so later, a device mapping table pops up, too. Here is the total text:

EFI Shell version 2.31 [5.8]
Current running mode 1.1.2
Device mapping table
blk0 :BlockDevice - Alias (null)
PciRoot(0x0)/Pci(0x17,0x0)/Ctrl(0x0)
blk1 :BlockDevice - Alias (null)
PciRoot(0x0)/Pci(0x17,0x0)/Ctrl(0x1)
blk2 :BlockDevice - Alias (null)
PciRoot(0x0)/Pci(0x17,0x0)/Ctrl(0x2)

Press ESC in 1 seconds to skip startup.nsh, any other key to continue.
Shell> _

If I plug in a keyboard at that point, I can actually interact with the EFI shell. But I have not done anything substantive there because I don't know what to do, and don't want to screw anything up if this is still possible to resuscitate.

Anyway, I was happy to see that the tablet could still go into DNX mode by holding down the vol- and vol+ and power buttons on boot. So I got everything installed as per the initial post here (using TecKnight's tutorials as guidance, but substituting in details as per the initial post). I got the MFT tool all ready, put the tablet into DNX mode, plugged in the tablet, and MFT started working its magic. It got to 10% completion and had the droidboot.img loaded at that time, then it continued, and ended up failing at 23% with the following error:

[FAILURE] OS flash failure fastboot -s Baytrail00000240 oem partition /tmp/partition.tbl

Here are the salient bits from the MFT log. The "partition.tbl" file seems to be copied over fine, but the actual partitioning process fails.

(bootloader) Start partitioning

OKAY [ 0.125s]
finished. total time: 0.125s
01/15/17 15:42:23.918 DEBUG : sleep 250 ms
01/15/17 15:42:24.168 INFO : Port 0/1/2 #0: fastboot -s Baytrail00000240 flash /tmp/partition.tbl "M:\sysdisk\Hardware and Drivers\Teclast X98 Air III (M5C5)\sikke1 X98 Air III (M5C5) GoogleNow\sikke1 rom\partition.tbl"
01/15/17 15:42:24.565 DEBUG : Port 0/1/2 #0: Process terminated, start reading output
01/15/17 15:42:24.565 DEBUG : Port 0/1/2 #0: Output OK
01/15/17 15:42:24.565 DEBUG : Port 0/1/2 #0: "fastboot -s Baytrail00000240 flash /tmp/partition.tbl "M:\sysdisk\Hardware and Drivers\Teclast X98 Air III (M5C5)\sikke1 X98 Air III (M5C5) GoogleNow\sikke1 rom\partition.tbl"" returns:
target reported max download size of 536870912 bytes
sending '/tmp/partition.tbl' (1 KB)...
OKAY [ 0.094s]
writing '/tmp/partition.tbl'...
OKAY [ 0.119s]
finished. total time: 0.213s
01/15/17 15:42:24.565 DEBUG : sleep 250 ms
01/15/17 15:42:24.816 INFO : Port 0/1/2 #0: fastboot -s Baytrail00000240 oem partition /tmp/partition.tbl
01/15/17 15:42:24.935 DEBUG : Port 0/1/2 #0: Process terminated, start reading output
01/15/17 15:42:24.935 DEBUG : Port 0/1/2 #0: Output OK
01/15/17 15:42:24.935 WARNING: Port 0/1/2 #0: Failed to execute "fastboot -s Baytrail00000240 oem partition /tmp/partition.tbl":
...
FAILED (remote: GPT command failed
)
finished. total time: 0.091s
01/15/17 15:42:24.935 DEBUG : sleep 250 ms
01/15/17 15:42:25.185 WARNING: Port 0/1/2 #0: Retry to execute fastboot -s Baytrail00000240 oem partition /tmp/partition.tbl
01/15/17 15:42:25.306 DEBUG : Port 0/1/2 #0: Process terminated, start reading output
01/15/17 15:42:25.306 DEBUG : Port 0/1/2 #0: Output OK
01/15/17 15:42:25.306 WARNING: Port 0/1/2 #0: Failed to execute "fastboot -s Baytrail00000240 oem partition /tmp/partition.tbl":
...
FAILED (remote: GPT command failed
)
finished. total time: 0.091s
01/15/17 15:42:25.306 DEBUG : sleep 250 ms
01/15/17 15:42:25.556 INFO : do_flash_finished END OF FLASH
01/15/17 15:42:25.556 ERROR : Port 0/1/2 #0: Flash failure

When I look at the tablet itself with the droidboot.img running, I see a "RESULT: FAIL(partition)" error.

Anyway, that's where I am at this point. Since the partitioning process fails, I am wondering if this might be a failure of the flash memory.

I am looking for any suggestions you might have. For the moment, here are a few things I am thinking about.

1.) Even though the partitioning process fails, maybe the partitions are still intact, and I can just flash images directly? I don't have high hopes for this scenario because if the low-level partitioning process fails, I can't imagine flashing directly will work either, but who knows.

2.) I'm happy to futz around in the EFI shell more--perhaps I may be able to gather some further information about the flash status? Though there are a bunch of info/status commands there, and I have sort of browsed through them, I did not see anything obvious when I was exploring. I was able to seemingly mount one of the blk0 device I mentioned at the start, and I assume I could probably do the same for the blk1 and blk2 devices, too. But I wasn't clear on the syntax/process (just make a directory, and mount it there like under Linux?) so I didn't want to screw things up more.

3.) Maybe there is just something screwed up with the ESP (EFI System Partition), and flashing the esp.img directly will solve the problem? This is purely speculative on my part--as I said, I can get into the EFI Shell, and work with it interactively so at least a portion of the ESP is working. I am just grasping at straws here...

4.) Maybe there is a way to put an image on MicroSD, and then from either the EFI Shell or droidboot.img via fastboot, I can work some magic?

Anyway, I am up for suggestions about how to proceed at this point so if you have any, glad to hear them--thanks!