Re: [RFC PATCH 01/12] drivers/char: Add support for Xue USB3 debugger

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Mon, Jun 6, 2022 at 10:10 AM Tamas K Lengyel
<tamas.k.lengyel@xxxxxxxxx> wrote:
>
> On Mon, Jun 6, 2022 at 10:03 AM Marek Marczykowski-Górecki
> <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, Jun 06, 2022 at 09:32:52AM -0400, Tamas K Lengyel wrote:
> > > > +/* Supported xHC PCI configurations */
> > > > +#define XUE_XHC_CLASSC 0xC0330ULL
> > > > +#define XUE_XHC_VEN_INTEL 0x8086ULL
> > > > +#define XUE_XHC_DEV_Z370 0xA2AFULL
> > > > +#define XUE_XHC_DEV_Z390 0xA36DULL
> > > > +#define XUE_XHC_DEV_WILDCAT_POINT 0x9CB1ULL
> > > > +#define XUE_XHC_DEV_SUNRISE_POINT 0x9D2FULL
> > > > +#define XUE_XHC_DEV_CANNON_POINT 0x9DEDULL
> > >
> > > I had to add an extra device ID here to get it working on my NUC,
> > > would be nice if we could add that to the list of supported configs so
> > > I don't need to custom patch:
> > >
> > > #define XUE_XHC_DEV_COMET_LAKE 0x02EDULL
> > >
> > > The patch is here:
> > > https://github.com/tklengyel/xen/commit/dd0423aba6caa4ef41dff65470598a1c0c1105ae
> >
> > Interesting, I think known_xhc() is used only in the EFI variant of Xue.
> > Xen one just looks for any XHC based on the device class. And indeed, I
> > works for me on Tiger Lake that is not included here.
> >
> > I did need to select specific controller, since I have 3 of them:
> > 00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB 
> > Controller (rev 01)
> > 00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI 
> > #0 (rev 01)
> > 00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 
> > xHCI Host Controller (rev 20)
> >
> > So, I need dbgp=xue2 or dbgp=xue@pci00:14.0.
>
> Interesting! OK, I'll give that a shot and see if it works that way
> for me too, it's certainly been a while since I last tested :)

Yeap, with console=dbgp dbgp=xue@pci00:14.0 it works as expected.
Xen's boot does hang if you don't have a debug cable connected or if
the other end is not plugged into the right USB3 port. Not sure if
that behavior is documented anywhere. Once I found the right USB3 port
on the machine that receives the debug output it started booting and
everything works expected (ie. one-way communication only).

Tamas