Message ID | 20240730222439.3469-1-quic_eserrao@quicinc.com (mailing list archive) |
---|---|
Headers | show |
Series | Enable EUD on Qualcomm sm8450 SoC | expand |
Hi, On 31/07/2024 00:24, Elson Roy Serrao wrote: > The Embedded USB Debugger (EUD) is a mini High-Speed USB on-chip hub to > support the USB-based debug and trace capabilities on Qualcomm devices. > The current implementation lacks in below aspects that are needed for > proper EUD functionality. > > 1.) HS-Phy control: EUD being a HS hub needs HS-Phy support for it's > operation. Hence EUD module should enable/disable HS-phy > accordingly. > > 2.) Proper routing of USB role switch notifications: EUD hub is physically > present in between the USB connector and the USB controller. So the > usb role switch notifications originating from the connector should > route through EUD. EUD also relies on role switch notifications to > communicate with the USB, regarding EUD attach/detach events. > > This series aims at implementing the above aspects to enable EUD on > Qualcomm sm8450 SoC. Are there any plans to make this feature available for folks outside of Qualcomm / an NDA? There is an openOCD fork on CodeLinaro but it still requires some proprietary library which is only available to folks with a quicinc email as I understand it. Kind regards, ~ someone eager for JTAG access > > Elson Roy Serrao (8): > dt-bindings: soc: qcom: eud: Add phy related bindings > dt-bindings: soc: qcom: eud: Add usb role switch property > dt-bindings: soc: qcom: eud: Add compatible for sm8450 > arm64: dts: qcom: sm8450: Add EUD node > arm64: dts: qcom: Enable EUD on sm8450 hdk > usb: misc: eud: Add High-Speed Phy control for EUD operations > usb: misc: eud: Handle usb role switch notifications > usb: misc: eud: Add compatible for sm8450 > > .../bindings/soc/qcom/qcom,eud.yaml | 17 +++ > arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 15 ++- > arch/arm64/boot/dts/qcom/sm8450.dtsi | 29 ++++ > drivers/usb/misc/qcom_eud.c | 125 +++++++++++++++--- > 4 files changed, 164 insertions(+), 22 deletions(-) >
On 7/31/2024 4:13 AM, Caleb Connolly wrote: >> >> 2.) Proper routing of USB role switch notifications: EUD hub is physically >> present in between the USB connector and the USB controller. So the >> usb role switch notifications originating from the connector should >> route through EUD. EUD also relies on role switch notifications to >> communicate with the USB, regarding EUD attach/detach events. >> >> This series aims at implementing the above aspects to enable EUD on >> Qualcomm sm8450 SoC. > > Are there any plans to make this feature available for folks outside of Qualcomm / an NDA? > > There is an openOCD fork on CodeLinaro but it still requires some proprietary library which is only available to folks with a quicinc email as I understand it. > Which codelinaro link are you referring here?
On 31/07/2024 13:13, Caleb Connolly wrote: > Hi, > > On 31/07/2024 00:24, Elson Roy Serrao wrote: >> The Embedded USB Debugger (EUD) is a mini High-Speed USB on-chip hub to >> support the USB-based debug and trace capabilities on Qualcomm devices. >> The current implementation lacks in below aspects that are needed for >> proper EUD functionality. >> >> 1.) HS-Phy control: EUD being a HS hub needs HS-Phy support for it's >> operation. Hence EUD module should enable/disable HS-phy >> accordingly. >> >> 2.) Proper routing of USB role switch notifications: EUD hub is physically >> present in between the USB connector and the USB controller. So the >> usb role switch notifications originating from the connector should >> route through EUD. EUD also relies on role switch notifications to >> communicate with the USB, regarding EUD attach/detach events. >> >> This series aims at implementing the above aspects to enable EUD on >> Qualcomm sm8450 SoC. > > Are there any plans to make this feature available for folks outside of > Qualcomm / an NDA? > > There is an openOCD fork on CodeLinaro but it still requires some > proprietary library which is only available to folks with a quicinc > email as I understand it. Are you saying that there is no fully open and available user-space which is necessary to use EUD? Best regards, Krzysztof
Hi Trilok, On 31/07/2024 21:58, Trilok Soni wrote: > On 7/31/2024 4:13 AM, Caleb Connolly wrote: >>> >>> 2.) Proper routing of USB role switch notifications: EUD hub is physically >>> present in between the USB connector and the USB controller. So the >>> usb role switch notifications originating from the connector should >>> route through EUD. EUD also relies on role switch notifications to >>> communicate with the USB, regarding EUD attach/detach events. >>> >>> This series aims at implementing the above aspects to enable EUD on >>> Qualcomm sm8450 SoC. >> >> Are there any plans to make this feature available for folks outside of Qualcomm / an NDA? >> >> There is an openOCD fork on CodeLinaro but it still requires some proprietary library which is only available to folks with a quicinc email as I understand it. >> > > Which codelinaro link are you referring here? That would be https://git.codelinaro.org/clo/la/openocd-org/openocd/-/blob/qcom_changes/README_QCOM?ref_type=heads Which says: Qualcomm specific tools: - Login to qpm.qualcomm.com - QUTS: 1.64.1.39 (version & above) - Qualcomm Host USB Product Suite - QUD QC only : 1.00.63 (supported version) - EUD QC : 2.1.1 (supported version) I believe the specific versions of QUD and EUD are only available to Qualcomm engineers and not even to OEMs, though I might be mistaken. Kind regards, > >
On 01/08/2024 09:55, Krzysztof Kozlowski wrote: > On 31/07/2024 13:13, Caleb Connolly wrote: >> Hi, >> >> On 31/07/2024 00:24, Elson Roy Serrao wrote: >>> The Embedded USB Debugger (EUD) is a mini High-Speed USB on-chip hub to >>> support the USB-based debug and trace capabilities on Qualcomm devices. >>> The current implementation lacks in below aspects that are needed for >>> proper EUD functionality. >>> >>> 1.) HS-Phy control: EUD being a HS hub needs HS-Phy support for it's >>> operation. Hence EUD module should enable/disable HS-phy >>> accordingly. >>> >>> 2.) Proper routing of USB role switch notifications: EUD hub is physically >>> present in between the USB connector and the USB controller. So the >>> usb role switch notifications originating from the connector should >>> route through EUD. EUD also relies on role switch notifications to >>> communicate with the USB, regarding EUD attach/detach events. >>> >>> This series aims at implementing the above aspects to enable EUD on >>> Qualcomm sm8450 SoC. >> >> Are there any plans to make this feature available for folks outside of >> Qualcomm / an NDA? >> >> There is an openOCD fork on CodeLinaro but it still requires some >> proprietary library which is only available to folks with a quicinc >> email as I understand it. > > Are you saying that there is no fully open and available user-space > which is necessary to use EUD? Yes, exactly. Tools must be obtained via the Qualcomm Package Manager which are not available by default after making an account and signing and NDA. Kind regards, > > Best regards, > Krzysztof >
On Tue, Jul 30, 2024 at 03:24:31PM -0700, Elson Roy Serrao wrote: > The Embedded USB Debugger (EUD) is a mini High-Speed USB on-chip hub to > support the USB-based debug and trace capabilities on Qualcomm devices. > The current implementation lacks in below aspects that are needed for > proper EUD functionality. > > 1.) HS-Phy control: EUD being a HS hub needs HS-Phy support for it's > operation. Hence EUD module should enable/disable HS-phy > accordingly. > > 2.) Proper routing of USB role switch notifications: EUD hub is physically > present in between the USB connector and the USB controller. So the > usb role switch notifications originating from the connector should > route through EUD. EUD also relies on role switch notifications to > communicate with the USB, regarding EUD attach/detach events. > > This series aims at implementing the above aspects to enable EUD on > Qualcomm sm8450 SoC. > For the open source community, EUD enablement means they will only get EUD ports enumerated on the host and nothing else. There is no public info on how to use EUD nor are there any tools to make use of it. So what is the purpose of upstreaming it in the first place? If the goal is to use EUD only by Qcom employees or customers who have signed NDA, then you can just supply them the out-of-tree EUD patches and tools to work with. There is absolutely no need to upstream the driver support. So for this series and any other future EUD patches, Nacked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> I'm really tempted to send a patch to remove the EUD driver altogether, but I'll just wait for the response before doing so. - Mani
On 8/1/2024 3:52 AM, Caleb Connolly wrote: > Hi Trilok, > > On 31/07/2024 21:58, Trilok Soni wrote: >> On 7/31/2024 4:13 AM, Caleb Connolly wrote: >>>> 2.) Proper routing of USB role switch notifications: EUD hub is physically >>>> present in between the USB connector and the USB controller. So the >>>> usb role switch notifications originating from the connector should >>>> route through EUD. EUD also relies on role switch notifications to >>>> communicate with the USB, regarding EUD attach/detach events. >>>> >>>> This series aims at implementing the above aspects to enable EUD on >>>> Qualcomm sm8450 SoC. >>> >>> Are there any plans to make this feature available for folks outside of Qualcomm / an NDA? >>> >>> There is an openOCD fork on CodeLinaro but it still requires some proprietary library which is only available to folks with a quicinc email as I understand it. >>> >> >> Which codelinaro link are you referring here? > > That would be https://git.codelinaro.org/clo/la/openocd-org/openocd/-/blob/qcom_changes/README_QCOM?ref_type=heads > > Which says: > > Qualcomm specific tools: > - Login to qpm.qualcomm.com > - QUTS: 1.64.1.39 (version & above) > - Qualcomm Host USB Product Suite - QUD QC only : 1.00.63 (supported version) > - EUD QC : 2.1.1 (supported version) > > I believe the specific versions of QUD and EUD are only available to Qualcomm engineers and not even to OEMs, though I might be mistaken. Thanks. So are we okay w/ one of the following option? (trying to understand the need here properly before I relay it internally). Options: (1) Provide EUD library and tools - proprietary w/o any login requirement. (2) Provide open-source EUD library and tools w/o any login requirement. Is Option (1) fine to begin with or option 2 is must?
On Tue, Aug 06, 2024 at 11:58:02AM GMT, Trilok Soni wrote: > On 8/1/2024 3:52 AM, Caleb Connolly wrote: > > Hi Trilok, > > > > On 31/07/2024 21:58, Trilok Soni wrote: > >> On 7/31/2024 4:13 AM, Caleb Connolly wrote: > >>>> 2.) Proper routing of USB role switch notifications: EUD hub is physically > >>>> present in between the USB connector and the USB controller. So the > >>>> usb role switch notifications originating from the connector should > >>>> route through EUD. EUD also relies on role switch notifications to > >>>> communicate with the USB, regarding EUD attach/detach events. > >>>> > >>>> This series aims at implementing the above aspects to enable EUD on > >>>> Qualcomm sm8450 SoC. > >>> > >>> Are there any plans to make this feature available for folks outside of Qualcomm / an NDA? > >>> > >>> There is an openOCD fork on CodeLinaro but it still requires some proprietary library which is only available to folks with a quicinc email as I understand it. > >>> > >> > >> Which codelinaro link are you referring here? > > > > That would be https://git.codelinaro.org/clo/la/openocd-org/openocd/-/blob/qcom_changes/README_QCOM?ref_type=heads > > > > Which says: > > > > Qualcomm specific tools: > > - Login to qpm.qualcomm.com > > - QUTS: 1.64.1.39 (version & above) > > - Qualcomm Host USB Product Suite - QUD QC only : 1.00.63 (supported version) > > - EUD QC : 2.1.1 (supported version) > > > > I believe the specific versions of QUD and EUD are only available to Qualcomm engineers and not even to OEMs, though I might be mistaken. > > Thanks. So are we okay w/ one of the following option? (trying to understand the need here properly before I relay it internally). > > Options: > > (1) Provide EUD library and tools - proprietary w/o any login requirement. > (2) Provide open-source EUD library and tools w/o any login requirement. > > Is Option (1) fine to begin with or option 2 is must? The usual problem of (1) is future compatibility guarantees. What system libraries will it depend upon? When the open-source world and openocd update to the next libusb ABI, will it break the EUD library? Next, which interfaces are going to be used and/or provided by the lib and tools? In other words, will it be really useful? Last, if is prorietary, then under which licence? Will it allow reverse engineering or not? Will it allow redistributing? Also note that OpenOCD is licenced under GPL-2.0-or-later, so while one can link it with a proprietary software, they can not further distribute the resulting binaries. Also there might be different questions on whether the lib itself is a derivative work (and as such it must be covered by the GPL).