WLE900VX QCA9880 (3×3 11ac PCIe x1) is now installed in mPCIe slot J5 —
exactly the canonical backhaul radio designated by CM-MESH-MPCIE-2026-06
v0.2.1 §3. This card uses the PCIe x1 lane of the slot.
Patch 004 (#463 / PR #464) had repurposed SerDes comphy5 lane 5 from
PCIe to USB3 SuperSpeed, physically removing PCIe from J5. To let the
WLE900VX enumerate, the slot must return to stock (PCIe x1 + USB 2.0
via UTMI from patch 003).
This revert restores the kernel to the "patch 003 only" baseline.
Patch 003 stays — it enables USB 2.0 on the slot for backwards
compatibility with cellular modems (Quectel EP06-E, etc.) plugged in
the slot's USB pins. The PCIe path of the slot becomes live again
WHEN the hardware modification is also reverted by the dev.
Sister concerns :
- #460 stays open as the canonical "enable cp0_pcie2 properly" issue
(the current patch 003 only addresses USB2, not PCIe activation).
May or may not need a separate patch 004v2 to ship cp0_pcie2
declarations.
- #463 will be closed as "obsoleted by hardware revert" once the
revert is done physically.
- USB3 WiFi cards (MT7921U from #462) will plug into standard USB3
ports on the SMSC hub, not J5.
Will trigger kernel rebuild as 5secubox after merge.
Hardware modification has retargeted SerDes lane 5 of the MOCHAbin
mPCIe slot J5 from PCIe x1 to USB 3.0 SuperSpeed on the mPCIe USB pins.
The DTS must reflect that :
- cp0_pcie2 disabled (no SerDes left, was on comphy5)
- cp0_usb3_1 binds cp0_comphy5 mode 5 (PHY_TYPE_USB3_HOST1) + UTMI
(UTMI from patch 003 kept for USB 2.0 baseline)
The mod aligns the slot with the Globalscale block diagram intent
("2x2 WiFi 802.11/ax BT5.1" card) — MT7921-class USB3 cards can now
enumerate at full 5 Gbps in J5.
Pattern mirrors cp0_usb3_0 (USB3 HUB on comphy1 mode 4
PHY_TYPE_USB3_HOST0). For stock MOCHAbin boards without the mod,
patch 003 alone is sufficient — this patch supersedes 003's
configuration only on hardware-modded boards.
Will trigger a kernel rebuild as 4secubox after merge ; deploy on gk2
to validate that the M.2-style USB3 WiFi card plugged in J5 enumerates
on Bus 003.
gk2 board runs 15+ LXCs on 8 GiB without swap; the stock kernel ships
`# CONFIG_ZRAM is not set` so zram-tools can't activate. Adding zram
as a module with zstd as the default compressor lets userspace create
/dev/zram0, mkswap, and swapon at ~25% of RAM for safe compressed
RAM-backed swap (no plaintext on disk — CSPN-friendly).
* board/mochabin/kernel/config-6.12.85-secubox-zram.fragment (new):
CONFIG_ZRAM=m, CONFIG_ZRAM_DEF_COMP_ZSTD=y, CONFIG_ZSMALLOC=y +
zstd/lz4/lzo crypto for runtime swap of compressor.
* kernel-build/build-kernel.sh: merge the zram fragment into the
kernel config alongside the OpenWrt-merged base.
Follow-up (separate issue): ship a minimal /usr/lib/systemd/system/
zramswap.service that does `modprobe zram; mkswap /dev/zram0;
swapon -p 100 /dev/zram0` so we don't need apt outbound for
zram-tools.
Co-authored-by: CyberMind-FR <gandalf@Gk2.net>
The MOCHAbin DTS (armada-7040-mochabin.dts) enables cp0_usb3_1 — the
mPCIe slot's USB 2.0 controller — with `status = "okay"` but assigns
no PHY. Result: the xhci driver registers the controller but it has
no signaling path; USB devices plugged into the mPCIe slot do not
enumerate.
This patch assigns the UTMI PHY (cp0_utmi1) to cp0_usb3_1, matching
the upstream armada-7040-db reference design for that controller.
After the patch, both USB3 host controllers bind at boot (was 1):
xhci-hcd f2500000.usb: cp0_usb3_0 (SMSC hub)
xhci-hcd f2510000.usb: cp0_usb3_1 (mPCIe slot, new)
The 6 SerDes (comphy) lanes are all allocated to other peripherals
(eth0=SFP+, eth1=Topaz, usb3_0=SMSC, sata0×2, pcie2=mPCIe). No lane
is available for USB 3.0 SuperSpeed on the slot, but the slot's USB
pins are USB 2.0 only by design — UTMI alone is correct.
Board-validated 2026-05-20 on gk2 (MOCHAbin):
Before patch: lsusb shows 2 buses (cp0_usb3_0)
After patch: lsusb shows 4 buses (cp0_usb3_0 + cp0_usb3_1 = 4)
NOTE: this patch is necessary but not sufficient for cellular modems
in the mPCIe slot to actually enumerate. The slot's W_DISABLE# /
power-enable sequencing also needs investigation. The Quectel EP06-E
plugged into J5 on gk2 still doesn't enumerate after this patch
(lspci shows the PCIe bridge with `[disabled]` memory window — modem
is electrically dark on both USB and PCIe interfaces). See #255 for
the remaining hardware investigation.
Ref #255
Co-authored-by: CyberMind-FR <gandalf@Gk2.net>
- Add build-kernel.sh for cross-compiling kernel 6.6.x LTS with LED as module
- Add secubox-led-reset tool for I2C recovery via rmmod/modprobe
- Add initramfs modules.d configs for LED (leds-is31fl319x) and USB network
- Update debian/rules to install initramfs configs and led-reset tool
- Fix .gitignore to track build-kernel.sh
LED driver as module (=m) allows recovery from I2C bus hang without reboot:
rmmod leds_is31fl319x && modprobe leds_is31fl319x
USB network modules (usbnet, cdc_ether, cdc_ncm, rndis_host) added for
Eye Remote gadget support at early boot.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Created kernel patches to fix I2C timing issues with IS31FL319X LED
controller on Marvell Armada platforms (errata FE-8471889):
- 001-leds-is31fl319x-add-i2c-delays.patch: Adds 1ms delays between
I2C register writes in LED driver to prevent bus errors
- 002-i2c-mv64xxx-increase-errata-delay.patch: Increases mv64xxx
errata delay from 5µs to 50µs for more reliable operation
Updated .gitignore to track kernel-build/patches/ while still
ignoring build outputs.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Kernel 6.12.x has mv64xxx I2C driver timing issues causing LED write
failures (-EIO). OpenWrt kernel 6.6.119 works perfectly with the same
IS31FL3199 LED chip.
Updated build instructions to use kernel 6.6.137 LTS (same generation
as OpenWrt) for reliable I2C/LED support on MOCHAbin.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
