<br><br><div class="gmail_quote">On Mon, Apr 13, 2009 at 11:16 PM, Steve Mosher <span dir="ltr"><<a href="mailto:steve@openmoko.com">steve@openmoko.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div>
A) buildable<br>
B) supportable<br>
C) sellable<br>
D) profitable.</blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This, coupled with my impatience, makes<br>
for spirited discussions between us, but our mutual rspect for each<br>
other keeps the discussion civil. Plus werner plays great tunes.<br>
</blockquote>
<br>
Hehe, thanks :-) I must say that I also find it very enlightening to<br>
better understand the marketing angle of things. Even as engineers,<br>
there are a lot of implicit marketing assumptions we just make, and<br>
and we don't even realize that they may actually be questionable or<br>
even wrong.<br>
</blockquote></div>
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.</blockquote><div>
<br></div><div>Everyone makes mistakes. Sometimes, even software and hardware guys. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- move BT to the PCB (yield goes up) <br>
</blockquote></div>
yes.</blockquote><div><br></div><div>BT == Bluetooth? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- NOR removal (hard to source and eats space)<br>
</blockquote></div>
yes<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Need to find a plan B for unbrickability then. Some possibilities:<br>
- do as we did in GTA01 and depend on the debug board<br>
</blockquote></div>
Yes I love selling that.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- add a NAND trap-door circuit<br>
</blockquote></div>
Explain please.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- integrate IDBG</blockquote></blockquote><div><br></div><div>I'm guessing this is a way to unbrick, or a failsafe?</div><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote>
HA. ok I'll look at it again. I'm more amenable this time around<br>
since I have attach rates for debug and better cost data and Some<br>
anecdotal info on the failure rates of the flex cable. You don't<br>
give up. I like that.. sometimes. So A fresh look.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">anything else ?<br></blockquote></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. GTA02 Glamoectomy - G<br>
</blockquote>
<br>
The moment of great liberation :-) <br>
</blockquote></div>
be gone dreaded glamo</blockquote><div><br></div><div>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).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Atheros are working on a "lean" firmware for the AR6002, but that<br>
won't be ready for some more months.</blockquote></div></blockquote><div><br></div><div>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 asking).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 4. GTA02 -G+E+P add 6410<br>
</blockquote>
<br>
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.</blockquote></div></div></blockquote><div>
<br></div><div>Real FPU? No more software floating point? :P</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Drawbacks of the 6410 include relatively new kernel support, more<br>
difficult SMT, and more difficult thermal management.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
then options of camera, 3g etc etc etc.<br>
</blockquote>
<br>
With the design we have for GTA03, the camera interface works. I<br>
just have to figure out how to get the camera to make good<br>
pictures :-)<br>
<br>
3G is the great unknown.<br>
<br>
For a community-centric approach, I think one important requirement<br>
would be to have a common set of tools, so that everyone can go<br>
through the schematics or layout, look at the CAD data, etc.<br>
<br>
In Openmoko, we always had that distinction of engineers with access<br>
to the proprietary EDA and CAD tools and the second-class citizen who<br>
depended on others to provide them with PDFs. This was always<br>
extremely dissatisfying, yielded a disconnected development process,<br>
and eventually caused problems to get overlooked.<br>
<br>
I'm not sure how feasible it would be to convert the existing material<br>
into something sufficiently free tools can use. PADS to KiCad, Pro/E<br>
to HeeksCAD ? :)<br>
<br>
Another issue is access to vendor documentation. There's a lot of<br>
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.<br></blockquote></div></div></blockquote></div><br><div>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).</div>
<div><br></div><div>Thanks again guys,</div><div>Gerald.</div>