Post- GTA02

[Andy Green]

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

Somebody in the thread at some point said:

Hi Joerg -

>> We have a choice about basing on S3C2443 or S3C6400.  A lot of the info
>> is confidential but not these high level things which are public domain
>> on Samsung's site.
> 
> On Samsung's site I see a registration form to get access to user-manual etc.
> So if everybody may register to get this "confidential" data which is 

Out of scope for me, but this is something we can ask about shortly.  I
was pleased that they had the overview out there at least.

>> S3C6400 is 90nm and has 480Mbps USB2 OTG, 667MHz max clock, some 2D
>> acceleration 
> 
> plus H263/H264 coding and decoding and LCD-interface. This means we get rid of 
> glamo, no?

In this design scenario the CPU can handle everything.

>>  - Focus on SD Card rootfs rather than internal memory
> 
> As long as we get a second media slot, preferably one that's accessable from 
> outside, 'hotswap', that's not adding to the footprint of the case as e.g a 
> USB-stick does.

This is possible to consider, 6400 has 3 x SD channels, if one goes on
WLAN, one for "rootfs" SD inside, we have one to burn.

>>  - Add a small lowpower MPU like TI MPS430 to manage everything
>> seamlessly when main CPU is down.  Stuff like motion sensors, wake
>> sources, battery management, maybe touchscreen, leds so there is an
>> always-on "guiding hand" in the phone that is consistent and reliable
> 
> Well sure a useful gadget, but hard to interface with the main cpu in a way 
> that's not a bottleneck. Should G-meters be accessed by main cpu via this 
> MPU, or shall there be concurrent access. The first sacrifices flexibility 
> (If MPU can't do it, it can't be done), the second adds complexity to both hw 
> & sw.
> I'd prefer to have a main CPU, that's up to reasonable power and back to 
> suspend in a few milliseconds, plus a nice timer to periodically wake the 
> CPU, and all needed interupt lines well done, and intelligent peripherials.
> Alas i fear that's not easy to design.

Well that is kind of seeking to reduce the dead time (which will be
hard), the MPU method eliminates the dead time and any inconsistency in
behaviours.  For the motion sensors, I imagine the MPU manages them
fully and we communicate with the MPU over SPI at 100sps if we really
wanted or more likely  a lower rate.  Raw motion sensor traffic is only
600 bytes / sec (2 x XYZ bytes x 100sps) so this is fine -- currently
motion sensors are quite expensive at 2 x 100Hz CPU interrupts and same
rate event handling.  The MPU can do "integration" of motion for 100% of
the samples over time as well even while the CPU is asleep, so it can
approximate (not mega accurately, but the order of magnitude anyway) how
far you moved and in what direction overall for arbitrary periods
without the CPU.  (Similarly it can accurately profile sleep current
consumption over HDQ without the CPU, something we would love).  We can
do things like wake the CPU because you have been still for a while
after traveling, or force airplane mode even if the CPU sleeps if it
detects accelerations that only happen in airplanes, etc.

If the MPU can do gesture estimation, it means also that we can wake the
CPU with a fully captured gesture handed to it when it wakes a second or
two later... things should just have less discontiguities depending on
the CPU state.  The CPU is then more like an expensive asset that we
leave asleep until we already determined something important happened
than the hassled thing that has to wake before any little thing can be
achieved.

>> To be clear though -- GTA02 is soon going to actually exist, and this is
>> just future talk right now.  But because of that, if you have any ideas
>> about future arch, now is the time to throw them in and they will at
>> least get the time of day.
> 
> Open up existing bonus functions like camera IF, video out..., don't spoil 
> them by using 3 of the 15 GPIOs for other tasks, but instead route them to 
> free pins of some (debug?) connector, or testpoints at least.

Yes that one is sold already :-)  Idea there currently is to provide SIL
pads on the PCB with rich IO, maybe behind the LCM, thanks for reminding!

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

iD8DBQFH4Q4iOjLpvpq7dMoRAhYGAJ9euPTdqIDBedW3maeq7iE6dPp8yACaAmRv
UDMX9TqNY3skZh8NlXXSt4A=
=u6GF
-----END PGP SIGNATURE-----