HOW TO - Connect the serial console
#11
A little more progress. To answer my earlier question, I can (sort of) tell the bootloader to use a different baud rate by setting the baudrate variable in /boot/armbianEnv. (This is, obviously, specific to Armbian, but I bet other distributions have a similar file in /boot.)

I say "sort of" because I still get garbage at first, but then I get some bootloader messages and kernel boot messages before the login prompt:

Code:
4239367 bytes read in 489 ms (8.3 MiB/s)
18667528 bytes read in 2009 ms (8.9 MiB/s)
87955 bytes read in 142 ms (604.5 KiB/s)
** File not found /boot/dtb/rockchip/overlay/rockchip-fixup.scr **
## Loading init Ramdisk from Legacy Image at 04000000 ...
  Image Name:   uInitrd
  Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
  Data Size:    4239303 Bytes = 4 MiB
  Load Address: 00000000
  Entry Point:  00000000
  Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
  Booting using the fdt blob at 0x1f00000
  Loading Ramdisk to f5af8000, end f5f02fc7 ... OK
  reserving fdt memory region: addr=1f00000 size=7b000
  Loading Device Tree to 00000000f5a7a000, end 00000000f5af7fff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.174-rockchip64 (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11) ) #6 SMP Sun Feb 10 10:43:16 CET 2019
[    0.000000] Boot CPU: AArch64 Processor [410fd034]
[    0.000000] earlycon: Early serial console at MMIO32 0xff1a0000 (options '')
[    0.000000] bootconsole [uart0] enabled

Debian GNU/Linux 9 rockpro64 ttyS2

rockpro64 login:
A couple of notes:

1) The baud rate for the login prompt and onward is set independently from the baud rate for everything before that. For whatever reason, Armbian has the baud rate hard-coded in boot.cmd, rather that looking for the baudrate environment variable.

2) There's a long delay (20+ seconds) after the last boot message ("bootconsole [uart0] enabled") and the ID line ("Debian GNU/Linux 9 rockpro64 ttyS2"). What happening, here? I'm I missing more of the boot messages? Is uart0 the same at ttyS2? (Seems like this should be uart2.)

And, of course, I haven't figured out how to get everything to the lower baudrate. Is the garbage at the very beginning of the boot sequence from the bootloader on the SD card, or is it from something built into the rockpro64 that runs before the SD card bootloader? Is it even possible to get that set to a lower baud rate?

I'm getting a new USB-serialTTL adapter that should support 1500000 baud, but now that I'm into this, I really want to understand what's going on.
  Reply
#12
So by adding this line to /boot/armbianEnv.txt, I get a lot more output after the "bootconsole" message:

Code:
console=serial

The console variable appears to default to "both" in boot.cmd. So that option doesn't seem to work correctly.

Here's the output I now get:

Code:
4239367 bytes read in 490 ms (8.3 MiB/s)
18667528 bytes read in 2010 ms (8.9 MiB/s)
87955 bytes read in 142 ms (604.5 KiB/s)
** File not found /boot/dtb/rockchip/overlay/rockchip-fixup.scr **
## Loading init Ramdisk from Legacy Image at 04000000 ...
  Image Name:   uInitrd
  Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
  Data Size:    4239303 Bytes = 4 MiB
  Load Address: 00000000
  Entry Point:  00000000
  Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
  Booting using the fdt blob at 0x1f00000
  Loading Ramdisk to f5af8000, end f5f02fc7 ... OK
  reserving fdt memory region: addr=1f00000 size=7b000
  Loading Device Tree to 00000000f5a7a000, end 00000000f5af7fff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.174-rockchip64 (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11) ) #6 SMP Sun Feb 10 10:43:16 CET 2019
[    0.000000] Boot CPU: AArch64 Processor [410fd034]
[    0.000000] earlycon: Early serial console at MMIO32 0xff1a0000 (options '')
[    0.000000] bootconsole [uart0] enabled
Loading, please wait...
starting version 232
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.29.2
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1
/dev/mmcblk0p1: Superblock last mount time (Thu Nov  3 17:16:42 2016,
       now = Fri Jan 18 08:50:09 2013) is in the future.
