Hey,
I have a tablet that seems to be using Realtek chips to do wireless
communications (hopefully, this time I won't be wrong[1]).
The device, under the gpio class in /sys, shows with a modalias of
"acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
the RTL8723AE chipset).
It shows up under:
/sys/devices/platform/80860F0A:00/subsystem/devices
Does anyone have details on how this chipset is actually hooked up? Can
a portion of the existing RTL8723AE driver code be reused?
Cheers
[1]:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/127591/focus=127703
On Thu, 2014-09-11 at 10:06 -0700, Marcel Holtmann wrote:
> Hi Bastien,
>
> >>>> Your device is a child of 80860F0A (UART) which is driven by the 8250_dw
> >>>> driver.
> >>>> OBDA8723 is the BT part of the realtek 8723 WiFi/BT combo chip.
> >>>> acpi_platform should create a platform device from the ACPI desc.
> >>>
> >>> That does show up already in udev, so I should be fine.
> >>>
> >>>> Then, you can add the OBDA8723 acpi id to the rfkill-gpio platform
> >>>> driver (net/rfkill) which
> >>>> seems to handle correctly the basic power management of this chip.
> >>>
> >>> OK. Something like that should do:
> >>> http://paste.fedoraproject.org/132832/14104505
> >>>
> >>>> You need to use hciattach to attach the chip to the BT stack (with
> >>>> H5/3-wire proto).
> >>>
> >>> Will that be required to enable Bluetooth at every boot?
> >>>
> >>> After inserting the above module, I ran:
> >>> hciattach -n ttyS0 3wire
> >>>
> >>> But no Bluetooth adapters showed up in hciconfig. The rfkill device did
> >>> show up in rfkill list though.
> >>
> >> my bet is that you need to start with the correct default speed, load
> >> some firmware and do more settings and then switch to the faster
> >> speed. There is an effort ongoing for the USB version of Realtek
> >> Bluetooth, but even that one has not yet completed.
> >
> > I have a firmware and a config file from the Windows driver, but I doubt
> > I'd be able to make great headway without more info.
>
> in theory this is straight forward, but since this is H:5 it needs extra work to make this nice and clean. So far no H:5 hardware required extra settings. This will be the first one. That is mainly because H:5 is not that popular.
>
> If you can have the basic attachment done with btattach and bring it up in raw only mode, then you could use HCI User Channel to poke with it. We have easy code in src/shared/hci.c that allows you to use the HCI User Channel.
>
> And you want a 3.17 kernel for toying with this of course since I only recently added the extra flags to hci_uart.ko driver to allow bringing the device up in raw only mode or in unconfigured mode.
This will have to wait a little then, as 3.17 kernel don't boot on this
device yet:
https://bugzilla.kernel.org/show_bug.cgi?id=84241
> On 9 Sep 2014, at 22:24, Larry Finger <[email protected]> wrote:
>
>> On 09/09/2014 03:00 PM, Bastien Nocera wrote:
>>> On Tue, 2014-09-09 at 14:27 -0500, Larry Finger wrote:
>>>> On 09/09/2014 04:56 AM, Bastien Nocera wrote:
>>>> Hey,
>>>>
>>>> I have a tablet that seems to be using Realtek chips to do wireless
>>>> communications (hopefully, this time I won't be wrong[1]).
>>>>
>>>> The device, under the gpio class in /sys, shows with a modalias of
>>>> "acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
>>>> Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
>>>> the RTL8723AE chipset).
>>>>
>>>> It shows up under:
>>>> /sys/devices/platform/80860F0A:00/subsystem/devices
>>>>
>>>> Does anyone have details on how this chipset is actually hooked up? Can
>>>> a portion of the existing RTL8723AE driver code be reused?
>>>
>>> Bastien,
>>>
>>> From the previous response, it seems unlikely that GPIO is used to control the
>>> device. That is what I expected. Working at that primitive level would be
>>> extremely difficult timing.
>>
>> Right.
>>
>>> I assume that you have checked both 'lspci' and 'lsusb' for any mention of the
>>> wireless device.
>>
>> No mentions at all in there.
>>
>>> I am not aware of a similar utility to scan an SDIO bus, but
>>> perhaps someone on this list will know.
>>
>> They would show up under /sys/bus/sdio/devices/ and there's nothing in
>> there except the SD card reader.
>>
>>> In addition, a full listing of 'lspci
>>> -nnv' will give a clue regarding what adapters are on the device.
>>
>> Here it is, I doubt that's much help.
>>
>> 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register [8086:0f00] (rev 0d)
>> Subsystem: Intel Corporation Device [8086:0f31]
>> Flags: bus master, fast devsel, latency 0
>> Kernel driver in use: iosf_mbi_pci
>> Kernel modules: iosf_mbi
>>
>> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0d) (prog-if 00 [VGA controller])
>> Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31]
>> Flags: bus master, fast devsel, latency 0, IRQ 106
>> Memory at a0000000 (32-bit, non-prefetchable) [size=4M]
>> Memory at 80000000 (32-bit, prefetchable) [size=512M]
>> I/O ports at 1000 [size=8]
>> Expansion ROM at <unassigned> [disabled]
>> Capabilities: <access denied>
>> Kernel driver in use: i915
>> Kernel modules: i915
>>
>> 00:14.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 0d) (prog-if 30 [XHCI])
>> Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI [8086:0f35]
>> Flags: bus master, medium devsel, latency 0, IRQ 104
>> Memory at a0800000 (64-bit, non-prefetchable) [size=64K]
>> Capabilities: <access denied>
>> Kernel driver in use: xhci_hcd
>>
>> 00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18] (rev 0d)
>> Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18]
>> Flags: bus master, fast devsel, latency 0, IRQ 107
>> Memory at a0700000 (32-bit, non-prefetchable) [size=1M]
>> Memory at a0600000 (32-bit, non-prefetchable) [size=1M]
>> Capabilities: <access denied>
>> Kernel driver in use: mei_txe
>> Kernel modules: mei_txe
>>
>> 00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c] (rev 0d)
>> Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c]
>> Flags: bus master, medium devsel, latency 0
>> Capabilities: <access denied>
>> Kernel driver in use: pmc_atom
>> Kernel modules: lpc_ich
>>
>>
>>> If the device were used with SDIO, then it would be known as the RTL8723AS. I
>>> could not find that chip, but there is an RTL8723BS with a 32-bit driver for
>>> Windows 8.1.
>>
>> That sounds like it could be that one then. This is the only info I
>> have, the (very generic) driver set for Windows (which seems to have
>> support for every variant) and the DSDT:
>> https://bugzilla.kernel.org/attachment.cgi?id=149331
>>
>> The Bluetooth device has a firmware named "rtl8723b_config.bin"
>>
>>> What specific Baytrail tablet do you have?
>>
>> The Onda v975w. It came with Windows 8.1 32-bit.
>>
>> I guess that the device is probably a PCI one, but the enumeration is
>> done through ACPI instead of "normal" PCI.
>
> In http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html, someone is specifically looking for an RTL8723BS driver.
That's helpful.
> I will see if my contact at Realtek knows who has worked on drivers for this device, and if it would be possible to use rtl8723be if we were to supply an SDIO frontend.
I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
> If I were to find code, do you have the possibility to build drivers for the device?
Certainly. I've already made attempts at getting a working touchscreen driver and I have a patch for the accelerometer.
Thanks for the detective work :)
Cheers
Hi Bastien,
> I have a tablet that seems to be using Realtek chips to do wireless
> communications (hopefully, this time I won't be wrong[1]).
>
> The device, under the gpio class in /sys, shows with a modalias of
> "acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
> Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
> the RTL8723AE chipset).
>
> It shows up under:
> /sys/devices/platform/80860F0A:00/subsystem/devices
>
> Does anyone have details on how this chipset is actually hooked up? Can
> a portion of the existing RTL8723AE driver code be reused?
so after a little bit of digging, this seems to be the UART device for the Bluetooth chip. Can you try using 8250_dw.ko driver and see if it binds to it and you get a new serial port.
If I am correct then you have to run H:5 UART transport protocol to enable Bluetooth for this device.
Please double check that this ACPI tables really wrongly declare this as a Broadcom chip. This seems to be a firmware bug then. Unfortunately I think that for Broadcom you run H:4 UART transport protocol and for Realtek you have to run H:5 UART transport protocol. So no idea how to nicely differentiate these.
Regards
Marcel
On Thu, 2014-09-11 at 09:37 -0700, Marcel Holtmann wrote:
> Hi Bastien,
>
> >> Your device is a child of 80860F0A (UART) which is driven by the 8250_dw
> >> driver.
> >> OBDA8723 is the BT part of the realtek 8723 WiFi/BT combo chip.
> >> acpi_platform should create a platform device from the ACPI desc.
> >
> > That does show up already in udev, so I should be fine.
> >
> >> Then, you can add the OBDA8723 acpi id to the rfkill-gpio platform
> >> driver (net/rfkill) which
> >> seems to handle correctly the basic power management of this chip.
> >
> > OK. Something like that should do:
> > http://paste.fedoraproject.org/132832/14104505
> >
> >> You need to use hciattach to attach the chip to the BT stack (with
> >> H5/3-wire proto).
> >
> > Will that be required to enable Bluetooth at every boot?
> >
> > After inserting the above module, I ran:
> > hciattach -n ttyS0 3wire
> >
> > But no Bluetooth adapters showed up in hciconfig. The rfkill device did
> > show up in rfkill list though.
>
> my bet is that you need to start with the correct default speed, load
> some firmware and do more settings and then switch to the faster
> speed. There is an effort ongoing for the USB version of Realtek
> Bluetooth, but even that one has not yet completed.
I have a firmware and a config file from the Windows driver, but I doubt
I'd be able to make great headway without more info.
That's Larry's driver for the USB variant:
https://github.com/lwfinger/rtl8723au_bt
Hey Loic,
On Thu, 2014-09-11 at 17:41 +0200, Loic Poulain wrote:
> Hi Bastien,
>
> Your device is a child of 80860F0A (UART) which is driven by the 8250_dw
> driver.
> OBDA8723 is the BT part of the realtek 8723 WiFi/BT combo chip.
> acpi_platform should create a platform device from the ACPI desc.
That does show up already in udev, so I should be fine.
> Then, you can add the OBDA8723 acpi id to the rfkill-gpio platform
> driver (net/rfkill) which
> seems to handle correctly the basic power management of this chip.
OK. Something like that should do:
http://paste.fedoraproject.org/132832/14104505
> You need to use hciattach to attach the chip to the BT stack (with
> H5/3-wire proto).
Will that be required to enable Bluetooth at every boot?
After inserting the above module, I ran:
hciattach -n ttyS0 3wire
But no Bluetooth adapters showed up in hciconfig. The rfkill device did
show up in rfkill list though.
Cheers
On 09/09/2014 04:22 PM, Bastien Nocera wrote:
>
> I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
The driver creates those entries when it loads. It is no mystery why they are
missing.
Larry
On 09/09/2014 04:56 AM, Bastien Nocera wrote:
> Hey,
>
> I have a tablet that seems to be using Realtek chips to do wireless
> communications (hopefully, this time I won't be wrong[1]).
>
> The device, under the gpio class in /sys, shows with a modalias of
> "acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
> Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
> the RTL8723AE chipset).
>
> It shows up under:
> /sys/devices/platform/80860F0A:00/subsystem/devices
>
> Does anyone have details on how this chipset is actually hooked up? Can
> a portion of the existing RTL8723AE driver code be reused?
Bastien,
From the previous response, it seems unlikely that GPIO is used to control the
device. That is what I expected. Working at that primitive level would be
extremely difficult timing.
I assume that you have checked both 'lspci' and 'lsusb' for any mention of the
wireless device. I am not aware of a similar utility to scan an SDIO bus, but
perhaps someone on this list will know. In addition, a full listing of 'lspci
-nnv' will give a clue regarding what adapters are on the device.
If the device were used with SDIO, then it would be known as the RTL8723AS. I
could not find that chip, but there is an RTL8723BS with a 32-bit driver for
Windows 8.1.
What specific Baytrail tablet do you have?
Larry
Hi Bastien,
>>>>>>> What specific Baytrail tablet do you have?
>>>>>>
>>>>>> The Onda v975w. It came with Windows 8.1 32-bit.
>>>>>>
>>>>>> I guess that the device is probably a PCI one, but the enumeration is
>>>>>> done through ACPI instead of "normal" PCI.
>>>>>
>>>>> In http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html, someone is specifically looking for an RTL8723BS driver.
>>>>
>>>> That's helpful.
>>>>
>>>>> I will see if my contact at Realtek knows who has worked on drivers for this device, and if it would be possible to use rtl8723be if we were to supply an SDIO frontend.
>>>>
>>>> I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
>>>
>>> I just booted up my Baytrail based Minnowboard Max in ACPI enumeration and then the SDIO host controller is enumerated via ACPI. This is compared to PCI enumeration where the SDIO controller shows up in lspci.
>>>
>>> So can you try to install sdhci-acpi and see if that starts showing SDIO devices. If the SDIO host controllers loads, then it start SDIO enumeration and you would see the cards.
>>
>> You may need to look in /sys/bus/mmc/devices/ instead of sdio.
>
> Indeed. That did the trick.
>
> mmc0:0001 is the builtin storage, mmc1:0001:1 however is an unbound
> device with vendor 0x024c and device 0xb723 (modalias:
> sdio:c07v024CdB723). More interestingly class is 0x07, which udev
> interprets as "WLAN interface".
I started creating a hwdb/sdio.ids in systemd. However vendor 0x024c is not listed at the moment. If we figure out which one that is, then that should also be added to udev. After that it can annotate these devices properly.
Also if this is a single SDIO interface, then the Bluetooth part might be exposed as serial port. I have seen Realtek devices that run H:5 UART protocol.
Regards
Marcel
Hi Bastien,
>>>> What specific Baytrail tablet do you have?
>>>
>>> The Onda v975w. It came with Windows 8.1 32-bit.
>>>
>>> I guess that the device is probably a PCI one, but the enumeration is
>>> done through ACPI instead of "normal" PCI.
>>
>> In http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html, someone is specifically looking for an RTL8723BS driver.
>
> That's helpful.
>
>> I will see if my contact at Realtek knows who has worked on drivers for this device, and if it would be possible to use rtl8723be if we were to supply an SDIO frontend.
>
> I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
I just booted up my Baytrail based Minnowboard Max in ACPI enumeration and then the SDIO host controller is enumerated via ACPI. This is compared to PCI enumeration where the SDIO controller shows up in lspci.
So can you try to install sdhci-acpi and see if that starts showing SDIO devices. If the SDIO host controllers loads, then it start SDIO enumeration and you would see the cards.
Regards
Marcel
On 09/09/2014 03:00 PM, Bastien Nocera wrote:
> On Tue, 2014-09-09 at 14:27 -0500, Larry Finger wrote:
>> On 09/09/2014 04:56 AM, Bastien Nocera wrote:
>>> Hey,
>>>
>>> I have a tablet that seems to be using Realtek chips to do wireless
>>> communications (hopefully, this time I won't be wrong[1]).
>>>
>>> The device, under the gpio class in /sys, shows with a modalias of
>>> "acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
>>> Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
>>> the RTL8723AE chipset).
>>>
>>> It shows up under:
>>> /sys/devices/platform/80860F0A:00/subsystem/devices
>>>
>>> Does anyone have details on how this chipset is actually hooked up? Can
>>> a portion of the existing RTL8723AE driver code be reused?
>>
>> Bastien,
>>
>> From the previous response, it seems unlikely that GPIO is used to control the
>> device. That is what I expected. Working at that primitive level would be
>> extremely difficult timing.
>
> Right.
>
>> I assume that you have checked both 'lspci' and 'lsusb' for any mention of the
>> wireless device.
>
> No mentions at all in there.
>
>> I am not aware of a similar utility to scan an SDIO bus, but
>> perhaps someone on this list will know.
>
> They would show up under /sys/bus/sdio/devices/ and there's nothing in
> there except the SD card reader.
>
>> In addition, a full listing of 'lspci
>> -nnv' will give a clue regarding what adapters are on the device.
>
> Here it is, I doubt that's much help.
>
> 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register [8086:0f00] (rev 0d)
> Subsystem: Intel Corporation Device [8086:0f31]
> Flags: bus master, fast devsel, latency 0
> Kernel driver in use: iosf_mbi_pci
> Kernel modules: iosf_mbi
>
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0d) (prog-if 00 [VGA controller])
> Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31]
> Flags: bus master, fast devsel, latency 0, IRQ 106
> Memory at a0000000 (32-bit, non-prefetchable) [size=4M]
> Memory at 80000000 (32-bit, prefetchable) [size=512M]
> I/O ports at 1000 [size=8]
> Expansion ROM at <unassigned> [disabled]
> Capabilities: <access denied>
> Kernel driver in use: i915
> Kernel modules: i915
>
> 00:14.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 0d) (prog-if 30 [XHCI])
> Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI [8086:0f35]
> Flags: bus master, medium devsel, latency 0, IRQ 104
> Memory at a0800000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: <access denied>
> Kernel driver in use: xhci_hcd
>
> 00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18] (rev 0d)
> Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18]
> Flags: bus master, fast devsel, latency 0, IRQ 107
> Memory at a0700000 (32-bit, non-prefetchable) [size=1M]
> Memory at a0600000 (32-bit, non-prefetchable) [size=1M]
> Capabilities: <access denied>
> Kernel driver in use: mei_txe
> Kernel modules: mei_txe
>
> 00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c] (rev 0d)
> Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c]
> Flags: bus master, medium devsel, latency 0
> Capabilities: <access denied>
> Kernel driver in use: pmc_atom
> Kernel modules: lpc_ich
>
>
>> If the device were used with SDIO, then it would be known as the RTL8723AS. I
>> could not find that chip, but there is an RTL8723BS with a 32-bit driver for
>> Windows 8.1.
>
> That sounds like it could be that one then. This is the only info I
> have, the (very generic) driver set for Windows (which seems to have
> support for every variant) and the DSDT:
> https://bugzilla.kernel.org/attachment.cgi?id=149331
>
> The Bluetooth device has a firmware named "rtl8723b_config.bin"
>
>> What specific Baytrail tablet do you have?
>
> The Onda v975w. It came with Windows 8.1 32-bit.
>
> I guess that the device is probably a PCI one, but the enumeration is
> done through ACPI instead of "normal" PCI.
In
http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html,
someone is specifically looking for an RTL8723BS driver.
I will see if my contact at Realtek knows who has worked on drivers for this
device, and if it would be possible to use rtl8723be if we were to supply an
SDIO frontend.
If I were to find code, do you have the possibility to build drivers for the device?
Larry
On 09/09/14 11:56, Bastien Nocera wrote:
> Hey,
>
> I have a tablet that seems to be using Realtek chips to do wireless
> communications (hopefully, this time I won't be wrong[1]).
>
> The device, under the gpio class in /sys, shows with a modalias of
> "acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
> Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
> the RTL8723AE chipset).
>
> It shows up under:
> /sys/devices/platform/80860F0A:00/subsystem/devices
>
> Does anyone have details on how this chipset is actually hooked up? Can
> a portion of the existing RTL8723AE driver code be reused?
It is unlike that it is hooked up with GPIO. It could be using a GPIO
for some purpose like host wakeup during sleep.
Regards,
Arend
> Cheers
>
> [1]:
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/127591/focus=127703
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bastien,
>>>> Your device is a child of 80860F0A (UART) which is driven by the 8250_dw
>>>> driver.
>>>> OBDA8723 is the BT part of the realtek 8723 WiFi/BT combo chip.
>>>> acpi_platform should create a platform device from the ACPI desc.
>>>
>>> That does show up already in udev, so I should be fine.
>>>
>>>> Then, you can add the OBDA8723 acpi id to the rfkill-gpio platform
>>>> driver (net/rfkill) which
>>>> seems to handle correctly the basic power management of this chip.
>>>
>>> OK. Something like that should do:
>>> http://paste.fedoraproject.org/132832/14104505
>>>
>>>> You need to use hciattach to attach the chip to the BT stack (with
>>>> H5/3-wire proto).
>>>
>>> Will that be required to enable Bluetooth at every boot?
>>>
>>> After inserting the above module, I ran:
>>> hciattach -n ttyS0 3wire
>>>
>>> But no Bluetooth adapters showed up in hciconfig. The rfkill device did
>>> show up in rfkill list though.
>>
>> my bet is that you need to start with the correct default speed, load
>> some firmware and do more settings and then switch to the faster
>> speed. There is an effort ongoing for the USB version of Realtek
>> Bluetooth, but even that one has not yet completed.
>
> I have a firmware and a config file from the Windows driver, but I doubt
> I'd be able to make great headway without more info.
in theory this is straight forward, but since this is H:5 it needs extra work to make this nice and clean. So far no H:5 hardware required extra settings. This will be the first one. That is mainly because H:5 is not that popular.
If you can have the basic attachment done with btattach and bring it up in raw only mode, then you could use HCI User Channel to poke with it. We have easy code in src/shared/hci.c that allows you to use the HCI User Channel.
And you want a 3.17 kernel for toying with this of course since I only recently added the extra flags to hci_uart.ko driver to allow bringing the device up in raw only mode or in unconfigured mode.
Regards
Marcel
On Thu, 2014-09-11 at 08:06 -0700, Marcel Holtmann wrote:
> Hi Bastien,
>
> > I have a tablet that seems to be using Realtek chips to do wireless
> > communications (hopefully, this time I won't be wrong[1]).
> >
> > The device, under the gpio class in /sys, shows with a modalias of
> > "acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
> > Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
> > the RTL8723AE chipset).
> >
> > It shows up under:
> > /sys/devices/platform/80860F0A:00/subsystem/devices
> >
> > Does anyone have details on how this chipset is actually hooked up? Can
> > a portion of the existing RTL8723AE driver code be reused?
>
> so after a little bit of digging, this seems to be the UART device for
> the Bluetooth chip. Can you try using 8250_dw.ko driver and see if it
> binds to it and you get a new serial port.
>
> If I am correct then you have to run H:5 UART transport protocol to
> enable Bluetooth for this device.
>
> Please double check that this ACPI tables really wrongly declare this
> as a Broadcom chip. This seems to be a firmware bug then.
No, there are devices declared in the DSDT that won't be available on
the platform itself. The _STA function for each device will tell you
whether the device is available or not (look for TSC in the DSDT, I
don't have 3 touchscreens either ;).
> Unfortunately I think that for Broadcom you run H:4 UART transport
> protocol and for Realtek you have to run H:5 UART transport protocol.
> So no idea how to nicely differentiate these.
On Tue, 2014-09-09 at 16:10 -0700, Marcel Holtmann wrote:
> Hi Bastien,
>
> >>>> What specific Baytrail tablet do you have?
> >>>
> >>> The Onda v975w. It came with Windows 8.1 32-bit.
> >>>
> >>> I guess that the device is probably a PCI one, but the enumeration is
> >>> done through ACPI instead of "normal" PCI.
> >>
> >> In http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html, someone is specifically looking for an RTL8723BS driver.
> >
> > That's helpful.
> >
> >> I will see if my contact at Realtek knows who has worked on drivers for this device, and if it would be possible to use rtl8723be if we were to supply an SDIO frontend.
> >
> > I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
>
> I just booted up my Baytrail based Minnowboard Max in ACPI enumeration
> and then the SDIO host controller is enumerated via ACPI. This is
> compared to PCI enumeration where the SDIO controller shows up in
> lspci.
>
> So can you try to install sdhci-acpi and see if that starts showing
> SDIO devices. If the SDIO host controllers loads, then it start SDIO
> enumeration and you would see the cards.
That was already loaded (thankfully, as it's a dependency of mmc_core,
which drives the builtin storage).
Hi Bastien,
>> Your device is a child of 80860F0A (UART) which is driven by the 8250_dw
>> driver.
>> OBDA8723 is the BT part of the realtek 8723 WiFi/BT combo chip.
>> acpi_platform should create a platform device from the ACPI desc.
>
> That does show up already in udev, so I should be fine.
>
>> Then, you can add the OBDA8723 acpi id to the rfkill-gpio platform
>> driver (net/rfkill) which
>> seems to handle correctly the basic power management of this chip.
>
> OK. Something like that should do:
> http://paste.fedoraproject.org/132832/14104505
>
>> You need to use hciattach to attach the chip to the BT stack (with
>> H5/3-wire proto).
>
> Will that be required to enable Bluetooth at every boot?
>
> After inserting the above module, I ran:
> hciattach -n ttyS0 3wire
>
> But no Bluetooth adapters showed up in hciconfig. The rfkill device did
> show up in rfkill list though.
my bet is that you need to start with the correct default speed, load some firmware and do more settings and then switch to the faster speed. There is an effort ongoing for the USB version of Realtek Bluetooth, but even that one has not yet completed.
Regards
Marcel
Hi Bastien,
Your device is a child of 80860F0A (UART) which is driven by the 8250_dw
driver.
OBDA8723 is the BT part of the realtek 8723 WiFi/BT combo chip.
acpi_platform should create a platform device from the ACPI desc.
Then, you can add the OBDA8723 acpi id to the rfkill-gpio platform
driver (net/rfkill) which
seems to handle correctly the basic power management of this chip.
You need to use hciattach to attach the chip to the BT stack (with
H5/3-wire proto).
Regards,
Loic
On 11/09/2014 17:06, Marcel Holtmann wrote:
> Hi Bastien,
>
>> I have a tablet that seems to be using Realtek chips to do wireless
>> communications (hopefully, this time I won't be wrong[1]).
>>
>> The device, under the gpio class in /sys, shows with a modalias of
>> "acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
>> Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
>> the RTL8723AE chipset).
>>
>> It shows up under:
>> /sys/devices/platform/80860F0A:00/subsystem/devices
>>
>> Does anyone have details on how this chipset is actually hooked up? Can
>> a portion of the existing RTL8723AE driver code be reused?
> so after a little bit of digging, this seems to be the UART device for the Bluetooth chip. Can you try using 8250_dw.ko driver and see if it binds to it and you get a new serial port.
>
> If I am correct then you have to run H:5 UART transport protocol to enable Bluetooth for this device.
>
> Please double check that this ACPI tables really wrongly declare this as a Broadcom chip. This seems to be a firmware bug then. Unfortunately I think that for Broadcom you run H:4 UART transport protocol and for Realtek you have to run H:5 UART transport protocol. So no idea how to nicely differentiate these.
>
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Intel Open Source Technology Center
http://oss.intel.com/
On Tue, 2014-09-09 at 14:27 -0500, Larry Finger wrote:
> On 09/09/2014 04:56 AM, Bastien Nocera wrote:
> > Hey,
> >
> > I have a tablet that seems to be using Realtek chips to do wireless
> > communications (hopefully, this time I won't be wrong[1]).
> >
> > The device, under the gpio class in /sys, shows with a modalias of
> > "acpi:OBDA8723:" (that's on "O", not "0"). This seems to correspond to a
> > Realtek chipset (Larry tells me it matches the PCI ID of 0bda:8723 for
> > the RTL8723AE chipset).
> >
> > It shows up under:
> > /sys/devices/platform/80860F0A:00/subsystem/devices
> >
> > Does anyone have details on how this chipset is actually hooked up? Can
> > a portion of the existing RTL8723AE driver code be reused?
>
> Bastien,
>
> From the previous response, it seems unlikely that GPIO is used to control the
> device. That is what I expected. Working at that primitive level would be
> extremely difficult timing.
Right.
> I assume that you have checked both 'lspci' and 'lsusb' for any mention of the
> wireless device.
No mentions at all in there.
> I am not aware of a similar utility to scan an SDIO bus, but
> perhaps someone on this list will know.
They would show up under /sys/bus/sdio/devices/ and there's nothing in
there except the SD card reader.
> In addition, a full listing of 'lspci
> -nnv' will give a clue regarding what adapters are on the device.
Here it is, I doubt that's much help.
00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register [8086:0f00] (rev 0d)
Subsystem: Intel Corporation Device [8086:0f31]
Flags: bus master, fast devsel, latency 0
Kernel driver in use: iosf_mbi_pci
Kernel modules: iosf_mbi
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0d) (prog-if 00 [VGA controller])
Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31]
Flags: bus master, fast devsel, latency 0, IRQ 106
Memory at a0000000 (32-bit, non-prefetchable) [size=4M]
Memory at 80000000 (32-bit, prefetchable) [size=512M]
I/O ports at 1000 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
00:14.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI [8086:0f35] (rev 0d) (prog-if 30 [XHCI])
Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI [8086:0f35]
Flags: bus master, medium devsel, latency 0, IRQ 104
Memory at a0800000 (64-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: xhci_hcd
00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18] (rev 0d)
Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine [8086:0f18]
Flags: bus master, fast devsel, latency 0, IRQ 107
Memory at a0700000 (32-bit, non-prefetchable) [size=1M]
Memory at a0600000 (32-bit, non-prefetchable) [size=1M]
Capabilities: <access denied>
Kernel driver in use: mei_txe
Kernel modules: mei_txe
00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c] (rev 0d)
Subsystem: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit [8086:0f1c]
Flags: bus master, medium devsel, latency 0
Capabilities: <access denied>
Kernel driver in use: pmc_atom
Kernel modules: lpc_ich
> If the device were used with SDIO, then it would be known as the RTL8723AS. I
> could not find that chip, but there is an RTL8723BS with a 32-bit driver for
> Windows 8.1.
That sounds like it could be that one then. This is the only info I
have, the (very generic) driver set for Windows (which seems to have
support for every variant) and the DSDT:
https://bugzilla.kernel.org/attachment.cgi?id=149331
The Bluetooth device has a firmware named "rtl8723b_config.bin"
> What specific Baytrail tablet do you have?
The Onda v975w. It came with Windows 8.1 32-bit.
I guess that the device is probably a PCI one, but the enumeration is
done through ACPI instead of "normal" PCI.
Cheers
On 09/10/14 01:10, Marcel Holtmann wrote:
> Hi Bastien,
>
>>>>> What specific Baytrail tablet do you have?
>>>>
>>>> The Onda v975w. It came with Windows 8.1 32-bit.
>>>>
>>>> I guess that the device is probably a PCI one, but the enumeration is
>>>> done through ACPI instead of "normal" PCI.
>>>
>>> In http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html, someone is specifically looking for an RTL8723BS driver.
>>
>> That's helpful.
>>
>>> I will see if my contact at Realtek knows who has worked on drivers for this device, and if it would be possible to use rtl8723be if we were to supply an SDIO frontend.
>>
>> I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
>
> I just booted up my Baytrail based Minnowboard Max in ACPI enumeration and then the SDIO host controller is enumerated via ACPI. This is compared to PCI enumeration where the SDIO controller shows up in lspci.
>
> So can you try to install sdhci-acpi and see if that starts showing SDIO devices. If the SDIO host controllers loads, then it start SDIO enumeration and you would see the cards.
You may need to look in /sys/bus/mmc/devices/ instead of sdio.
Gr. AvS
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/10/2014 05:21 AM, Arend van Spriel wrote:
> On 09/10/14 11:50, Bastien Nocera wrote:
>>
>> Indeed. That did the trick.
>>
>> mmc0:0001 is the builtin storage, mmc1:0001:1 however is an unbound
>> device with vendor 0x024c and device 0xb723 (modalias:
>> sdio:c07v024CdB723). More interestingly class is 0x07, which udev
>> interprets as "WLAN interface".
>
> Now you have to find and load the right driver.
In response to a question from me, my contact at Realtek sent me such a driver
last night. I have forwarded it to Bastien and he should be in business soon.
Larry
On 09/10/14 11:50, Bastien Nocera wrote:
> On Wed, 2014-09-10 at 10:46 +0200, Arend van Spriel wrote:
>> On 09/10/14 01:10, Marcel Holtmann wrote:
>>> Hi Bastien,
>>>
>>>>>>> What specific Baytrail tablet do you have?
>>>>>>
>>>>>> The Onda v975w. It came with Windows 8.1 32-bit.
>>>>>>
>>>>>> I guess that the device is probably a PCI one, but the enumeration is
>>>>>> done through ACPI instead of "normal" PCI.
>>>>>
>>>>> In http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html, someone is specifically looking for an RTL8723BS driver.
>>>>
>>>> That's helpful.
>>>>
>>>>> I will see if my contact at Realtek knows who has worked on drivers for this device, and if it would be possible to use rtl8723be if we were to supply an SDIO frontend.
>>>>
>>>> I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
>>>
>>> I just booted up my Baytrail based Minnowboard Max in ACPI enumeration and then the SDIO host controller is enumerated via ACPI. This is compared to PCI enumeration where the SDIO controller shows up in lspci.
>>>
>>> So can you try to install sdhci-acpi and see if that starts showing SDIO devices. If the SDIO host controllers loads, then it start SDIO enumeration and you would see the cards.
>>
>> You may need to look in /sys/bus/mmc/devices/ instead of sdio.
>
> Indeed. That did the trick.
>
> mmc0:0001 is the builtin storage, mmc1:0001:1 however is an unbound
> device with vendor 0x024c and device 0xb723 (modalias:
> sdio:c07v024CdB723). More interestingly class is 0x07, which udev
> interprets as "WLAN interface".
Now you have to find and load the right driver.
Gr. AvS
On Wed, 2014-09-10 at 08:45 -0500, Larry Finger wrote:
> On 09/10/2014 05:21 AM, Arend van Spriel wrote:
> > On 09/10/14 11:50, Bastien Nocera wrote:
> >>
> >> Indeed. That did the trick.
> >>
> >> mmc0:0001 is the builtin storage, mmc1:0001:1 however is an unbound
> >> device with vendor 0x024c and device 0xb723 (modalias:
> >> sdio:c07v024CdB723). More interestingly class is 0x07, which udev
> >> interprets as "WLAN interface".
> >
> > Now you have to find and load the right driver.
>
> In response to a question from me, my contact at Realtek sent me such a driver
> last night. I have forwarded it to Bastien and he should be in business soon.
And I'm in business now, after some API porting. If you import the
driver into your repo, I'd be happy to help out with some of the
cleaning up, as you've done in: https://github.com/lwfinger/rtl8723au
Cheers
On Wed, 2014-09-10 at 10:46 +0200, Arend van Spriel wrote:
> On 09/10/14 01:10, Marcel Holtmann wrote:
> > Hi Bastien,
> >
> >>>>> What specific Baytrail tablet do you have?
> >>>>
> >>>> The Onda v975w. It came with Windows 8.1 32-bit.
> >>>>
> >>>> I guess that the device is probably a PCI one, but the enumeration is
> >>>> done through ACPI instead of "normal" PCI.
> >>>
> >>> In http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html, someone is specifically looking for an RTL8723BS driver.
> >>
> >> That's helpful.
> >>
> >>> I will see if my contact at Realtek knows who has worked on drivers for this device, and if it would be possible to use rtl8723be if we were to supply an SDIO frontend.
> >>
> >> I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
> >
> > I just booted up my Baytrail based Minnowboard Max in ACPI enumeration and then the SDIO host controller is enumerated via ACPI. This is compared to PCI enumeration where the SDIO controller shows up in lspci.
> >
> > So can you try to install sdhci-acpi and see if that starts showing SDIO devices. If the SDIO host controllers loads, then it start SDIO enumeration and you would see the cards.
>
> You may need to look in /sys/bus/mmc/devices/ instead of sdio.
Indeed. That did the trick.
mmc0:0001 is the builtin storage, mmc1:0001:1 however is an unbound
device with vendor 0x024c and device 0xb723 (modalias:
sdio:c07v024CdB723). More interestingly class is 0x07, which udev
interprets as "WLAN interface".
Cheers
On Wed, 2014-09-10 at 12:21 +0200, Arend van Spriel wrote:
> On 09/10/14 11:50, Bastien Nocera wrote:
> > On Wed, 2014-09-10 at 10:46 +0200, Arend van Spriel wrote:
> >> On 09/10/14 01:10, Marcel Holtmann wrote:
> >>> Hi Bastien,
> >>>
> >>>>>>> What specific Baytrail tablet do you have?
> >>>>>>
> >>>>>> The Onda v975w. It came with Windows 8.1 32-bit.
> >>>>>>
> >>>>>> I guess that the device is probably a PCI one, but the enumeration is
> >>>>>> done through ACPI instead of "normal" PCI.
> >>>>>
> >>>>> In http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet-9-7-inch-retina-screen-ram-2gb-wifi-32gb.html, someone is specifically looking for an RTL8723BS driver.
> >>>>
> >>>> That's helpful.
> >>>>
> >>>>> I will see if my contact at Realtek knows who has worked on drivers for this device, and if it would be possible to use rtl8723be if we were to supply an SDIO frontend.
> >>>>
> >>>> I'm not sure why the device doesn't show up in the sysfs tree, but maybe it needs a driver bound to it to show up.
> >>>
> >>> I just booted up my Baytrail based Minnowboard Max in ACPI enumeration and then the SDIO host controller is enumerated via ACPI. This is compared to PCI enumeration where the SDIO controller shows up in lspci.
> >>>
> >>> So can you try to install sdhci-acpi and see if that starts showing SDIO devices. If the SDIO host controllers loads, then it start SDIO enumeration and you would see the cards.
> >>
> >> You may need to look in /sys/bus/mmc/devices/ instead of sdio.
> >
> > Indeed. That did the trick.
> >
> > mmc0:0001 is the builtin storage, mmc1:0001:1 however is an unbound
> > device with vendor 0x024c and device 0xb723 (modalias:
> > sdio:c07v024CdB723). More interestingly class is 0x07, which udev
> > interprets as "WLAN interface".
>
> Now you have to find and load the right driver.
Right. I'll have to defer to Larry's inquiry about this with Realtek, to
check whether it's the same interface as the PCI RTL8723be.
Cheers