qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leif Lindholm
Subject: Re: [PATCH 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
Date: Wed, 31 May 2023 17:36:56 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1

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.

/
    Leif





reply via email to

[Prev in Thread] Current Thread [Next in Thread]