VelocityDRIVE-SP-2026.06 Release Notes

1. 2026.06

Version:            2026.06
Previous Version:   2026.03
Release date:       2026-07-03
Type:               Roadmap release
YANG Catalog SHA:   a451a0f8915c93316acec762c840219d

1.1. New features

1.1.1. MLD Snooping added

MLD (Multicast Listener Discovery) Snooping has been added. It constrains IPv6 multicast forwarding to the ports that have active listeners, instead of flooding multicast to every member port of a VLAN. The implementation covers MLDv2 (RFC 9777) with backward compatibility for MLDv1 (RFC 2710) and is based on lightweight snooping protocol (RFC5790) and is configured and monitored via the RFC 9166 YANG model (ietf-igmp-mld-snooping) over CORECONF/CoAP.

See the MLD Snooping guide for configuration examples, and the mld-snooping-instance YANG model.

1.1.2. Port Test and cable diagnostics added

A port test framework has been added, exposed under the port test subtree of the interface model. It provides:

  • One-shot tests: cable diagnostics (pair status and length), host-side loop frame test, frame generator and PRBS generator.

  • Multi-step tests with individually controllable actions: isolate, line-side loop, host-side loop and PRBS (PHY-host / switch) generation with error counting.

  • A read-only Signal Quality Index (SQI) value.

See the Switch Interface Port guide for details and examples, and the eth-port/test YANG model.

1.1.3. CORECONF client library added

A new C client library (velocitydrivesp-client-lib / lm_client) has been added for building CORECONF/CoAP requests and decoding the responses from a host application. It ships with MUP1, CoAP and CORECONF transports, x86 and ARMv7 build presets, a C++ compile test, and is MISRA C:2023 checked.

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

1.1.4. LAN969x OTP provisioning YANG added

A new YANG model has been added to facilitate OTP (and secure boot) provisioning using the CORECONF interface.

The supported fields include:

  • Serial number

  • Ethernet MAC address range

  • Root-of-Trust public-key for FW authentication

  • Secret symmetric key for FW encryption

  • Boot-strap disable mask

  • Secure JTAG configuration

See the LAN969x OTP Provisioning guide and the otp-provisioning-1 RPC for more details.

OTP programming is irreversible and can permanently brick the board.

1.1.5. Firmware update: per-platform image compatibility check

The firmware-update service now rejects firmware images that were not built for the running board (LMSTAX-372). Each board carries a platform_id (board:capabilities/platform_id in board.yang), and each generated LAN969x image is stamped with the id of the board it was built for. A PUT /fw/image whose stamped id is not compatible with the running board is rejected before anything is written to flash, so an image built for a different platform can no longer be installed and leave the device unbootable.

Boards that share the same SoC share an id and stay cross-loadable (for example, the auto and non-auto variants of the same SoC).

See the Firmware Update guide for the compatibility scheme.

This breaks downgrade to releases built before this check. Once 2026.06 is deployed the board’s platform_id is set to a real value, while pre-2026.06 LAN969x images are stamped 0x0000 (untagged). An untagged image is not treated as universal (only 0xffff is), so it fails the exact-match and is rejected. Downgrading to a pre-2026.06 release over PUT /fw/image will therefore be refused.

1.1.6. MUP1: Configurable UART baud rate added

The MUP1 UART baud rate is now configurable via the mup1-baudrate leaf, supporting the standard rates from 9600 up to 921600 bps (default 115200). The change takes effect after saving the configuration and rebooting; the matching rate must be selected on the host tools (mup1ct, mup1cc) via --baudrate.

See this section of the MUP1 configuration guide and the mup1-baudrate leaf for details.

1.1.7. Board configuration: Port max-speed advertisement

A max_speed leaf has been added to the board configuration eth_port/phy container. When set, it limits the speed advertised during PHY auto-negotiation, allowing a port to be capped below its maximum capability.

1.1.8. Board configuration: new peripheral and mux definitions

The board configuration model has been extended with:

  • uarts/uart and i2cs/i2c entries to declare SoC UART and I2C bus controllers and assign them logical handles.

  • PCA954x-type I2C multiplexers (i2c_mux_pca954x), in addition to the existing GPIO-controlled muxes.

  • MCP230xx I2C GPIO expanders (gpio_mcp230xx).

See Board Configuration for details.

1.1.9. Board configuration: PHY drivers: dummy-PHY support on LAN969x variants

The dummy-PHY driver has been added to the velocitysp_lan969x and velocitysp_lan969x_auto MEPA variants. Its purpose is to support MAC-to-MAC connections, i.e. ports that have no external PHY (such as SerDes/backplane links between two MACs), allowing such ports to be brought up.

1.2. Behavioral changes

1.2.1. L3: Static routes created together with their protocol instance

Static routes live under a user-managed control-plane-protocol instance of type static, which (per RFC 8349 §5.3.1) is not created implicitly by the system. The configuration guide now shows the initial routing table being set with a single request that creates the instance together with all its routes — the same form used when the running configuration is applied at boot — while individual routes can still be added later by addressing the route list directly.

See the L3 configuration guide for details.

2. 2026.06-1

Version:            2026.06-1  (yyyy.mm-cnt)
Previous Version:   2026.06
Release date:       2026-07-10
Type:               Bugfix release
YANG Catalog SHA:   a451a0f8915c93316acec762c840219d

2.1. Bugfixes

2.1.1. Bugfix: CoAP/CORECONF get running config failed on some boards

The 2026.06 release introduced the port and cable test feature, which requires new features from the PHY API. Not all PHY drivers have been updated to support the port-test feature. Drivers not supporting this feature return the NOT_IMPLEMENTED error code. This was not handled correctly, and caused the entire CoAP/CORECONF get request to fail.

If a PHY driver does not implement a given feature, it shall not cause a request to fail; instead, the feature shall be marked as disabled in the get/status request.