boards: st: nucleo_l496zg: cannot run usb demos

[cfriedt]

Describe the bug The nucleo_l496zg board needs a couple of minor modifications to DTS in order to support USB on-the-go full-speed.

Although, it wasn't mentioned as a supported feature of the board in v3.7 docs, USB is listed under available hardware capabilities. It seems like a useful device to enable, since most ST boards are great for USB.

This is on the cusp of feature request, but I thought I would put together an issue for backporting purposes, since it was a very simple fix (#78187).

Please also mention any information which could help others to understand the problem you're facing:

• What target platform are you using? nucleo_l496zg
• What have you tried to diagnose or workaround this issue? Fixed it :-) #78187
• Is this a regression? No

To Reproduce

Steps to reproduce the behavior:

1. west build -b nucleo_l496zg samples/subsys/usb/console/
2. See error

Expected behavior

This sample should be able to build for the board in question, since it does have all of the necessary hardware.

Impact An annoyance

Logs and console output

devicetree error: /Users/cfriedt/zephyrproject/zephyr/samples/subsys/usb/console/app.overlay:13 (column 1): parse error: undefined node label 'zephyr_udc0'

Environment (please complete the following information):

• OS: Ubuntu
• Toolchain: Zephyr SDK
• Commit SHA or Version used: v3.6-branch, v3.7-branch

Additional context

[erwango]

USB is listed under available hardware capabilities

Agreed but these hardware capabilities sections list available IPs on the SoC and we can't consider this is a bug if not enabled in Zephyr.

[cfriedt]

https://github.com/zephyrproject-rtos/zephyr/wiki/Change-Control-and-Backports-to-stable-branches

The following are the candidates for back-porting to stable branches and specifically the LTS branch:

Security Bug Fixes Functional Bug Fixes Usability Bug Fixes and improvements Documentation and Test Improvements

This would fall under the category of a Usability bug fix or improvement.

This is actually a great candidate / example because it's so isolated (i.e. there are no side-effects), but does require review by the CCB.

IMO, it's nice because it makes ST platforms in Zephyr more consistent. E.g. one could almost naively assume these days that just about all ST parts in Zephyr with USB (OTG or device) hardware can be used for USB (OTG or device) applications because the platform is so mature. It was somewhat shocking to learn that was not the case here.

[henrikbrixandersen]

This would fall under the category of a Usability bug fix or improvement.

No, it would not. There's nothing here that cannot be added via a simple devicetree overlay for older releases.

[cfriedt]

This would fall under the category of a Usability bug fix or improvement.

No, it would not. There's nothing here that cannot be added via a simple devicetree overlay for older releases.

Based on my experiments, that assumption has proven to be incorrect.

For example, if one would like to use mcuboot on this platform with USB device capabilities, without significantly modifying build steps or forking, then the zephyr_udc0 node needs to exists in the board definition, and not in an overlay.

There are alternatives - e.g. forking mcuboot, forking zephyr, applying patches at build time, maybe adding some command-line parameters outside of the regular west build --sysbuild path/to/app flow. But each of those reduces usability.

It would be great if you could provide some evidence to the contrary though.

[henrikbrixandersen]

Closing as the two backport PRs referencing this issue were closed.