Serial settings for the newer LG drives

[Rupan]

Many (all?) of the newer LG drives - those based on the Mediatek ARM SoC, not the Renesas drives - appear to have 3.3v (CMOS logic) serial headers on the back, next to the SATA/power connectors. Based on a quick look with an oscilloscope, it seems that the ramp down/up for one bit is somewhere between 113 ~ 120 kilohertz, so I'd guess that the serial line speed is 115200. However, when I connect a USB<->Serial device I get garbage in minicom. Does anyone on this forum know the correct settings?

[jpsdr]

You can first try to play with the several standards settings for an RS232 port COMs :
Parity bit : None, Odd, even
Stop Bits : 1,2
This will make 6 settings to test.
I doubt you'll have to test for 7 bits data...
But, do you know what you're supposed to receive and/or send ?
It's not because it's a serial link that you're supposed to receive text.
There is often serial link on devices for testing/maintenance purpose, which send (or receive) pure binary data/information.

[Mike Chen]

These are correct settings. MTK firmware does not log strings, instead it uses a custom binary log format with message IDs and arguments encoded as binary. Useless without formware source code. What exactly you wanted to see there?

[Rupan]

I was hoping that there was some way to upgrade, downgrade, or patch areas of the firmware via the serial console. Maybe implement some sort of rudimentary GDB backend, if possible. Would you be willing to share what you know of the binary protocol (if anything)? Can you confirm the remainder of settings for the serial interface, including data bits, stop bits, parity, and flow control?

[jpsdr]

The most usual is 1 bit stop, no parity, 8 bits data. But it's just the most usual, no garanty for sure it's what is used here.

[Rupan]

Indeed, the 8n1 serial configuration seems to be in widespread use. I don't remember ever using a serial device with settings other than those. However, this is a highly specialized device which is probably hostile to unauthorized users and it wouldn't surprise me if some parameters were nonstandard. The problem is that since the protocol is binary I have no way of telling whether the data I see is garbage as a result of say 2 stop bits instead of the usual 1 stop bit.

[Mike Chen]

I was hoping that there was some way to upgrade, downgrade, or patch areas of the firmware via the serial console.
No, none of it is possible via UART. But all you ask is actually possible via other means. For example all firmware versions (including the latest one, with disabled vendor commands and ATA extension to access SPI flash) do allow reading the same debug data from the ring buffer using vendor commands.

Would you be willing to share what you know of the binary protocol (if anything)?I never cared enough to actually fully decode it, but trust me - it is useless for most part.

Can you confirm the remainder of settings for the serial interface, including data bits, stop bits, parity, and flow control?
I do not know :( . If you really want I can decode the initial handshake bytes from your firmware, so you can check if you are getting the right data. There is however one useful thing you can do with the serial header - I'm not ready to discuss it publicily yet, but if interested - please PM me or better write to mike@makemkv.com .