Cudy P2 5G support

For Developers
61

Great, then it should def be stored somewhere "safe".

62

You can't stop it using Ctrl+C but it times out quickly.

I will change the device name.

The dts includes wr3000-nand.dtsi as it is exactly the same.

63

Does the unit have a V1 on the label ?

Most vendors don't print any version on the sticker until it's a > V1.

64

Yes, it does. About nand, sorry, i didn't notice that it includes wr3000-nand-dtsi.

65

I've changed the device name to "P2"

66

No worries, I just wanted it to be correct.

67

Other users might find the external OpenWrt feed for vendor's sprd-pcie driver I made useful:

This driver is confirmed as working on Cudy P2 with the current main branch and also with 25.12.4 and the 25.12 branch.

68

Here is a completely stock build of OpenWrt 25.12.4 with sprd-pcie compiled in. It has no additional software and is compatible with stock packages including kernel modules.

sprd-pcie is licensed under GNU GPLv2 so it's distribution should not be an issue.

69

Hi, I was just wondering if someone can take a look at the merge request and if it can move forward.

Also, the AI review generated this:

nit: the two closest NAND siblings with KERNEL_IN_UBI := 1 — cudy_wr3000s-v1 (line 1338) and cudy_wbr3000uax-v1 (line 1464) — both set UBINIZE_OPTS := -E 5, which this block omits. Was dropping it intentional, or should it be added for parity to reserve UBI erase blocks?

What does this option do - I can't find it in the ubinize's man page.

70

a simple search ...

What is it ?

  • ubinize Tool: This option passes arguments directly to the ubinize utility during the build process.

  • -E 5 Flag: It tells the tool to initialize the eraseblock headers with an initial wear count (erase count) of 5 instead of the default 0.

Why is it used ?

  • Factory Flashing: When a device is manufactured, the flash memory is often written using an external programmer or factory tool that bypasses the operating system.

  • Wear Tracking: Setting this value to 5 provides a small buffer. It acknowledges that the flash chips have already undergone a few erase cycles during factory testing and initial flashing before reaching the consumer.

  • Kernel Warnings: It prevents potential issues or warnings in the Linux kernel regarding uninitialized or zero-wear blocks on brand-new hardware.

71

On my Ubuntu 24.04 system in man docs it says:

       -e, --erase-counter=num
              The erase counter value to put to EC headers (default is 0).

This is lowercase e, not uppercase.

72

its blue ...NO its royal blue :slight_smile: same same. Also, the A.I is reffering to openwrt ubinize tools -E .. not ubuntu's -e.

73

I have made the change, but I saw a curious comment on the pull request:

For anyone using the Cudy P2 v2, I have prepared a custom OpenWrt patch here: https://github.com/AidenShaw2020/openwrt-cudy-p2-v2-patch

Someone used my pull request and made a patch to include v2 support - it differs in:

  • 512MB of DDR3L instead of 512MB of DDR3
  • MeiG SRM810-EU 5G modem instead of Quectel RG500U-EB

The change from my patch is relatively small - the main difference is the new device tree - here is their diff:

--- mt7981b-cudy-p2-v1.dts	2026-07-07 18:57:09.013395249 +0200
+++ mt7981b-cudy-p2-v2.dts	2026-07-09 17:19:59.330593196 +0200
@@ -4,8 +4,8 @@
 #include "mt7981b-cudy-wr3000-nand.dtsi"
 
 / {
-	model = "Cudy P2 v1";
-	compatible = "cudy,p2-v1", "mediatek,mt7981";
+	model = "Cudy P2 v2";
+	compatible = "cudy,p2-v2", "mediatek,mt7981";
 	aliases {
 		label-mac-device = &gmac0;
 		led-boot = &led_power;
@@ -85,13 +85,13 @@
 
 		voip_volte {
 			gpio-export,name = "voip_volte";
-			gpio-export,output = <1>;
+			gpio-export,output = <0>;
 			gpios = <&pio 5 GPIO_ACTIVE_LOW>;
 		};
 
 		5gpwr {
 			gpio-export,name = "5gpwr";
-			gpio-export,output = <0>;
+			gpio-export,output = <1>;
 			gpios = <&pio 6 GPIO_ACTIVE_LOW>;
 		};
 
@@ -149,10 +149,6 @@
 	};
 };
 
-&xhci {
-	phys = <&u2port0 PHY_TYPE_USB2>;
-	status = "okay";
-};
 
 &usb_phy {
 	status = "okay";
@@ -164,6 +160,20 @@
 
 
 &pio {
+	modem_power_hog {
+		gpio-hog;
+		gpios = <6 1>;
+		output-high;
+		line-name = "5gpwr-hog";
+	};
+
+	modem_mux_hog {
+		gpio-hog;
+		gpios = <8 0>;
+		output-low;
+		line-name = "usb5g-hog";
+	};
+
 	pcie_pins: pcie-pins {
 		mux {
 			function = "pcie";
@@ -236,3 +246,15 @@
 &pcie_intc {
 	msi-controller;
 };
+
+
+&u3port0 {
+	status = "okay";
+};
+
+&xhci {
+	phys = <&u2port0 PHY_TYPE_USB2>;
+	phy-names = "usb2-0";
+	mediatek,u3p-dis-msk = <1>;
+	status = "okay";
+};

It looks to me that this can be done with a shared .dtsi and a specific one for v1 and v2.

The modem is connected via the same PCIe and USB lanes.