Re: [PATCH v4 2/3] arm64: dts: ti: Add k3-am62l3-beaglebadge
From: Judith Mendez
Date: Tue May 26 2026 - 17:59:40 EST
On 5/18/26 8:11 AM, Nishanth Menon wrote:
On 10:35-20260515, Judith Mendez wrote:
BeagleBoard.org BeagleBadge is a compact, affordable open source
hardware single board computer based on the Texas Instruments AM62L3
SoC designed for IoT and embedded applications with low power
consumption. Expansion is provided over open standards based headers
including QWIIC and GPIO interfaces.
https://github.com/beagleboard/BeagleBadge
Why not use https://www.beagleboard.org/boards/beaglebadge ?
Will switch link
Co-developed-by: Andrew Davis <afd@xxxxxx>
Signed-off-by: Andrew Davis <afd@xxxxxx>
Signed-off-by: Judith Mendez <jm@xxxxxx>
---
Changelog since v3:
- Add missing newline in commit message
- Drop beagleboard URL
- Drop uneeded header files
- Add boothph flags in wkup_i2c0 & PMC nodes
---
arch/arm64/boot/dts/ti/Makefile | 1 +
.../boot/dts/ti/k3-am62l3-beaglebadge.dts | 700 ++++++++++++++++++
2 files changed, 701 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 5269c9619b65c..4e377ca011cd8 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62d2-evm.dtb
# Boards with AM62Lx SoCs
dtb-$(CONFIG_ARCH_K3) += k3-am62l3-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am62l3-beaglebadge.dtb
# Boards with AM62Px SoC
dtb-$(CONFIG_ARCH_K3) += k3-am62p5-sk.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
new file mode 100644
index 0000000000000..30fc9c83b1f44
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62l3-beaglebadge.dts
@@ -0,0 +1,700 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * https://www.beagleboard.org/boards/beaglebadge
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
Seeing the tags, I assume no BeagleBoard.org member contributions?
Not yet ^.^
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include "k3-am62l3.dtsi"
+#include "k3-pinctrl.h"
+
+/ {
+ compatible = "beagle,am62l3-beaglebadge", "ti,am62l3";
+ model = "BeagleBoard.org BeagleBadge";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio2 = &wkup_gpio0;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c4 = &wkup_i2c0;
+ mmc1 = &sdhci1;
+ mmc2 = &sdhci2;
+ serial3 = &uart1;
+ usb0 = &usb0;
+ usb1 = &usb1;
is this valid?
git grep of_alias_ driver/usb/
am I missing something?
+ };
+
+ memory@80000000 {
+ /* 256MB */
+ reg = <0x00000000 0x80000000 0x00000000 0x10000000>;
+ device_type = "memory";
+ bootph-all;
+ };
+
+ thermal-zones {
+ wkup0-thermal {
+ polling-delay-passive = <250>; /* milliSeconds */
+ polling-delay = <500>; /* milliSeconds */
+ thermal-sensors = <&vtm0 0>;
+
+ trips {
+ crit0 {
+ temperature = <125000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
This is better done by having something like
arch/arm64/boot/dts/ti/k3-am62l-industrial-thermal.dtsi
I am following what k3-am62l3-evm.dts is doing [0], we moved
thermal-zones node to the board file instead of defining in thermal.dtsi
[0] https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/ti/k3-am62l3-evm.dts#L61
[..]
+
+ sensor_3v3: regulator-4 {
+ /* TPS22918DBVR */
+ compatible = "regulator-fixed";
+ regulator-name = "Sensor_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vdd_3v3>;
+ regulator-boot-on;
+ regulator-always-on;
Why sensor supply is always on?
No special reason, I can remove to help with power saving.
+ enable-active-high;
+ gpio = <&wkup_gpio0 1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sensor_3v3_ena_pins_default>;
+ bootph-all;
+ };
+
+ wlan_en: regulator-5 {
+ compatible = "regulator-fixed";
+ regulator-name = "wlan_en";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ enable-active-high;
+ gpios = <&gpio0 51 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_en_pins_default>;
+ };
+};
+
[..]
+
+ usr_button_pins_default: usr-button-default-pins {
+ pinctrl-single,pins = <
+ AM62LX_IOPAD(0x00a4, PIN_INPUT, 7) /* (H18) GPMC0_AD11.GPIO0_26 */
+ AM62LX_IOPAD(0x01e4, PIN_INPUT, 7) /* (D16) EXT_REFCLK1.GPIO0_104 */
+ AM62LX_IOPAD(0x00c0, PIN_INPUT, 7) /* (N19) GPMC0_ADVn_ALE.GPIO0_32 */
+ AM62LX_IOPAD(0x00e8, PIN_INPUT, 7) /* (L19) GPMC0_CSn1.GPIO0_42 */
+ AM62LX_IOPAD(0x00b8, PIN_INPUT, 7) /* (L21) GPMC0_CLK.GPIO0_31 */
+ AM62LX_IOPAD(0x01c0, PIN_INPUT, 7) /* (B13) UART0_RTSn.GPIO0_95 */
+ >;
+ };
no wakeup from usr buttons?
RTC wakeup node is not in upstream tree, so no, user button wakeup
support is not enabled yet.
[...]
+};
+
+&gpio0 {
+ gpio-line-names ="","","","","","","","","","", /* 0-9 */
space after that =
Will fix.
+ "","","","","","BOOST_5V_ENA","VDD_3V3_SD_ENA","","","", /* 10-19 */
+ "","","","","","MCP23S18_RESET","BTN_SELECT","","","", /* 20-29 */
+ "","BTN_LEFT","BTN_UP","","LORA_RESET","","","","","", /* 30-39 */
+ "FUEL_GAUGE_BATLOW","LORA_RFSW","BTN_DOWN","USB_HUB_RST","MIKROBUS_INT","","","","","", /* 40-49 */
+ "","WLAN_EN","","","","","","","","", /* 50-59 */
+ "","","","","","","","","","", /* 60-69 */
+ "","","","","","","","","","", /* 70-79 */
+ "","","","","MIKROBUS_RST","","","","LORA_BUSY","", /* 80-89 */
+ "","","","","LORA_DIO","BTN_RIGHT","","","","", /* 90-99 */
+ "","","","","BTN_BACK","","","","","", /* 100-109 */
+ "","","","","","","","","","", /* 110-119 */
+ "","","SD_CD","","",""; /* 120-125 */
Could you keep these under 100 chars?
I could for most of these lines I believe, but it will completely mess
up the alignment in comments, If that is fine, I will fix. (:
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio0_pins_default>, <&usr_button_pins_default>, <&lora_control_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&wkup_gpio0 {
+ gpio-line-names ="","SENSOR_3V3_ENA","","","","","",""; /* 0-7 */
same
+ bootph-all;
+ status = "okay";
+};
+
+&sdhci1 {
+ /* SD/MMC */
+ vmmc-supply = <&vdd_3v3_sd>;
+ disable-wp;
+ cd-gpios = <&gpio0 122 GPIO_ACTIVE_LOW>;
+ cd-debounce-delay-ms = <100>;
+ ti,fails-without-test-cd;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_default>;
+ bootph-all;
+ status = "okay";
+};
+
+&sdhci2 {
+ vmmc-supply = <&wlan_en>;
+ bus-width = <4>;
+ non-removable;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins_default>;
+ ti,driver-strength-ohm = <50>;
+ ti,fails-without-test-cd;
+ status = "okay";
+};
Why not introduce the sdhci2 and supplies once we get wlan driver in
upstream?
I can do that. NP.
~ Judith
...