It's common for chips to have reset strapping on some of their pins. Low strength pull-ups or pull-downs are used to set the pin high or low on reset and this is used to configured the chip in some way. Usually there are several for booting, e.g. which device(s) to try or what voltage the eMMC chip should use, etc. Then in normal use the pins are driven with enough power to counter the weak pulls from the reset strapping resistors.
So it could be the uart pin shouldn't be held the way the serial cable is holding it on reset, and this is misconfiguring the SoC.
Also the 3.0 V line that powers the IO pins in the uart block is probably not up instantly. There is usually a complex process with a PMIC that brings all the different power rails up on some order. So maybe uart RX is held at 3.3V externally and the Vcc supply for that pin is still at 0V. Bad things can happen in this case. That block might try to draw power through the RX IO pin since it's at a higher voltage than the supply pin.
I would have designed the board with a built in RS232-USB chip. The USB side is powered via the USB bus, so it does not disappear/reappear on the host device every time the PBP reboots or resets. This is really annoying. Minicom on Linux handles it admirably, and automatically re-connects quickly when the USB serial device reappears. Windows hyperterm is horrible and needs to be restarted. So you can never see the console from just after reset.
The RS-232 side of the chip is powered from the same 3.0V rail that powers the IO block in the RK3399 with the UART. That way the voltage is exactly correct! And it means the 232-USB chip will not power the IO pins before the RK3399 has power to those pins' block.
And then you could get the serial console with a simple micro usb cable. Wouldn't that be nice!
Thanks for the update. I also confirmed with a multimeter and have removed that note about the Pine store version from the wiki.
