Monitor Rock64 serial console with PineA64

[MarkHaysHarris777]

   

The Rock64 uses a serial console with a baud rate of 1.5M !  This can be a challenge especially if you're used to the 115200 baud rate of the PineA64, or the RPi3. Some of the bridges ( cp2102, ch340g, pl2303hx ) will work at 1.5M but many will not (some ch340g, pl2303ta, cp2104).

In this post I am highlighting the PineA64 as a great serial console monitor for the Rock64, using a modified cat5 ethernet cable. In the pic above you can see the serial console cable plugged into the P-2 bus [brown-gnd pin(6), orange-Tx pin(8), and yellow-Rx pin(10)].  Also visible is the .95m transmission cable that I have been experimenting with:  the solid blue and brown wires are the Tx--Rx  Rx--Tx data lines, and the striped blue|brown are the ground returns;  the ground returns are tied together and each data line is twisted with its corresponding ground.  While this increases the capacitance of the transmission cable it is very quiet and still short enough that the cable is quite effective at 1.5M !

   

On the other end of the cable is my PineA64 desk machine cabled to the Rock64 on uart(3), /dev/ttyS3;  again the striped ground returns are tied to sold blue (ground) and the solid brown is tied to Tx, while the solid white is tied to Rx  ( see foreground of pic above ) .  I have found that most 'screen' implementations do not support 1.5M, although there is a debian patch to correct this. Minicom and 'cu' are the standard(s) that continue to work time and again, and in this case I am running minicom in a terminal as my serial console software. In addition to setting 1500000 baud rate (ctrl-A o e aaaaaa) I also set flow control OFF (both) and set line wrap (ctrl-A w) and set off cr (ctrl-A a) and set off local echo (ctrl-A e).  The terminal is quite stable and works very well even after being up for several days.

   

The pic above is my PineA64 desk which I have used as primary computer desk since last November.  Visible is the terminal running minicom over the uart(3) /dev/ttyS3 connected via the modified cat5 transmission cable to the Rock64 prototype board;  cased in the C4Labs Zebra case from Dustin!

The image is ayufan's  gnu+linux ubuntu minimal 0.2.1 running the python suite. Displayed is the AGM PI routine output (taken from "Projects in Scientific Computation" Crandall ; 1994  pp. 11-12) which shows 1010 digits of PI with accuracy of +|- (1) in the last two digits!  Typically the Rock64 will compute this result in an average time of about 460ms. 

Note:   I disassembled a standard cat5 ethernet cable for this project. The other two pairs (orange and green) were used for hook-up wire on my DSKY replica ca. 1967.  I discarded the sheath to make the cable liter and easier to manage around the crap on my desktop. Obviously if you can place the two units next to one another the cable is not necessary; on the other hand, if your lab is spread out across multiple desks (as mine is) this transmission cable is a serial data saver.

[pfeerick]

What.... no PADIs in transparent serial mode making it Serial over WiFi over Serial? :-P

[martinayotte]

What.... no PADIs in transparent serial mode making it Serial over WiFi over Serial? :-P

[jl_678]

I love this idea and will use it if my USB to serial cable does not work. Couldn't I simply use dupont cables to connect the tx/rx, rx/TX and ground? Yours seems more involved, and I want to be sure that my proposed strategy would work. As an FYI, this would be a temporary configuration used to implement the eMMC copy process that you describe in your tutorial.

Sent from my SM-T537V using Tapatalk

[rmbusy]

The Rock64 uses a serial console with a baud rate of 1.5M !  This can be a challenge especially if you're used to the 115200 baud rate of the PineA64, or the RPi3. Some of the bridges ( cp2102, ch340g, pl2303hx ) will work at 1.5M but many will not (some ch340g, pl2303ta, cp2104).

In this post I am highlighting the PineA64 as a great serial console monitor for the Rock64, using a modified cat5 ethernet cable. In the pic above you can see the serial console cable plugged into the P-2 bus [brown-gnd pin(6), orange-Tx pin(8), and yellow-Rx pin(10)].  Also visible is the .95m transmission cable that I have been experimenting with:  the solid blue and brown wires are the Tx--Rx  Rx--Tx data lines, and the striped blue|brown are the ground returns;  the ground returns are tied together and each data line is twisted with its corresponding ground.  While this increases the capacitance of the transmission cable it is very quiet and still short enough that the cable is quite effective at 1.5M !



