I recently obtained a Gemini 4g x27 model from an eBay seller and after having a fun week with it, decided to do the update to dual boot an Android / Debian install. The instrucitons and tools appeared to be good and searching the forums showed a few 'rough edges' occasionally, but overall folks were able to do the upgrade without much of a problem. The week of playing with the x27 was highly successful and I had no problems at all. Fantastic battery life compared to some of my recent tablets when used in the manner I was using the Gemini.
I created a new Ubuntu 18.04 desktop and installed the flash tool. Using the parition tool I created a mostly half/half Android/Debian scatter file and downloaded the installable images.
The installation seemed to go ok up to a point where an error was thrown - sorry I don't have the specific error but it was some kind of generic sounding 'failed, try again' thing.
I tried to re-perform the flashing by powering off the Gemini and restart the install. Mistakenly I actually rebooted the Gemini and it started to come up. It wanted to erase all user data due to the partition size changes so I allowed it and it ended up in a loop of:
1. Blank screen
2. Screen with mostly white circle, with "Erasing." below that centered on screen.
3. Delay of a few seconds.
4. Repeat at 1.
(It now does that loop at every power up and no longer recognizes 'recovery' mode button pattern.)
I an investigation of what might have been wrong, I found the scatter file contained some wild 'petabyte' range partitions (as reported by another on this site.) I repeated a partition tool request with a different partition size for Debian and examined the results until I received one with seemingly valid numbers. Reflashing this update fails with the same "Invalid ROM or PMT."
I have *not* tried the 'format' option (per Gemini warnings.) I *did* save my NVRAM before I started this, but I've tried re-reading the NVRAM using the flash tool and it still returns the same value as I recorded before starting the flash process.
My previous experience (despite warnng from Gemini) with the flash tool on other platforms is that I should be able to construct a *complete* scatter file with the NVRAM partition included an install with the 'format' option enabled. This should put everything right, but I'm sure if something goes wrong here, I *will* have a complete $600 brick.
So the question is: has anyone successfully used the flash process with the 'format' option to restore the complete state of the unit?
---------------------------
EDIT: I've gotten nothing useful from Planet - they assumed I was trying to *INSTALL* Ubuntu on the Gemini and ignored the rest of my message. I"m retrying the support request, but still waiting...
Has anyone had success doing a "Format All / Download" with a scatter file that includes the NVRAM0? Does failure of this step complely brick the unit (mine is only 'half bricked' in that it still responds to the flash tool commands?) It's just nothing will currently Download or Upgrade due to "partition table" errors. I am 'kinda' familiar with the partitioning thing since I dealt with a 'llght' version of this issue on the NextThing "C.H.I.P." before they went bust. I had a yocto build environment set up to build nand images for the Chip and ChipPro but it was delicate 'updating' those with the tools available.
I'm just not confident I know enough about the *inside* of the flashing process *on the device* to trust a blind format until I get some feedback that others have tried it and succeeded. I've seem messages suggesting it works, but none were real confidence builders.
FOLLOWUP: As of yesterday, all is working again. After the last missive from Planet, I made a few guesses and found the secret sauce (at least it was secret to me...)
Was suggested I do a "Format + Download" of a "standard scatter file." Didn't work from flash_tool.sh GUI as it seems that part was disabled. (Yes I know I could have edited the source and remove the disabling code, but I decided to just use the command line parameter.)
The Format and Download of an "Android Only" version worked. Well, 'almost.' Even though I was able to read-back the NVRAM chunk and it compared as equal to the file I read-back before I started this operation, the Android OS wouldn't come up entirely until I "downloaded" the NVRAM chunk by itself. After this, Android was alive and well and all IMEI / SIM information was intact from the orignal turnon.
I then did a "format + download" of my Android + Debian scatter file (watch out for the weird partition_sizes of some of the scatter file contents!) and it had the same problem as above. Until I did a "download" only on the NVRAM chunk, it wouldn't come up. However, after that step, all is well. At least I have both Android and Debian running. Can't say I'm impressed (as others have said) by the UI on the Debian side. I've seen better handling of screen real-estate: lots of dialogs and screens have the buttons "below the margin" and you have to work hard to move the window around so you can accept some change. Connman is particularly difficult.
Rather than just complaining I'm hoping to dig in and start helping in a few days after all these holiday distractions :-)
If anyone doesn't understand what I intended by the above description of actions for flashing, feel free to contact me and I'll try to do a better job explaining.