FIXED.
/dev/mmcblk0p1: Superblock last write time is in the future.
       (by less than a day, probably due to the hardware clock being incorrectly set)
/dev/mmcblk0p1: 36772/960992 files (0.2% non-contiguous), 354106/3843376 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

Welcome to Debian GNU/Linux 9 (stretch)!

[  OK  ] Listening on Syslog Socket.
[  OK  ] Started Dispatch Password Requests to Console Directory Watch.
[  OK  ] Listening on fsck to fsckd communication Socket.
[  OK  ] Reached target Remote File Systems.
[  OK  ] Listening on udev Kernel Socket.
[  OK  ] Reached target Swap.
[  OK  ] Created slice System Slice.
        Mounting Debug File System...
[  OK  ] Listening on udev Control Socket.
        Mounting POSIX Message Queue File System...
[  OK  ] Listening on Journal Socket (/dev/log).
[  OK  ] Created slice system-getty.slice.
[  OK  ] Set up automount Arbitrary Executab…rmats File System Automount Point.
[  OK  ] Created slice User and Session Slice.
[  OK  ] Listening on Journal Audit Socket.
[  OK  ] Started Forward Password Requests to Wall Directory Watch.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Encrypted Volumes.
[  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[  OK  ] Listening on Journal Socket.
        Starting Journal Service...
        Starting Restore / save the current clock...
        Starting Create list of required st…ce nodes for the current kernel...
        Starting Load Kernel Modules...
        Starting Nameserver information manager...
        Starting Set the console keyboard layout...
[  OK  ] Reached target Slices.
        Starting Remount Root and Kernel File Systems...
        Mounting Huge Pages File System...
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Mounted Debug File System.
[  OK  ] Mounted Huge Pages File System.
[  OK  ] Started Restore / save the current clock.
[  OK  ] Started Create list of required sta…vice nodes for the current kernel.
[  OK  ] Started Load Kernel Modules.
[  OK  ] Started Remount Root and Kernel File Systems.
[  OK  ] Started Nameserver information manager.
        Starting Load/Save Random Seed...
        Starting udev Coldplug all Devices...
        Starting Apply Kernel Variables...
        Mounting Configuration File System...
        Mounting FUSE Control File System...
        Starting Create Static Device Nodes in /dev...
[  OK  ] Mounted Configuration File System.
[  OK  ] Mounted FUSE Control File System.
[  OK  ] Started Journal Service.
[  OK  ] Started Set the console keyboard layout.
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started Create Static Device Nodes in /dev.
        Starting udev Kernel Device Manager...
[  OK  ] Reached target Local File Systems (Pre).
        Mounting /tmp...
        Starting Flush Journal to Persistent Storage...
[  OK  ] Mounted /tmp.
[  OK  ] Reached target Local File Systems.
        Starting Armbian ZRAM config...
        Starting Raise network interfaces...
        Starting Set console font and keymap...
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Started udev Coldplug all Devices.
[  OK  ] Started Set console font and keymap.
[  OK  ] Started Flush Journal to Persistent Storage.
        Starting Create Volatile Files and Directories...
[  OK  ] Started Create Volatile Files and Directories.
[  OK  ] Reached target Sound Card.
[  OK  ] Started Entropy daemon using the HAVEGE algorithm.
[  OK  ] Reached target System Time Synchronized.
        Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Found device /dev/ttyS2.
[  OK  ] Started Update UTMP about System Boot/Shutdown.
[  OK  ] Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
        Starting Load/Save RF Kill Switch Status...
[  OK  ] Started Load/Save RF Kill Switch Status.
[  OK  ] Started Raise network interfaces.
[  OK  ] Started Armbian ZRAM config.
        Starting Armbian memory supported logging...
[  OK  ] Started Armbian memory supported logging.
[  OK  ] Reached target System Initialization.
        Starting Armbian hardware optimization...
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Started Daily apt download activities.
[  OK  ] Started Daily apt upgrade and clean activities.
[  OK  ] Reached target Timers.
        Starting Armbian hardware monitoring...
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Started Armbian hardware optimization.
[  OK  ] Started Armbian hardware monitoring.
[  OK  ] Reached target Basic System.
        Starting LSB: Start/stop sysstat's sadc...
        Starting LSB: Load kernel modules needed to enable cpufreq scaling...
        Starting Login Service...
        Starting System Logging Service...
[  OK  ] Started D-Bus System Message Bus.
        Starting Save/Restore Sound Card State...
        Starting Network Manager...
[  OK  ] Started Regular background program processing daemon.
[  OK  ] Started System Logging Service.
[  OK  ] Started Save/Restore Sound Card State.
[  OK  ] Started LSB: Start/stop sysstat's sadc.
[  OK  ] Started Login Service.
[  OK  ] Started LSB: Load kernel modules needed to enable cpufreq scaling.
        Starting LSB: set CPUFreq kernel parameters...
[  OK  ] Started LSB: set CPUFreq kernel parameters.
        Starting LSB: Set sysfs variables from /etc/sysfs.conf...
[  OK  ] Started LSB: Set sysfs variables from /etc/sysfs.conf.
[  OK  ] Started Network Manager.
        Starting Network Manager Wait Online...
[  OK  ] Reached target Network.
        Starting OpenBSD Secure Shell server...
[  OK  ] Started Unattended Upgrades Shutdown.
        Starting Permit User Sessions...
[  OK  ] Started Permit User Sessions.
        Starting Network Manager Script Dispatcher Service...
[  OK  ] Started Network Manager Script Dispatcher Service.
        Starting Hostname Service...
[  OK  ] Started OpenBSD Secure Shell server.
[  OK  ] Started Hostname Service.
        Starting Authorization Manager...
[  OK  ] Started Authorization Manager.
[  OK  ] Started Network Manager Wait Online.
[  OK  ] Reached target Network is Online.
        Starting LSB: Advanced IEEE 802.11 management daemon...
        Starting /etc/rc.local Compatibility...
        Starting LSB: Start NTP daemon...
[  OK  ] Started LSB: Advanced IEEE 802.11 management daemon.
[  OK  ] Started /etc/rc.local Compatibility.
[  OK  ] Started Getty on tty1.
[  OK  ] Started Serial Getty on ttyS2.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started LSB: Start NTP daemon.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.
        Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.

Debian GNU/Linux 9 rockpro64 ttyS2

rockpro64 login:

I'm still getting a bunch of junk at the very beginning (not shown), probably due to mismatched baud rate. I still haven't found a way to set the baud rate for the very early boot stages. Perhaps it's impossible to change. And there's still that weird "bootconsole [uart0] enabled" message, which appears to be pointing to the wrong port.
  Reply
#13
First of all, I will give my thoughts and say what I know from a technical point of view.
I think that purchasing a compatible item is far more sensible than doing various trials because the 1.5M bps compatible USB-UART item is inexpensive and easy to obtain.
In addition, Changing this part easily is considered a nuisance to developers.

--
The following is the result of researching purely from technical interest.
(My original purpose is fix to "sdram initialization" code)

> 1) The baud rate for the login prompt and onward is set independently from the baud rate for everything before that. ...

