[HOW TO] Get your ODROID online using its debug serial cable

Post Reply
campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

[HOW TO] Get your ODROID online using its debug serial cable

Unread post by campbell » Fri Sep 08, 2017 9:43 am

(This is related to my previous guide viewtopic.php?f=53&t=25527 but requires less prior setup, and can actually get your odroid online, not just connected to the host computer)

This method will work between any Linux/Mac host computer and any embedded board with the pppd binary and associated kernel modules. My setup is a Macbook Pro running macOS Sierra, Hardkernel USB-UART cable (Silicon Labs CP2104 usb to serial adapter), and Odroid C2 running Arch Linux. Your /dev/tty* will differ.

– Connect to the serial console via screen as you normally would:

Code: Select all

screen /dev/tty.SLAB_USBtoUART 115200
– Run the following command on the board, after logging in at the serial console:

Code: Select all

sudo pppd -detach noauth nocrtscts local silent lcp-echo-failure 2 lcp-echo-interval 5 defaultroute 460800
– The above will appear to do nothing. Now disconnect from screen (ctrl+a, k, y)

– Run the following commands on your Mac (the first need only be run once per boot of the Mac). Note you will have to manually pick an IP address for the board that is not already in use on your LAN.

Code: Select all

sudo sysctl -w net.inet.ip.fw.enable=1
sudo -b pppd -detach noauth nocrtscts local proxyarp [LAN IP of mac]:[desired LAN IP of board] /dev/tty.SLAB_USBtoUART 460800
– Now you can ssh or scp* to/from the board at the second IP address you provided in the above line, from anywhere on your network, and from the board you can reach the LAN and the outside world, including running package managers and the like. It MAY be necessary to manually add 8.8.8.8 to /etc/resolv.conf on some board images (not Arch).

– When finished, just run “sudo pkill pppd” on your Mac. After about ten seconds the serial port should be back to a regular prompt (alternatively, run “sudo pkill pppd” on the remote end, and then press enter, tilde, period to kill the hung ssh session. This will bring it down immediately, but is harder to remember if it’s not in your muscle memory).

*Note that scp will lie to you about progress and time remaining for file transfers in the “push” direction (local to remote), your best bet is to eyeball the growing file size, or ssh into the remote end and scp them from remote to local.

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Fri Sep 08, 2017 4:27 pm

This is great! It can be used to salvage xu4s with broken usb controllers which lost network access as well. You should pm robroy to include this guide in the magazine!
Also, what baud rate is supported on an xu4 with the ttl adapter? I heared it was ~900kbps?

campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by campbell » Fri Sep 08, 2017 4:45 pm

Yes, i have successfully used ppp between an XU4 and the host laptop at 921600 using the Hardkernel USB-UART. For some reason the Odroid C2 tops out at 460800 over the same cable, although two C2s can talk to each other reliably at up to 2.5 MBd when wired directly together.

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Fri Sep 08, 2017 4:58 pm

by wired directly do you mean jumper cables between the UART port with TX/RX reversed? Do you also connect GND, or do you leave it floating?

campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by campbell » Sat Sep 09, 2017 12:06 am

Yes, individual wires between the TX and RX lines. I'm pretty sure I connected ground to ground as well, but now I'm second guessing myself.

campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by campbell » Mon Sep 11, 2017 12:32 pm

I finally got around to retesting this with and without ground. The results are as follows:

with ground:
2.0 MBd: 189 kB/s (theoretical max 200 kB/s)
2.5 MBd: 252.6 kB/s (theoretical max 250 kB/s)
3.0 MBd -> 20 kB/s

without ground:
2.0 MBd -> 88.2 kB/s
2.5 MBd -> 101 kB/s
3.0 MBd -> under 5 kB/s

So it's reaching it's maximum potential speed with the ground wire connected, and not without it. But bear in mind these wires are about six inches long and there isn't a lot of area enclosed in the ground loop. If the boards were any significant distance from each other this probably wouldn't work as well.

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Mon Sep 11, 2017 12:57 pm

That's very interesting, thanks.
Regarding ppp - how does it work? Does it use stdin and stdout with ascii/binary encoding to write packets? Does it take over the tty and write directly in binary? If there are kernel debug/error messages printed to console do they cause packets to be corrupted?

campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by campbell » Mon Sep 11, 2017 1:31 pm

