TinyUSB for Communication on PC Motherboards

[calware]

Hello.

I'm trying to see if I can use TinyUSB for my project, which is a hypervisor microkernel built from scratch that executes on bare metal consumer PCs (alongside the guest operating systems (VMs) below it). What I'm trying to do is to create a logging/debugging transport via USB that goes from the microkernel to an external device connected via a male-to-male USB cable.

Upon reading the Getting Started page for TinyUSB projects, I have found that two macro definitions are required by the tusb_config.h header which seem to be problematic. For CFG_TUSB_OS I'm aware I can specify that there is no underlying OS via OPT_OS_NONE, but for CFG_TUSB_MCU I'm uncertain what kind of option to specify. I believe this may relate to the supported devices list, along with some of the compilation options for specifying the build board; all of which is leading me to believe this type of configuration won't be possible with TinyUSB.

Would anybody more knowledgeable on the subject be willing to lend some guidance as for whether or not I should continue with TinyUSB or look elsewhere for my needs?

Thank you for your time :)

Edit:
I have retroactively found a related question from around 3 years ago which seeks out some of the same guidance here: #987

Still curious if there have been any developments in this area that would address both issues, or if one would still need to add their own board configuration to get TinyUSB working for this purpose.

[hathach]

TinyUSB can run on RPI broadcom CPU since it comes with dwc2 controller. What is your USB controller, most x86 only comes with xhci which is not supported yet. EHCI/OHCI would be easier but still need some porting effort.

[calware]

Hey! Happy holidays, and thank you for taking the time to get back to me.

Yes, I believe this motherboard only has xHCI--at least that's all I can see in software views of the on-board controllers. If it helps , we're also working with capabilities supplied by EDK2 in UEFI's DXE space, so we do have some protocols that can find USB controllers and hubs by abstracting on any xHCI/OHCI/EHCI/UHCI-dependent logic. To quote the spec on the aforementioned EDK2 capability:

The EFI_USB2_HC_PROTOCOL abstracts basic functionality that is designed to operate with the EHCI, UHCI and OHCI standards. By using this protocol, a single USB bus driver can be implemented without knowing if the underlying USB host controller conforms to the XHCI, EHCI, OHCI or the UHCI standards.

However, with all of that said, I'm still honestly not sure how to go about porting any of the necessary requirements to get TinyUSB running. The docs page that lists instructions for porting TinyUSB to new hardware states that the very first changes you may consider making require you to identify the vendor and chip family for the board you're working on, whereas identifying the USB MCU for consumer motherboards--at least for this one I'm trying to test on--has proven to be quite challenging; with no information included in any of the motherboard manuals, and no easily identifying text present on the on-board components. Further, the goal of this sort of port would be to support as many consumer motherboards as possible without only acquiescing to one specific manufacturer family, such as by only supporting boards produced by ASUS/GIGABYTE/HP/etc..

Excuse the uninformed question, and I'm pretty sure this is a dumb question, but why is it that you'd have to make any specific changes to the TinyUSB code on a board-specific basis if you already support one of these controller specifications like EHCI/xHCI/etc.? I've seen several operating system projects which seem to implement USB support on their respective consumer motherboards without doing anything specific to account for the board's manufacturer. Is this just nuance with embedded devices which may not have something like UEFI to perform some of the setup tasks that it appears the board_init function is in charge of (such as booting up the MCU and configuring clock speed/pins)?

If it's true that this is just nuance related to embedded systems, and that you don't need any board-specific code (if you can assume the inbuilt firmware has already booted up the board's USB MCU), do you think it'd be very easy then--as a potential path forward--to connect the UEFI protocol for handling USB devices to functions within TinyUSB which may require access to the host's USB controller, and then just proceed as you would with any standard build of TinyUSB? This would allow you to not have to build in support for xHCI, while then also supporting all machines which boot from EDK2 firmware; assuming your device is launched in that stage of the machine's boot.

Thank you again for your time, and apologies if any of the information or ideas above are off-track :)