GTA04 Block V4

[Carsten Haitzler (The Rasterman)]

On Wed, 30 Apr 2008 22:10:46 +0100 Andy Green <andy at openmoko.com> babbled:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This documents a proposal that we won't use and the no-JTAG MSP430 with
> UART mux that it seems we will.
> 
> Joerg, you were looking at FTDI earlier, do you have an idea for how to
> mux the UART that will be good for userspace using /dev/ttyS1 semantics?
> ~ Eg, RTS or such?

i didn't think the 2nd 6400 was being taken seriously (enough) to put it on a
diagram. ok. here's my feedback:

the comparison chart:
* smarts while cpu down: irrelevant. we don't need any smarts while it is down
imho. we can live without a flashing led. hell - we don't even know *IF* we
will have led's (worth talking about).

* flash led's during call: the spu will be up and kicking. no need for mpu here.
there is no sense suspending the cpu during a call. if its voip it will never
be able to suspend, if its gsm - it likely needs to have features like beep
every 30 seconds to let u know how long a call is (this is a common option on
phones), as well as display call duration on the screen etc. i see no sensible
reason to suspend or even zero-clock during a call.

* power management ok during boot: as i understand it the pmu we have by default
has a sane configuration - it is delivering the right voltage to the cpu and
ram to power them up and charging battery. the mpu couldn't do anything sane
like negotiate to 500ma on usb without the cpu's help so it's not much use
really.

* wake dead time...
* seamless motion capture: never going to do this without cpu up - who is
volunteering to be the mpu developer in what spare time with a toolchain and
compiler unknown etc. etc.? seriously - will you have enough grunt to even
sanely process the motion events and make an intelligent decision. not to
mention why would you want to know about motion while asleep? really? give me a
good example. wake up on shake? we can live without. it's a spurious feature :(

* seamless touchscreen capture: same as motion capture... if the ts is to be
listened to the screen had better be up and drawing/responding to those events.
that means cpu is up. mpu isn't useful.

* button lag covering: if the screen doesn't respond and redraw -
it's pointless. users must see the result of their interaction. they can't even
see WHAT to press unless the screen is up and drawn - that means cpu is up.
without it it's a black panel that has nothing on it.

* production test assist...
* get suspend current while cpu down: don't you guys have lots of measuring
equipment for this? :)

need to deal with power and charging logic inside linux/bootloader: we already
have this - in u-boot. no work to be done. mpu means this needs to change. so
more work.

power in standby: spurious argument. it will be the SAME for mpu and no-mpu see
the above. cpu will need to be up in all cases of any interest - mpu or not.

pmu sequencing risk: as i understand it the pmu comes in a flavor that has its
default exactly what we want. so i'dsay the risk is zero in both cases - right?

...

so taking this into account, pmu has added to it the need to get a new toolchain
working, a developer time to learn it and write code for it, for a new
architecture and proprietary toolkit, extra work to flash the pmu in addition
to the cpu (jtag), the extra mpu cost, the extra board space. all for no
benefit if you agree to my arguments above? (that the mpu doesn't buy us
anything useful from a product and usability point of view).

i still think the mpu is not needed. i'm unconvinced of its usefulness. if
there has to be another chip - make it useful (6400!), but really - just don't
put one on. go for the simpler no-mpu option. :)

so that's my take on it. most of it comes just from the userspace and software
side.

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>