[Android Q&A, Help & Troubleshooting] fesustamus:
Old Thread, new info

Figured I would post a belated follow-up on this thread so it's out there to help someone else. I have a D910a phone (yes the North American flavor). I've had it for a couple years now and only real complaints are the absolutely horrid GPS sensitivity and terrible low-light/white balance performance on the camera. That aside, my phone recently it experienced what I can only be describe as a sudden bout of crappiness. After hours and hours of digging through XDA forums I did locate the slightly older version (v3.1224.01) of the "Smart Phone Flash Tool" or simply SP_Flash_Tool (spft) Turns out the newer version, v3.1328.0, had issues as mentioned in at least one post I found. Also useful was the MtkDroidTools which I used to create the "scatter" file required by spft. I did locate sptf .img's for both CWM and TWRP recovery partitions but unfortunately the only spft rom image to be posted anywhere is the 910i version which I'll get to in a moment. The only 910a backup rom I could find was in CWM/ nandroid format so not all that useful considering I couldn't even boot and the CWM recovery I found doesn't seem to like that format. MTK VCOM drivers also had to get installed. To save someone some frustration, SPTF only connects to the phone with battery out and you plug in just the USB cable (just like the tutorial on XDA says)... the non-obvious catch is that SPTF has to be listening for the port to exist by initiating either a download or readback prior to plugging in the phone. The port is only present for a few seconds before the embedded MTK chipset loader turns it back off.

So here was the issue, plugged in the phone and set it on my night-stand on a Sunday evening. Monday morning, all I got when I tapped the power button was, well, nothing. Thought an app hung while in standby (not the first time) and killed the battery so I plugged it in. Got the phone-is-off battery charging screen (big animated charging battery), then held the power button on for a bit, got the pre-loader BLU logo but it never made it to the animated boot logo, it then rebooted to recovery mode after a while. So as I initially guessed, some partition table somewhere in the NAND flash got corrupted. In the end I determined that the "ANDROID"/system/OS partition was reporting as less than one third the size as it should be based on looking at scatter files included with various recovery ROM images.

Step 1 was to use spft and very manually readback the memory blocks which matched the various scatter files including the OS partition (MTKDroidTool calls it ANDROID when it generates a scatter file). Ignored the __NODL_ entries in the scatter files hoping it was one of these that contained the baseband information which tells the phone which region it thinks it's in. SPFT gets finicky if all of the blocks listed after loading a scatter file aren't linked to an image (happens automatically if they exist in the same folder as the loaded scatter file). Figured out I could just modify the scatter file and add __NODL_ to every item except the one I was trying to flash. (other variations worked). Flashed the TWRP recovery partition and then I had access to the adb debug interface which is not available in the stock recovery. Made TWRP backups for system, data, and cache then did adb pulls on /system and /data until I had everything I could back up. Then I started wiping cache and data partitions with TWRP. Phone still didn't boot. Finally flashed the wrong OS image from the d910i mentioned above. Still didn't boot. Then I flashed every partition active when loading that d910i scatter file. Phone booted to the OOBE (out of box experience)!!! Then I thought, I wonder if the OS block I read back from the phone before messing with it was any good, flashed that and it worked too. Tried to flash back all the pre-wipe NAND block reads I did on my phone and didn't work so I reverted back to the working state, ran the TWRP restore on the backups I'd made before wiping stuff, which left the OS non-bootable again, but then I sptf flashed (tool calls it "download") just the OS partition which I pulled from the phone manually (couldn't use the scatter file generated by MTKDroidTool... it was busted, based my start/stop on the scatter included in other valid rom/partition images), and poof, my phone was back to life, user data, wallpaper, everything.

You may be wondering why this is posted in this thread. Skipping over some details, now my phone about screen says the build is d910i, not d910a. No matter, the radios don't seem to care and it still connects to AT&T for voice and 3G data which gets back to the original question on this thread. Even if the OS version is reporting the wrong region, it may not matter. From experience with a Samsung GT-I5500, no amount of messing with the base band partitions will ever make the radios talk correctly in a different region, the hardware is different when they build the phone. I'm guessing that launching the d910i image modified something in one of the "hidden" partitions (which you don't want to touch if you can help it). I further speculate that if you did manage to flash over the partition containing the baseband info you would tank the phone's ability to work with any network but for now, it is just acceptably unsettling that mine just reports the wrong OS build but the phone works otherwise. It's likely that the d910i and d910a OS builds are identical and they key off of some other information to report the region variant.

In hind sight I wish I had just reflashed the OS partition I pulled from my phone because that's what seemed to fix the partition table. Probably could have saved a ton of trials and probably wouldn't have even had to restore any user data not to mention phone probably would have still thought it was a d910a.

Now the only question, is how long until it flakes out again? I suspect a critical section of the NAND is not what it used to be and will be more prone to failing again... after all, it is a low cost phone so the NAND was the stuff rejected by major brand suppliers (they cherry-pick flash chips but they pay for it). Fingers crossed it holds the partition table for a while... no idea where that info resides on this phone but did find the recovery logs which look like what MTKDroidTool looks at. Go ask an actual android developer :) I don't write code but have exceptional hardware debugging skills.