Hi Sergey,
On Thu, 14 Apr 2022 at 20:31, Sergey Nazaryev sergey@coolautomation.com wrote:
Hi!
As I can see, recently [1] the implementation of USB ACM gadget has been merged into U-boot master. I tried to use it but the problem is that running `setenv stdout usbacm` on my board based on STM32MP157 leads to errors below:
STM32MP> setenv stdout usbacm couldn't find an available UDC g_dnl_register: failed!, error: -19 ## Error inserting "stdout" variable, errno=22
After some research I've found that USB OTG controller must be initialized somehow before we can actually start using any gadget. For instance, on my STM32MP board `dwc2_udc_otg_probe` should be called. My research shows that `usb_gadget_initalize` is responsible for it; so, for this reason, there are explicit calls of `usb_gadget_initialize` (e.g. usb_dnl_dfu [2], usb_dnl_sdp [3]) before actual usage of any gadget.
However, unlike all other gadgets, usb_serial_acm code and code that uses it don't call usb_gadget_initialize at all. Okay, I understand that usb_serial_acm shouldn't initialize USB controllers by itself, but it's still unclear who must be responsible for it.
So, my main question is: what's the best place for `usb_gadget_initialize` call? Should I put it to board-specific code (board/vendor/xxx.c) or maybe it's better to put `usb_gadget_initialize` into new `usb` subcommand (`usb otgstart` or something like that) and call it before `setenv stdout usbacm`?
Yes, you're right. I did not catch this problem because the iMX board/platform I've tested on automatically initializes the usb controller in the right role (peripheral) based on devicetree property... but it's specific to that host driver.
So I think the right place to call usb_gadget_initialize is probably before registering the acm gadget function into acm_stdio_start(). Can you try this? and submit a follow_up fix patch if working?
Regards, Loic