On the official list of mainboards
supported by coreboot there are two boards listed using the RK3399:
Google Gru Chromebook (2017) and RockPro64. Both have a status of
“unknown”. There is a src/soc/rockchip/rk3399/
directory
that was last updated in 2021.
In 2021 Mortiz Fischer from Google added initial support for the RockPro64 (see mainboard/pine64/rockpro64: Add initial ROCKPro64 support and Gerrit 50625). Unfortunately, the implementation of DDR initialization based on U-Boot code was never completed. The Google Gru Chromebook uses DDR3 SDRAM, however the RockPro64 uses DDR4.
Additionally, comparing the Makefile.mk
in the Gru and
RockPro64 mainboard directories shows a great deal of potentially
missing functionality. Perhaps a reasonable way to quickly determine the
support for a board is by runnning:
wc -l src/mainboard/*/*/Makefile.mk | sort -hr
Mortiz was able to get soc/rockchip/rk3399/sdram:
Add phy_ctrl_reset merged, which fixed an issue with the RockPro64
in sdram_init()
, despite the fact that the RockPro64
support for SDRAM initialization was never merged.
Two additional related changes made by Mortiz were abandoned:
Mortiz had four commits on mfischer/wip-rk3399-lpddr4 with the first commit pushed to Gerrit above. The three additional commits are:
soc/rockchip/rk3399/sdram: Compute stride for 2 channels
soc/rockchip/rk3399/sdram: Compute stride for 1 channel a
soc/rockchip/rk3399/sdram: Add rank detection support
Note none of these changes include additional code in
src/mainboard/pine64/rockpro64
.
The RockPro64 apparently shipped with either 2GB or 4GB. I purchased the 4GB model in October 2018.
The Google Kukui also uses a LPDDR4 MT53, but specifically the MT53E1G32DXNX.
I can’t find where U-Boot keeps SDRAM initialization code. Perhaps in
arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
, but shouldn’t it
be board specific?
As a intermediary step, until the coreboot implementation is complete, it may be possible to use U-Boot SPL in “Falcon Mode” to boot a stage containing a u-root initramfs with partial UEFI support.
Falcone mode requires booting the system with U-Boot and running
spl export
at the U-Boot prompt to write “parameters” in
memory that can then be stored in persistent storage. The parameters
presumably include a devicetree and kernel command-line. Then after
resetting the system U-Boot SPL can read that data and pass it to the
kernel, which is normally the responsibility of U-Boot.
It appears to deafult to reading from NAND, but also support NOR.
There are also a falcon_args_file
and
falcon_image_file
that are used in the SPL EXT and FAT
filesystem code.
https://elixir.bootlin.com/u-boot/latest/source/doc/develop/falcon.rst