Re: USB init before using usb_serial_acm gadget?

Re: USB init before using usb_serial_acm gadget?

[Loic Poulain]

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

Re: USB init before using usb_serial_acm gadget?

[Sergey Nazaryev]

> 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?

It's required for `usb_gadget_initialize` to provide a "USB
controller index" as an argument. It's pretty obvious how to do it in
"interactive world" (e.g. to ask user for this number via CLI, like
it was in commands mentioned in my previous message) but in our case
we need to provide this number in non-interactive manner.

There is not an elegant solution with hardcoding '0' as a controller
index like it was done in `ether` gadget [1], but it seems that it
was a temporary fix ("This is a preparatory work for DM support for
UDC drivers") that occasionaly became a permament solution.

So, that's why I suggested to add a new subcommand to `usb` for OTG
initialization: in my opinion, it's better to require an explicit
call of something like `usb otgstart 0` than hardcoding a '0' into
the code. One more option is to add a new environment variable to
explictly specify a controller index, and read this variable from all
places when it requires.

P.S. I already put `usb_gadget_intiialize(0)` to my board code, and
ACM gadget started working; so the remaining problem is only to
decide where is the best place for this call.

[1]: https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/usb/gadget/ether.c#L2355

Re: USB init before using usb_serial_acm gadget?

[Loic Poulain]

On Sun, 17 Apr 2022 at 10:45, Sergey Nazaryev <sergey@coolautomation.com> wrote:
>
> > 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?
>
> It's required for `usb_gadget_initialize` to provide a "USB
> controller index" as an argument. It's pretty obvious how to do it in
> "interactive world" (e.g. to ask user for this number via CLI, like
> it was in commands mentioned in my previous message) but in our case
> we need to provide this number in non-interactive manner.
>
> There is not an elegant solution with hardcoding '0' as a controller
> index like it was done in `ether` gadget [1], but it seems that it
> was a temporary fix ("This is a preparatory work for DM support for
> UDC drivers") that occasionaly became a permament solution.
>
> So, that's why I suggested to add a new subcommand to `usb` for OTG
> initialization: in my opinion, it's better to require an explicit
> call of something like `usb otgstart 0` than hardcoding a '0' into
> the code. One more option is to add a new environment variable to
> explictly specify a controller index, and read this variable from all
> places when it requires.
>
> P.S. I already put `usb_gadget_intiialize(0)` to my board code, and
> ACM gadget started working; so the remaining problem is only to
> decide where is the best place for this call.

Yes, but whatever the solution, we also need to know the controller
index from gadget driver, since we need it for
usb_gadget_handle_interrupts(index). So an env or global variable
would be at least a good start.

Regards,
Loic

>
> [1]: https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/usb/gadget/ether.c#L2355

USB init before using usb_serial_acm gadget?

[Sergey Nazaryev]

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`?

Thank you in advance,
Sergey

[1]: https://source.denx.de/u-boot/u-boot/-/commit/fc2b399ac03b91339a1cb1bfd4d1a9ca87fe95c6
[2]: https://source.denx.de/u-boot/u-boot/-/blob/master/common/dfu.c#L28
[3]: https://source.denx.de/u-boot/u-boot/-/blob/master/cmd/usb_gadget_sdp.c#L24