[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