GTA04 ... JTAG / Autonomous PMU voltages and sequencing

Andy Green andy at openmoko.com
Wed Apr 30 11:28:44 CEST 2008


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

Somebody in the thread at some point said:
| Andy Green wrote:
|> Who knows, Werner found it uses some weirdo TDI clocking scheme.  Do we
|> really want to buy into that?
|
| I'd still like to have the option of using JTAG to the MPU. If it
| works, we can remove the multiplexer and its support circuit and
| everyone will be happier for it. But I also agree that JTAG won't
| work "out of the box" for the MPU and that the default configuration
| of the GTA04v0 board should be not to have it in the chain.
|
|> There are other issues around needing to
|> deliver on timing constraints for flash programming which we can't
|> really guarantee to do with an arbitrary host either, but the bootloader
|> in the MSP430 does guarantee correct timing.
|
| I think what one has to do here is to download small code fragments
| into MPU RAM, and then execute them there, outside of JTAG control.
| That way, the MPU will use its own clock. Of course, this also means
| that the programming process becomes more complex.

We should just use the internal bootloader for lower risk and faster
implementation.

Unless there's an actual proposition for an actually better way we
should assume now we use UART -> MSP430 bootloader.

|> Actually I think it's important that the 6400 can come up without MSP430
|> being there at all, since we know it just about works good enough for
|> GTA02.  Then we null out much of the risk of introducing the MSP430.
|
| Well, let's consider this once we've looked at the exact power
| sequencing needs of the 6400. It would certainly be desirable for
| the 6400 to be able to come up without MPU involvement.

We need to consider it right from the start if we will succeed to do it.
~ I looked at CPU Vcore requirement and it is met by default Vcore from
GTA02 PMU variant, so that's OK.

In terms of actual sequencing, that PMU variant 04 brings up 3.3V, 1.8V
and Vcore all that the same "activation phase", phase 3.  This was
evidently good enough for 2442 :-O

I studied the sequencing requirement for 6400X54 (ds p 1129).  It
basically wants VDDIO 1us before Vcore (=VINT).  We can get this by the
bypass capacitive load on VDDIO being considerably larger (as we would
intend anyway) than that on Vcore.

So I didn't see a problem here.

| However, in case the MPU needs to be in charge, it should be able
| to assert RESET. So if we have the pins PMU.nRSTHC (OCF50633, reset
| out), MPU.nRST (MSP430, reset in), MPU.GPIO (MSP430, arbitrary GPIO),
| and CPU.XnRESET (S3C6400, reset in), there should be two possible
| configurations:
|
| CPU comes up without MPU:
|
|   net1 = (PMU.nRSTHC, MPU.nRST, CPU.XnRESET)
|   net2 = (MPU.GPIO)  // not used
|
| MPU needs to reset the CPU:
|
|   net1 = (PMU.nRSTHC, MPU.nRST)
|   net2 = (MPU.GPIO, CPU.XnRESET)

OK, this is also compatible with MPU being NC on board too.

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

iEYEARECAAYFAkgYO8wACgkQOjLpvpq7dMpEJQCeL3TNB/mffwyp+LgCVdXGW0aS
1ssAnj47SlV5e5RLEBxNocn2XrHwaNUa
=b1Nj
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list