3

I am currently extending an embedded hardware platform which runs a linux kernel 3.16. I want to connect an external SDIO controller to the USB bus, and then run a WIFI module using that SDIO controller.

Since I have only little experience with SDIO devices (I know how to configure eMMC, SD-Card, ... in the device tree), I am unsure about how to proceed if an USB-SDIO-bridge is used.

Does such a setup run without any device tree adaption (aka "Hey, its USB, let's simply plug it in!"), or must I specify the exact location of the SDIO controller in the device tree file?

Alex Stragies
  • 5,857
  • 2
  • 32
  • 56
Hoedur
  • 31
  • 1
  • 6
  • I have the exact same issue here. To be more precise I am trying to use a WF111 module connected to USB2640 (USB hub + SD interface). It seems that there is no glue in kernel to connect both – RDP Jan 18 '16 at 18:15
  • Have you advanced with this? I will get to the problem solving soon, but my interaction with the community (USB and SCSI drivers lists) suggested that the path relies on using SCSI subsystem to deliver Transport messages to SDIO controller, which will then send it to the module. At least this is how USB2640 application note shows it has to be done. – RDP Apr 25 '16 at 03:10
  • No, unfortunately I haven't made any progress in this issue. I finally had to select a USB based WiFi module, as I urgently needed to proceed with my project. – Hoedur Apr 26 '16 at 08:42
  • The problem with the USB2640 is that unless you have the right firmware, it won't do a USB->SDIO function right. From there, it should act as a moderately normal (for some medium values there) SD Host Controller. From there, the device should hotplug detect (if it's connected to the other chip right) as an SDIO card inserted into the Host Controller. IF you've got something that works without an OOB interrupt source (Broadcom, WF111, etc...), you should have it just detect and load the driver for the SDIO device. – Svartalf Feb 06 '19 at 20:56
  • One of the Gotchas here for this plan is one of latencies, etc. A VUB300 is sllloooww. A USHC controller (Like the Cambrdge Silicon's eval board adapter) is twitchy. So far, there's no "good" bridge and you still have a 100msec Interrupt URB latency to deal with on the operation. Nothing so far works in the needed manners to side step much of the problems with these designs yet. Yet. There's plans to figure out what needs to be done to make this work right and make a bespoke core for FPGA or chip sales. – Svartalf Feb 06 '19 at 20:59
  • After an abysmal failure on my part trying to implement a 'USHC2' using the Cypress Semiconductor FX3 series parts (Whereas Cambridge Silicon's dev board adapter (No longer made, barely available...) used the Cypress FX2 series), I determined a lot of the serious design issues with all of the outstanding solutions in this space. Many of the SDIO drivers presume something with a differing latency behavior than your typical SDHC, Performance suffers or the driver flat doesn't work for varying reasons like I mention in the main thread. – Svartalf Feb 06 '19 at 21:34

1 Answers1

1

With regards to SDIO to USB adapters like something based off of a VUB300, under Linux, the bridge itself will Hot-plug USB and do the "right" things.

The SDIO device, on the other hand...depends on whether the vendor (giving TI a nasty, nasty look right now...grrr...) did something non-standard and their drivers RELY on that off in the weeds behavior. The WiLink series parts use an OOB interrupt to speed things up. Problem is...their drivers don't work right without said interrupt. There's quite a bit of BROKEN there with that. Now...your mileage may vary. Some devices will drop straight in no worries. At least some of them have...issues...like I related here.

Svartalf
  • 111
  • 4