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.schulz@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+uboot@0leil.net Signed-off-by: Quentin Schulz quentin.schulz@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-751d7cc978b9@theobrom...
- };
+};
+&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/9e644284ab812f2db23f6185af77c0... 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