VelocityDRIVE-SP-2026.09 Release Notes

1. 2026.09

Version:            2026.09
Previous Version:   2026.06-1
Release date:       2026-09-25
Type:               Roadmap release
YANG Catalog SHA:   b9a283a2c36b799683c792d8a0c21559

1.1. New runtime features

1.1.1. IGMP Snooping added

IGMPv2/v3 Snooping has been added. It constrains IPv4 multicast forwarding to the ports that have active listeners, instead of flooding multicast to every member port of a VLAN. The implementation covers IGMPv3 (RFC 3376) with backward compatibility for IGMPv2 (RFC 2236) and is based on lightweight snooping protocol (RFC 5790). It is configured and monitored via the RFC 9166 YANG model (ietf-igmp-mld-snooping) over CORECONF/CoAP.

See the IGMP Snooping guide for configuration examples, and the igmp-snooping-instance YANG model.

1.1.2. ACL2: New ACL YANG model

A new ACL YANG module (mchp-velocitysp-acl2) replaces the previous mchp-velocitysp-acl model. The two modules co-exist during a transition period — the old module is still accepted on input but read requests return no data; the ACL2 module backs both.

The key changes in ACL2:

  • It is now possible to utilize 3 different lookup in the HW. To introduce this change rules are keyed by [lookup id] rather than a single id. The lookup selects the VCAP IS2 lookup that holds the rule, so the same rule id can be used once per lookup, and a frame is matched against every lookup.

  • A priority leaf sets the search order within a lookup (lowest first).

  • A read-only status leaf reports whether a rule can be hit at all, depending on the per-lookup key types in acl-key-types.

  • Match parameters are split into common-match-params and a frame-type specific container (frame-etype, frame-ipv4, frame-ipv6).

  • Actions are grouped in an actions container that also carries the new mirror-enable flag.

See the ACL configuration guide for configuration examples, and the acl2 YANG model.

The old mchp-velocitysp-acl model has been obsoleted, and is planned to be removed in the 2027.06 release (last planned version to include it is 2027.03). Existing configurations using it should be migrated to mchp-velocitysp-acl2 before the 2027.06 release.
During the transition period (until and including the 2027.03 release), configuration stored in the startup config will be loaded using the backwards compatibility, the resulting config should be saved to startup-config to migrate the persisted config to the new YANG. Read/fetch requests on the old mchp-velocitysp-acl model will not return any data.

1.1.3. Test Frame Generator added

A line-rate frame load has been added for driving front ports with traffic - useful for hardware bring-up and stress testing. This feature is different from the port-test YANG added in the earlier release in the sense that it accepts a port list and can generate traffic on one or more ports in parallel, and this feature does not do any looping or inspection of counters - this must be done by the operator.

The load is controlled via the mchp-velocitysp-frame YANG module under CORECONF/CoAP. A port used for management must be excluded from egress-port-list, as every driven port discards incoming frames and the deactivation command would then be undeliverable.

See the Frame Generator guide for details and the mchp-velocitysp-frame YANG model.

1.1.4. MUP1: State machine status counters added

The MUP1 serial transport now exposes a set of read-only state machine counters under mup1-config/status. The counters track MUP1 link events (frames received, frames sent, resync events) and can be read via a CORECONF FETCH.

See the MUP1 status section for FETCH examples and the mup1-config/status YANG model.

1.1.5. PTP: configurable frame TX priority

A new frame-tx-prio leaf has been added to the PTP instance configuration (ieee1588-ptp). It allows the CoS priority of PTP-generated frames to be set explicitly, instead of relying on the default.

See the frame-tx-prio YANG leaf.

1.1.6. LLDP: configurable message Tx interval

The LLDP global message transmission interval is now configurable via the msg-tx-interval leaf in the LLDP instance configuration. In addition, the implementation now starts a fast transmission burst whenever a port comes up, accelerating neighbor discovery after a link event.

See the LLDP configuration guide for FETCH and iPATCH examples.

1.1.7. LLDP: Organizationally Specific TLV transmission

Custom Organizationally Specific TLVs can now be configured for transmission via the new remote-org-tlv-xmt table in the LLDP port configuration. The OUI is a 24-bit number written in decimal; the information field is base64. Every received Organizationally Specific TLV is also reported in the status subtree.

See the LLDP configuration guide for configuration examples, and the remote-org-tlv-xmt YANG model.

1.1.8. Firmware update: chunked upload support

The firmware update PUT endpoint now accepts an ?offset=n query parameter, allowing the firmware image to be uploaded in multiple chunks. This makes it possible to perform firmware updates over transports with limited block sizes without holding the entire image in the client’s memory.

See the Firmware Update guide for the chunked upload protocol.

1.1.9. System: memory usage monitoring

The /system/memory container (under mchp-velocitysp-system) is now accessible via CORECONF. It exposes the used and free heap figures and a per-capability breakdown list so that memory consumption can be attributed to individual protocol modules.

The figures are a snapshot taken once at the end of boot-time initialisation and do not change at runtime, so polling the container returns the same values. The per-capability list is not a complete accounting either: the sum of its bytes values is strictly less than used, because non-capability memory (module state, drivers, MESA-internal tables) is not itemised.

See the System configuration guide for FETCH examples, and the system/memory YANG model.

1.1.10. System: source revision exposed

