Hi, Joseph Kogut <joseph.kogut@xxxxxxxxx> writes: > Hi David, > > I know this is a pretty old thread. I tried searching for the LKML > etiquette on something like this and came up empty. If I should start > a new thread, let me know. > > After what I learned from the last thread, I dropped the idea of using > the device controller from the Dell tablet I had. A few months later, > I learned that some overseas electronics companies are now making > dual-boot tablets, that support both Android and generic x86 operating > systems through an IA32 UEFI firmware. I did some research on the > devices, and found that they support interaction over USB with the > Android tools ADB and fastboot, which indicated to me that they likely > had a working USB device controller. > > With my curiosity piqued, I acquired one. My testing confirmed that > the installed Android OS had the capability of utilizing both the host > and device controllers, and allowed file transfer over MTP, as well as > USB networking. > > After discovering that much of the kernel code supporting Baytrail had > yet to be mainlined, I shelved the device for a few months. > > In the last few days, I've revisited the tablet, and replaced the > second OS that came on it with a Linux distribution running the > mainline kernel, compiled with DWC3 and OTG support. After booting the > tablet and attempting to load a gadget module, I had a bout of deja > vu. The device controller doesn't appear in the list of PCI devices. > > When attempting to load a gadget module, the kernel log reports: > >> udc-core: couldn't find an available UDC > > After reviewing this thread, I confirmed that the device id 8086:0f37 > does not appear in the output of 'lspci -nn', but 8086:0f35 does. > > The dual-boot capability of the device seems to be implemented by > switching between two distinct firmwares, but I can't be sure. If that > is the case, I'm wondering if the PC compatible firmware just doesn't > expose the device controller for some reason. Alternatively, like > Felipe mentioned, I wonder if there's not a muxer between the phy and > device/host controllers that needs to be configured somehow. > > Do you have any light to shed on this? You can extract ACPI tables to figure this one out: # acpidump -o acpi.bin Then copy that over to your PC using, e.g. MTP and run: $ acpixtract -a acpi.bin followed by: $ iasl -d *.dat Then you can look in dsdt.dsl for XDCI or OTGD, or whatever might look like the peripheral controller. Look at the _STA method and see what it returns. Devices only show up on PCI bus when _STA is non-zero (usually, it returns 0xF). I'd assume there's a If() condition for the reported OS type. To test things out, you can overwrite FW DSDT with your own, but be very, very careful when doing so. I recommend reading on Google and Documentation directory before attempting. -- balbi
Attachment:
signature.asc
Description: PGP signature
