[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 15:56:57 UTC 2021


>
> 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 (#75878): https://edk2.groups.io/g/devel/message/75878
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/17b59f9a/attachment.htm>


More information about the edk2-devel-archive mailing list