Hi Dinesh,
On Fri, 26 Jun 2026 00:59:09 +0800, [email protected] wrote:
diff --git a/arch/arm/dts/socfpga_agilex5_socdk_013b.dts
b/arch/arm/dts/socfpga_agilex5_socdk_013b.dts
@@ -0,0 +86,15 @@ finding 90-96
+&i3c1 {
+ status = "okay";
+};
+
+&mmc {
+ status = "okay";
+ bus-width = <4>;
+ no-1-8-v;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ disable-wp;
+ sd-uhs-sdr50;
+ cdns,phy-use-ext-lpbk-dqs = <1>;
+ cdns,phy-use-lpbk-dqs = <1>;
+ cdns,phy-use-phony-dqs = <1>;
SD UHS is advertised while 1.8 V signaling is disabled (patman-adjacent
DT consistency).
UHS-I SDR50 requires 1.8 V I/O. no-1-8-v tells the SD stack the board
cannot switch signaling voltage. Shipping both properties confuses
capability negotiation for U-Boot and Linux consumers of the same .dts.
Please: Pick one board policy: either drop sd-uhs-sdr50 (and keep
no-1-8-v for 3.3 V-only SD), or drop no-1-8-v if the 013B slot truly
supports UHS-I 1.8 V switching. Do not leave both on the merged DT.
diff --git a/arch/arm/dts/socfpga_agilex5_socdk_013b.dts
b/arch/arm/dts/socfpga_agilex5_socdk_013b.dts
@@ -0,0 +85,32 @@ finding 89-133
+
+&i3c1 {
+ status = "okay";
+};
+
+&mmc {
+ status = "okay";
+ bus-width = <4>;
+ no-1-8-v;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ disable-wp;
+ sd-uhs-sdr50;
+ cdns,phy-use-ext-lpbk-dqs = <1>;
+ cdns,phy-use-lpbk-dqs = <1>;
+ cdns,phy-use-phony-dqs = <1>;
+ cdns,phy-use-phony-dqs-cmd = <1>;
+ cdns,phy-io-mask-always-on = <0>;
+ cdns,phy-io-mask-end = <5>;
+ cdns,phy-io-mask-start = <0>;
+ cdns,phy-data-select-oe-end = <1>;
+ cdns,phy-sync-method = <1>;
+ cdns,phy-sw-half-cycle-shift = <0>;
+ cdns,phy-rd-del-sel = <52>;
+ cdns,phy-underrun-suppress = <1>;
+ cdns,phy-gate-cfg-always-on = <1>;
+ cdns,phy-param-dll-bypass-mode = <1>;
+ cdns,phy-param-phase-detect-sel = <2>;
+ cdns,phy-param-dll-start-point = <254>;
+ cdns,phy-read-dqs-cmd-delay = <0>;
+ cdns,phy-clk-wrdqs-delay = <0>;
+ cdns,phy-clk-wr-delay = <0>;
MMC Cadence PHY props are duplicated in two incompatible schemas across
.dts and -u-boot.dtsi.
U-Boot builds the DTB from .dts + -u-boot.dtsi. After merge the node
carries both cap-mmc-highspeed and no-mmc, plus two different Cadence
property families. Base Agilex5 SoCDK avoids that by leaving MMC board
tuning in the U-Boot dtsi only.
Please: Follow the base SoCDK split: keep Linux-facing MMC essentials in
.dts if needed, put U-Boot Cadence timing only in -u-boot.dtsi, and
/delete-property/ any .dts keys that contradict no-mmc / U-Boot timing
(especially cap-mmc-highspeed when no-mmc is set).
…
diff --git a/arch/arm/dts/socfpga_agilex5_socdk_013b.dts
b/arch/arm/dts/socfpga_agilex5_socdk_013b.dts
@@ -0,0 +58,15 @@ finding 62-68
+ phy-handle = <&emac2_phy0>;
+ max-frame-size = <9000>;
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ emac2_phy0: ethernet-phy@0 {
+ reg = <0>;
+ rxc-skew-ps = <0>;
+ rxdv-skew-ps = <0>;
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txc-skew-ps = <0>;
MDIO child uses snps,dwmac-mdio while sibling Agilex5 boards use
snps,dwxgmac-mdio.
Functional impact is likely low (XGMAC driver allocates its own MDIO bus
from phy-handle), but the string diverges from every in-tree Agilex5
sibling and from the parent dwxgmac compatible.
Please: Change the MDIO child compatible to snps,dwxgmac-mdio to match
other Agilex5 SoCDK variants.
diff --git a/arch/arm/dts/socfpga_agilex5_socdk_013b.dts
b/arch/arm/dts/socfpga_agilex5_socdk_013b.dts
@@ -0,0 +8,13 @@ finding 12-16
+/ {
+ model = "SoCFPGA Agilex5 013B SoCDK";
+
+ aliases {
+ serial0 = &uart0;
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ ethernet2 = &gmac2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
ethernet0/ethernet1 aliases point at disabled gmac0/gmac1; only gmac2 is
enabled.
Dead aliases make eth0/eth1 names resolve to disabled controllers.
Acceptable if intentional single-port board, but worth an explicit board
note or cleanup.
Please: If 013B HPS enablement only wires EMAC2, drop
ethernet0/ethernet1 aliases (or enable the ports that are actually
populated). Confirm against the DK-A5E013BM16AEA board design.
Best regards,
Tien Fong
