GTA04 Block V4

[Andy Green]

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

Somebody in the thread at some point said:
| 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.

The default voltages are OK, but the sequencing is wrong for 6400.  They
have four steps where they can bring up the rails, for some reason in
this variant they bring up the important ones all at once in step 3.
The Vcore voltage is higher than it needs to be but that should be OK.
I think we can slug rails with caps to change their risetime but I
didn't hear much discussion of it yet.

| 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 :)

Actually I bent over backwards to make that list neutral and went as far
to draw the block diagram both ways, when it looks much simpler without
the MPU.  The list is formed from all of the aspects I could remember we
touched on to date.

Created by the stridency of the "kill" emails there are apparently two
sides formed in this debate, the "give me MPU" and the "give me death",
but the reality is more complex.  I was and am quite open to the no-MPU
path, it's even considered a goal.  But as this design matures and
solidifies, in the power area for example, we are seeing more
opportunities for a supervisor to take care of stuff outside the CPU.
It's pretty annoying to see people (who are not going to have to take
care of it CPU or MPU side or even in schematic complexity fallout)
trying to remove that option for dogmatic reasons without understanding
the detail in context.  Just sticking things on a CPU GPIO is the start
of the solution not the end of it, it also has costs and ramifications
all over the shop.

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

iEYEARECAAYFAkga0EEACgkQOjLpvpq7dModYgCfZdUW/2Gm0HwockA/dTieJ9pF
djAAn1lEbEr8x+ZlnSHRtiGGL2ra/Ykz
=X4sf
-----END PGP SIGNATURE-----