The 1.1 revision of the XHCI specification added an extra 5 bits to the Max Scratchpad Bufs field of HCSPARAMS2 that newer controllers make use of. Not honoring these bits means we're not allocating as many scratchpad buffers as the controller expects, which means it will interpret some uninitialized values from the end of the pointer array as scratchpad buffer pointers.
We just fixed this in libpayload and it seems to apply the same way to SeaBIOS (I only compile-tested this, though... sorry).
Signed-off-by: Julius Werner jwerner@chromium.org --- src/hw/usb-xhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/hw/usb-xhci.c b/src/hw/usb-xhci.c index d6caa77..0059f2e 100644 --- a/src/hw/usb-xhci.c +++ b/src/hw/usb-xhci.c @@ -465,7 +465,7 @@ configure_xhci(void *data) xhci->evts->cs = 1;
reg = readl(&xhci->caps->hcsparams2); - u32 spb = reg >> 27; + u32 spb = (reg >> 21 & 0x1f) << 5 | reg >> 27; if (spb) { dprintf(3, "%s: setup %d scratch pad buffers\n", __func__, spb); u64 *spba = memalign_high(64, sizeof(*spba) * spb);
On Fri, Aug 07, 2015 at 08:07:12PM -0700, Julius Werner wrote:
The 1.1 revision of the XHCI specification added an extra 5 bits to the Max Scratchpad Bufs field of HCSPARAMS2 that newer controllers make use of. Not honoring these bits means we're not allocating as many scratchpad buffers as the controller expects, which means it will interpret some uninitialized values from the end of the pointer array as scratchpad buffer pointers.
We just fixed this in libpayload and it seems to apply the same way to SeaBIOS (I only compile-tested this, though... sorry).
Thanks - I committed this change.
If a controller requires that much reserved ram, it will likely lead to an out of memory error in the current seabios code. (But an error is much preferable to a silent failure.)
-Kevin
-
Julius Werner -
Kevin O'Connor