From silicon to subscriber: a carrier firmware bring-up

The shape of the programme

An OEM or MSO brings a reference board and a launch date. What they need shipped is not a kernel that boots but a firmware that a support desk never hears about: radios tuned per SKU, mesh that survives a subscriber moving the node, an update path that cannot brick the estate, and a build that an auditor can reproduce.

Bring-up and BSP

• Board bring-up on MediaTek Filogic, Qualcomm IPQ or Broadcom BCM with the vendor SDK integrated into a per-SKU buildroot whose layers are locked by SHA.
• Device tree, drivers and NSS or hardware-offload paths validated on target before any feature work starts.
• Signed boot with a dm-verity root and no telnet, from the first image, so hardening is not bolted on at the end.

Radio and mesh

• Wi-Fi 6E and 7 in production: 320 MHz channel operation, MLO in both STR and EMLSR, 6 GHz AFC client integration, OFDMA and MU-MIMO tuning per SKU.
• Tri-band steering with 802.11k/v/r hooks and RRM exports to the ACS so the fleet can self-optimise.
• EasyMesh R3 controller and agent with fronthaul and backhaul SLA telemetry; prpl backhaul with rate adaptation where the platform is prplOS.

Security and the update path

• WPA3-SAE-PK with OWE transition and DPP onboarding; a hostapd CVE backport pipeline per SKU.
• Per-SKU SBOM with CycloneDX export, so the customer's security team can answer a CVE question without opening a ticket.
• OTA over TR-369 USP with a plain HTTPS fallback, health-gated 5% → 25% → 100%, and automatic rollback on KPI regression.

After launch

The same engineers stay on the programme for sustaining work: kernel and toolchain uplift, silicon end-of-life migrations, conformance as the standards move, and CVE response against an agreed SLA. This is the part most firmware vendors hand to a different team; we do not have a different team.