id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,blockedby,blocking,estimated,haspatch,patchreview,reproducible
3,Debug Board trying to control GSM_EN / FA_19,laforge@…,sean_chiang@openmoko.org,"Looking at the debug board schematics, there is a transistor with some
resistors connected to GSM_EN (called X_FA19 in that schematic).

The way the transistor is being used, it has a pull-up resistor to
+3.3V, making it pull GSM_EN to ground.

Only if CEN_FUNC0 is pulled to ground, the transistor Q1 is switched
'off' and thus the pull-up resistor R106 becomes active, pulling GSM_EN
to high level.

CEN_FUNC0 is only present on pin 16 of the JTAG connector.  IF your JTAG
probe grounds that pin, and it is connected, then the serial port will
work.  otherwise it won't.  Since my USB-JTAG doesn't ground that pin,
and I only use the wiggler for flashing (but disconnect it before
booting), it never worked for me.

Sean seems to have connected the wiggler at all time, thus the serial
port works for him.  Am I right, Sean?  Can you verify my analysis by
disconnecting your JTAG probe and checking whether the serial port still
works?

I think this is a general mis-design between the debug board and the
GTA01.  The question is: Who drives that signal?
To my understanding, it has always been the S3C2410. Configuring GPF2 as
output, and then deciding whether to enable the GSM Modem, or to use the
port as a serial console.  Basically whenever we power-up GSM, we also
switch the serial port to GSM.  If GSM is powered down (such as during
early bootup), we can use it as serial console.

However, such operation collides with the notion that the debug board
seems to take:  It thinks, it owns the signal and thus drives it.

The debug board either pulls the signal high (10kOhms) or drives it to
low using Q1. There is no possibility to set it in ""high reststance""
(like tri-state).

Therefore, a conflict (short-circuit) is basically pre-programmed. Most
likely the GPIO of S3C2410 will die before Q1 does (in case of a
conflict).

My proposed interim solution is:

- Disconnect FA_19 on the debug board (unsolder R105 and R106)
- Use u-boot to initialize GPF2 as output
- initally set the GPF2(GSM_EN) level to high, enabling serial console
- use kernel-level driver to switch GPF2 to low, once GSM is powered up
  and kernel has made sure this UART is no longer used for debug
  messages (switched off system console on /dev/ttyS0)

This has been verified to work.",defect,closed,high,,default component,unspecified,normal,fixed,,buglog@…,,,,,,