https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288144
--- Comment #1 from Paige Thompson <pa...@paige.bio> --- I'm not exactly sure with USB, I might be misunderstanding something important; with uart_hci, you just specify which protocol you want to use (h4 usually) and it goes but I wonder now if since this is USB if it needs a firmware blob or something to be initialized. On Linux it just works and I don't have much detail on how usb_hci works on Linux but on there I don't even have to hci or btattach it. I see I missed a few messages from somebody on the Discord from the other day: BSOD[BSD] — 7/8/25, 9:06 AM https://cgit.freebsd.org/src/commit/?id=79a100e28e3c814773bb4c1826cfa25fbe31140e Bluetooth has largely (completely?) moved on from bluetooth over UART transport. That is kinda what I was guessing is probably the reasoning but over behind me I've got an XPS 9310 (approx 2020) and even hciconfig I believe says that's a UART but sure 5 years old and it's probably a ton of overhead to support something like that for as many different protocols as there are, I guess that makes sense. Initially I tried using just the default usb_hci sample application provided in the Zephyr SDK however, the interface / endpoint topology was wrong and I was getting the following error: ubt0 on uhub0 ubt0: <ZEPHYR USB-DEV, class 0/0, rev 2.00/4.01, addr 12> on usbus0 ubt0: ubt_attach:680: could not get two interfaces device_attach: ubt0 attach returned 6 I am really not sure what the difference is when you use USB-next on zephyr (the difference is it provides a topology of two interfaces and a correct number endpoints per interface) but what that is characteristic of I'm not sure. What I can say for sure is that people who are coming to FreeBSD expecting Bluetooth are likely the types of people who know that they can at least get Bluetooth to work on Linux. Here's what I know works on Linux: - nrf52840 with hci_uart - nrf52840 with hci_usb - nrf52840 with hci_usb (using USB-Next) - qca6390 (requires a firmware blob, indicates UART bus type in hciconfig, admittedly it took several years before it would work any other way but from a cold start but it does now.) I've also got a 7002, a 5340-dk, and an Infineon CYW920829M2EVK-02 but forget about these because getting them to work with hci_usb or hci_uart is extra work that isn't even worth doing because that's not really what they're for; it's convenient that the nrf52 works with either of the sample projects out of the box (different build params for USB-Next) but it really doesn't do the development kits that they are any justice to use them as an HCI for a computer. Still it would just be nice to have something that just works in this case, where my only goal is to pair with a Bluetooth device (the thing I actually want to develop.) I also think most people coming from Linux (especially those who know at least as much as I know about uart_hci) will probably be very disappointed. I get it, but even though there's probably only a handful of people who would even bother. I'm still trying to wrap my head around ng_h4 being removed because it's old. I want to say I got the nrf 7002 to work once as an HCI but there was something I had to change in the source and the prj, I might be wrong though it's been awhile--but that is a relatively new dev kit (nrf7002-dk) and in a pinch hciattach/btattach has always been really reliable (I know at least for sure for the nrf52.) I guess I wouldn't really care that much but I have it programmed with hci_usb, USB-Next, has the correct topology ➜ sys git:(stable/14) ✗ service bluetooth start ubt0 /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 ➜ sys git:(stable/14) ✗ bluetooth-config scan No usable Bluetooth host controllers were found. These host controllers exist in the system: ubt0 Choose a host controller to set up: [ubt0] /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 It doesn't like it for some reason. I guess I'll go look and try to figure out if it needs a firmware or something. -- You are receiving this mail because: You are the assignee for the bug.
