Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Stefan, On 11 March 2016 at 09:28, Stefan Roese wrote: > Hi Simon, > > > On 09.03.2016 18:11, Simon Glass wrote: >> >> On 9 March 2016 at 09:15, Stefan Roese wrote: >>> >>> >>> Hi Simon, >>> >>> On 09.03.2016 00:33, Simon Glass wrote: >>> >>> >>> >>> 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 device0x80 > 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 disabl
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Simon, On 09.03.2016 18:11, Simon Glass wrote: On 9 March 2016 at 09:15, Stefan Roese wrote: Hi Simon, On 09.03.2016 00:33, Simon Glass wrote: 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 device0x80 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
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Stefan, On 9 March 2016 at 09:15, Stefan Roese wrote: > > Hi Simon, > > On 09.03.2016 00:33, Simon Glass wrote: > > > > 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 device0x80 > >> 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 men
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Simon, On 09.03.2016 00:33, Simon Glass wrote: 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 device0x80 >> 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
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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@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 inde
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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@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@0 {
>>> gpio-offset = <0x80 9>;
>>> - pad-offset = <0x258>;
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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@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@0 {
>> gpio-offset = <0x80 9>;
>> - pad-offset = <0x258>;
>> + pad-offset = <0x250>;
>> mode-gpio;
>> output-value = <1>;
>> direction = ;
>>
>> Does that fix it?
>
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Simon, On Wed, Aug 12, 2015 at 11:54 AM, 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@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/minnowma
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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. > I've tested xHCI port in Linux on Bayley Bay today. Linux kernel xHCI driver works great on Bayley Bay. So indeed U-Boot xHCI driver has some issues supporting Intel chipset. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Andrew, On 12 August 2015 at 05:52, Andrew Bradford wrote: > Hi Simon, > > On 08/11 21: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 an
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Simon, On 08/11 21: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@0 is wrong and that it should be 0x250 instead of > > 0x258. > > > > diff --git a/arch/x86/dts/minnowmax.dts b/arch/x8
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
+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@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@0 {
> gpio-offset = <0x80 9>;
> - pad-offset = <0x258>;
> + pad-offset = <0x250>;
>
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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@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@0 {
gpio-offset = <0x80 9>;
- pad-offset = <0x258>;
+ pad-offset = <0x250>;
mode-gpio;
output-value = <1>;
direction = ;
Does that fix it?
Thanks,
Andrew
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listin
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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. > >> So overall I think we are in a better position to go with ehci for >> now, i.e. drop the fsp,enable-xhci property. > > OK, sounds good! > > Thanks! > -Andrew Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Simon, On 08/10 21:39, Simon Glass wrote: > Hi Bin, > > On 10 August 2015 at 21:31, Bin Meng wrote: > > Hi Simon, > > > > On Tue, Aug 11, 2015 at 11:24 AM, Simon Glass wrote: > >> Hi Bin, > >> > >> On 10 August 2015 at 21:17, Bin Meng wrote: > >>> Hi Simon, > >>> > >>> On Tue, Aug 11, 2015 at 11:07 AM, 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. > >>> > >>> There are 3 ports on Intel Bayley Bay. One USB 3 (blue port) and two > >>> USB 2 ports. The board user guide explicitly mentions that the top USB > >>> 2 port does not work and needs PCB rework. For the other two ports, > >>> I've tested U-Boot EHCI stack and it works fine. Interesting to hear > >>> that MinnowMax also has some USB port issue. Maybe the board design is > >>> following Bayley Bay. > >> > >> Maybe. > >> > >>> > > So overall I think we are in a better position to go with ehci for > now, i.e. drop the fsp,enable-xhci property. > >>> > >>> OK, then could you please remove this for Bayley Bay as well? Also I > >>> think we need remove the MRC debug output as well. > >> > >> Yes will do. > >> > >>> > > I think there is a little tweak needed to support both ports, but I > haven't dug into it yet. > > >>> > >>> This is not possible. According to Intel E3800 datasheet, the xHCI and > >>> EHCI are mutually exclusive. We can either use xHCI, or EHCI. > >> > >> I believe you can put the ports into a mode where both work, although > >> presumablly they are both either EHCI or xHCI. When I boot UEFI both > >> ports work. > >> > > > > Yep, that's what I meant. When using EHCI the USB 3 port will function > > as a USB 2 port and when using xHCI the USB 2 port will
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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? > So overall I think we are in a better position to go with ehci for > now, i.e. drop the fsp,enable-xhci property. OK, sounds good! Thanks! -Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Bin, On 10 August 2015 at 21:31, Bin Meng wrote: > Hi Simon, > > On Tue, Aug 11, 2015 at 11:24 AM, Simon Glass wrote: >> Hi Bin, >> >> On 10 August 2015 at 21:17, Bin Meng wrote: >>> Hi Simon, >>> >>> On Tue, Aug 11, 2015 at 11:07 AM, 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. >>> >>> There are 3 ports on Intel Bayley Bay. One USB 3 (blue port) and two >>> USB 2 ports. The board user guide explicitly mentions that the top USB >>> 2 port does not work and needs PCB rework. For the other two ports, >>> I've tested U-Boot EHCI stack and it works fine. Interesting to hear >>> that MinnowMax also has some USB port issue. Maybe the board design is >>> following Bayley Bay. >> >> Maybe. >> >>> So overall I think we are in a better position to go with ehci for now, i.e. drop the fsp,enable-xhci property. >>> >>> OK, then could you please remove this for Bayley Bay as well? Also I >>> think we need remove the MRC debug output as well. >> >> Yes will do. >> >>> I think there is a little tweak needed to support both ports, but I haven't dug into it yet. >>> >>> This is not possible. According to Intel E3800 datasheet, the xHCI and >>> EHCI are mutually exclusive. We can either use xHCI, or EHCI. >> >> I believe you can put the ports into a mode where both work, although >> presumablly they are both either EHCI or xHCI. When I boot UEFI both >> ports work. >> > > Yep, that's what I meant. When using EHCI the USB 3 port will function > as a USB 2 port and when using xHCI the USB 2 port will only get high > speed. Ah I see. I fixed these up and also some 80col problems. Please let me know if anything is wrong. Applied to u-boot-x86. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Simon, On Tue, Aug 11, 2015 at 11:24 AM, Simon Glass wrote: > Hi Bin, > > On 10 August 2015 at 21:17, Bin Meng wrote: >> Hi Simon, >> >> On Tue, Aug 11, 2015 at 11:07 AM, 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. >> >> There are 3 ports on Intel Bayley Bay. One USB 3 (blue port) and two >> USB 2 ports. The board user guide explicitly mentions that the top USB >> 2 port does not work and needs PCB rework. For the other two ports, >> I've tested U-Boot EHCI stack and it works fine. Interesting to hear >> that MinnowMax also has some USB port issue. Maybe the board design is >> following Bayley Bay. > > Maybe. > >> >>> >>> So overall I think we are in a better position to go with ehci for >>> now, i.e. drop the fsp,enable-xhci property. >> >> OK, then could you please remove this for Bayley Bay as well? Also I >> think we need remove the MRC debug output as well. > > Yes will do. > >> >>> >>> I think there is a little tweak needed to support both ports, but I >>> haven't dug into it yet. >>> >> >> This is not possible. According to Intel E3800 datasheet, the xHCI and >> EHCI are mutually exclusive. We can either use xHCI, or EHCI. > > I believe you can put the ports into a mode where both work, although > presumablly they are both either EHCI or xHCI. When I boot UEFI both > ports work. > Yep, that's what I meant. When using EHCI the USB 3 port will function as a USB 2 port and when using xHCI the USB 2 port will only get high speed. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Bin, On 10 August 2015 at 21:17, Bin Meng wrote: > Hi Simon, > > On Tue, Aug 11, 2015 at 11:07 AM, 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. > > There are 3 ports on Intel Bayley Bay. One USB 3 (blue port) and two > USB 2 ports. The board user guide explicitly mentions that the top USB > 2 port does not work and needs PCB rework. For the other two ports, > I've tested U-Boot EHCI stack and it works fine. Interesting to hear > that MinnowMax also has some USB port issue. Maybe the board design is > following Bayley Bay. Maybe. > >> >> So overall I think we are in a better position to go with ehci for >> now, i.e. drop the fsp,enable-xhci property. > > OK, then could you please remove this for Bayley Bay as well? Also I > think we need remove the MRC debug output as well. Yes will do. > >> >> I think there is a little tweak needed to support both ports, but I >> haven't dug into it yet. >> > > This is not possible. According to Intel E3800 datasheet, the xHCI and > EHCI are mutually exclusive. We can either use xHCI, or EHCI. I believe you can put the ports into a mode where both work, although presumablly they are both either EHCI or xHCI. When I boot UEFI both ports work. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Simon, On Tue, Aug 11, 2015 at 11:07 AM, 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. There are 3 ports on Intel Bayley Bay. One USB 3 (blue port) and two USB 2 ports. The board user guide explicitly mentions that the top USB 2 port does not work and needs PCB rework. For the other two ports, I've tested U-Boot EHCI stack and it works fine. Interesting to hear that MinnowMax also has some USB port issue. Maybe the board design is following Bayley Bay. > > So overall I think we are in a better position to go with ehci for > now, i.e. drop the fsp,enable-xhci property. OK, then could you please remove this for Bayley Bay as well? Also I think we need remove the MRC debug output as well. > > I think there is a little tweak needed to support both ports, but I > haven't dug into it yet. > This is not possible. According to Intel E3800 datasheet, the xHCI and EHCI are mutually exclusive. We can either use xHCI, or EHCI. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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. So overall I think we are in a better position to go with ehci for now, i.e. drop the fsp,enable-xhci property. I think there is a little tweak needed to support both ports, but I haven't dug into it yet. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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. Thanks, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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 enabled the MRC debug messages as it was helpful to me as there are a > set of FSP UPD device tree properties which during my development turned > out to boot enough for the MRC code in the FSP to run but which would > not actually end up starting u-boot. At least having the MRC debug > message print out showed me that at least u-boot was operating enough to > call into the FSP and that likely I had something misconfigured in the > UPD memory settings. Probably not showing these debug messages is the > right choice, as if someone wants more debug output then they can also > use the FSPv4 debug build that Intel now provides. > Yep, I found the FSP debug build is pretty useful. At least you can guess what the FSP is trying to do with the hardware :-) > Thanks for your help with this patch! :) > -Andrew Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
Hi Simon, On Sun, Aug 9, 2015 at 12:18 AM, 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 Ah, I thought xHCI was working on MinnowMax! Further looking at the codes, I found you added the pci-xhci driver but is not enabled on MinnowMax. In fact, I was trying to bring up xHCI on BayleyBay as it does not work. I thought it might be caused by my BayTrail stepping is pretty old on my board. But now since it does not work on MinnowMax (which has B2 and D0 stepping), so it looks it may be a U-Boot xHCI driver issue? > - fsp,mrc-debug-msg needs to be removed to prevent debug information > being displayed > I was using a FSPv4 debug binary and does not notice this. > I plan to apply this with these changes - please let me know if this > doesn't suit. > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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. I enabled the MRC debug messages as it was helpful to me as there are a set of FSP UPD device tree properties which during my development turned out to boot enough for the MRC code in the FSP to run but which would not actually end up starting u-boot. At least having the MRC debug message print out showed me that at least u-boot was operating enough to call into the FSP and that likely I had something misconfigured in the UPD memory settings. Probably not showing these debug messages is the right choice, as if someone wants more debug output then they can also use the FSPv4 debug build that Intel now provides. Thanks for your help with this patch! :) -Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree
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 [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
