On Thu, 1 Jun 2023 at 20:00, Leif Lindholm <quic_llind...@quicinc.com> wrote: > > +Ard > > On Thu, Jun 01, 2023 at 16:01:43 +0100, Peter Maydell wrote: > > > >> 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). > > The original argument was that having the device on the sysbus > 1) enabled codepaths we wanted to exercise and > 2) more closely resembled the development systems available at the > time. > > 1 still applies, but I'm not sure 2 does. Ard? >
It was always primarily about #1. This was also the reason for putting all DRAM above 4G. I'm surprised that the EHCI never worked, though - I don't see the point in keeping it in that case.