On the other end of the cable is my PineA64 desk machine cabled to the Rock64 on uart(3), /dev/ttyS3;  again the striped ground returns are tied to sold blue (ground) and the solid brown is tied to Tx, while the solid white is tied to Rx  ( see foreground of pic above ) .  I have found that most 'screen' implementations do not support 1.5M, although there is a debian patch to correct this. Minicom and 'cu' are the standard(s) that continue to work time and again, and in this case I am running minicom in a terminal as my serial console software. In addition to setting 1500000 baud rate (ctrl-A o e aaaaaa) I also set flow control OFF (both) and set line wrap (ctrl-A w) and set off cr (ctrl-A a) and set off local echo (ctrl-A e).  The terminal is quite stable and works very well even after being up for several days.



The pic above is my PineA64 desk which I have used as primary computer desk since last November.  Visible is the terminal running minicom over the uart(3) /dev/ttyS3 connected via the modified cat5 transmission cable to the Rock64 prototype board;  cased in the C4Labs Zebra case from Dustin!

The image is ayufan's  gnu+linux ubuntu minimal 0.2.1 running the python suite. Displayed is the AGM PI routine output (taken from "Projects in Scientific Computation" Crandall ; 1994  pp. 11-12) which shows 1010 digits of PI with accuracy of +|- (1) in the last two digits!  Typically the Rock64 will compute this result in an average time of about 460ms. 

Note:   I disassembled a standard cat5 ethernet cable for this project. The other two pairs (orange and green) were used for hook-up wire on my DSKY replica ca. 1967.  I discarded the sheath to make the cable liter and easier to manage around the crap on my desktop. Obviously if you can place the two units next to one another the cable is not necessary; on the other hand, if your lab is spread out across multiple desks (as mine is) this transmission cable is a serial data saver.

Does someone have a explanation why the default serial console baud rate is set to 1.5MB??  Seems absurdly high, given that almost no Linux serial terminal applications support it (and none that I've found so far).  I just downloaded what appears to the the latest version of minicom, 2.7, (which I stopped using years ago because of its ancient / archaic interface), built it from source, and it only lists 115200 in the port settings page as the highest rate.

What version are you using that supports 1.5MB?  Also, I don't have a PineA64, and have no plans to get one, so is there information somewhere for regular Linux users that I missed in my days of searching?

Not having a serial console for boot is a non-starter for me.  I'm now looking for info on how to get setup to build Ayufans' source so I can change the baud rate back to the standard default of 115200.  Any pointers in that direction would be helpful too.

[belfastraven]

What version are you using that supports 1.5MB?  Also, I don't have a PineA64, and have no plans to get one, so is  there information somewhere for regular Linux users that I missed in my days of searching?

Not having a serial console for boot is a non-starter for me.  I'm now looking for info on how to get setup to build Ayufans' source so I can change the baud rate back to the standard default of 115200.  Any pointers in that direction would be helpful too.

 I am using the serial device which was sold in the pine store with the rock64.  I use picocom software ( on Archlinux) and specify the baudrate on the command line (-b 1500000).  I believe you could also specify the baud rate on the command line for minicom.   Serial console has been working fine for me..

[rmbusy]

What version are you using that supports 1.5MB?  Also, I don't have a PineA64, and have no plans to get one, so is  there information somewhere for regular Linux users that I missed in my days of searching?

Not having a serial console for boot is a non-starter for me.  I'm now looking for info on how to get setup to build Ayufans' source so I can change the baud rate back to the standard default of 115200.  Any pointers in that direction would be helpful too.

 I am using the serial device which was sold in the pine store with the rock64.  I use picocom software ( on Archlinux) and specify the baudrate on the command line (-b 1500000).  I believe you could also specify the baud rate on the command line for minicom.   Serial console has been working fine for me..

Thanks for the info.  I tried the command line baud setting to minicom 2.7 ( -b 1500000), and that worked.  I was still getting garbage, so tried a different USB to serial adapter (now using a Softway board), and I'm getting valid console output.  I'm half expecting to see random garbage though, due to the high baud rate.

I still would like to know why such a high baud rate was chosen, and any pointers to rebuilding the code Ayufan has graciously provided, so I can build my own version with a 115200 console, for better compatibility with all USB to serial devices and apps.

[MarkHaysHarris777]

Thanks for the info.  I tried the command line baud setting to minicom 2.7 ( -b 1500000), and that worked.  I was still getting garbage, so tried a different USB to serial adapter (now using a Softway board), and I'm getting valid console output.  I'm half expecting to see random garbage though, due to the high baud rate.

I still would like to know why such a high baud rate was chosen, and any pointers to rebuilding the code Ayufan has graciously provided, so I can build my own version with a 115200 console, for better compatibility with all USB to serial devices and apps.

1.5M  is becoming the standard baud rate for console;  even 115200 is not fast enough to keep up with the console in many cases.