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.
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