One more thing: if instead of using the actual serial debug port, you use the USB OTG port in serial gadget mode, it will allow you to transfer files at 3.2 MB/s (yes megabytes) no matter what baud rate you specify. The drivers at either end of the link are smart enough to tell that it's USB end to end and not actually a serial port.

campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by campbell » Mon Sep 11, 2017 1:34 pm

mad_ady wrote:Does it use stdin and stdout with ascii/binary encoding to write packets? Does it take over the tty and write directly in binary? If there are kernel debug/error messages printed to console do they cause packets to be corrupted?
Yes (binary), yes, and yes. If you don't specify a /dev/tty as one of the arguments to pppd, it used the one that is currently connected to stdin/stdout. So on the board end, you do just that. Disabling kernel messages on that tty would in theory cause fewer packets to be corrupted, but in practice, unless you are doing something with UDP where you need zero percent packet loss, you won't notice it, as the TCP layer will just have those packets retransmitted.

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Mon Sep 11, 2017 3:01 pm

USB gadget is nice and all, but it requires a working Odroid. I'm more interested in bringing back to life Odroid XU4s which have their USB bus burned out (so far I've seen two in this state caused by shorts when replacing the cooler). USB bus burned out means no USB 2/3, no Ethernet, no SD card (emmc still boots after about 5 minutes delay). Also HDMI seems to be dead, and I'm not sure if the GPIO pins are working or not. It would be interesting to see if GPIO were still working if the GPIO UART gives better performance or not. The problem with it is that you'd need special, smaller cables (because of the connector pitch being less than 2.5mm) to attach it to the pins (or solder it to adapter cables).
Such a busted odroid could still be used to perform things like boinc processing or even mining crypto-currencies, so it wouldn't be a total loss.

Regarding disabling kernel messages, I think we can use

Code: Select all

sudo dmesg -n 1
There's one more thing I'm worried about - If I set up two such odroids in serial back-to-back configuration and I set up ppp to start up via rc.local, If I reboot both of them at the same time (e.g. power outage), won't the uboot messages cause boot to stop? There a step where uboot waits for an enter for a second to interrupt boot which might be a problem... I'll need to try it out.

campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by campbell » Mon Sep 11, 2017 3:25 pm

mad_ady wrote:There's one more thing I'm worried about - If I set up two such odroids in serial back-to-back configuration and I set up ppp to start up via rc.local, If I reboot both of them at the same time (e.g. power outage), won't the uboot messages cause boot to stop? There a step where uboot waits for an enter for a second to interrupt boot which might be a problem... I'll need to try it out.
Yes, this happened to me tonight. I think the general fix is to not wire two debug serial consoles together. Luckily, there are other uarts on the gpio headers. You could wire each board's serial console to the gpio on the other board and then you'd be fine.

PPP is actually smart enough to aggregate links if it detects that multiple connections go to the same remote device. They appear as a single network device that will persist as long as any one of the participating physical links is still up, and the bandwidth of the network device will be the total of the participating links.

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Sun Oct 29, 2017 6:26 pm

I'm trying to resuscitate a broken XU4 and bring it online by bridging it to a working XU4 using your method. In order to save the USB-Serial adapter, I went with a "direct-cable connection" approach by using the serial ports (with RX-TX switched). Image

I've not disabled uboot messages yet (but I will do it with this guide: https://wiki.odroid.com/odroid-xu4/trou ... le_console), but I did disable linux console on the serial port.
The working XU4 (router) has this configuration:

Code: Select all

LOCALIP=192.168.228.11
REMOTEIP=192.168.228.12
PORT=/dev/ttySAC2
BAUD=460800
/usr/sbin/pppd updetach noauth nocrtscts local proxyarp persist maxfail 0 $LOCALIP:$REMOTEIP $PORT $BAUD
The broken odroid connects with this in rc.local:

Code: Select all

PORT=/dev/ttySAC2
BAUD=460800
/usr/sbin/pppd updetach noauth nocrtscts local silent lcp-echo-failure 2 lcp-echo-interval 5 defaultroute persist maxfail 0 $BAUD $PORT
For now I power on the router first and then the second Odroid. I also made the second Odroid log some stuff to disk for troubleshooting and run a ping to the router:

Code: Select all

