public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Mario Bălănică" <mariobalanica02@gmail.com>
To: Sunny Wang <Sunny.Wang@arm.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	 Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>,
	Sami Mujawar <Sami.Mujawar@arm.com>,
	 Jeremy Linton <Jeremy.Linton@arm.com>,
	Pete Batard <pete@akeo.ie>,
	 Ard Biesheuvel <ardb+tianocore@kernel.org>
Subject: Re: [edk2-devel] [PATCH v3 2/2] Platform/RaspberryPi: Enable Bluetooth and UART in Windows OS
Date: Mon, 31 May 2021 19:35:44 +0300	[thread overview]
Message-ID: <CAA3kFM8bh5ebywwVft2qcvMYMmf0FxDfd8rY+vwqiE8LwL4SZg@mail.gmail.com> (raw)
In-Reply-To: <CAA3kFM-HDvNQFZSdBLdMK44ZcjYE6PV8ah2bV9_DVvxQJWrTBw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 14556 bytes --]

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@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@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@edk2.groups.io <devel@edk2.groups.io> * On Behalf Of *Mario
>> Balanica via groups.io
>> *Sent:* Monday, May 31, 2021 8:41 PM
>> *To:* Sunny Wang <Sunny.Wang@arm.com>
>> *Cc:* devel@edk2.groups.io; Samer El-Haj-Mahmoud <
>> Samer.El-Haj-Mahmoud@arm.com>; Sami Mujawar <Sami.Mujawar@arm.com>;
>> Jeremy Linton <Jeremy.Linton@arm.com>; Pete Batard <pete@akeo.ie>; Ard
>> Biesheuvel <ardb+tianocore@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@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@arm.com>
>> Cc: Sami Mujawar <sami.mujawar@arm.com>
>> Cc: Jeremy Linton <jeremy.linton@arm.com>
>> Cc: Pete Batard <pete@akeo.ie>
>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
>> Cc: Mario Bălănică <mariobalanica02@gmail.com>
>> Signed-off-by: Sunny Wang <sunny.wang@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.
>>
>

[-- Attachment #2: Type: text/html, Size: 25321 bytes --]

  reply	other threads:[~2021-05-31 16:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-31  8:22 [PATCH v3 0/2] Dynamically build UARTs info in ACPI Sunny Wang
2021-05-31  8:22 ` [PATCH v3 1/2] Platform/RaspberryPi: " Sunny Wang
2021-05-31  8:22 ` [PATCH v3 2/2] Platform/RaspberryPi: Enable Bluetooth and UART in Windows OS Sunny Wang
2021-05-31 12:40   ` Mario Bălănică
2021-05-31 13:26     ` [edk2-devel] " Sunny Wang
2021-05-31 15:56       ` Mario Bălănică
2021-05-31 16:35         ` Mario Bălănică [this message]
2021-06-07  8:31           ` Sunny Wang
2021-06-07 14:58             ` Mario Bălănică
2021-06-02 12:11 ` [edk2-devel] [PATCH v3 0/2] Dynamically build UARTs info in ACPI Samer El-Haj-Mahmoud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA3kFM8bh5ebywwVft2qcvMYMmf0FxDfd8rY+vwqiE8LwL4SZg@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox