05-21-2019, 07:34 PM
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.)
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