Hey Sam,
On 24-04-11 16:35:57, Sam Edwards wrote:
On Thu, Apr 11, 2024 at 1:29 AM Florian Klink <flo...@flokli.de> wrote:
On 23-12-14 18:46:47, Joshua Riek wrote:
>The Turing RK1 is a Rockchip RK3588 based SoM from Turing Machines.
>
>Specifications:
>
> Rockchip RK3588 SoC
> 4x ARM Cortex-A76, 4x ARM Cortex-A55
> 8/16/32GB memory LPDDR4x
> Mali G610MC4 GPU
> 32GB eMMC HS400
> 2x USB 2.0, 2x USB 3.0
> 2x MIPI CSI 4x lanes
> 1x MIPI-DSI DPHY 2x lanes
> PCIe 2.0 x1, PCIe 3.0 x4
> 1x HDMI 2.1 output, 1x DP 1.4 output
> Gigabit Ethernet
> Size: 69.6mm x 45mm (260-pin SO-DIMM connector)
>
>Kernel commit:
>2806a69f3fef ("arm64: dts: rockchip: Add Turing RK1 SoM support")
[…]
>diff --git a/configs/turing-rk1-rk3588_defconfig
b/configs/turing-rk1-rk3588_defconfig
>new file mode 100644
>index 0000000000..289f2da775
>--- /dev/null
>+++ b/configs/turing-rk1-rk3588_defconfig
>@@ -0,0 +1,133 @@
>+CONFIG_ARM=y
>+CONFIG_SKIP_LOWLEVEL_INIT=y
>+CONFIG_SYS_HAS_NONCACHED_MEMORY=y
>+CONFIG_COUNTER_FREQUENCY=24000000
>+CONFIG_ARCH_ROCKCHIP=y
>+CONFIG_TEXT_BASE=0x00a00000
>+CONFIG_SPL_LIBCOMMON_SUPPORT=y
>+CONFIG_SPL_LIBGENERIC_SUPPORT=y
>+CONFIG_NR_DRAM_BANKS=2
>+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc00000
>+CONFIG_SF_DEFAULT_SPEED=24000000
>+CONFIG_SF_DEFAULT_MODE=0x2000
>+CONFIG_DEFAULT_DEVICE_TREE="rk3588-turing-rk1"
>+CONFIG_ROCKCHIP_RK3588=y
>+CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
>+CONFIG_ROCKCHIP_SPI_IMAGE=y
Hi Florian,
Thanks for getting in touch!
Does the RK1 have an SPI chip attached, and is is possible to flash
u-boot into SPI and boot from it?
The answer you want is "no." Though the RK1 does have an unpopulated
pad for SPI flash, actually installing one would be a pretty involved
user modification, and those users almost certainly can/will build the
SPI boot image themselves.
This has sparked some confusion on whether "u-boot-rockchip-spi.bin"
should be provided in a downstream build or not.
Ah yeah the CONFIG_ROCKCHIP_SPI_IMAGE=y might not be a sensible
default given that 99.9% of users don't need it. Is that config entry
the main thing creating the confusion? I think it should be removed
here in U-Boot if so.
Yes, it caused a "u-boot-rockchip-spi.bin" to be produced, and we were
wondering on whether it should be provided as a result of our build to
downstream users [1].
Removing it from the `defconfig` sounds like the best way to prevent
this confusion. If people solder on a SPI Flash manually, they probably
know how to re-add it to the uboot config ;-)
Could you send a patch for that?
Note that the RK1 is a little different from most RK3588 boards in
that UART9 at 115200 baud is the generally-accepted debug UART (due
both to the popularity of pairing it with the Turing Pi 2
clusterboard, and for pin-compatibility with most NVIDIA Jetson SoMs),
and setting this very early in boot requires using Rockchip's
"ddrbin_tool" to change the configuration embedded in the ddrbin/TPL
image. If you're already supporting other targets that require ddrbin
configuration changes, please add these for RK1:
uart id=9
uart iomux=0
uart baudrate=115200
...but if this would require going significantly out of your way,
don't worry about it. IIUC this is only required to get TPL+SPL output
routed correctly: the U-Boot monitor + kernel will still
(re)initialize UART9 appropriately.
We currently simply use
`bin/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.16.bin`
from https://github.com/rockchip-linux/rkbin for all RK3588 targets as
`ROCKCHIP_TPL`.
There doesn't seem to be a RK1-specific blob in the repo, and so far
we're not invoking the closed-source x86_64-linux-only
`tools/ddrbin_tool` binary to produce an alternative version of the SPL
for other targets either.
So if it also works without doing that (maybe with a little bit less
debug serial output during early boot) we'd probably keep it like this
;-)
Thanks,
Florian
[1]: https://github.com/NixOS/nixpkgs/pull/302138#discussion_r1560349114
