[edk2-devel] [PATCH v3 2/2] Platform/RaspberryPi: Enable Bluetooth and UART in Windows OS
Mario Bălănică
mariobalanica02 at gmail.com
Mon May 31 16:35:44 UTC 2021
edit: "GpioPinSet (31, 0);" should be "GpioPinSet (31, FALSE);" and maybe
add the "fake the CTS signal as we don't support HW flow control yet"
comment too.
When this patch gets merged, I'll add my Bluetooth changes to
raspberrypi/windows-drivers:
Windows IOT drivers (github.com)
<https://github.com/raspberrypi/windows-drivers> and submit another patch
here to enable hardware flow control.
--Mario
În lun., 31 mai 2021 la 18:56, Mario Bălănică <mariobalanica02 at gmail.com> a
scris:
> If there is no COM port for PL011 UART, how can I check PL011 UART’s
>> functionality? How can I use a telnet tool like PuTTY to send messages from
>> RPi4 to my laptop?
>
>
> You can use: samples/MinComm at develop · ms-iot/samples (github.com)
> <https://github.com/ms-iot/samples/tree/develop/MinComm> (let me know if
> you need a precompiled binary)
>
> As for why I mux both UARTs to the BT chip, I was trying to address your
>> comment “This always assumes that PL011 is used for Bluetooth”. Apparently,
>> it didn’t address your comment. No matter whether I add “PinFunction
>> (Exclusive, PullDown, BCM_ALT5, "\\_SB.GDV0.GPI0", 0, ResourceConsumer,
>> , ) { 32, 33 }” or not, the Bluetooth has NOT worked when I configure
>> PL011 UART as the primary serial console. Bluetooth only works when I
>> configure Mini UART as the Primary serial console. I also confirmed that
>> this problem also exists with RPi4 Release FW 1.26 +
>> edk2-platforms-raspberrypi-pl011-bth-noflow.diff in
>> https://github.com/worproject/RPi-Bluetooth-Testing/. Do you have any
>> idea to make the Bluetooth work with configuring PL011 UART as the primary
>> serial console?
>
>
> Bluetooth doesn't really work with the mini UART driver at the moment. The
> chip stalls after a few transfers, as far as I remember. Haven't looked
> much into it.
>
> By the way, it is good to know the loading sequence. Do you know where I
>> can quickly find this information without using WinDbg?
>
>
> I'm not aware of any way to see the driver loading order without WinDbg.
> Also, verbose mode must be enabled before boot: View Verbose Output -
> Windows drivers | Microsoft Docs
> <https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/view---verbose-output>
>
> You could also test if Bluetooth will break by uninstalling /
> re-installing the mini UART driver while the system is running, then try to
> scan for nearby BT devices.
>
> 1. What is the connection between GPIO 128 and Bluetooth (BT_ON)? Why did
>> we add this line in the beginning? I just removed it by your request and
>> according to the change in worproject/RPi-Bluetooth-Testing/, but I’m
>> still worried about if we did this for some other purposes.
>
>
> That is a leftover from the MS-IOT tables. It tries to toggle BT_ON from
> the GPIO expander (I2C) through RPIQ (mailbox), but the driver has no
> knowledge of it. And since the firmware blob turns on Bluetooth by default,
> the line is completely useless.
>
> We may want to have something like this in the future, for power
> management of the BT chip (will require some driver changes too).
>
> 2. Why do we need to configure GPIO 32 and 33? Is the Bluetooth using
>> GPIO 32 and 33? Or Is Windows OS checking GPIO 32 and 33 for Bluetooth?
>> Where can I find the information?
>
>
> Yes, the Bluetooth chip is available on pins 32, 33 (TX / RX). Also 30, 31
> for hardware flow control (CTS / RTS). More info can be found in the BCM2711
> datasheet
> <https://datasheets.raspberrypi.org/bcm2711/bcm2711-peripherals.pdf> (5.3.
> Alternative Function Assignments)
>
> 3. As for your comment about GPIO 31, I was confused, so I didn’t update
>> anything for addressing this comment. My understanding was that It is
>> intended to override the BCM_ALT2’s default setting from PullLow to
>> PullNone to fack the CTS signal. If we change it to PullLow, it will be
>> used for HW flow control, which is unwanted, isn’t it? What did you want me
>> to change? Could you directly paste the code change you wanted here for my
>> reference?
>
>
> The BCM_ALT2 thing is a dirty hack. Pin 31 must be held LOW so that we can
> talk to the BT chip without flow control. It seems this can't be described
> with PinFunction, so I've relied on the default value of ALT2 for pin 31
> (which turns out to be always LOW).
>
> My proposal is to move the pin muxing stuff in ConfigDxe, like this:
>
> STATIC VOID
>>
>> ApplyVariables (
>>
>> VOID
>>
>> )
>>
>> {
>>
>> ...
>>
>>
>>> if (FanOnGpio) {
>>
>> DEBUG ((DEBUG_INFO, "Fan enabled on GPIO %d\n", FanOnGpio));
>>
>> GpioPinFuncSet (FanOnGpio, GPIO_FSEL_OUTPUT);
>>
>> }
>>
>>
>>> /*
>>
>> * Bluetooth pin muxing
>>
>> */
>>
>> GpioPinFuncSet (31, GPIO_FSEL_OUTPUT);
>>
>> GpioPinSet (31, 0);
>>
>>
>>> if ((PcdGet32 (PcdUartInUse) == PL011_UART_IN_USE)) {
>>
>> GpioPinFuncSet (32, GPIO_FSEL_ALT3);
>>
>> GpioPinFuncSet (33, GPIO_FSEL_ALT3);
>>
>> } else {
>>
>> GpioPinFuncSet (32, GPIO_FSEL_ALT5);
>>
>> GpioPinFuncSet (33, GPIO_FSEL_ALT5);
>>
>> }
>>
>> }
>>
>>
> --Mario
>
> În lun., 31 mai 2021 la 16:26, Sunny Wang <Sunny.Wang at arm.com> a scris:
>
>> Hi Mario,
>>
>>
>>
>> Thanks for checking this.
>>
>> Yeah, the problem is NO COM port for PL011 UART in Windows IOT’s device
>> manager, so I thought it doesn’t work. If there is no COM port for PL011
>> UART, how can I check PL011 UART’s functionality? How can I use a
>> telnet tool like PuTTY to send messages from RPi4 to my laptop? How to use
>> SerCx2? Is there a guideline for using PL011 UART on RPi4 with Windows IoT?
>>
>>
>>
>> As for why I mux both UARTs to the BT chip, I was trying to address your
>> comment “This always assumes that PL011 is used for Bluetooth”. Apparently,
>> it didn’t address your comment. No matter whether I add “PinFunction
>> (Exclusive, PullDown, BCM_ALT5, "\\_SB.GDV0.GPI0", 0, ResourceConsumer,
>> , ) { 32, 33 }” or not, the Bluetooth has NOT worked when I configure
>> PL011 UART as the primary serial console. Bluetooth only works when I
>> configure Mini UART as the Primary serial console. I also confirmed that
>> this problem also exists with RPi4 Release FW 1.26 +
>> edk2-platforms-raspberrypi-pl011-bth-noflow.diff in
>> https://github.com/worproject/RPi-Bluetooth-Testing/. Do you have any
>> idea to make the Bluetooth work with configuring PL011 UART as the primary
>> serial console? By the way, it is good to know the loading sequence. Do you
>> know where I can quickly find this information without using WinDbg?
>>
>>
>>
>>
>>
>> Actually, the original code change (Patch 2/2) is the patch
>> (edk2-platforms-raspberrypi-pl011-bth-noflow.diff) on
>> https://github.com/worproject/RPi-Bluetooth-Testing/. I’m not familiar
>> with Windows drivers’ behavior, so I had no idea about why we need to
>> change them and couldn’t find more information about the changes’
>> background either. It looks like you know the details. Could you share with
>> me more information about the background of these changes? At least, I have
>> some questions below:
>>
>> 1. What is the connection between GPIO 128 and Bluetooth (BT_ON)? Why
>> did we add this line in the beginning? I just removed it by your request
>> and according to the change in worproject/RPi-Bluetooth-Testing/, but I’m
>> still worried about if we did this for some other purposes.
>>
>> 2. Why do we need to configure GPIO 32 and 33? Is the Bluetooth using
>> GPIO 32 and 33? Or Is Windows OS checking GPIO 32 and 33 for Bluetooth?
>> Where can I find the information?
>>
>> 3. As for your comment about GPIO 31, I was confused, so I didn’t update
>> anything for addressing this comment. My understanding was that It is
>> intended to override the BCM_ALT2’s default setting from PullLow to
>> PullNone to fack the CTS signal. If we change it to PullLow, it will be
>> used for HW flow control, which is unwanted, isn’t it? What did you want me
>> to change? Could you directly paste the code change you wanted here for my
>> reference?
>>
>>
>>
>> Moreover, for the changes you want, could you also paste the code change?
>>
>>
>> Best Regards,
>>
>> Sunny Wang
>>
>>
>>
>> *From:* devel at edk2.groups.io <devel at edk2.groups.io> * On Behalf Of *Mario
>> Balanica via groups.io
>> *Sent:* Monday, May 31, 2021 8:41 PM
>> *To:* Sunny Wang <Sunny.Wang at arm.com>
>> *Cc:* devel at edk2.groups.io; Samer El-Haj-Mahmoud <
>> Samer.El-Haj-Mahmoud at arm.com>; Sami Mujawar <Sami.Mujawar at arm.com>;
>> Jeremy Linton <Jeremy.Linton at arm.com>; Pete Batard <pete at akeo.ie>; Ard
>> Biesheuvel <ardb+tianocore at kernel.org>
>> *Subject:* Re: [edk2-devel] [PATCH v3 2/2] Platform/RaspberryPi: Enable
>> Bluetooth and UART in Windows OS
>>
>>
>>
>> Hi Sunny,
>>
>>
>>
>> What issues are you seeing with the PL011 UART in Windows? Last time I
>> checked, it worked fine, and the fact that Bluetooth works also confirms
>> this.
>>
>> It won't show up as a COM port (like mini UART does) as it's built using
>> SerCx2.
>>
>>
>>
>> @@ -30,6 +30,12 @@ Device (URT0)
>> {
>> MEMORY32FIXED (ReadWrite, 0, BCM2836_PL011_UART_LENGTH, RMEM)
>> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) {
>> BCM2836_PL011_UART_INTERRUPT }
>> +
>> + PinFunction (Exclusive, PullDown, BCM_ALT3, "\\_SB.GDV0.GPI0", 0,
>> ResourceConsumer, , ) { 32, 33 }
>> +
>>
>>
>>
>> @@ -79,6 +85,11 @@ Device (URTM)
>> // from muxing the pins away.
>>
>> // PinFunction (Exclusive, PullDown, BCM_ALT5, "\\_SB.GPI0", 0,
>> ResourceConsumer, , ) { 14, 15 }
>> + PinFunction (Exclusive, PullDown, BCM_ALT5, "\\_SB.GDV0.GPI0", 0,
>> ResourceConsumer, , ) { 32, 33 }
>> +
>>
>>
>>
>> What is the reason for trying to mux both UARTs to the BT chip? If PL011
>> is used for Bluetooth and the mini UART driver loads *after* it,
>> wouldn't it mux away the pins and break Bluetooth?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> În lun., 31 mai 2021 la 11:23, Sunny Wang <Sunny.Wang at arm.com> a scris:
>>
>> This change is based on edk2-platforms-raspberrypi-pl011-bth-noflow.diff
>> in https://github.com/worproject/RPi-Bluetooth-Testing/ for enabling
>> Bluetooth and serial port (Mini UART) in Windows IOT.
>>
>> Note that PL011 UART still doesn't work with Windows 10 IOT with this
>> change, but PL011 UART works fine with VMware ESXi-Arm Fling v1.3.
>> Therefore, there should be no issue with PL011 UART related changes,
>> and we will still need a Windows expert to take a further look in the
>> future. Making PL011 UART work properly with Windows 10 IOT may require
>> additional changes to Windows driver or firmware's ACPI table.
>>
>> Testing Done:
>> - Successfully booted Windows Windows 10 IOT (20279.1) on SD (made by
>> WOR) with
>> the RPi-Windows-Drivers release ver 0.5 downloaded from
>> https://github.com/worproject/RPi-Windows-Drivers/releases
>> and checked that both Bluetooth and serial port (Mini UART) can
>> work fine.
>> - Successfully booted VMware ESXi-Arm Fling v1.3 with only serial
>> console connection (PL011 UART).
>>
>> Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud at arm.com>
>> Cc: Sami Mujawar <sami.mujawar at arm.com>
>> Cc: Jeremy Linton <jeremy.linton at arm.com>
>> Cc: Pete Batard <pete at akeo.ie>
>> Cc: Ard Biesheuvel <ardb+tianocore at kernel.org>
>> Cc: Mario Bălănică <mariobalanica02 at gmail.com>
>> Signed-off-by: Sunny Wang <sunny.wang at arm.com>
>> ---
>> Platform/RaspberryPi/AcpiTables/Uart.asl | 19 +++++++++++--------
>> 1 file changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/Platform/RaspberryPi/AcpiTables/Uart.asl
>> b/Platform/RaspberryPi/AcpiTables/Uart.asl
>> index bac9d791eb..cb99086d39 100644
>> --- a/Platform/RaspberryPi/AcpiTables/Uart.asl
>> +++ b/Platform/RaspberryPi/AcpiTables/Uart.asl
>> @@ -30,6 +30,12 @@ Device (URT0)
>> {
>> MEMORY32FIXED (ReadWrite, 0, BCM2836_PL011_UART_LENGTH, RMEM)
>> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) {
>> BCM2836_PL011_UART_INTERRUPT }
>> +
>> + PinFunction (Exclusive, PullDown, BCM_ALT3, "\\_SB.GDV0.GPI0", 0,
>> ResourceConsumer, , ) { 32, 33 }
>> +
>> + // fake the CTS signal as we don't support HW flow control yet
>> + // BCM_ALT2 is set as output (low) by default
>> + PinFunction (Exclusive, PullNone, BCM_ALT2, "\\_SB.GDV0.GPI0", 0,
>> ResourceConsumer, , ) { 31 }
>> })
>> Method (_CRS, 0x0, Serialized)
>> {
>> @@ -79,6 +85,11 @@ Device (URTM)
>> // from muxing the pins away.
>>
>> // PinFunction (Exclusive, PullDown, BCM_ALT5, "\\_SB.GPI0", 0,
>> ResourceConsumer, , ) { 14, 15 }
>> + PinFunction (Exclusive, PullDown, BCM_ALT5, "\\_SB.GDV0.GPI0", 0,
>> ResourceConsumer, , ) { 32, 33 }
>> +
>> + // fake the CTS signal as we don't support HW flow control yet
>> + // BCM_ALT2 is set as output (low) by default
>> + PinFunction (Exclusive, PullNone, BCM_ALT2, "\\_SB.GDV0.GPI0", 0,
>> ResourceConsumer, , ) { 31 }
>> })
>> Method (_CRS, 0x0, Serialized)
>> {
>> @@ -143,10 +154,6 @@ Device(BTH0)
>> UAR0, // DescriptorName: creates name
>> // for offset of resource descriptor
>> ) // Vendor data
>> - //
>> - // RPIQ connection for BT_ON/OFF
>> - //
>> - GpioIO (Shared, PullUp, 0, 0, IoRestrictionNone, "\\_SB.GDV0.RPIQ",
>> 0, ResourceConsumer, , ) { 128 }
>> })
>>
>> //
>> @@ -190,10 +197,6 @@ Device(BTH0)
>> UARM, // DescriptorName: creates name
>> // for offset of resource descriptor
>> ) // Vendor data
>> - //
>> - // RPIQ connection for BT_ON/OFF
>> - //
>> - GpioIO (Shared, PullUp, 0, 0, IoRestrictionNone, "\\_SB.GDV0.RPIQ",
>> 0, ResourceConsumer, , ) { 128 }
>> })
>>
>> Method (_CRS, 0x0, Serialized)
>> --
>> 2.31.0.windows.1
>>
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75879): https://edk2.groups.io/g/devel/message/75879
Mute This Topic: https://groups.io/mt/83205747/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20210531/56737c7b/attachment.htm>
More information about the edk2-devel-archive
mailing list