I've been looking into the issue of why the UART is left maped to GPIOs 14 and 15, and the answer is essentially because the firmware is not expecting it to move. Only Compute Modules are able to make use of the GPIOs above 27, so the firmware assumes that the primary UART (the one not used by Bluetooth) will either be on GPIOs 14&15 or it will be disabled. Parsing the default CM dt-blobs during bootup causes 14 & 15 to be switched to UART0, which will later be switched to UART1 if needed. If it's determined that the UART should be disabled, and if 14 & 15 are still mapped to UARTs, then they are returned to inputs. Because you want the UART to be enabled, the unmapping logic doesn't apply and the UART ends up in two different places.
There are a few solutions to this:
1. Get the firmware to read the Device Tree to work out where the UART is mapped, and undo the 14&15 mapping as necessary. This is feasible but cumbersome.
2. Get the firmware to always remove the 14 & 15 mapping, trusting the kernel to remap the UART. This would probably lose early-console output.
3. Modify the overlay to explicitly return GPIOs 14 & 15 to inputs.
Of these, 3 is my clear favourite. You can download a patched overlay here
- copy it into /boot/overlays, disable any forced GPIO patching you may have in place form /etc/rc.local etc., and reboot.
Let me know if it works for you, and I'll push the change into the kernel for future releases.