OESF Portal | OESF Forum | OESF Wiki | LinuxPDA | #planetgemini chat on matrix.org | #gemini-pda chat on Freenode | #zaurus and #alarmz chat on Freenode | ELSI (coming soon) | Ibiblio


Welcome Guest ( Log In | Register )

Personal Photo
Personal Statement
Doing imbedded development since the first microprocessors. Did some earlier 'embedded' development on DEC pdp-11 for factory automation before 1975 (yes, I'm old.)
Today mostly embedded Linux-based special-purpose applications involving small machine control or data collection. W
Personal Info
Age Unknown
Gender Not Set
Location Unknown
Birthday Unknown
No Information
Joined: 15-November 18
Profile Views: 577*
Last Seen: 3rd December 2018 - 04:57 PM
Local Time: Jan 26 2020, 12:27 AM
4 posts (0 per day)
Contact Information
AIM No Information
Yahoo No Information
ICQ No Information
MSN No Information
Contact Private
* Profile views updated each hour



My Content
23 Nov 2018
Yocto and bitbake are my go-to tools for developing for Raspberry PI and BeagleBone (and NextThing Co C.H.I.P. and ChipPro before they died.) I'm working on a 'meta-planetcom' meta layer (similar to meta-rpi for the raspberry pi family) that will allow me to build compete Debian distros and images for this little machine.

Are there any other developers also working on this? I would like to avoid needless duplication of effort if possible.

19 Nov 2018
As subject asks: is the internal flash on the Gemini a self-contained device with internal wear leveling (like the external microSD) or is it more like a large nand-flash with a wear-leveling driver above it?

The reason for the question is that a self-contained device would not lose it's block mapping tables during a device 'format' while a simple nand-flash with driver would. This would make a 'Format and Download' a dangerous operation to perform without additional tools I don't have.

19 Nov 2018
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.

Last Visitors

27 Nov 2018 - 16:36

Other users have left no comments for Robosity.

There are no friends to display.
RSS Lo-Fi Version Time is now: 26th January 2020 - 12:27 AM