This is fine as long as they do not consider anything other than 1.5M bps.
If you consider other baud rates, you should change it in "boot.cmd" as follows.

"console=ttyS2,1500000 ${consoleargs}" -> "${consoleargs} console=ttyS2,${baudrate}n8"

> 2) There's a long delay (20+ seconds) after the last boot message ("bootconsole [uart0] enabled") ...

In the current settings, many messages are output to HDMI.
Please try combining "verbosity = 7" with the above correction.
You should get the expected results, even with the "both" setting.

---

> I still haven't found a way to set the baud rate for the very early boot stages.
> Perhaps it's impossible to change. ...

There are two boot related software with hard coded baud rate settings.
One is "u-boot" and the other is "rk3399_ddr_800MHz_v1.13.bin".
Unless you can avoid these two things, you can not get the results you want.
And if you try to avoid this, big hurdles stand up.

It is easy to find the hard coding part in "u-boot".
However, the important "sdram initializing" code does not work properly.
This is probably why most distributions use "rk3399_ddr_xxxMHz_v???.bin".
And "rk3399_ddr_xxxMHz_v???.bin" is a binary only offer, the source code has not been opend.

You have to overcome this obstacle to get the results you want.
But, both of them are "specification is not open, source code is not open", so the difficulty is high.

If you solve the above, you will get the results you want.
This is not a guess.
I have actually done it and confirmed that it works as expected.

