Re: [PATCH v3 2/3] arm64: dts: ti: Add support for Kontron SMARC-sAM67
From: Kumar, Udit
Date: Fri Oct 24 2025 - 09:36:08 EST
Hi Michael,
On 10/24/2025 12:21 PM, Michael Walle wrote:
Hi Udit,
thanks for the thorough review!
On Fri Oct 24, 2025 at 7:13 AM CEST, Udit Kumar wrote:
On 10/17/2025 7:20 PM, Michael Walle wrote:
Add device tree support for the Kontron SMARC-sAM67 module, which is
based on a TI AM67A SoC.
The module features:
* Quad-core AM67A94 at 1.4GHz with 8 GiB RAM
* 64 GiB eMMC, 4 MiB SPI flash for failsafe booting
* Dedicated RTC
* Multiple interfaces: 4x UART, 2x USB 2.0/USB 3.2, 2x GBE, QSPI,
7x I2C,
* Display support: 2x LVDS, 1x DSI (*), 1x DP (*)
* Camera support: 4x CSI (*)
* Onboard microcontroller for boot control, failsafe booting and
external watchdog
(*) not yet supported by the kernel
There is a base device tree and overlays which will add optional
features. At the moment there is one full featured variant of that
board whose device tree is generated during build by merging all the
device tree overlays.
Signed-off-by: Michael Walle <mwalle@xxxxxxxxxx>
---
arch/arm64/boot/dts/ti/Makefile | 7 +
.../dts/ti/k3-am67a-kontron-sa67-base.dts | 1091 +++++++++++++++++
.../dts/ti/k3-am67a-kontron-sa67-gbe1.dtso | 26 +
.../dts/ti/k3-am67a-kontron-sa67-gpios.dtso | 61 +
.../ti/k3-am67a-kontron-sa67-rtc-rv8263.dtso | 31 +
5 files changed, 1216 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-base.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-gbe1.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-gpios.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-rtc-rv8263.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 743115b849a7..d2a40ea642c4 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -137,7 +137,14 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
# Boards with J722s SoC
+k3-am67a-kontron-sa67-dtbs := k3-am67a-kontron-sa67-base.dtb \
+ k3-am67a-kontron-sa67-rtc-rv8263.dtbo k3-am67a-kontron-sa67-gbe1.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am67a-kontron-sa67.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am67a-kontron-sa67-base.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am67a-kontron-sa67-gbe1.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am67a-kontron-sa67-gpios.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am67a-kontron-sa67-rtc-rv8263.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-tevi-ov5640.dtbo
diff --git a/arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-base.dts b/arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-base.dts
new file mode 100644
index 000000000000..7169d934adac
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am67a-kontron-sa67-base.dts
@@ -0,0 +1,1091 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Kontron SMARC-sAM67 module
+ *
+ * Copyright (c) 2025 Kontron Europe GmbH
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/phy/phy.h>
+#include "k3-j722s.dtsi"
+#include "k3-serdes.h"
+
[..]+
+ ospi0_pins_default: ospi0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x000, PIN_OUTPUT, 0) /* (L24) OSPI0_CLK */
+ J722S_IOPAD(0x02c, PIN_OUTPUT, 0) /* (K26) OSPI0_CSn0 */
+ J722S_IOPAD(0x030, PIN_OUTPUT, 0) /* (K23) OSPI0_CSn1 */
+ J722S_IOPAD(0x034, PIN_OUTPUT, 0) /* (K22) OSPI0_CSn2 */
I am not sure, which flash device is being used , could you check once
if all three CS are supported.
Yes, all three are used. This board has one 4MiB on-board flash
W25Q32 (or similar) and the two others CS are routed to the edge
connector. They aren't multi purpose, so we can already set them
to the CS function.
Thanks for details. Just want to make sure, pins are not used for multi
purpose.
Please use
Reviewed-by: Udit Kumar <u-kumar1@xxxxxx>
+ J722S_IOPAD(0x00c, PIN_INPUT, 0) /* (K27) OSPI0_D0 */
+ J722S_IOPAD(0x010, PIN_INPUT, 0) /* (L27) OSPI0_D1 */
+ J722S_IOPAD(0x014, PIN_INPUT, 0) /* (L26) OSPI0_D2 */
+ J722S_IOPAD(0x018, PIN_INPUT, 0) /* (L25) OSPI0_D3 */
+ >;
+ bootph-all;
+ };
+
+ pcie0_rc_pins_default: pcie0-rc-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x2ac, PIN_OUTPUT, 0) /* (F25) PCIE0_CLKREQn */
+ J722S_IOPAD(0x1b4, PIN_OUTPUT, 7) /* (B20) SPI0_CS0.GPIO1_15 */
+ >;
+ };
+
+ pmic_irq_pins_default: pmic-irq-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x090, PIN_INPUT, 7) /* (P27) GPMC0_BE0n_CLE.GPIO0_35 */
+ >;
+ };
+
[..]
+/* I2C_PM */
+&wkup_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ clock-frequency = <100000>;
+ status = "okay";
This is more a question, I see all i2c controller you want to run at
100Kz, but most of devices are supporting 400Khz
like tps652g1 over main_i2c0 , pca9546 over main_i2c1 , is there
specific reason for this
Actually yes and it was at 400kHz at first. But it wont work with
the onboard management controller at that bus. Although it supports
400kHz, the mode in which we are using it, doesn't. In short, we
aren't using clock stretching as this might cause the whole bus to
hang without being able to recover it from the SoC. Therefore, the
i2c reply bytes have to be prepared just-in-time and it turn out
that 400kHz is too fast for that.
Understood.
-michael
+};
+
+/* SER3 */
+&wkup_uart0 {
+ /* WKUP UART0 is used by Device Manager firmware */
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_uart0_pins_default>;
+ bootph-all;
+ status = "reserved";
+};
[..]