This version of MiniComm will work without vcredist (compiled with /MT): https://drive.google.com/file/d/1v04RHUEIqlhrg2TUU_d_G4Z6lbZ1l44g/view?usp=sharing --Mario În lun., 7 iun. 2021 la 11:31, Sunny Wang a scris: > 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) > > > 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 ) > 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@edk2.groups.io * On Behalf Of *Mario > Balanica via groups.io > *Sent:* Tuesday, June 1, 2021 12:36 AM > *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 > > > > 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. > > > 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. >