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:
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.
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: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.