--
If you examine "rk3399_ddr_xxxMHz_v???.bin",
You can be understood that the 115200 and 1500000 two types of baud rates can be supported.
This choice would have been difficult for them at first time.

U-Boot with TPL ("rk3399_ddr_xxxMHz_v???.bin" is not used.)
Code:
U-Boot TPL 2019.01 (May 06 2019 - 12:24:04)
Starting SDRAM initialization...
Channel 0: LPDDR4, 50 MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50 MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
change freq to 400 MHz 0, 1
channel 0 training pass
channel 1 training pass
change freq to 800 MHz 1, 0
channel 0 training pass
channel 1 training pass
ch 0 ddrconfig = 0x101, ddrsize = 0x2020
ch 1 ddrconfig = 0x101, ddrsize = 0x2020
pmugrf_os_reg[2] = 0x3aa1faa1, stride = 0xd
Finish SDRAM initialization...
Returning to boot ROM...

U-Boot SPL board init

U-Boot SPL 2019.01 (May 06 2019 - 12:24:04)
booted from SPI
Trying to boot from SPI
NOTICE:  BL31: v2.0(release):7d38840
NOTICE:  BL31: Built : 09:20:31, Jan 30 2019
NOTICE:  BL31: Rockchip release version: v1.1


U-Boot 2019.01 (May 06 2019 - 12:24:28 +0900)
Model: Pine64 RockPro64
DRAM:  3.9 GiB
PMIC:  RK808
MMC:   sdhci@fe330000: 0, dwmmc@fe320000: 1
SF:    Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
In:    serial@ff1a0000
Out:   serial@ff1a0000
Err:   serial@ff1a0000
Net:   eth0: ethernet@fe300000
Hit any key to stop autoboot:  0
  Reply
#14
Thank you for the very informative reply! A couple of specific points I want to respond to:

(05-21-2019, 07:34 PM)t4_4t Wrote: First of all, I will give my thoughts and say what I know from a technical point of view.
I think that purchasing a compatible item is far more sensible than doing various trials because the 1.5M bps compatible USB-UART item is inexpensive and easy to obtain.
In addition, Changing this part easily is considered a nuisance to developers.

I do have a more appropriate serial adapter on the way, because that always appeared to be the path of least resistance. But in the meantime, I wanted to see how far I could get. Also, I have a compulsion to understand what I'm using!

It's also annoying that someone chose an oddball baudrate to be hardcoded! I was a little surprised by that.

Quote:> 1) The baud rate for the login prompt and onward is set independently from the baud rate for everything before that. ...

This is fine as long as they do not consider anything other than 1.5M bps.
If you consider other baud rates, you should change it in "boot.cmd" as follows.

"console=ttyS2,1500000 ${consoleargs}" -> "${consoleargs} console=ttyS2,${baudrate}n8"

Yeah, I just don't understand why the stock Armbian image isn't like that, already.

Quote:> 2) There's a long delay (20+ seconds) after the last boot message ("bootconsole [uart0] enabled") ...

In the current settings, many messages are output to HDMI.
Please try combining "verbosity = 7" with the above correction.
You should get the expected results, even with the "both" setting.

I'll try that. But why would the verbosity default be different for the two consoles?
  Reply
#15
> I do have a more appropriate serial adapter on the way,
> because that always appeared to be the path of least resistanc ...
Don't worries, I wrote because I was watching the above post.

> It's also annoying that someone chose an oddball baudrate to be hardcoded!
I was also surprised at first, why did you choose 1.5M bps without any major benefits ?
The only way to verify this is to ask them (Rockchip).
However, I do not think that the answer comes back even if we ask the reason.

