next-generation MPU discussion

joerg at openmoko.org joerg at openmoko.org
Fri Apr 25 17:43:34 CEST 2008


Am Fr  25. April 2008 schrieb Werner Almesberger:
> joerg at openmoko.org wrote:
> > The idea is *every* GPIO is I *and* O, so you have maximum flexibility.
> 
> Our layout girls are probably busy making "Joerg" voodoo dolls right
> now ;-)

She's sitting next booth to me, so far I didn't notice any black magic.
Well even schematics not started yet, let's wait for the PCB-routing... ;-)


> 
> I'd say that we should consider GTA04v1 (v0 ? ;-) as a first test
> balloon, where we can do things that won't make sense in the final
> product, if doing those things helps us to speed up development.
> 
> This will also help us avoid endless haggling about some minor features
> that may get overridden later by larger design decisions anyway.
> 
> So I'd agree with the MPU being able to do more than strictly needed.
> Then, as development continues, we'll gradually get a better idea of
> what we really need and what not, and then we can always decide to
> remove some connections 
Remove connections? Never! Maybe remove a whole layer, so it's worth it, but 
some connections... :-/
 
> or even to pick a less powerful and cheaper 
> chip.
Yep.

> 
> By the way, "help to speed up development" should also go for our
> hardware team. If any of this sounds unreasonable for you, please don't
> hesitate to raise your concerns.
> 
> It wouldn't do us any good to design a software engineer's wet dream
> platform where all the system software can be easily done in half a
> day, but where we need a 50-layer board and dozens of prototype runs
> to get the hardware working ;-)
> 
> > BTW: which number of LED is GTA04 
> 
> I don't think we know yet. I think Steve hates them a bit. I'd like
> to have at least one "engineering LED" for debugging, but it doesn't
> have to be visible when the case is closed :-)


We have to plan for _some_ maximum. 64? 256? Drop some of them later no 
problem. This is our core-design!


cheers
jOERG




More information about the openmoko-kernel mailing list