GTA04 Block V4

[Carsten Haitzler (The Rasterman)]

On Thu, 1 May 2008 22:43:53 -0300 Werner Almesberger <werner at openmoko.org>
babbled:

> Carsten Haitzler wrote:
> > pmu sequencing risk: as i understand it the pmu comes in a flavor that has
> > its default exactly what we want.
> 
> I wish ... :-( It's merely the variant that combines availability with the
> least evil set of default. Actually, I'm not even sure if we actually have
> a choice among variants. If we do, it's not among many.

so what is the default pmu state on bringup? i find it a bit hard to fathom
that it is far from what we want - or at least need or can live with long
enough to get kboot (or uboot) up to quickly re-program it to something a
little nicer.

we need enough power to run the soc and ram. likely battery has to be in a
charging state. we seem to accomplish this find on the gta02... so i'd like to
know why we now need an mpu to fix anything? i just saw a list of arguments
(the matrix) that lean the view to the mpu making it look really good where
most of those arguments are not useful or "when it comes to reality" wrong as
userspace is going to disagree and not want to be idle :)

nb - we also work on a premise that wakeup is slow. if the n800 ands my rokr
can live for days with the core just set to 0 clock (not suspended) or they can
suspend and wakeup almost instantly - we can too. sure 0 clock consumes more
power - but it means we do get instant-on. we are putting in hardware for what
is really a software problem. most of the things the mpu claims to solve
(respond to button presses, touchscreen, accelerometer etc.) are just not viable
uses. if we did it, it'd make life more complex. the 6400 has separate clocks
for everything as i understand and so we can very easily clock anything up and
down as we want. this is what we need to do anyway. :)

> > 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,
> 
> This is indeed one of the less pleasant aspects of this. I had a look
> at several various low-end ARM microcontrollers, but they all tend to
> be a bit on the power-hungry side, at least when compared to the MSP430.

this is actually one of the big things that makes me go "oh shit this is going
to complicate things and become a source of all sorts of trouble". :(

> The nicest one I found is the ST STM32F103 series, but they still eat
> about 9mA at 8MHz (top speed is 72MHz, but then you need a crystal and
> 50mA), and 14uA in "Stop". (The low-power modes are similar to the big
> ARMs, just the overhead is greatly reduced. Note that "Standby" here
> loses the RAM content, so one has to use "Stop" to do something useful.)
> 
> http://www.st.com/stonline/products/literature/ds/13587.pdf
> 
> A further disadvantage of picking such a chip is that we couldn't scale
> down as far as with 8-bit or 16-bit microcontrollers. I.e., if we find
> we only need very few features, the smallest member of the MSP430 family
> comes in a 4x4mm package and costs below USD 1, while the smallest
> STM32F103 would still be 6x6mm and cost more than USD 3.
> 
> Of course, it's a real ARM, with tons of peripherals, real JTAG, etc.
> 
> - Werner


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