debug menu without Ex-Link cable

[goaskin]

Establishing a serial cable connection to the TV requires a computer beside it. A possibility to access the debug menu via Telnet would be more comfortable.

Has anybody an idea how it may be possible to simulate a serial 'loopback' connection? By running Minicom from an USB device to connect with /dev/ttyS0, I had no success. Has anybody an idea how it may be possible to 'catch' the serial data sent to ttyS0 in an usable way that allows you to interact by using a terminal program? Possibly by:

- bridging ttyS0 and ttyS1
- hacking a fake device node into /dev to redirect the I/O to another process
- (if there is no soft solution) plugging an USB-to-serial-converter into an USB slot to bridge the Ex-link port with an USB ports

The best solution would be to redirect the serial data to a TCP port somehow to make it possible to access the debug menu by establishing a telnet connection to a different TCP port than 23.

[erdem_ua]

1.) I tried to open /dev/ttyS* via picocom utility by telnet and have no success. I couldn't read it and don't know why.
2.) No knowledge on it.
3.) Quite possible but that will require USB-to-Serial cables linux drivers that compiled for exact kernel version (2.6.18)

[goaskin]

to:

1.) When establishing a connection to /dev/ttyS0 via Minicom, I saw some binary data in the Window. Keyboard inputs were ignored at all. No success with different terminal settings - either the same or no data. When connecting to non-existant serial devices (ttyS1, ttyS2), there is no data to see in Minocom, so something is different with ttyS0 that may be usable
2.) Also no idea how it may be possible but it could be a solution to let the program believe that it spawns the data to a serial device but to redirect them to another application
3.) May be the easiest solution but requires hardware. If there are no ideas how to realize a "terminal over network" service, I will continue I make experiments with this solution. Porting an usable driver should not be a big prpblem.

[goaskin]

I had partially success with forwarding the serial data via TCP. By using the netcat-command (debian-package for armel does not require any external dependencies), it is easy to open a TCP-port that redirects to the serial. For that, just type:

Code: Select all

stty -F /dev/ttyS1 raw 9600 -echo
nc -l -p 1111  >/dev/ttyS1 </dev/ttyS1

But if you telnet to port 1111 then, you only receive some binary data without the possibility to interact with them. There is another solution required instead of using netcat that converts the serial data to something usable for the telnet-client. You may create a fake serial port on client side and connect to it using a terminal program but that is no good solution (and requires Linux at last).

[erdem_ua]

I had partially success with forwarding the serial data via TCP. By using the netcat-command (debian-package for armel does not require any external dependencies), it is easy to open a TCP-port that redirects to the serial. For that, just type:

Code: Select all

stty -F /dev/ttyS1 raw 9600 -echo
nc -l -p 1111  >/dev/ttyS1 </dev/ttyS1

But if you telnet to port 1111 then, you only receive some binary data without the possibility to interact with them. There is another solution required instead of using netcat that converts the serial data to something usable for the telnet-client. You may create a fake serial port on client side and connect to it using a terminal program but that is no good solution (and requires Linux at last).

I think you needed to use 115200 baud. That probably lead the "corruption"(or binary data) on telnet client output.

[goaskin]

Code: Select all

stty -F /dev/ttyS1 raw 115200 -echo

TV reboots after a few seconds