> I just don't understand why the stock Armbian image isn't like that, already.
Even for them (Armbian),
It should not be easy to go beyond the hurdles of non-disclosure of information.
And, unless go beyond this hurdle, they can not take options other than 1.5MBps.

If so, there do not need to pay attention to this part coding.
"Just wrote the numbers directly without any special intentions"
I think that there is no special meaning.

> But why would the verbosity default be different for the two consoles?
I do not know about this because I have not investigated it in detail.

I usually do not use "Armbian".
However, compared to the image of "ayufan", the amount of log output was clearly smaller.
I felt uncomfortable with this difference.
So I tried changing "verbosity = 7". and "console" order.
The log output will then be at the same level as the "ayufan" image.

As for me, this is the correct answer.
So I didn't need to investigate further.
  Reply
#16
Couldn't we just have a username and password setup in the SD card image and login with SSH?

SD card image: NetBSD-evbarm-aarch64-201906031130Z-rockpro64.img.gz on second boot does a DHCP
and starts the SSHD daemon.
Yes, had I known, I would have acquired the serial console board.

Alan B
  Reply
#17
Hi,

On macOS, I get a strange output, does someone know how to fix it?
Code:
���:<�Y}~���=�]��<~�������~�����_�����y���}�>��=�Y<�}�����W��~]��^ͽ}�]n�Y����(�s�����at^����������ܸ����x�������CS����须z�iXO�[+�Jjj�me��Rsڛ��ŏ�u�+:�۩++��x������$������Jͭ�����j,��G?Q:�������������$��'����J�����ɺ��|�����$�ٵ$��dʭ�*�������]�}������J�������*����*�+����9��e����T��ڡ�ڣQ�ͱ�i������K���X��
                                                       ���;�K��b�!j����`k���&�uʭ����pщ���q��

Here is what I did:
stty -f /dev/tty.usbserial-1420 115200
screen /dev/tty.usbserial-1420 115200


If I try that:
stty -f /dev/tty.usbserial-1420 150000
I get that:
stty: tcsetattr: Invalid argument
  Reply
#18
Hello.

Three things I came across with.

1 - Not all UART adapters can run at 1500000 bps. Make sure the one you're using, can run at that speed. I tried to use one that couldn't work at that speed and I wasn't aware of it.

2 - I'm not sure why, but I was advised to make sure the TX line of the UART adpter was runnig at 3v3. Not at 5V.

3 - If you're using minicom, make sure both Hardware and Software flow control options are disabled in minicom configuration. Otherwise, your laptop keyboard won't respond.

Hope this helps too! Smile
  Reply
#19
(03-25-2021, 01:21 PM)PsySc0rpi0n Wrote: Hello.

2 - I'm not sure why, but I was advised to make sure the TX line of the UART adpter was runnig at 3v3. Not at 5V.

The RockPro64 GPIO where the UART transmits from operates at 3.3v. This is also true of the Raspberry Pi GPIO, which is what the RockPro64 GPIO is modeled after. If I remember right, the logic chip that interfaces with the GPIO operates at that voltage.
Quartz64, RockPro64, PinePhone Mobian, PineBook Pro, PineTime, and all the trimmings that make FOSS fun.
  Reply
#20
Currently doing this trying to get my first RockPro64 working.

With the serial console connected to my Pinebook Pro, what I had to do was,
$ stty -F /dev/ttyUSB0 1500000
$ minicom -D /dev/ttyUSB0 -b 1500000

Then all the boot messages display with no garbage at the beginning.

But, after logging in, I have to drop the speed to 115200 or else lost characters garble the output.
$ stty 115200 # this time in the terminal emulator window as a command to the remote system
and the matching config option in the terminal emulator.

Critically, the "Finish Manjaro ARM Install" script is garbled to the point of unusability until I Ctrl-C out of it and drop the tty speed to 115200. It took some time to figure out that the default baud rate was causing that.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Serial Connection Tutorial: FTDI 232RL hmuller 0 3,135 10-23-2020, 11:56 AM
Last Post: hmuller

Forum Jump:


Users browsing this thread: 2 Guest(s)