Hi Sergey,
On Thu, 14 Apr 2022 at 20:31, Sergey Nazaryev <ser...@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
