GTA04 Block V4

[joerg at openmoko.org]

Am Do  1. Mai 2008 schrieb Carsten Haitzler:
> On Wed, 30 Apr 2008 22:10:46 +0100 Andy Green <andy at openmoko.com> babbled:
> > This documents a proposal that we won't use and the no-JTAG MSP430 with
> > UART mux that it seems we will.

As I was very busy the last 4~6 weeks with a wide range of different topics 
mostly related to my start at .tw-OM-office, until recently I wasn't able to 
really catch up with the lists' postings and thus probably missed quite some 
of the arguments for and against a MCU (MicroController-Unit. I prefer this 
acronym, for it's more distinguishable to PowerManagementUnit).
[I know I missed the Wednesday meeting as well. Sorry - blame google calendar 
for that ;). At least I wasn't invited.]

Now on topic:
MCU is a technically interesting thing to do for GTA04 (Engineer's point of 
view), but I missed description of any exactly defined usecase up til now, 
that would make me think it's worth the additional effort and -in relation- 
extremely high cost (13$/chip, Sean tells me: device costs increase by factor 
3 of part costs. Plus circuitry engineering, PCB-routing, FW-coding 
expenses!).
Now I hear on the GTA04 meeting (that I missed (shame on me)), consensus was 
we *will* use the MCU. So I think there have to be some good arguments that 
came up there on Wednesday to convince everybody except me it's worth to sell 
GTA04 on X+~60$ with MCU, and there are usecases like x), y), z) and 
corresponding added value of device, compared to a GTA04 w/o MCU that sells 
for X$.
Please give me a comprehensive list of these usecases to
a) convince me it's the right thing to go MCU
b) check against this list whether our design here will meet all these cases.
The "wired-or" design I intend to suggest (and did suggest in London) 
basically means you can break out the MCU from any GTA04, and the device will 
continue to function. This reduces quite some of the risk, and may give us 
additional functionality, but I have to check whether we can achieve the 
exact goals we have to use the MPU for, by such a design. So exactly 
specified usecases (specs) and what is the benefit from using MPU in each of 
them is needed.

As Andy stated in GTA02.internal:
> | Other manufacturers have impressive cpufreq solutions, that's how they
> | get amazing standby + instant(!) on.
>
> This is correct, the culprit is the S3C2442 itself which is basically
> hostile to dynamic clock scaling (breaking UARTs, etc).  Even the 2443
> fixed this and the 6400 really fixed it with separate PLLs.
We *can* do *instant* 'resume' with 6400, just by software improvements, so I 
think it's better use of resources to fix the dead-time-issue this way, than 
by adding complexity and cost to hw. Software costs are not per device, MCU 
*is*!



> 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).

PowerMgmtUnit can do LED flash, in a limited number of sw-selectable ways. No 
need for MCU - unless you want spend X-ties of $ for a custom pattern. :-/
Still we can wire-or the LED's and do whatever fancy trick to them while CPU 
up.

 
> * 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.

+1! I wouldn't buy a device I have no option at least to have the screen up 
during a call - I want to see duration, RF-signal quality, battery state etc 
pp. The possible call duration factor of *1,2 ~ *2.0 doesn't bother me at 
all.
Again: with 6400 we can clock down. We can dim backlight. No need for 
*full*suspend*, which is the only state the MCU is designed for.


> * 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.

Negotiation of USB-Vbus current is not useful anyway. This can be done by CPU, 
program PMU, go to sleep. As long as we plan for a design that allows us to 
trow out the MCU later on, we have to be able to start without MCU right now. 
And we are, did it for GTA02, and probably can do it for GTA04 as well.


> * 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 :( 

I don't see much use in checking the accelerometer by MCU either, as I'm told 
they have a threshold so you can wake CPU when device is moved. There is 
nothing really meaningful that can be done beyond this in the little MCU, 
that's WORTH going MCU.


> * 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.

Yep. TS-gesture recognition sounds like a stupid thing, if we can have some 
additional pushbuttons doing the same more accurately, easy (=convenient) and 
MUCH simpler/cheaper. Again, what for would we even need any input from TS, 
as long as nothing inside the device can answer on it in a reasonable way 
(when CPU is down, and *IF* we can't achieve to wake it up in fraction of a 
second)?

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

All this still is a big mystery for me - probably I have to come back to .tw 
in a few weeks to learn about factory, testsoftware etc pp.
As with software- vs hw-implemented features (clockdown above), there is 
per-device cost in implementing test features to the device, vs per 
production-line cost in making fixtures, getting test equipment etc...
Of course the production staff would like if the devices 
build/calibrate/test/pack and ship themselves ;-)


> 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.

Same argument as above. CPU can do this and go to sleep again. There's nothing 
bad in waiting a few seconds until the PMU is programmed correctly (other 
than maybe when user pulls charger and *instantly* [means <resume-time, which 
we think we can get down to <1sec with sw-changes] inserts some 
hostconnection that will moan when leeched 1A. What a usecase is *this*? Need 
MCU?!?)


> 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 
mpu =mcu
> 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 
mpu =mcu
> addition 
> to the cpu (jtag),
Even worse: mux serial!
> 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. :)

Go for cpufreq redesign of kernel!


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


Most of my statements not verified for correctness, so "IIRC" and "I think" 
applies to all of them.


cheers
jOERG