Gerald A geraldablists at gmail.com
Wed Apr 15 04:33:17 CEST 2009

On Mon, Apr 13, 2009 at 11:16 PM, Steve Mosher <steve at openmoko.com> wrote:

>   A) buildable
>   B) supportable
>   C) sellable
>   D) profitable.

Thanks for both this breakdown, and the 13 step one. It does help clarify to
me what you guys are trying to do, and where the efforts go.

This, coupled with my impatience, makes
>>>  for spirited discussions between us, but our mutual rspect for     each
>>>  other keeps the discussion civil. Plus werner plays great tunes.
>> Hehe, thanks :-) I must say that I also find it very enlightening to
>> better understand the marketing angle of things. Even as engineers,
>> there are a lot of implicit marketing assumptions we just make, and
>> and we don't even realize that they may actually be questionable or
>> even wrong.
> I appreciate that. I readily admit to some classic bone head moves. For
> people's edification I can detail them... I did a bit in the writing about
> chasm theory. I would definitely do things differently.

Everyone makes mistakes. Sometimes, even software and hardware guys. :)

> - move BT to the PCB (yield goes up)
>    yes.

BT == Bluetooth?

>  - NOR removal (hard to source and eats space)
>    yes
>>  Need to find a plan B for unbrickability then. Some possibilities:
>>  - do as we did in GTA01 and depend on the debug board
>      Yes I love selling that.
>>  - add a NAND trap-door circuit
>      Explain please.
>>  - integrate IDBG
I'm guessing this is a way to unbrick, or a failsafe?

What I'm wondering is if there would be a way to slap a small Readonly piece
in there, which can do a reflash. I know I live in utopia here, but it might
be one way to do it. Comments?

>>       HA. ok I'll look at it again. I'm more amenable this time around
>      since I have attach rates for debug and better cost data and Some
>      anecdotal info on the failure rates of the flex cable. You don't
>      give up. I like that.. sometimes. So A fresh look.
>> anything else ?
>>    2. GTA02 Glamoectomy - G
>> The moment of great liberation :-)
>      be gone dreaded glamo

Question -- is there anything in this form factor which is actually better
then the Glamo? (I know about the problems, and the suck factor, but am
wondering if it's trading a suck factor we kind of understand for an unknown
suck factor, or if we'll see something better on the Graphics front).

Atheros are working on a "lean" firmware for the AR6002, but that
>> won't be ready for some more months.
And, if this one is selected, will we be able to do a field upgrade, or
would it be another TI GSM firmware upgrade game? (I think not, but just

  4. GTA02 -G+E+P  add 6410
>> The 6410 would give us more connectivity choices (more SDIO, more UARTs,
>> High-Speed USB, etc.), better overall performance (FPU and all that), and
>> more flexible clock management.
Real FPU? No more software floating point? :P

> Drawbacks of the 6410 include relatively new kernel support, more
>> difficult SMT, and more difficult thermal management.
>>    then options of camera, 3g etc etc etc.
>> With the design we have for GTA03, the camera interface works. I
>> just have to figure out how to get the camera to make good
>> pictures :-)
>> 3G is the great unknown.
>> For a community-centric approach, I think one important requirement
>> would be to have a common set of tools, so that everyone can go
>> through the schematics or layout, look at the CAD data, etc.
>> In Openmoko, we always had that distinction of engineers with access
>> to the proprietary EDA and CAD tools and the second-class citizen who
>> depended on others to provide them with PDFs. This was always
>> extremely dissatisfying, yielded a disconnected development process,
>> and eventually caused problems to get overlooked.
>> I'm not sure how feasible it would be to convert the existing material
>> into something sufficiently free tools can use. PADS to KiCad, Pro/E
>> to HeeksCAD ? :)
>> Another issue is access to vendor documentation. There's a lot of
>> material that is under some form of NDA and that would have to be
>> made accessible to the community in order to allow people to understand
>> how things work.
I remember a lot of questions and suggestions that people be "employed" by
OM for a nominal amount so they could gain access to the NDA. Of course,
there would be legal overhead that need be involved, but if I remember the
NDA's were for the documentation provided, but not for the derived works
(meaning an OM "employee" could write a document explaining OM's
implementation, could write open source drivers and release them, etc).

Thanks again guys,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/gta03/attachments/20090414/f737faa0/attachment.htm 

More information about the Gta03 mailing list