[Michael Duggan (miduggan24)]

Issue Link:
MATTER-4641

Description of Problem/Feature:
Phase 1 of Matter Renode CI artifact work. The build and publish workflow is in Phase 2.

This PR checks in guest and simulation files that phase 2 will consume, matching the current manual Renode setup

Description of Fix/Solution:
Check in the following under renode_integration/:

• zynqmp-matter-linux.dts: ZynqMP device tree derived from tree from antmicro extended for Matter Hub
• root filesystem overlay scripts applied to the linux image in phase 2
  • S99matter-services
  • matter-thread-init
  • chip-tool wrapper (binary built in phase 2)
• renode scripts to drive simulation
  • matter-sim-full.resc - cold boot
  • matter-sim.resc - load from checkpoint and attach Matter SoC at runtime

Also adds sim-manifest.json to pin versions and RCP configuration, and .gitignore for build products in phase 2

Testing Done:
Manual testing of these simulation inputs as described in the confluence page (these inputs come from the zip file)
https://confluence.silabs.com/spaces/MATTER/pages/878464295/Renode+Simulation

[Michael Duggan (miduggan24)]

bugbot run

[cursor]

PR Summary

Low Risk
New simulation-only assets and shell glue; no production runtime or auth changes. Risk is mainly maintenance of pinned manifests and guest boot scripts.

Overview
Phase 1 adds a new renode_integration/ tree so a later CI phase can build and run a Matter hub in Renode without relying on a manual zip.

The ZynqMP guest is described by zynqmp-matter-linux.dts (Antmicro SM-K26 base plus virtio,mmio for the matter-tools disk and UART wiring for hub/RCPs). A rootfs overlay boots OTBR end-to-end: S99matter-services mounts the tools image, brings up D-Bus, Bluetooth (HCI over ttyPS3), and otbr-agent on Spinel/ttyPS0; matter-thread-init forms a Thread network via D-Bus; chip-tool is a thin launcher for the packaged AArch64 binary.

Renode scripts wire three machines: matter-sim-full.resc cold-boots the Linux hub plus Thread and BLE RCPs over UART hubs and 802.15.4/BLE media (with UART pacing so RCP USART buffers are not overrun); matter-sim.resc loads a checkpoint and hot-attaches a Matter SoC. sim-manifest.json pins Renode, base rootfs, ot-br-posix, and RCP SLCP builds; .gitignore excludes phase-2 artifacts (*.ext2, *.dtb, checkpoints).

^{Reviewed by Cursor Bugbot for commit 2c1b61e. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: UART2 reuses SDHCI interrupt
  • Changed UART2 interrupt from SPI 0x30 (48) to the correct SPI 0x25 (37) per ZynqMP TRM, eliminating the exclusive IRQ conflict with SDHCI0.

Or push these changes by commenting:

@cursor push 0cb0adcf1c

Preview (0cb0adcf1c)

diff --git a/renode_integration/guest/dts/zynqmp-matter-linux.dts b/renode_integration/guest/dts/zynqmp-matter-linux.dts
--- a/renode_integration/guest/dts/zynqmp-matter-linux.dts
+++ b/renode_integration/guest/dts/zynqmp-matter-linux.dts
@@ -1276,17 +1276,17 @@
 			phandle = <0x6d>;
 		};
 
-		uart2: serial@ff080000 {
-			compatible = "xlnx,zynqmp-uart", "cdns,uart-r1p12";
-			status = "okay";
-			interrupt-parent = <0x05>;
-			interrupts = <0x00 0x30 0x04>;
-			reg = <0x00 0xff080000 0x00 0x1000>;
-			clock-names = "uart_clk", "pclk";
-			power-domains = <0x11 0x21>;
-			clocks = <0x04 0x38 0x04 0x1f>;
-			phandle = <0xf0>;
-		};
+	uart2: serial@ff080000 {
+		compatible = "xlnx,zynqmp-uart", "cdns,uart-r1p12";
+		status = "okay";
+		interrupt-parent = <0x05>;
+		interrupts = <0x00 0x25 0x04>;
+		reg = <0x00 0xff080000 0x00 0x1000>;
+		clock-names = "uart_clk", "pclk";
+		power-domains = <0x11 0x21>;
+		clocks = <0x04 0x38 0x04 0x1f>;
+		phandle = <0xf0>;
+	};
 
 		usb0: usb@ff9d0000 {
 			#address-cells = <0x02>;

_{You can send follow-ups to the cloud agent here.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 2c1b61e. Configure here.}

[sarthak shaha (Sarthak-Shaha)]

is this something that we would need to keep updating? for all commits in this file. If yes , how often?

[Michael Duggan (miduggan24)]

the sha will need to be maintained/updated, but likely not often (perhaps once per release cycle to stay up to date with otbr and base rootfs)

the renode sha can change with each release cycle unless there is some bug/optimization we want to pick up before then

aside from that not much maintenance, the rcp slcp files come directly from sisdk submodule (which may need to change with package manager), ubuntu/mac versions updated in sync with github when they update their runners, etc.