[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Simon Glass
sjg at chromium.org
Wed Mar 9 18:11:26 CET 2016
Hi Stefan,
On 9 March 2016 at 09:15, Stefan Roese <sr at denx.de> wrote:
>
> Hi Simon,
>
> On 09.03.2016 00:33, Simon Glass wrote:
>
> <snip>
>
> >>>> I'm currently struggling with the USB EHCI ports on my custom Bay
> >>>> Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
> >>>> only some of the USB EHCI ports are enabled / available. Here
> >>>> the "usb tree" output with 3 USB keys installed:
> >>>>
> >>>> => usb tree
> >>>> USB device tree:
> >>>> 1 Hub (480 Mb/s, 0mA)
> >>>> | u-boot EHCI Host Controller
> >>>> |
> >>>> +-2 Hub (480 Mb/s, 0mA)
> >>>> |
> >>>> +-3 Hub (480 Mb/s, 100mA)
> >>>> | |
> >>>> | +-4 Hub (12 Mb/s, 100mA)
> >>>> |
> >>>> +-5 Mass Storage (480 Mb/s, 200mA)
> >>>> JetFlash Mass Storage Device 3281440601
> >>>>
> >>>> When I first start the original (AMI) BIOS on this custom board,
> >>>> and then reboot into U-Boot (without a power-cycle), I see this
> >>>> configuration:
> >>>>
> >>>> => usb tree
> >>>> USB device tree:
> >>>> 1 Hub (480 Mb/s, 0mA)
> >>>> | u-boot EHCI Host Controller
> >>>> |
> >>>> +-2 Hub (480 Mb/s, 0mA)
> >>>> |
> >>>> +-3 Hub (480 Mb/s, 100mA)
> >>>> | |
> >>>> | +-4 Hub (12 Mb/s, 100mA)
> >>>> |
> >>>> +-5 Hub (480 Mb/s, 0mA)
> >>>> | |
> >>>> | +-6 Mass Storage (480 Mb/s, 200mA)
> >>>> | | Kingston DataTraveler 2.0 50E549C688C4BE7189942766
> >>>> | |
> >>>> | +-7 Mass Storage (480 Mb/s, 98mA)
> >>>> | USBest Technology USB Mass Storage Device 09092207fbf0c4
> >>>> |
> >>>> +-8 Mass Storage (480 Mb/s, 200mA)
> >>>> JetFlash Mass Storage Device 3281440601
> >>>>
> >>>> So now all 3 USB sticks are detected.
> >>>>
> >>>> It doesn't seem to be a problem with missing USB power switch
> >>>> enabling via some GPIOs. I've checked the schematics and all ports
> >>>> should have power enabled.
> >>>>
> >>>> Do you have any quick ideas, what might be missing to enable all
> >>>> 4 EHCI ports on Bay Trail? There seems to be a per-port disable
> >>>> feature which might be involved. I'm still pretty new to x86, and
> >>>> I'm struggling with finding the correct datasheet for this. So any
> >>>> hints are really appreciated.
> >>>
> >>> It might be worth checking the pci bus device list in both cases.
> >>> Perhaps one of the USB ports is disabled?
> >>
> >> IIUTC, its only one PCI device, that handles all EHCI USB 2.0 ports.
> >> In both cases its this output:
> >>
> >> => pci
> >> Scanning PCI devices on bus 0
> >> BusDevFun VendorId DeviceId Device Class Sub-Class
> >> _____________________________________________________________
> >> 00.1f.00 0x8086 0x0f1c Bridge device 0x01
> >> 00.00.00 0x8086 0x0f00 Bridge device 0x00
> >> 00.02.00 0x8086 0x0f31 Display controller 0x00
> >> 00.11.00 0x8086 0x0f15 Base system peripheral 0x05
> >> 00.12.00 0x8086 0x0f16 Base system peripheral 0x05
> >> 00.13.00 0x8086 0x0f23 Mass storage controller 0x06
> >> 00.15.00 0x8086 0x0f28 Multimedia device 0x01
> >> 00.18.00 0x8086 0x0f40 Base system peripheral 0x01
> >> 00.18.01 0x8086 0x0f41 Serial bus controller 0x80
> >> 00.18.02 0x8086 0x0f42 Serial bus controller 0x80
> >> 00.18.03 0x8086 0x0f43 Serial bus controller 0x80
> >> 00.18.04 0x8086 0x0f44 Serial bus controller 0x80
> >> 00.18.05 0x8086 0x0f45 Serial bus controller 0x80
> >> 00.18.06 0x8086 0x0f46 Serial bus controller 0x80
> >> 00.18.07 0x8086 0x0f47 Serial bus controller 0x80
> >> 00.1a.00 0x8086 0x0f18 Cryptographic device 0x80
> >> 00.1c.00 0x8086 0x0f48 Bridge device 0x04
> >> 00.1c.03 0x8086 0x0f4e Bridge device 0x04
> >> 00.1d.00 0x8086 0x0f34 Serial bus controller 0x03
> >> 00.1e.00 0x8086 0x0f06 Base system peripheral 0x01
> >> 00.1e.01 0x8086 0x0f08 Serial bus controller 0x80
> >> 00.1e.02 0x8086 0x0f09 Serial bus controller 0x80
> >> 00.1e.04 0x8086 0x0f0c Simple comm. controller 0x80
> >> 00.1e.05 0x8086 0x0f0e Serial bus controller 0x80
> >> 00.1f.03 0x8086 0x0f12 Serial bus controller 0x05
> >>
> >> Here 00.1d.00 is the EHCI controller. The "pci long" output
> >> is also identical. So its not that simple I'm afraid.
> >>
> >> The Intel Atom Processor Z3600 and Z3700 Series Datasheet Vol 1
> >> mentions in chapter "10.3.1 EHCI USB 2.0 Controller Features" on
> >> page 150:
> >>
> >> • Per port USB disable
> >>
> >> Perhaps this feature is biting me here. I'm wondering how this can
> >> be configured.
> >
> > That sounds likely.
> >
> > Also: xHCI and EHCI Port Mapping
> >
> > suggests that you need to make sure the ports are being driven by EHCI
> > instead of XHCI.
> >
> > It mentions USB2HCSEL but I cannot find that in the datasheet.
>
> Same here.
>
> > It does appear here though:
> >
> > https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/perf_power.c
> >
> > See IOSF_PORT_0x5a here:
> >
> > https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/broadwell_fsp/src/lib/reg_script.c
> >
> > So it looks like you need to set up this port, and perhaps some others
> > asper that file.
>
> I've looked into these coreboot files today. And ported parts of them
> to U-Boot to run these configurations there as well. Unfortunately
> without any (positive) effect. Some things I've tested are:
>
> Configure 0x5a / 0xd0 (USB2HCSEL???) to different values. All
> without effect.
>
> Unfortunately this value can't be read-out. At least I read always
> 0 here. So I can't see, if the AMI BIOS version configures here
> something different.
That's really odd, because it looks like this is a read/write
interface. Worth digging int I think, and trying to find docs.
>
> Then I've started looking into ehci.c:
>
> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/ehci.c
>
> EHCI_USB2PDO (per-port disable) looked promising here. And writing
> 0xff into this reg results in all ports disabled:
>
> => usb tree
> USB device tree:
> 1 Hub (480 Mb/s, 0mA)
> | u-boot EHCI Host Controller
> |
> +-2 Hub (480 Mb/s, 0mA)
>
> So this register at least has some effect. But its initialized with
> 0 and writing 0 into it does not fix the problem with the missing
> ports.
>
> I also ported the PHY values from usb2_phy_init() without any
> changes. The values here are the default values, as I can read
> them back. Also the AMI BIOS does not change these values, I've
> double checked this as well.
BTW is the AMI BIOS UEFI? If so, for now I suppose you could boot into
U-Boot from that, and deal with the problem later.
>
> So I'm nearly out of ideas right now what else to configure / test
> to get all ports running. One idea is that the xHCI controller also
> needs some configuration for this port muxing. See:
>
> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/xhci.c:
>
> /* USB3 SuperSpeed Enable */
> REG_PCI_WRITE32(XHCI_USB3PR, BYTM_USB3_PORT_MAP),
> /* USB2 Port Route to XHCI */
> REG_PCI_WRITE32(XHCI_USB2PR, BYTM_USB2_PORT_MAP),
>
> and:
>
> /* Set USB2 Port Routing Mask */
> REG_PCI_WRITE32(XHCI_USB2PRM, BYTM_USB2_PORT_MAP),
> /* Set USB3 Port Routing Mask */
> REG_PCI_WRITE32(XHCI_USB3PRM, BYTM_USB3_PORT_MAP),
> /*
> * Disable ports if requested
> */
> /* Open per-port disable control override */
> REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~0, UPRWC_WR_EN),
> REG_PCI_WRITE32(XHCI_USB2PDO, config->usb2_port_disable_mask),
> REG_PCI_WRITE32(XHCI_USB3PDO, config->usb3_port_disable_mask),
> /* Close per-port disable control override */
> REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~UPRWC_WR_EN, 0),
>
> But I can only either see the EHCI or the xHCI controller via
> "pci". If I configure the FSP to enable xHCI (fsp,enable-xhci)
> the EHCI PCI device is not listed. And without this DT property
> the xHCI PCI device is missing. So I only have access to one
> USB controller at the some time.
>
> Any further ideas are really welcome! :)
I'm pretty short on time this month otherwise I would love to look at
this. Can you post a patch that adds all the init code you have found
to baytrail?
>
> BTW: Did you (or somebody else?) already start moving xHCI (PCI) to
> DM yet? If yes, could you perhaps provide this version so that I
> could continue with it.
Yes, see u-boot-x86/samus-working.
>
> Thanks,
> Stefan
>
Regards,
Simon
More information about the U-Boot
mailing list