Re: [PATCH 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI

[Peter Maydell]

On Wed, 31 May 2023 at 17:37, Leif Lindholm <quic_llindhol@quicinc.com> wrote:
>
> On 2023-05-31 16:27, Peter Maydell wrote:
> > On Wed, 31 May 2023 at 15:58, Graeme Gregory <graeme@xora.org.uk> wrote:
> >>> The current sbsa-ref cannot use EHCI controller which is only
> >>> able to do 32-bit DMA, since sbsa-ref doesn't have RAM above 4GB.
> >>> Hence, this uses XHCI to provide a usb controller with 64-bit
> >>> DMA capablity instead of EHCI.
> >>
> >> Should this be below 4G?
> >
> > It would be pretty disruptive to try to rearrange the memory
> > map to put RAM below 4GB at this point, though in theory it's
> > possible I guess. (I have a vague recollection that there was
> > some reason the RAM was all put above 4GB, but can't find
> > anything about that in my email archives. Perhaps Leif remembers?)
>
> I think Graeme was just pointing out a typo in Marcin's email.
>
> Yeah, we're not changing the DRAM base at this stage.
> I think the reason we put no RAM below 4GB was simply that we had
> several real-world platforms where that was true, and given the intended
> use-case for the platform, we explicitly wanted to trigger issues those
> platforms might encounter.
>
> >> Also has EHCI never worked, or has it worked in some modes and so this
> >> change should be versioned?
> >
> > AIUI, EHCI has never worked and can never have worked, because
> > this board's RAM is all above 4G and the QEMU EHCI controller
> > implementation only allows DMA descriptors with 32-bit addresses.
> >
> > Looking back at the archives, it seems we discussed XHCI vs
> > EHCI when the sbsa-ref board went in, and the conclusion was
> > that XHCI would be better. But there wasn't a sysbus XHCI device
> > at that point, so we ended up committing the sbsa-ref board
> > with EHCI and a plan to switch to XHCI when the sysbus-xhci
> > device was done, which we then forgot about:
> > https://mail.gnu.org/archive/html/qemu-arm/2018-11/msg00638.html
>
> Ah, thanks! That explains why we did the thing that made no sense :)
>
> To skip the migration hazard, my prefernece is we just leave the EHCI
> device in for now, and add a separate XHCI on PCIe. We can drop the
> EHCI device at some point in the future.

Why PCIe for the XHCI and not sysbus? At the time the board
was originally added the argument was in favour of using
a sysbus USB controller (you can see Ard making that point
in the linked archive thread).

thanks
-- PMM