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) and submit another patch here to enable hardware flow control. --Mario În lun., 31 mai 2021 la 18:56, Mario Bălănică 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) > (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 > > > 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 > (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 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@edk2.groups.io * On Behalf Of *Mario >> Balanica via groups.io >> *Sent:* Monday, May 31, 2021 8:41 PM >> *To:* Sunny Wang >> *Cc:* devel@edk2.groups.io; Samer El-Haj-Mahmoud < >> Samer.El-Haj-Mahmoud@arm.com>; Sami Mujawar ; >> Jeremy Linton ; Pete Batard ; Ard >> Biesheuvel >> *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 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 >> Cc: Sami Mujawar >> Cc: Jeremy Linton >> Cc: Pete Batard >> Cc: Ard Biesheuvel >> Cc: Mario Bălănică >> Signed-off-by: Sunny Wang >> --- >> 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. >> >