unreliable serial console output?!

[consoleadam]

Together with Rock64/1GB board, I have bought the USB serial console as listed on Pine/Rock64 site. Booting the board with the community build of 'xenial-i3-rock64-0.5.10-118-arm64.img'. On a linux workstation, using minicom (1500000 8N1 | NOR | Minicom 2.7 | VT102 | Offline | ttyUSB0), I can interact with the board check the following excerpts:
root@rock64:~# uname -a
Linux rock64 4.4.77-rockchip-ayufan-118 #1 SMP Thu Sep 14 21:59:24 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
root@rock64:~#



The issue is: it is highly unstable meaning if I run the same following command:
root@rock64:~# cat /proc/cpuinfo

multiple times, gives different outputs for each run (as shown below)!! Is this a common problem? is it hardware or software related?
appreciated your help on this matter.
---------------------------------------------------------
root@rock64:~# cat /proc/cpuinfo 

processor       : 0
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture        : 0xd03
CPU revision    : 4

processor       : 1
BogoMIPS        : 48.00
F       : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd0 asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41n : 4

processor       : 3
BogoMIPS        : 48.00
Features        : fp asimd evcture: 8
CPU variant     : 0x0
CPU part        : 0xd03
root@rock64:~# cat /proc/cpuinfo 
processor       : 0
BogoMIPS        : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU partoMIPS   : 48.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 c
                                                        CPU part        : 0xd03
CPU revision    : 4

processor       : 2
BogoMIPS        :ementer        : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU partres     : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementePU revision       : 4

Serial          : b5f2b912efc3f49b
root@rock64:~# 

[MarkHaysHarris777]

hi, 
Please describe your topology;  also, which usb to serial TTL bridge adapter are you using ( which model, chipset ) ?

[consoleadam]

hi, 
Please describe your topology;  also, which usb to serial TTL bridge adapter are you using ( which model, chipset ) ?

Hi, 
As stated, the usb to serial TTL bridge adapter is the one listed on Pine64 site: 
https://www.pine64.org/?product=padi-serial-console
I believe this should be the most compatible serial-to-usb adapter to connect with rock64?!

The unstable behavior was there although have tried the following combinations: 
1. with jumer (on the serial-adapter) on 3v3 and 5v0, 
2. with/without connecting 5v from the serial-adapter to pin4 of Pi-2 Bus, 
3. same unstable behavior on both u-boot console and that of Linux console of different images, 
4. tried different images xenial-i3-rock64-0.5.10-118-arm64.img, jessie-openmediavault-rock64-0.5.10-118-arm64.img, my own built images.

As you know, a stable serial console is very crucial to the success of rock64 and that of RK3328, Thus, does anybody experiencing such unstable behavior?

appreciated your answer/contribution

[maal]

I have a different adapter (based on FTDI FT232RL) and my serial console works reliably.

My connections:

Adapter         Rock64 (Pi-2 Bus)

GND     <--->   pin 6   GND
RXD     <--->   pin 8   GPIO2_A0 (UART2_TX_M1)
TXD     <--->   pin 10  GPIO2_A1 (UART2_RX_M1)


Are your connections the same?
If yes, I would start with replacing wires between adapter and Rock64.
I would also replace USB cable between adapter and workstation.

Also it's very important that you keep your adapter set at 3.3V (I think pin 10 on Pi-2 Bus is connected directly to the RK3328 chip).

[MarkHaysHarris777]

hi, 
Please describe your topology;  also, which usb to serial TTL bridge adapter are you using ( which model, chipset ) ?

Hi, 
As stated, the usb to serial TTL bridge adapter is the one listed on Pine64 site: 
https://www.pine64.org/?product=padi-serial-console

hi ,  when I asked for your topology I meant that I want to know how 'specifically' you have it wired.  

The chipset I believe you are using is the CH340g;  this is the best adapter we can recommend and it is reliable, but because of the higher frequencies (1.5M baud rate) the topology is more critical; hap-hazzard wiring will not work well.  Here are some tips:

1) DO NOT connect the voltage lead of the CH340g adapter ANYWHERE...  ( words to the wise )
2) make sure you have a good ground connection 
3) place the adapter CH340g as close to the Rock64 as possible ( no more than 6" leads, but the shorter the better )
4) use three wires:  Tx,  Rx,  Ground
5) use a 'short' usb extension cable from the adapter to the monitor computer.
6) use minicom with gnu+linux   ( any distro )
7) use the settings and disable both flow controls ( hardware and software )


If still unstable or unreliable, try plugging the CH340g into a powered hub.  Plug the powered usb hub into the monitor computer, then plug the CH340g into the powered hub.  Often the CH340g will not work well at higher baud rates on all ports unless it gets better power feed;  this is particularly true if you're trying to use the Pinebook left hand usb port !  Any powered usb hub ( Belkin's is nice ) will work;  however, make sure that your powered hub does not provide back-feed -- do your research.

Also not all usb ports are identical;  some have internal hubs ( which work better for terminals ).  For instance the Pinebook's right hand usb port is a hub, and it works brilliantly with the CH340g no worries.




PS,  if you have another SBC ( Rapsberry PI, PineA64+, etc ) you can use that SBC uart directly ( no adapter ) to monitor the Rock64 serial console output !

.

[consoleadam]

Thank you for following up on this matter. Well, since from the very beginning, I was able to interact with the serial using minicom, I believe the wiring was not an issue, in other words, connected RX/TX/GND correctly, more over connecting/not-connecting voltage did not have any effect.

Also since I have a PandaES that works fine with my current Linux/Minicom/USB port configuration, I rule out anything to do with that part, and probably you are right to suggest it might be some hardware issues specifically related to my board.

still it would be great if anybody can assert that running any command in-tandem more than once produces the same consistent output !!!

[MarkHaysHarris777]

Thank you for ... <snip>

still it would be great if anybody can assert that running any command in-tandem more than once produces the same consistent output !!!

I'm not sure what the emphasis is about...  the assertion you're looking for depends on the command and the specific circumstances ( obviously ).

The specific inconsistency in your examples is due to your comm link...  fix the comm link, and the output will become consistent. The Rock64 has up'd the anti a bit;  1.5M baud is trickier to get 'consistent' results from on the lab top.

Computers in general ( outside of hardware errors ) must be consistent, or they are useless.  Of course you should be able to get consistent results from your gnu+linux commands.

[consoleadam]

Thank you for ... <snip>

still it would be great if anybody can assert that running any command in-tandem more than once produces the same consistent output !!!

I'm not sure what the emphasis is about...  the assertion you're looking for depends on the command and the specific circumstances ( obviously ).

The specific inconsistency in your examples is due to your comm link...  fix the comm link, and the output will become consistent. The Rock64 has up'd the anti a bit;  1.5M baud is trickier to get 'consistent' results from on the lab top.

Computers in general ( outside of hardware errors ) must be consistent, or they are useless.  Of course you should be able to get consistent results from your gnu+linux commands.

This certainly an assertion of a known shortcoming of laptops .. [ Rock64 has up'd the anti a bit;  1.5M baud is trickier to get 'consistent' results from on the lab top ]  or maybe the RK3328 SoC ;)
thanxxx