[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Simon Glass
sjg at chromium.org
Wed Mar 9 00:33:23 CET 2016
Hi Stefan,
On 8 March 2016 at 10:41, Stefan Roese <sr at denx.de> wrote:
> Hi Simon,
>
> On 08.03.2016 17:54, Simon Glass wrote:
>> Hi Stefan,
>>
>> On 8 March 2016 at 09:45, Stefan Roese <sr at denx.de> wrote:
>>> Hi Simon, Hi Bin,
>>>
>>> On 12.08.2015 05:54, Simon Glass wrote:
>>>> +Gabriel
>>>>
>>>> Hi Andrew,
>>>>
>>>> On 11 August 2015 at 09:20, Andrew Bradford <andrew at bradfordembedded.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On 08/11 08:06, Simon Glass wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> On 11 August 2015 at 06:08, Andrew Bradford <andrew at bradfordembedded.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On 08/10 21:07, Simon Glass wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>>>>>> Hi Andrew,
>>>>>>>>>
>>>>>>>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>>>>>>>> <andrew at bradfordembedded.com> wrote:
>>>>>>>>>> Hi Bin,
>>>>>>>>>>
>>>>>>>>>> On 08/09 10:52, Bin Meng wrote:
>>>>>>>>>>> Hi Andrew,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>>>>>>>>> <andrew at bradfordembedded.com> wrote:
>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/08 10:18, Simon Glass wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>>>>>>>>>>> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>>>>>>>>>>>> <andrew at bradfordembedded.com> wrote:
>>>>>>>>>>>>>>> From: Andrew Bradford <andrew.bradford at kodakalaris.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Allow for configuration of FSP UPD from the device tree which will
>>>>>>>>>>>>>>> override any settings which the FSP was built with itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>>>>>>>>>>>>> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>>>>>>>>>>>>> with the condition that the memory-down parameters for MinnowMax are
>>>>>>>>>>>>>>> also used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Andrew Bradford <andrew.bradford at kodakalaris.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn at gmail.com>
>>>>>>>>>>>>>> Tested-by: Bin Meng <bmeng.cn at gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Acked-by: Simon Glass <sjg at chromium.org>
>>>>>>>>>>>>> Tested on minnowmax:
>>>>>>>>>>>>> Tested-by: Simon Glass <sjg at chromium.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I found that I need to remove two properties from the minnowmax.dts:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>>>>>>>>>>> at present and stops EHCI from working
>>>>>>>>>>>>> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>>>>>>>>>>> being displayed
>>>>>>>>>>>>>
>>>>>>>>>>>>> I plan to apply this with these changes - please let me know if this
>>>>>>>>>>>>> doesn't suit.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>>>>>>>>>>
>>>>>>>>>>>> But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>>>>>>>>>> port on Minnow Max will only act as a USB 2.0 port. That u-boot doesn't
>>>>>>>>>>>> yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>>>>>>>>>> sure which was a better choice.
>>>>>>>>>>>
>>>>>>>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>>>>>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>>>>>>>>
>>>>>>>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>>>>>>>>> not have a board so I'm unable to test, sorry.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>>>>>>>
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>>>>>>>
>>>>>>>> The problem is that USB is then broken in U-Boot. I think it is better
>>>>>>>> to limit the speed for the moment until we have that fixed. It is
>>>>>>>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>>>>>>>
>>>>>>>> With my testing the bottom (blue) port works fine but the top port
>>>>>>>> does not. This happens regardless of the xhci setting.
>>>>>>>
>>>>>>> Minnowmax has a USB power switch enable which determines if the VBUS2
>>>>>>> net is turned on or not, which will supply or not supply power to the
>>>>>>> USB 2.0 port. The blue USB 3.0 port also has an enable. Both enables
>>>>>>> and the USB ports themselves are located on page 16 of the schematic
>>>>>>> that I have.
>>>>>>>
>>>>>>> The switches to enable the VBUS for each port are active high and pulled
>>>>>>> down. So to turn them on, I believe that's the point of the pinmuxing
>>>>>>> and GPIO settings which are used in the minnowmax.dts. Can you verify
>>>>>>> if these are correctly turning on VBUS2 (since it sounds like they are
>>>>>>> turning on VBUS1)? If not, when you turn these GPIO on manually, does
>>>>>>> the USB 2.0 port work correctly?
>>>>>>
>>>>>> I see power on the bottom port but not the top one.
>>>>>
>>>>> OK, that's odd, but likely can be fixed with changes to the pin mux and
>>>>> pad settings in the dts. I believe that the "pad-offset" for
>>>>> pin_usb_host_en1 at 0 is wrong and that it should be 0x250 instead of
>>>>> 0x258.
>>>>>
>>>>> diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
>>>>> index d0c0fe6..4988163 100644
>>>>> --- a/arch/x86/dts/minnowmax.dts
>>>>> +++ b/arch/x86/dts/minnowmax.dts
>>>>> @@ -39,7 +39,7 @@
>>>>>
>>>>> pin_usb_host_en1 at 0 {
>>>>> gpio-offset = <0x80 9>;
>>>>> - pad-offset = <0x258>;
>>>>> + pad-offset = <0x250>;
>>>>> mode-gpio;
>>>>> output-value = <1>;
>>>>> direction = <PIN_OUTPUT>;
>>>>>
>>>>> Does that fix it?
>>>>
>>>> I dug into this a bit and it all seems quite broken:
>>>>
>>>> - PCI bus configuration does not work in gpio_ich6_pinctrl_init(). I
>>>> will send a patch for this
>>>> - gpio_ich6_get_base() returns a 16-bit word but function is also used
>>>> to read the memory address which holds a 32-bit word
>>>> - Intel's hardware won't let you read the status of an output!
>>>>
>>>> The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We
>>>> need to mirror the lvl register in order to be able to read it.
>>>>
>>>> I confirmed that with the 'correct' value in the lvl registers both
>>>> USB ports work.
>>>
>>> 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.
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.
>
> Any further ideas are welcome.
>
> Thanks,
> Stefan
>
Regards,
Simon
More information about the U-Boot
mailing list