[gta04] Meeting minutes for GTA04 discussion 20080411

Andy Green andy at openmoko.com
Mon Apr 14 20:10:11 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> ~ - If we see any user interaction with the phone, ie, touchscreen,
|> buttons, we always power the LCM backlight and S3C6400 ready to respond
|> to what it is he wanted to do
|
| Hmm, I'd leave the decision whether to power on the backlight or not
| to the CPU. Before the CPU is up, there's nothing useful to display
| anyway, and the CPU (application, really) may very well decide not to
| bring up the LCM.

OK, fair enough.  I guess a button might cause the CPU to make a beep
for feedback or something.

|> Stuff that goes through the CPU has dead-time when the CPU is down, and
|> loads the CPU when it is up.  For example, currently the motion sensors
|> generate 200 or 800 interrupts a second on the CPU all the time neod is
|> up, this has a power dimension.
|
| That's in fact the perfect example for something the CPU can't do
| usefully without expending great amounts of power (in relation to what
| else is going on in the system), but something that's easy to do for
| the MPU.

Well we can still come at it from the threshold side to reduce it if we
wanted to get rid of MSP430.  There is another issue that gestures would
be lost while the CPU came up.

|> We can still meet the gsm polling if we schedule wakeups from deep sleep
|> externally or via RTC to do the polling, we still spend the vast bulk of
|> time during the call with the CPU down.
|
| I suppose we could just clock it down if we're sure there's nothing else
| to do. That might bring CPU power consumption within a small enough
| fraction of the modem's power consumption. (Which should be pretty high
| during a call.)

Yeah.  But a lot of the time we want to black out the CPU when we're not
on a call.  We need some infrastructure for timed wake anyway.  If we
did this effort for being on a call only, I would take the point but we
need it generally.

| At least in GTA01/02, the issue is also that the CPU has to receive
| things on the UART, so almost no dead time is allowed. This may be
| similar also in GTA04, just with protocols that aren't quite as easy to
| handle as UART (which the MPU could do just fine, of course).

I'm not sure this is the case.  When I asked Erin and Sean Chiang about
this they made it sound like the CPU is polling for status, not waiting
for async response.  And that fits what I understood about the +++AT
- -based command set of these things.  In that case, we are just
periodically waking and polling from CPU and there is no issue.

| As I said, I think the MPU should try to do as little as possible, but
| do it well, and keep plenty of room for future demands, since they will
| certainly come. The more we can let the CPU handle, the better, since
| this reduces the number of Openmoko-only quirks in our design.

Well, we can note the smallest possible number of things for the MSP430
to handle is zero, I think we should note it and think about it too.

Another way to put "more things we let the CPU handle the better" is we
should take care that the MPU doesn't HIDE things that close off
possibilities if the CPU could have seen them RAW: likewise then we
don't close off the possibility the CPU doesn't want to deal with it so
the MPU should have that opportunity.

|> Let's identify what that other chipset/component does and costs then we
|> can compare it.  I don't have shares in TI :-) but I know MSP430 is very
|> low power and Milosch for example had success with it.
|
| Also, it has JTAG, which is quite exceptional in the small MPU segment.

Good point.

| By the way, do you already have an idea which of the many MSP430 chips
| and/or sub-families would suit our needs best ? I remember that Milosch
| mentioned that some better supported Linux tools than others, so this
| would be something to consider. It would be kind of sad of one had to
| use Wine or Windows just to make some new firmware ...

I guess Allen and now Joerg will choose something and propose it, if we
still go down this path.

|> Right.  We perfer not to have the NAND at all and use a small 256KByte
|> NOR to hold the bootloader.
|
| For GTA02, we looked for the cheapest/smallest/lowest-power NOR we
| could find, and ended up with 2MB. If we want to put a bit of a recovery

Events have overtaken this, we learn get some NAND on the S3C6400
without choice so there is no point for NOR.  I guess we use the NAND
for bootloader... it says the first 128KBytes of the NAND is guaranteed
not to be "bad" "with ECC".

But if we want to put the backup/secondary kernel+rootfs in there too,
we have to support enough bad block / ECC comprehension in the
bootloader to put it there and pull it out again.  (The bootloader could
be capable to read a specially named file from SDCARD root dir if
present and copy it into NAND during production and subsequently).

Although I don't like initramfs for this job because it is either too
big or too limiting, if in fact we did use initramfs, we would have the
situation that the only bit of software that needed to know about NAND /
bad blocks / ECC would be the bootloader.  The initramfs is in RAM by
the time Linux sees it.  It's not ideal but it isn't too bad either, we
end up with bootloader and secondary / backup kernel + rootfs in NAND
without Linux needing to know about NAND at all.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgDnf4ACgkQOjLpvpq7dMo3IgCfXNL+J+hx4qmw/T9ivKZVvfk6
gnoAnj+9Mb0v8j8GoIpYIlURngMxJvJZ
=EEjK
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list