IP for ppp0 is  192.168.228.12 peer 192.168.228.11
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:96 errors:0 dropped:0 overruns:0 frame:0
          TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:7584 (7.5 KB)  TX bytes:7584 (7.5 KB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:192.168.228.12  P-t-P:192.168.228.11  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:72 (72.0 B)  TX bytes:258 (258.0 B)
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
192.168.228.11  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
PING 192.168.228.11 (192.168.228.11) 56(84) bytes of data.
64 bytes from 192.168.228.11: icmp_seq=1 ttl=64 time=5.59 ms
64 bytes from 192.168.228.11: icmp_seq=2 ttl=64 time=2.71 ms
64 bytes from 192.168.228.11: icmp_seq=3 ttl=64 time=4.50 ms
64 bytes from 192.168.228.11: icmp_seq=4 ttl=64 time=4.40 ms
64 bytes from 192.168.228.11: icmp_seq=5 ttl=64 time=3.93 ms
64 bytes from 192.168.228.11: icmp_seq=6 ttl=64 time=4.39 ms
64 bytes from 192.168.228.11: icmp_seq=7 ttl=64 time=3.38 ms
64 bytes from 192.168.228.11: icmp_seq=8 ttl=64 time=5.14 ms
64 bytes from 192.168.228.11: icmp_seq=9 ttl=64 time=4.18 ms
64 bytes from 192.168.228.11: icmp_seq=10 ttl=64 time=5.11 ms

--- 192.168.228.11 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9015ms
rtt min/avg/max/mdev = 2.714/4.337/5.592/0.816 ms

So, traffic works (I can see it with tcpdump on the router), but I am unable to connect back to the broken XU4 and it doesn't reply to ping from the router. Also, the link fails shortly after.
Any suggestions what I should be looking into?

I will try to pass more traffic from the broken Odroid - maybe the link needs activity to stay up. I admit I haven't used ppp since dialup went away...

campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by campbell » Mon Oct 30, 2017 2:42 pm

mad_ady wrote:Any suggestions what I should be looking into?
I'd try going to one of the other uarts, on the GPIO header, rather than the one with the debug console. And/or maybe turn up the lcp-echo-failure parameter - it might be quitting after it gets interrupted twice by kernel messages?

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Mon Oct 30, 2017 4:15 pm

I will try, thanks. There should be no kernel debug messages on that serial port - I redirected all boot messages to the the serial port on the 30 pin connector.

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Mon Oct 30, 2017 11:09 pm

I've managed to get it to work @460800 and will post a how-to when I'm happy with the setup, but there's a problem with the ARP.
When PPP first connects, the "client" board can access the network through the "router" board. I suspect that the router board does a gratuitous ARP to let the LAN know about the IP on the PPP link. But once this ARP expires, the client can only talk with the "router" board.
I'll need to set up some captures to see what packets are being exchanged. Is there a way to have PPP send gratuitous ARPs? I could do it with arping, I suppose, but it's hacky...

Here's what a host on the LAN sees after a while - it can't figure out what the MAC of 192.168.228.12 is...

Code: Select all

16:05:16.818138 IP 192.168.228.12 > 192.168.228.1: ICMP echo request, id 1828, seq 21, length 64
16:05:17.858042 IP 192.168.228.12 > 192.168.228.1: ICMP echo request, id 1828, seq 22, length 64
16:05:17.858083 ARP, Request who-has 192.168.228.12 tell 192.168.228.1, length 28
16:05:18.857918 ARP, Request who-has 192.168.228.12 tell 192.168.228.1, length 28
16:05:18.898026 IP 192.168.228.12 > 192.168.228.1: ICMP echo request, id 1828, seq 23, length 64
16:05:19.857929 ARP, Request who-has 192.168.228.12 tell 192.168.228.1, length 28
16:05:19.938806 IP 192.168.228.12 > 192.168.228.1: ICMP echo request, id 1828, seq 24, length 64

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Tue Oct 31, 2017 9:59 pm

Ok, some update on the project - a more detailed HowTo.
The goal is to bring a "burned-out" XU4 (burned USB bus, no network, no SD card, no HDMI) back online. The burned device still has to be able to boot from eMMC and has to have the serial port working. Usually these XU4s burn when users make a mistake while changing the heatsink and inadvertantly short out something on the board. The CPU and memory is usually intact and the system can run fine but without external access (only serial).

So - to do this you will need:
1. A working XU4 (called 'router' from now on)
2. A broken XU4 + eMMC (called broken from now on)
3. 3 dupont female wires (like these:http://www.5thpostulate.com/5pe-female- ... of-10.html).

Having a serial-usb adapter can help with debugging, but is not necessary.

Steps:
1. Connect the wires between the two Serial port connectors like this:

Code: Select all

_____UART____	_____UART____
|Pin 4 - GND|	|Pin 4 - GND|
|Pin 3 - RXD|	|Pin 3 - RXD|
|Pin 2 - TXD|	|Pin 2 - TXD|
|Pin 1 - VCC|	|Pin 1 - VCC|
\___________|	\___________|
GND <-> GND
RXD <-> TXD
TXD <-> RXD
VCC - unconnected

It should look like this image:
Image

2. Disable uboot messages (https://wiki.odroid.com/odroid-xu4/trou ... le_console). The u-boot messages need to be disabled at least on one host, so that u-boot messages at startup don't interrupt the startup of the other host. I disabled them for the broken odroid.
3. Disable kernel console. This is described in the article above, but needs to be done on both boards (router and broken). A difference I would make compared with the wiki is to make the changes in /media/boot/boot.ini.default and run sudo dpkg-reconfigure bootini, so that changes are not lost on bootini upgrades.
4. Unmap the power button from the power function. Since I'll be using the boards headless, it would be nice to use the power button for interaction with the boards (like to restart the network connection). You can do this on both boards, but it's more important on the broken board, since you may not have other means of communication with it. Decouple the power button by editing /etc/systemd/logind.conf:

Code: Select all

$ sudo vi /etc/systemd/logind.conf 
[Login]
HandlePowerKey=ignore
5. Install multibutton handler to give the button a new purpose.

Code: Select all

$ git clone https://github.com/mad-ady/multibutton.git
$ cd multibutton
$ sudo perl -MCPAN -e 'install Linux::Input'
$ sudo apt-get install libconfig-yaml-perl liblog-log4perl-perl libproc-background-perl
$ sudo cp multibutton.pl /usr/local/bin
$ sudo cp config-minimal.yaml /etc/multibutton.yaml
$ sudo cp multibutton.service /etc/systemd/system
$ sudo vi /etc/systemd/system/multibutton.service
[Unit]
Description=Multibutton key handler for a keyboard-like input device

[Service]
Type=simple
ExecStart=/usr/local/bin/multibutton.pl -i "/dev/input/by-path/platform-gpio_keys:-event" -c "/etc/multibutton.yaml"
Restart=always
#WatchdogSec=300

[Install]
WantedBy=multi-user.target

$ sudo systemctl enable multibutton
$ sudo systemctl start multibutton
Edit /etc/multibutton.yaml and add this contents:

Code: Select all

# Configuration sample for multibutton.pl

# Set logging level (logging goes to STDERR/journalctl). Allowed values are: DEBUG, INFO, WARN, ERROR, FATAL

logging: INFO

# Set updatePeriod to the number of microseconds between key presses checks
# Default is 200ms between key presses

updatePeriod: 200000

# Set bufferSize to how many keys to keep in memory when analizing a multiple key press.
# The larger the value, the more time you have to wait until any action executes

bufferSize: 10

# Set longPress to a fraction - how many times does a key have to appear in a sequence before considering it a long press.
# The default is 0.7 which means 70% of the keys in bufferSize have to be the same to register as a long press

longPress: 0.7

# The following section defines possible key sequences and an action that should be executed in the background
# Note that the command runs as the same user you run multibutton.pl by default

# Example commands (one line each):
#KEY_CAMERA: logger "Key has been pressed"
#KEY_CAMERA-KEY_CAMERA: logger "Key has been double pressed"; logger "Two commands have been executed"
#KEY_CAMERA-KEY_CAMERA-KEY_CAMERA: su -c "logger 'Tripleclick - This command is run as a different user (uid $EUID)'" odroid
#LONGKEY_CAMERA: DISPLAY=:0 xeyes

KEY_POWER: /usr/sbin/service setup-serial restart
KEY_POWER-KEY_POWER: logger -s 'Pressed double'
KEY_POWER-KEY_POWER-KEY_POWER: logger -s 'Pressed triple'
LONGKEY_POWER: logger -s 'Pressed long'

6. Set up ppp over serial on the 'router' (based on campbell's original post), but as systemd services. Customize the IP addresses in the scripts below. I've tested with baudrates higher than 921600, but I experienced big packet losses. If you find better baud rates, let me know!

Code: Select all

router$ cat /usr/local/bin/restart-ppp.sh 
#!/bin/bash
/usr/bin/pkill pppd
LOCALIP=192.168.228.11
REMOTEIP=192.168.228.12
PORT=/dev/ttySAC2
#BAUD=460800
BAUD=921600
#BAUD=1843200
/usr/sbin/pppd nodetach noauth nocrtscts local proxyarp persist maxfail 0 $LOCALIP:$REMOTEIP $PORT $BAUD
sleep 2
router$ sudo chmod a+x /usr/local/bin/restart-ppp.sh
router$ cat /etc/systemd/system/setup-serial.service 
[Unit]
Description=Setup PPP over Serial (Router)

[Service]
Type=simple
ExecStart=/usr/local/bin/restart-ppp.sh
Restart=always

[Install]
WantedBy=multi-user.target
router$ sudo systemctl enable setup-serial
router$ sudo systemctl start setup-serial
Set up IP forwarding on the 'router'

Code: Select all

router$ sudo vi /etc/rc.local
echo 1 > /proc/sys/net/ipv4/ip_forward
7. Set up ppp over serial on the 'broken' board:

Code: Select all

broken$ cat /usr/local/bin/restart-ppp-client.sh 
#!/bin/bash
/usr/bin/pkill pppd
sleep 3
PORT=/dev/ttySAC2
#BAUD=460800
BAUD=921600
#BAUD=1843200
/usr/sbin/pppd nodetach noauth nocrtscts local silent lcp-echo-failure 5 lcp-echo-interval 5 defaultroute persist maxfail 0 $BAUD $PORT 2>&1

broken$ cat /etc/systemd/system/setup-serial.service 
[Unit]
Description=Setup PPP over Serial (Client)

[Service]
Type=simple
ExecStart=/usr/local/bin/restart-ppp-client.sh
Restart=always

[Install]
WantedBy=multi-user.target

broken$ sudo systemctl enable setup-serial
broken$ sudo systemctl start setup-serial
8. Force /etc/resolv.conf to a nameserver on the 'broken' board. We're going to delete the resolv.conf symlink and create a file with the correct setting and set it immutable so that no process can edit it.

Code: Select all

broken# ls -la /etc/resolv.conf 
broken# rm /etc/resolv.conf
broken# echo 'nameserver 8.8.8.8' > /etc/resolv.conf
broken# lsattr /etc/resolv.conf
broken# chattr +i /etc/resolv.conf
broken# cat /etc/resolv.conf 
Right now, if you reboot both boxes (even at the same time), the PPP link should come up and stay up. You should be able to ssh into the broken odroid box and get a performance close to 100KB/s.

Troubleshooting.
1. You can restart the PPP connection by pressing once on the power button (on either system)
2. Sometimes ARP might expire and the client will remain isolated (can only communicate with the host, but not with the LAN). Either restart the PPP connection, or use static ARP on the hosts on the LAN that need to communicate with the client, like:

Code: Select all

lan-host$ sudo arp -s ip-of-broken-odroid mac-of-router-odroid
So far this should be enough to bring back a broken XU4 from the dead and have it do something useful (like a boinc client). If I have time I might play with remote USB support (over IP) - http://usbip.sourceforge.net/, though it will be slow. Maybe keyboard/mouse will work.

User avatar
memeka
Posts: 4242
Joined: Mon May 20, 2013 10:22 am
languages_spoken: english
ODROIDs: XU rev2 + eMMC + UART
U3 + eMMC + IO Shield + UART
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by memeka » Tue Oct 31, 2017 10:28 pm

Why not use the gpio serial so you can still have access to the console on ttysac2?

User avatar
mad_ady
Posts: 5444
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1, H2, N2
Location: Bucharest, Romania
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by mad_ady » Tue Oct 31, 2017 11:01 pm

:) There's a practical aspect - I can force dupont female cables in the UART connector and it works, but the pins on the 30 pin connector are too narrow and tightly packed and I don't have a suitable connector. Maybe you can suggest something that can be done from household items :)
Anyway, I'm not sure if the GPIO pins work on the broken units. - I haven't tried them. I suspect they do - mostly the USB bus, SD card controller and HDMI burns out.

campbell
Posts: 381
Joined: Thu Sep 03, 2015 1:13 pm
languages_spoken: english
ODROIDs: N2, C2, C1+, XU4, XU3, Cloudshell, Smart Power
Contact:

Re: [HOW TO] Get your ODROID online using its debug serial c

Unread post by campbell » Wed Nov 01, 2017 3:04 am

The 2mm pitch on the XU4 GPIO pins is one of the reasons I only use the Odroid C2 now (along with ethernet-over-USB, 32 bit, and a vastly higher bootup power draw requirement...)

Post Reply

Return to “General”

Who is online

Users browsing this forum: No registered users and 0 guests