Florian v. Samson fsamson at unix-ag.uni-kl.de
Sun Apr 26 23:56:07 CEST 2009

I am glad to see such a focused and open discussion discussion about the
next steps of the OM hardware development.  This is a novelty IMHO and
bears some potential, though caused by an unfortunate situation.

I am also very positively surprised, that the discussion is centered
around incremental and feasible steps, leading to an GTA02+, rather than
an GTA2.5, or GTA03 (which still is the name of this mailing list ;-) ).

Concerning the big picture, I believe putting application and UI
development mostly in external hands ("the community", i. e. volunteers
and, hopefully, third parties) was an unavoidable (and hence overdue)
decision.  Luckily the software development infrastructure for ARM-based
SmartPhones and PDAs has been heavily improved over the last years, so
today building upon community efforts is likely to work far better than
back in the days of an Agenda VR-3 (MIPS32) or (later) Sharp Zaurus
SL-5500 (which both failed for a good part due to that).

Actually, within the short time this list exists, an quite concise plan
has been evolving (partially just summarising former mails below):

1. GTA02+

a. Hardware itself
- Trying ro retain as much as possible, especially the OM case
- Glamectomy (implying AR6001 SDIO -> SPI conversion already done by
- DeNANDification & integration of IDBG (Internal Debug Board)
- Audio Rework (including Wolfson-IRQ), already drafted by Joerg
- (My 2c:) Reverting the accelerometer IRQ change (including keeping
  *two* accelerometers) or rework accelerometer IRQs

  Rationale for the last point:
  - The way the IRQ lines were rewired for GTA02-A7 was already
    recognized as being flawed.
  - A single accelerometer is unable to detect and measure
    rotational movement, if the axis of the rotation intersects with
    the accelerometer; other rotational movements in combination
    with translational movements will lead to mismeasurements of the
    translational forces.  Hence two accelerometers are necessery in
    order to measure, calculate and factor out rotational movements
    correctly.  This can be best achived in an generic fashion by
    transforming (needs a bit of 3D math) the two independent three
    axis measurements of the accelerometers from local coordinates
    into a 3+3+3 value scheme in world coordinates: 3 translational
    directions, 3 rotational directions, plus a normal vector for
    the device orientation.
    To ease the calculation (coordinate transformation) and enhance
    precision, optimally the two accelerometers are positioned at
    the same distance from the center of the device, either
    diagonally (i.e. at NorthWest-SouthEast or NE-SW positions), or
    orthogonally (West-North, E-N, W-S, E-S).

Werner recently put the GTA02+ effort into perspective

b. Hardware development infrastructure
Open up (legally and technically) all GTA02 schematics and PCB layouts
in an editable format.  Technically, a well working toolchain has to be
employed, but by no means it ought restrain the practicability of
development.  As a last resort, this might imply looking at proprietory
software (zero cost or not) or even keeping parts or all of the current

c. Constitute a formal body (e.g. non-profit organisation), which
organisationally and formally takes care of the opened IP and the 
openmoko.org domain and sevices.

d. (My 2c:) "Outreach" (I hate this marketing term, but here it fits
There has been little to no visible effort to aquire volunteers,
sponsors and partners beyond relying on the sexyness of the device, an
open infrastructure (Wiki, CVS, MLs, etc.) and many talks at
A simple announcement that Openmoko is on the quest for volunteers,
sponsors and partners (companies, universities, etc.), effectively
spread, might already make a difference for the start; still, it needs
to be clearly defined first what a sponsor or a partner might get / gain
(i.e. what Openmoko can offer, e.g. logos of a certain size on the
mainpage, or for a PCB / SMT assembler a share of future revenues per
piece produced there). 

2. Steps which were discussed for an GTA2.5, and might serve as an stop
gap measure in case a major component becomes scarce; hopefully to be
- Conversion: TI Calypso -> Siemens / Cinterion MC75i (alternatively
  Telit UC864-E)
- Substitution: Atheros AR6001 -> AR6002

3. Future: GTA03 development
- Open up (legally and technically) all GTA03 and OM3D7K schematics and 
  PCB layouts in an editable format.
- Continue development on (as it was suggested by Joerg) GTA03 (as of 
  12/2008), before it became OM3-R2D2.


P.S.: And to finally expose some classical featurism and
Why does the GTA lack an SIR- / CIR-Port (Simple-Infrared /
Consumer-IR), which would enable a multitude of applications, such as a
"learning" remote control?  This feature is low risk, as the software
stack well alive (lirc.org) and it "just" needs an free UART, an
receiver and an transmitter IR-diode, and a few passive components (see
http://www.lirc.org/receivers.html /
Seriously, while being a "low hanging fruit", this change might easily
be considered as too invasive.

<Moved that down here, as it was IMO too distractive from the central
statements above>
4. (My 2c:) Far future: GTA04 development
Keep the memory of the hard learned lessons (here and elsewhere) alive:
rely on components with are well known / understood (esp. by the team),
already have some (proven at best) software support (drivers, etc.; the
more, the better), and have (hopefully / potentially) reliable
It is so nice to see no repetition of the classic "throw in some
arbitrary component ideas, which would result in changing / breaking
everything (e.g. basic hardware design, software development
infrastructure, etc.) and hence render all past experiences made
worthless" an this GTA03 mailing list. 
Basically this means to definitly stick with an ARM-based SoC, and try
to stick to derivatives / successors of already utilised peripherials /
other components.
Beside the traditionally (by OM) used Samsung-SoCs (as written, already
a big pro), IMO only TIs OMAP line (e.g. OMAP3530) is about to fulfill
these requirements. 

BTW (an old tune), while I also think a System-Controller / BMC (almost
as in big iron servers) is ultracool, could be utilised in many ways
(key / pushbutton controller, system supervision (voltages, temp.,
etc.), system control (voltages, etc.), controlling audio (e.g.
loudness), GSM, BT, GPS, LCM etc. with MPU sleeping (e.g. during a
talk), etc.), and a TI MSP340F5xxx (these µCs are slow and resource
limited, so pick the current generation) running FreeRTOS supposedly is
the best suited basis for that, the relying on that effort is somewhat
risky, as proper interaction with the rest of the hardware (esp. MPU) is
absolutly crucial for the system stability and a proper implementation
bears some complexity.  Hence, if really depending on an BMC 
implementation, it has to be a prime objective in the GTA04 development.
Ah, and in a clamshell design an MSP340 could be driving a small
secondary display (e.g. 96x128 monochrome; the LCD controllers in some
MSP430s are of no use, as they all are for driving 7-segment displays)
and work as a keyboard controller; just dreaming :-) .

More information about the Gta03 mailing list