Hi Stefan, On 11 March 2016 at 09:28, Stefan Roese <s...@denx.de> wrote: > Hi Simon, > > > On 09.03.2016 18:11, Simon Glass wrote: >> >> On 9 March 2016 at 09:15, Stefan Roese <s...@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. > > > I've really tried to find some docs here. But all I can find on the > net are the links to the coreboot source. > > I've also printed all 0x5a registers, well not all but from 0x00 to > 0x200. And all of them are read as 0. Yes, this is odd but I can't > see that I'm doing something wrong here while reading those values. > >>> >>> 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? > > > I think so - I need to check to be 100% sure though. > >> If so, for now I suppose you could boot into >> U-Boot from that, and deal with the problem later. > > > Interesting idea. Right now I'm booting into the AMI BIOS once, and then > only doing reset's into U-Boot (I can toggle the SPI NOR chip via > a DIP switch, which is quite handy). > > >>> >>> 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. > > > That would be great, thanks! > >> Can you post a patch that adds all the init code you have found >> to baytrail? > > > I need to clean this mess up a bit before I can post something of > this. And I've used the last few days to implement the USB scanning > enhancements, as you will have noticed in your inbox. :) > > I'll definitely come back to your offer beginning of next week > and will post this coreboot register access stuff I've added to > my platform code for testing.
Actually I was saying that I am short on time, not that I can look at ti soon :-) I'm pretty tied up with travel etc. for the next 3 weeks, sorry. > >>> >>> 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. I'll probably look into this next week. > > Thanks, > Stefan > Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
