[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

Simon Glass sjg at chromium.org
Sat Mar 12 01:33:01 CET 2016


Hi Stefan,

On 11 March 2016 at 09:28, Stefan Roese <sr at denx.de> wrote:
> Hi Simon,
>
>
> On 09.03.2016 18:11, Simon Glass wrote:
>>
>> 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.
>
>
> 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


More information about the U-Boot mailing list