[Xiaomi Mi 5 Questions & Answers] davidcie:
Bit of a long shot but hey, this is XDA :)

I purchased a soft-bricked Mi 5, the FDD-LTE variant. It had a functioning fastboot mode that worked every single time, but no official ROM liked to flash stating that phone is locked. (At the time I did not know of Xiaomi PC Suite to try.) So I went down the EDL rabbit hole: found the testpoints, successfully flashed 7.7.20 china development ROM with MiFlash and... have not seen anything on the screen since.

Tried vol+ with vol- with power for 30s.

Tried to leave phone on the charger for a day and the above combo again.

Tried flashing with Qualcomm Flash Image Loader v2.0.1.1.

Tried flashing 6.12.8 china, 7.7.20 china, 7.7.20 global, 8.5.24 china, 8.8.9 china, 7.2.4.0 global, 9.6.1.0 china with no errors in MiFlash / QFIL.

It is either bad luck and PMI8994 got fried at the exact same time as I flashed or... something else. I don't believe in bad luck so hoping for the "something else" part :) To discover what could the problem be I was hoping to hook up a UART console to the board. Unfortunately I found no accounts of someone doing this on the Mi 5 and hence this post.

From Mi 5 PCB schematics it seems that on this phone UART console is connected to the ISL54062 analog switch and then output via the headphone jack (think Nexus 4) if enabled. The "enabled" bit is tricky – according to ISL54062 datasheet, both IN1 and IN2 need to have a logic state of "1" for TX/RX to be enabled. These are supposedly routed directly from MSM8996 as AUDIO_SWITCH_EN on pin BE49. This is as far as I got so far.

Has any of you heard of someone tracing down these lines? Does anyone know the conditions that would trigger AUDIO_SWITCH_EN to "1"? (On the Nexus 4 it was voltage comparison on some jack pins, on some phones it is resistance, etc.) Would prefer not to desolder the ISL54062 as it is a tiny µTQFN package (1.8 x 1.4mm) unless absolutely necessary.

Would love to get this board up and running and am prepared to ruin it for science since it does not boot anyway. If we do discover something, however, it seems that it will also be applicable to other Xiaomi phones – I fould the exact same circuitry on Mi 2 schematics. Perhaps there is some trigger that works on many/most Qualcomm SoCs?

EDIT: some more info confirming what I wrote above. According to kernel sources for MSM8996, the SoC's GPIO_4 and GPIO_5 are indeed configured for UART console. The interesting bit is the analog switch enablement pin, GPIO_49. According to kernel sources, GPIO_49, GPIO_50, GPIO_51 and GPIO_52 are a classic SPI MOSI, MISO, CS, CLK configuration for an interface referred to as "SPI9". Only on the Mi 5 they are marked as AUDIO_SWITCH_EN, FP_SPI_RST, TYPEC_I2C_SDA and TYPEC_I2C_SCL, where the last three go to the bottom fpc connector. Hmm... shame I do not have a proper microscope yet!

EDIT 2: Since the original post I also went through a list of all Mi 5 test points and while some look interesting in general phone diagnostic (PMI8994), none seem to have anything to do with UART enablement analogous to the way TP1204 and TP1205 force EDL mode.

EDIT 3: Out of curiosity I went through the Xiaomi kernel code drop for the Mi5 looking for ways they might be detecting voltage on the mic line and/or controlling the ISL54062 audio switch via AUDIO_SWITCH_EN. Nothing out of interest really. Shame we do not have a leaked Xiaomi bootloader code somewhere ;)

EDIT 4: Yup, still going. Had a few spare minutes with a scope today and tried the Nexus 4 way of feeding the phone +3.3V on the mic line, hoping that as Xiaomi was copying other bits from other manufacturers they also copied that trick. Didn't do a thing unfortunately. Next step: look for and desolder ISL54062 to get to the data lines underneath.

EDIT 5: Had a hotair gun handy so went ahead with checking whether ISL54062 is hiding beneath RF shielding (as I hoped) or not (as the PCB layout from the schematics shows). Unfortunately it seems the schematic, showing that the final PCB design omits the audio switch IC, won. As you can see in the attachment, there is space and pads but they are not populated. One last thing to try is to solder a thin wire to the relevant pad to see if perhaps MSM8996 does still transmit stuff but is "only" no longer able to re-route this communication via the audio jack or if they also removed all relevant print lines from PBL/SBL source/build. Stay tuned ;)