Hello!
On Tuesday 16 November 2021 20:05:07 Loic Poulain wrote:
Hi Pali,
Sorry for the late reply,
On Mon, 27 Sept 2021 at 22:04, Pali Rohár pali@kernel.org wrote:
On Thursday 19 August 2021 13:13:06 Loic Poulain wrote:
This command allows to start CDC ACM function and redirect console (stdin, stdout, stderr) to USB (acmconsole start). The console can then be accessed through the USB host for debugging purpose. The host can stop the session (acmconsole stop) to revert back console to serial and unregister CDC ACM USB function.
Hello!
Could you rather implement this CDC ACM gadget in a way that calling 'setenv stdout cdc_acm' (or 'setenv stdout usbtty') would do this console redirect? Like it is supported for current usbtty or vga output code.
Then this acmconsole command would not be needed at all.
Yes, that would be good, but AFAIR I restricted this cdc_acm usage to this command because we can't have fine grained control like e.g. using cdc_acm as stdout only, when used, it should necessarily be STDIN (at least). The reason is because of the single-tasking nature of u-boot, and the fact that we need to poll the USB controller for events via the 'usb_gadget_handle_interrupts()' function.
There was already discussion that custom commands for activating drivers are against driver model design. See: https://lore.kernel.org/u-boot/20211026151742.42b0fcfa@thinkpad/
So I think that there should not be any driver specific command which just activates device (in this case console).
In our case we simply do that in the getc() function, which is only called for input consoles in the u-boot mainloop.
This looks like a hack in the current implementation which seems that also misuse driver model design. At least this should be documented as this is limitation of functionality.
An alternative would be to have a u-boot API to register generic callbacks to be executed in the mainloop, but this is probably a different thread.
I guess that this should be discussed, so some optimal solution for issue is chosen. Otherwise we will have there second implementation of "usbtty", which even would not provide all functionality as original "usbtty" code.
Also we could possibly live with this 'bug' and simply accept that stdout-only configuration will be broken.
Regards, Loic