[edk2-devel] [PATCH v3 2/2] Platform/RaspberryPi: Enable Bluetooth and UART in Windows OS
Mario Bălănică
mariobalanica02 at gmail.com
Mon Jun 7 14:58:05 UTC 2021
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 <Sunny.Wang at arm.com> 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)
> <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>
> 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.
>
>
> 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 (#76134): https://edk2.groups.io/g/devel/message/76134
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/8ad1720c/attachment.htm>
More information about the edk2-devel-archive
mailing list