the FSP is configuring the XHCI controller. Coreboot is not touching
it - this is at Intel's request.
Enabling both the XHCI and EHCI controllers in devicetree sets XHCI off
and EHCI on. You'll see the state of all of the devices that gets
passed into the FSP very early in the boot sequence if you have the
console set to debug or spew.
I saw the same hang in SeaBIOS when I used the default SeaBIOS built by
coreboot. When I built it separately, It still didn't boot from the
XHCI device, but it did identify it, and didn't hang. I'm including the
SeaBIOS .config that I used.
On 06/13/2014 04:21 AM, Mike Hibbett wrote:
Does anyone have a view on the state of xHCI on
I've enabled xHCI ( and disabled eHCI ) in devicetree.cb, but the resulting build
with SeaBIOS as a payload will not go further than displaying the SeaBIOS header string.
With both xHCI and eHCI enabled in devicetree.cb - which the comments in that file say I
should not do - SeaBIOS loads, and can recognize a DVD drive attached to a USB3 USB hub.
I'm not sure whether this is a safe combination, or whether there are other settings
I should change.