OBB port on GTM900-B risks causing hw damage with fighting driver outputs on Calypso GPIO3/DTR line
FPC interface pin 22 on the GTM900-B module is defined by Huawei as UART_DTR (input to the modem, output from external host), but physically inside the module it is connected to Calypso GPIO3. This Calypso GPIO pin powers up as an input, and Huawei's official firmware leaves it as such, as needed for the intended logical function of DTR input to the modem. However, the current OBB port to GTM900-B configures this GPIO3 pin as output, as a result of steve-m having blindly copied my GPIO config code which was (and still is) correct for the Openmoko gta0x target, but is not correct for GTM900-B.
If the current OBB code is loaded and run on a GTM900-B module that is wired up externally per Huawei's official documentation, with PFC interface pin 22 connected to the DTR output of a CP2105, FT2232x or RS-232 receiver chip, the result will be a driver conflict, with the Calypso chip's GPIO output and the external chip's DTR output fighting on the same wire. It is my understanding that such driver fighting can cause hardware damage in one or both of the chips, hence this bug should be considered critical.
The proposed patch attached to this bug report is one possible way to fix this bug, out of an infinite number of possibilities. Also my experiments on GTM900-B modules using my MMTB1 adapter indicate that this GPIO3/DTR line appears to be outfitted with an internal pull-down resistor inside the module, hence the Calypso input won't float if the DTR pin on the FPC interface is simply left unconnected.
i'm not sure i am following. according to the schem. in #4030, fpc pin22 is UART_TXD not DTR - please recheck.
Sorry, I am using Huawei's official pin numbering for the FPC interface, the one in their datasheet - I don't know why you chose to reverse these pin numbers on your schem. Right now the following relation holds as a result of this reversal:
Sysmocom_schem_pinnum = 41 - Huawei_datasheet_pinnum
On Mon, Jun 29, 2020 at 03:15:50PM +0000, roh [REDMINE] wrote:
this needs to work even when keeping the stock fw in the modems.
I fully agree. Whatever hardware we ship has to fulfill the above criteria.
i think this should be rejected.
so why should the software patch be rejected?
we will not patch and flash the firmware of all gtm900 modems we get before use/shipping.
who states that this should be done? The gtm900 have original proprietary firmware on them
an will remain to do so.
The patch is just a fix for OsmcoomBB to avoid running into the problem described.
#6 Updated by laforge about 1 month ago
- Status changed from New to In Progress
- Assignee changed from steve-m to laforge
- % Done changed from 0 to 80
This is adressed by an updated patc with Change-Id Ia41f8bc19fb1775b0587fe1ceaa8acd066710aa5 currently in gerrit as https://gerrit.osmocom.org/c/osmocom-bb/+/20327