Ticket #3 (closed defect: fixed)
Debug Board trying to control GSM_EN / FA_19
| Reported by: | laforge@… | Owned by: | sean_chiang@… |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | default component | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: | buglog@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
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.
As a final solution (in a next version of the debug board), I suggest:
circuitry on the debug board.
We can use switch 5 of S1, since it's current function is just to hard-wire
FA_19 to +3.3V, which is superfluous. FA_19 already has a pullup resistor
(R106), and due to the unconditional pull-up of CEN_MODE0 by R102, there is
nothing that switch 5 of S1 could be used for anyway.