A new source-revision leaf under /system-state/platform (in mchp-velocitysp-system) exposes the full (unabbreviated) git SHA of the firmware image currently running. This makes it straightforward to trace an installed image back to the exact source commit it was built from.

See the system-state/platform/source-revision YANG leaf.

1.2. New HW Support

1.2.1. LAN969x: unified PHY driver set and VSC8504/VSC8574 support

The VDSP_BIN_LAN969x and VDSP_BIN_LAN969x_AUTO binary variants previously had exclusive PHY sets. They now ship the same unified driver set — the union of what both variants previously supported:

  • LAN8814/LAN8804/LAN8818/LAN8808 (QSGMII, 4x10/100/1000BASE-T) — previously in LAN969x only, now also in LAN969x_AUTO.

  • LAN887x (LAN8870, LAN8870B, LAN8871, LAN8872 — RGMII/SGMII 100/1000BASE-T1) and LAN867x (LAN8671, LAN8670 — 10BASE-T1S) — previously in LAN969x_AUTO only, now also in LAN969x.

In addition, support for the VSC8504 and VSC8574 quad-port 10/100/1000BASE-T PHYs has been added to both LAN969x variants. Only Rev-E silicon is supported. The PHY-timestamping feature of the VSC8574 is not supported.

See Software Variants for the full updated PHY support table.

1.3. New tailoring/board configuration features

1.3.1. Board configuration: PHY device ID verification

Two new board configuration fields have been added to the eth_port/phy container:

  • phy_driver_id — the expected PHY device identifier. If set, the system verifies that the PHY responds with this ID at startup and logs an error if the IDs do not match.

  • phy_readback — a list of register read-back checks applied to the PHY after initialisation.

See Board Configuration for details.

1.3.2. Board configuration: multiple status LEDs

The board configuration now supports a status_leds container, holding a status_led list, alongside the previous single-LED container. Up to four instances can be configured, each with its own instance_id, gpio_state_at_init and gpio_state_at_boot_complete. The older single-LED container continues to be honoured but cannot be combined with the new list.

See Board Configuration for details and drive-state examples.

1.3.3. Board configuration: PHY media interface selection

A media_interface leaf has been added to the eth_port/phy container. It selects the physical media interface between the MAC and the PHY: Cu, SGMII, or 1000BASE-X. If absent the default is Cu.

See Board Configuration for details.

1.3.4. Board configuration: PHY tunables

A tunables list has been added to the eth_port/phy container in the board configuration. It allows named PHY parameters to be set at startup without modifying the PHY driver. The supported tunable types are documented in the board configuration guide.

See Board Configuration for details.

1.3.5. Tailoring: flash and bootloader flash configuration

Two new tailoring sections cover flash speed configuration:

  • The board:drivers/flash_static container selects the flash access mode and sets a maximum SPI clock rate. The achieved clock may be lower than the requested bound, clamped to what the divider can express.

  • The LAN969X_FW_CONFIG_DTS device-tree knobs let the BL2 bootloader’s flash rate be set independently of the application’s rate — both have to be lowered to de-risk a marginal board.

See Board Configuration and Tailoring for details.

1.4. New support features

1.4.1. YANG SID files published in RFC 9595 format

YANG SID files are now generated and shipped in RFC 9595 format alongside the existing legacy-format files.

  • New location: docs/sw_refs/yang/new-sid-files/<module>@<revision>.sid — RFC 9595 format, using the ietf-sid-file:sid-file namespace, item (not items) and assignment-range (not assignment-ranges).

  • Legacy location: docs/sw_refs/yang/<module>@<revision>.sid — retained unchanged for backward compatibility.

Both the YANG catalog tar (attached to the documentation) and the velocitydrivesp-client-lib packet include the new-sid-files directory.

1.4.2. SBOM published SPDX

The Software Bill of Materials is now published as a self-contained browsable HTML file alongside the SPDX JSON. Both the binary packet SBOM and the client-library SBOM are attached to the documentation and linked from the SBOM page.

The JSON SPDX files are also embedded in the distributed tar files.

1.4.3. Client library: new example tools

Two new C example programs are included in the client-library packet:

  • mup1ct — a C port of the MUP1 configuration tool, demonstrating CORECONF get and set over MUP1.

  • dbgreg — a MIIM / switch register access tool that demonstrates raw register reads and writes via the client library.

See client-lib/README.md in the source tree for build and usage details.

1.5. Behavioral changes

1.5.1. CORECONF: two-pass validation for PUT/iPATCH

PUT and iPATCH requests on the <running> datastore (/c) are now validated in two passes before any change is applied. The first pass checks the entire request against the YANG schema; if it finds a violation (for example, a value outside its permitted range) the request is rejected with an error before the configuration is touched. This makes it less likely that the rollback mechanism is needed, and means that a malformed request is always visible as a clean error rather than a partially applied update.

1.6. Bugfixes

1.6.1. Bugfix: LAN969x: Secure boot ROT key leading-zero guard

An ECDSA public key coordinate with a leading zero byte could previously be silently accepted as a Root-of-Trust key, producing a key shorter than the expected 32 bytes and causing signature verification to fail at boot. The provisioning tooling now rejects any ROT key whose X or Y coordinate has a leading zero, so the problem is caught before the key is written to OTP.