| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <DDQCQPRRVOHB.1ENJWEGUOSBTR@kernel.org>
Date: Fri, 24 Oct 2025 08:51:55 +0200
From: "Michael Walle" <mwalle@...nel.org>
To: "Kumar, Udit" <u-kumar1@...com>, "Nishanth Menon" <nm@...com>, "Vignesh
Raghavendra" <vigneshr@...com>, "Tero Kristo" <kristo@...nel.org>, "Rob
Herring" <robh@...nel.org>, "Krzysztof Kozlowski" <krzk+dt@...nel.org>,
"Conor Dooley" <conor+dt@...nel.org>
Cc: <linux-arm-kernel@...ts.infradead.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/3] arm64: dts: ti: Add support for Kontron
SMARC-sAM67
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@...nel.org>
>> ---
>> 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.
>> + 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.
-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";
>> +};
> [..]
Powered by blists - more mailing lists