[edk2-devel] [PATCH v3 2/2] Platform/RaspberryPi: Enable Bluetooth and UART in Windows OS
Sunny Wang
Sunny.Wang at arm.com
Mon Jun 7 08:31:28 UTC 2021
Thanks for all the valuable comments, Mario. I learned a lot from your comments.
I just sent v4 for addressing your comments.
By the way, for samples/MinComm at develop · ms-iot/samples (github.com)<https://github.com/ms-iot/samples/tree/develop/MinComm>
1. I successfully build it. However, when I ran MinComm.exe on RPi4, I saw the “vcruntime140.dll was not found” error message, and couldn’t fix it by installing the latest Microsoft Visual C++ Redistributable (vc_redist.arm64.exe<https://aka.ms/vs/16/release/VC_redist.arm64.exe>) from https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0.
2. Just a suggestion. I think it would be good to upload the precompiled binary somewhere.
Best Regards,
Sunny Wang
From: devel at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Mario Balanica via groups.io
Sent: Tuesday, June 1, 2021 12:36 AM
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
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<mailto: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<file://_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<mailto: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<file://_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<mailto:devel at edk2.groups.io> <devel at edk2.groups.io<mailto:devel at edk2.groups.io>> On Behalf Of Mario Balanica via groups.io<http://groups.io>
Sent: Monday, May 31, 2021 8:41 PM
To: Sunny Wang <Sunny.Wang at arm.com<mailto:Sunny.Wang at arm.com>>
Cc: devel at edk2.groups.io<mailto:devel at edk2.groups.io>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud at arm.com<mailto:Samer.El-Haj-Mahmoud at arm.com>>; Sami Mujawar <Sami.Mujawar at arm.com<mailto:Sami.Mujawar at arm.com>>; Jeremy Linton <Jeremy.Linton at arm.com<mailto:Jeremy.Linton at arm.com>>; Pete Batard <pete at akeo.ie<mailto:pete at akeo.ie>>; Ard Biesheuvel <ardb+tianocore at kernel.org<mailto:ardb%2Btianocore 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<file://_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<file://_SB.GPI0>", 0, ResourceConsumer, , ) { 14, 15 }
+ PinFunction (Exclusive, PullDown, BCM_ALT5, "\\_SB.GDV0.GPI0<file://_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<mailto: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<mailto:samer.el-haj-mahmoud at arm.com>>
Cc: Sami Mujawar <sami.mujawar at arm.com<mailto:sami.mujawar at arm.com>>
Cc: Jeremy Linton <jeremy.linton at arm.com<mailto:jeremy.linton at arm.com>>
Cc: Pete Batard <pete at akeo.ie<mailto:pete at akeo.ie>>
Cc: Ard Biesheuvel <ardb+tianocore at kernel.org<mailto:ardb%2Btianocore at kernel.org>>
Cc: Mario Bălănică <mariobalanica02 at gmail.com<mailto:mariobalanica02 at gmail.com>>
Signed-off-by: Sunny Wang <sunny.wang at arm.com<mailto: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<file://_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<file://_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<file://_SB.GPI0>", 0, ResourceConsumer, , ) { 14, 15 }
+ PinFunction (Exclusive, PullDown, BCM_ALT5, "\\_SB.GDV0.GPI0<file://_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<file://_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<file://_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<file://_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.
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 (#76119): https://edk2.groups.io/g/devel/message/76119
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/20210607/a7569bc1/attachment.htm>
More information about the edk2-devel-archive
mailing list