[gta04] Meeting minutes for GTA04 discussion 20080411
andy at openmoko.com
Mon Apr 14 13:10:34 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
Hi Anthony -
I changed this to kernel list to save Wolfgang some blood pressure :-)
|> My consider is a some user case:
|> I think if the vibrator is active, it notified the user of some
|> message(or something), Next we need turn on LCM and display an image for
|> user(like call-in, SMS, alarm&etc.). At moment, the S3C6400 and MCU is
|> active. Because LCM control by S3C6400.
|> keypad same as vibrator, user press keypad do something, then LCM also
|> need turn on and display image for user, Even touch-screen. If our
|> handset doesn't turn on a LCM, the user can't to identify what happen on
|> our handset.
Sure. I guess I may have made it sound like we should never turn the
S3C6400 on :-)
I propose some guidelines about it without mentioning MSP430. I try to
consider in this mail working without MSP430.
~ - if the LCM backlight is powered, the S3C6400 MUST also be active,
because it provides the video data for the LCM.
~ - the phone usage has "modes" or "states", ie, standby, in a call, user
is using applications. When the phone is stuck in a state, it can turn
off everything it doesn't need in that state. That includes when we are
"in a call", we don't need the LCM or the CPU.
~ - User interaction with the phone moves us between states. If we
didn't see a button or touchscreen or motion, we remain in the state.
For example if we are in a call, we stay "in a call" with CPU and LCM
off until the user wants to hang up or the other side hangs up.
Likewise, if we go to deep standby, we stay in standby until incoming
call, buttons pressed, etc.
~ - 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
~ - If there is no user interaction with the phone or other events, we
move to "Deep Standby" after a little timeout, with LCM backlight off
and CPU off.
|> if main function active will be influence to S3C6400, let S3C6400 is
|> maybe we can move these key/main functions into S3C6400. next, we remove
|> MCP430, then an other function (except: keypad, vibrator&) replace by
On GTA01 and GTA02 we used this approach where the CPU is responsible
for everything, so we have some experience with this method. It
basically works. This and the MSP430 method are the two approaches we
can consider that are largely in conflict.
In the GTA01/02 cases, we implemented support for charging modes and PMU
into U-Boot and kernel separately which was a major pain. U-Boot and
kernel power implementations are different (U-Boot does not respond to
PMU interrupts like USB cable change) and act different. While the
kernel boots, there service for PMU actions is deferred, but it still
gets serviced eventually. For GTA04+ case we determined to kill U-Boot,
without MSP430 it means we could just ignore power management until we
get into Linux... that is a simplification over GTA01/02 that is OK for me.
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. But in truth, we can improve that using
the thresholding on the sensors and improving the driver around that.
Also there is an assumption at every level that the CPU is always up,
for example during a call at the moment the CPU is assumed to be able to
continually poll the gsm chipset. Some folks think about this device as
a desktop linux box not a mobile device that has to take care about
battery life at each step, and the CPU running is pretty expensive. To
get really good use from the battery we need to adapt that thinking to
understand that the CPU is expensive and should not stay up when it has
nothing useful to do.
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.
Something else is that we won't achieve really instant suspend and
resume with Linux. Depending on what the Samsung BSP drivers act like
it can be many 100ms each way or variable. Its possible this laggy
behaviour will make a bad user experience. We can find out about this
when we have the BSP and eval boards.
|> other chipset/component. Thus, we maybe can try to reduce cost.
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.
| ~ - Split mDDR 64 / 64 is not ideal, external bus routing for mDDR is
| likely to be challenging. We can end up that the external bus routing
| slows down even the internal MCP mDDR. It is better if Samsung can
| provide 128MB mDDR on the MCP (and no NAND!), I understand we don't
| control that, if we can't do it well ok.
|> I don't suggest use MCP (oneNAND 256MB, mDDR 64MB).
Well see a bit later about mDDR / MCP discussion.
|> I get a some message: the kernel, root-fs.img, home.img will be to place
|> into internal SD card. If this right, then the oneNAND will be to place:
|> bootloader& (I guess also have: SIM-IMEI, network NIC-MAC address& I
|> can't sure. Somebody can tell me? Please)
|> If data size is very small in oneNAND, I think it is an extravagance.
Right. We perfer not to have the NAND at all and use a small 256KByte
NOR to hold the bootloader. It is not clear if Samsung will force us to
have NAND in the MCP. If they force us to have it, we cannot waste it
:-( It will mean we have to put stuff in there and that means all the
crap about bad block management, JFFS2 and so on.
These MCPs with NAND and mDDR in there rock... IF they give you the
ingredients you want. If they give you the wrong ingredients (NAND we
didn't want, not enough mDDR) it will make pain.
|> Second, if we need add extra mDDR (64MB). Why can't combine both
|> (internal and extra mDDR) to become a single extra mDDR_128MB? or
|> replace by other DDR?
There are two issues with the mDDR.
~ - Samsung may force us to have some in the MCP, like the NAND issue.
We can't waste it then same as we can't waste NAND they force us to have
~ - external mDDR requires tight tolerance in PCB routing and techniques
like impedence matched routing. I don't know how good a job we will do
on that if we didn't have experience of doing it before or the CAD
software doesn't support impedence / length matched routing. We can end
up with degraded or unreliable memory bus performance quite easily. So
it is ideal if we can get 128MB of mDDR in the MCP and no NAND.
But if we can answer the second part about PCB routing, and Samsung do
offer the CPU with no memory in MCP, then actually I think that is not a
bad way. We can get away from NAND, take our own responsibility for
mDDR and have a small NOR for bootloader.
|> Third, the cast view: chipset/component should be share with other
|> Example: if we can select 2 component on our project, and each unit
|> price is same:
|> 0 5000 pcs = $ 5/pcs
|> 5001 10000 pcs = $ 4.8/pcs
|> 10001 20000 pcs = $ 4.5/pcs
|> 20001 30000 pcs = $ 4/pcs
|> 30001 50000 pcs = $ 3.5/pcs
|> In GTA04, we need 15000 pcs.
|> Next project/other platform, we need 13000 pcs.
|> If 2 project component is different
|> Cast = 15000 * 4.5 + 13000 * 4.5
|> If 2 project/platform use same component:
|> Cast = (15000 + 13000) * 4
|> I think this component is difficult use on other platform&it is almost
|> bind on Samsung's product.
|> I suggest we can use common/universal flash and DDR.
I am not sure that for a company like FIC, the pricing is quite as fixed
as it is for small companies as you show. Even for smaller companies,
it's often possible to negotiate starting at one or two price breaks
better if you can convince the vendor you have a good chance to reach
high volumes. When the volumes can be very big like with FIC, probably
a vendor might support a low volume introduction at higher volume
pricing routinely just to get the design-in.
But I agree about component reuse for a different reason. Once we get
anything working, software or hardware, it's pretty cheap and low risk
for us to deploy it again. We already have proven schematics and
drivers and so on.
We are fixed on whatever CPU we choose for the same reason, once we took
the hit of prototyping it and getting it working, we are going to want
to amortize that over more than one design. (This is doubled when you
consider the software investment in getting Linux working well on the
platform). On the subsequent designs, the risk is low for us because we
deploy the same schematics we just had success with. So it isn't a
consideration to be locked into a particular CPU for some period, we
actually want that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel