From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Tue, 8 Mar 2016 16:33:23 -0700 Subject: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree In-Reply-To: <56DF0EE0.2000200@denx.de> References: <1438950995-7771-1-git-send-email-andrew@bradfordembedded.com> <20150809010859.GA3842@bradfordembedded.com> <20150810113256.GA3645@rhino.kodakalaris.net> <20150811120820.GA13429@rhino.kodakalaris.net> <20150811152038.GC13429@rhino.kodakalaris.net> <56DF01B6.9040800@denx.de> <56DF0EE0.2000200@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Stefan, On 8 March 2016 at 10:41, Stefan Roese wrote: > Hi Simon, > > On 08.03.2016 17:54, Simon Glass wrote: >> Hi Stefan, >> >> On 8 March 2016 at 09:45, Stefan Roese 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 wrote: >>>>> Hi Simon, >>>>> >>>>> On 08/11 08:06, Simon Glass wrote: >>>>>> Hi Andrew, >>>>>> >>>>>> On 11 August 2015 at 06:08, Andrew Bradford wrote: >>>>>>> Hi Simon, >>>>>>> >>>>>>> On 08/10 21:07, Simon Glass wrote: >>>>>>>> Hi Bin, >>>>>>>> >>>>>>>> On 10 August 2015 at 20:53, Bin Meng wrote: >>>>>>>>> Hi Andrew, >>>>>>>>> >>>>>>>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford >>>>>>>>> wrote: >>>>>>>>>> Hi Bin, >>>>>>>>>> >>>>>>>>>> On 08/09 10:52, Bin Meng wrote: >>>>>>>>>>> Hi Andrew, >>>>>>>>>>> >>>>>>>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi Simon, >>>>>>>>>>>> >>>>>>>>>>>> On 08/08 10:18, Simon Glass wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 7 August 2015 at 06:44, Bin Meng wrote: >>>>>>>>>>>>>> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> From: Andrew Bradford >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Reviewed-by: Bin Meng >>>>>>>>>>>>>> Tested-by: Bin Meng >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Acked-by: Simon Glass >>>>>>>>>>>>> Tested on minnowmax: >>>>>>>>>>>>> Tested-by: Simon Glass >>>>>>>>>>>>> >>>>>>>>>>>>> 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 = ; >>>>> >>>>> 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