[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Stefan Roese
sr at denx.de
Fri Mar 11 17:28:36 CET 2016
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.
>>
>> 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
More information about the U-Boot
mailing list