GTA04 PMU / Core arch block diagram v1
mathias.boesl at gmx.de
Wed Apr 2 16:56:11 CEST 2008
> There's more scope for these "hard-acting" IO events now the MPU will
> monitor the UI IO.
IMO there are not only IO event which should "never break", but things
like the timer for the alarm clock.
> | the system should be as much off as possible for as much of the
> | time as possible. But policy decisions belong into user space. You
> | don't want to have to flash new MPU firmware just when you add a
> | new application
> Consider that GPS app opens a socket or dev node, writes "60s" down it
> to queue a wakeup event with the MPU, and then does a blocking read.
> The CPU suspends in the meantime, when we get woke with that cookie the
> read unblocks and the GPS app does its thing before looping.
> So "policy" and fulfilment lives on the CPU in userspace, enforcement
> lives on the MPU,
How do you think about implement a small kind of api / abi in the MPU
that can be accessed by the CPU in user space combined with something
like a "event queue" that lives in MPU RAM ?
First create a virtual device /dev/mpu which represents the MPU in user
space and can be accessed something like
# echo "powerdown audio" > /dev/mpu
# echo "setdata alarmtime 08:00" > /dev/mpu
# echo "getdata motionsensor" > /dev/mpu | /bin/someApplication
This way you can use the MPU as "latch" if CPU is up.
The second thing is the "event queue" which means the MPU has a queue of
commands in RAM that has to be executed on special events. Every command
itself is written in the ROM. So you only need one byte to choose the
Powerbutton pressed event : <powerup PLLs> , <start Clock>, <powerup
Backlight>, <resume CPU>
or something like that. This way the usage Policy (which I think IS very
useful) can be done by MPU (rapid response), Policy can changed easily
(by writing the new queue to /dev/mpu) without flashing. Another point
is that you get a very high amount of openness because you can change
virtually the whole behavior of you moko.
I am reading the openmoko.kernel ml for about 2 months and i like
(almost) everything i read here, but this problem IMO is very important
and could choose the direction in which the whole openmoko will go.
More information about the openmoko-kernel