Hi Jonas,
On 2/11/24 22:34, Jonas Karlman wrote:
Hi Quentin,
On 2024-02-09 10:50, Quentin Schulz wrote:
From: Quentin Schulz <quentin.sch...@theobroma-systems.com>
JAGUAR is a Single-Board Computer (SBC) based around the rk3588 SoC and
is targeting Autonomous Mobile Robots (AMR).
It features:
* LPDDR4X (up to 16GB)
* 1Gbps Ethernet on RJ45 connector (KSZ9031 or KSZ9131)
* PCIe 3.0 4-lane on M.2 M-key connector
* PCIe 2.1 1-lane on M.2 E-key
* USB 2.0 on M.2 E-key
* 2x USB3 OTG type-c ports with DP Alt-Mode
* USB2 host port
* HDMI output
* 2x camera connectors, each exposing:
* 2-lane MIPI-CSI
* 1v2, 1v8, 2v8 power rails
* I2C bus
* GPIOs
* PPS input
* CAN
* RS485 UART
* FAN connector
* SD card slot
* eMMC (up to 256GB)
* RTC backup battery
* Companion microcontroller
* ISL1208 RTC emulation
* AMC6821 PWM emulation
* On/off buzzer control
* Secure Element
* 80-pin Mezzanine connector for daughterboards:
* GPIOs
* 1Gbps Ethernet
* PCIe 2.1 1-lane
* 2x 2-lane MIPI-CSI
* ADC channel
* I2C bus
* PWM
* UART
* SPI
* SDIO
* CAN
* I2S
* 1v8, 3v3, 5v0, dc-in (12-24V) power rails
The Device Tree comes from next-20240110 Linux kernel.
Cc: Quentin Schulz <foss+ub...@0leil.net>
Signed-off-by: Quentin Schulz <quentin.sch...@theobroma-systems.com>
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3588-jaguar-u-boot.dtsi | 38 +
arch/arm/dts/rk3588-jaguar.dts | 803 +++++++++++++++++++++
arch/arm/mach-rockchip/rk3588/Kconfig | 28 +
board/theobroma-systems/jaguar_rk3588/Kconfig | 16 +
board/theobroma-systems/jaguar_rk3588/MAINTAINERS | 13 +
board/theobroma-systems/jaguar_rk3588/Makefile | 10 +
.../jaguar_rk3588/jaguar_rk3588.c | 52 ++
configs/jaguar-rk3588_defconfig | 115 +++
doc/board/index.rst | 1 +
doc/board/rockchip/rockchip.rst | 1 +
doc/board/theobroma-systems/index.rst | 9 +
doc/board/theobroma-systems/jaguar_rk3588.rst | 100 +++
include/configs/jaguar_rk3588.h | 15 +
14 files changed, 1202 insertions(+)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3beb8f1b9d4..7c103655e1d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -193,6 +193,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
+ rk3588-jaguar.dtb \
rk3588-nanopc-t6.dtb \
rk3588s-orangepi-5.dtb \
rk3588-orangepi-5-plus.dtb \
diff --git a/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
b/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
new file mode 100644
index 00000000000..a0207c265c9
--- /dev/null
+++ b/arch/arm/dts/rk3588-jaguar-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include "rk3588-u-boot.dtsi"
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/usb/pd.h>
These dt-bindings includes should not be needed in this file.
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
Is there specific reasoning behind why eMMC is listed before SD-card?
Consistency with our other products (Ringneck PX30 and Puma RK3399).
rk3588-u-boot.dtsi should now contain a default with a same-as-spl >
SD-card > eMMC order.
Also guess in practice it should not matter mutch, if TPL/SPL is running
from eMMC it will read FIT from eMMC > eMMC > SD-card. And if TPL/SPL is
running from SD-card it will read FIT from SD-card > eMMC > SD-card.
I was pondering whether we should do something about this, to avoid
reading twice from the same boot medium, this unnecessarily increase the
boot time in case we're entering the fallback mechanism.
Main difference would be if TPL/SPL is running from SPI, then it will
read FIT from SPI > eMMC > SD-card instead of SPI > SD-card > eMMC.
Yes, we do have an SPI-NOR on Puma, and we want SPI -> eMMC -> SD card
there (mainly because that's what we've always done, thus now for
"backward" compatibility).
For SPI-less systems, I guess it doesn't matter much indeed.
In my mind anything after same-as-spl would mostly be used for recovery.
And preferring SD-card may ease in such situation?
No, this we don't want. But this is just a different policy from
Rockchip's default.
c.f.
https://lore.kernel.org/u-boot/7b5cb03f-c2b2-4cf2-b06a-751d7cc97...@theobroma-systems.com/
+ };
+};
+
+&emmc_pwrseq {
+ bootph-all;
+};
+
+&emmc_reset {
+ bootph-all;
+};
+
+&gpio0 {
+ bootph-all;
+};
+
+&gpio2 {
+ bootph-all;
I am guessing that emmc_pwrseq, gpio0 and gpio2 would not be needed in
TPL so bootph-all could be too inclusive, for now I guess this does not
really matter because an external TPL blob is used anyway.
Don't have much of a choice sadly, c.f.
https://source.denx.de/u-boot/u-boot/-/commit/9e644284ab812f2db23f6185af77c0e771b0be73
Considering that we need the eMMC in U-Boot proper before relocation, I
assume I need the emmc_pwrseq as well in bootph-all.
As for gpio0, I think we use one of the pins in that bank for the NVMe
but we indeed wouldn't need it before relocation. Especially since I
somehow didn't manage to get it to work in U-Boot yet.
Cheers,
Quentin
