[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Andrew Bradford]

From: Andrew Bradford <andrew.bradford@kodakalaris.com>

Allow for configuration of FSP UPD from the device tree which will
override any settings which the FSP was built with itself.

Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
settings from the Intel FSPv4 Gold release to the respective dts files,
with the condition that the memory-down parameters for MinnowMax are
also used.

Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
---

Changes from v3:
- Fix small typographical issues (lowercase hex numbers, grammar, etc),
  no functional changes.

Changes from v2:
- Switch to using booleans in dts, where appropriate.
- Add Bayley Bay dts modifications.
- Clarify docs to show bool versus int properties.
- Include enable-igt property from FSPv4.

Changes from v1:
- Use "-" rather than "_" in dt property names.
- Use "Bay Trail" for the formal name of the Intel product family.
- Use an "fsp," prefix for dt property names for clarity.
- Fix minor code indentation issues.
- Create a dt subnode for the memory-down-params.
- Clarify documentation that dt overrides the FSP's config, so we don't
  use booleans.

 arch/x86/cpu/baytrail/fsp_configs.c                | 167 +++++++++++++++++----
 arch/x86/dts/bayleybay.dts                         |  40 +++++
 arch/x86/dts/minnowmax.dts                         |  58 +++++++
 .../misc/intel,baytrail-fsp.txt                    | 158 +++++++++++++++++++
 include/fdtdec.h                                   |   2 +
 lib/fdtdec.c                                       |   2 +
 6 files changed, 397 insertions(+), 30 deletions(-)
 create mode 100644 doc/device-tree-bindings/misc/intel,baytrail-fsp.txt

diff --git a/arch/x86/cpu/baytrail/fsp_configs.c b/arch/x86/cpu/baytrail/fsp_configs.c
index 86b6926..ba56ebb 100644
--- a/arch/x86/cpu/baytrail/fsp_configs.c
+++ b/arch/x86/cpu/baytrail/fsp_configs.c
@@ -1,14 +1,18 @@
 /*
  * Copyright (C) 2013, Intel Corporation
  * Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com>
+ * Copyright (C) 2015, Kodak Alaris, Inc
  *
  * SPDX-License-Identifier:	Intel
  */
 
 #include <common.h>
+#include <fdtdec.h>
 #include <asm/arch/fsp/azalia.h>
 #include <asm/fsp/fsp_support.h>
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /* ALC262 Verb Table - 10EC0262 */
 static const uint32_t verb_table_data13[] = {
 	/* Pin Complex (NID 0x11) */
@@ -116,41 +120,144 @@ const struct pch_azalia_config azalia_config = {
 	.reset_wait_timer_us = 300
 };
 
+/**
+ * Override the FSP's UPD.
+ * If the device tree does not specify an integer setting, use the default
+ * provided in Intel's Baytrail_FSP_Gold4.tgz release FSP/BayleyBayFsp.bsf file.
+ */
 void update_fsp_upd(struct upd_region *fsp_upd)
 {
 	struct memory_down_data *mem;
+	const void *blob = gd->fdt_blob;
+	int node;
 
-	/*
-	 * Configure everything here to avoid the poor hard-pressed user
-	 * needing to run Intel's binary configuration tool. It may also allow
-	 * us to support the 1GB single core variant easily.
-	 *
-	 * TODO(sjg at chromium.org): Move to device tree
-	 */
-	fsp_upd->mrc_init_tseg_size = 8;
-	fsp_upd->mrc_init_mmio_size = 0x800;
-	fsp_upd->emmc_boot_mode = 0xff;
-	fsp_upd->enable_sdio = 1;
-	fsp_upd->enable_sdcard = 1;
-	fsp_upd->enable_hsuart0 = 1;
 	fsp_upd->azalia_config_ptr = (uint32_t)&azalia_config;
-	fsp_upd->enable_i2_c0 = 0;
-	fsp_upd->enable_i2_c2 = 0;
-	fsp_upd->enable_i2_c3 = 0;
-	fsp_upd->enable_i2_c4 = 0;
-	fsp_upd->enable_xhci = 0;
-	fsp_upd->igd_render_standby = 1;
+
+	node = fdtdec_next_compatible(blob, 0, COMPAT_INTEL_BAYTRAIL_FSP);
+	if (node < 0) {
+		debug("%s: Cannot find FSP node\n", __func__);
+		return;
+	}
+
+	fsp_upd->mrc_init_tseg_size = fdtdec_get_int(blob, node,
+						     "fsp,mrc-init-tseg-size",
+						     0);
+	fsp_upd->mrc_init_mmio_size = fdtdec_get_int(blob, node,
+						     "fsp,mrc-init-mmio-size",
+						     0x800);
+	fsp_upd->mrc_init_spd_addr1 = fdtdec_get_int(blob, node,
+						     "fsp,mrc-init-spd-addr1",
+						     0xa0);
+	fsp_upd->mrc_init_spd_addr2 = fdtdec_get_int(blob, node,
+						     "fsp,mrc-init-spd-addr2",
+						     0xa2);
+	fsp_upd->emmc_boot_mode = fdtdec_get_int(blob, node,
+						 "fsp,emmc-boot-mode", 2);
+	fsp_upd->enable_sdio = fdtdec_get_bool(blob, node, "fsp,enable-sdio");
+	fsp_upd->enable_sdcard = fdtdec_get_bool(blob, node,
+						 "fsp,enable-sdcard");
+	fsp_upd->enable_hsuart0 = fdtdec_get_bool(blob, node,
+						  "fsp,enable-hsuart0");
+	fsp_upd->enable_hsuart1 = fdtdec_get_bool(blob, node,
+						  "fsp,enable-hsuart1");
+	fsp_upd->enable_spi = fdtdec_get_bool(blob, node, "fsp,enable-spi");
+	fsp_upd->enable_sata = fdtdec_get_bool(blob, node, "fsp,enable-sata");
+	fsp_upd->sata_mode = fdtdec_get_int(blob, node, "fsp,sata-mode", 1);
+	fsp_upd->enable_azalia = fdtdec_get_bool(blob, node,
+						 "fsp,enable-azalia");
+	fsp_upd->enable_xhci = fdtdec_get_bool(blob, node, "fsp,enable-xhci");
+	fsp_upd->enable_lpe = fdtdec_get_bool(blob, node, "fsp,enable-lpe");
+	fsp_upd->lpss_sio_enable_pci_mode = fdtdec_get_bool(blob, node,
+							    "fsp,lpss-sio-enable-pci-mode");
+	fsp_upd->enable_dma0 = fdtdec_get_bool(blob, node, "fsp,enable-dma0");
+	fsp_upd->enable_dma1 = fdtdec_get_bool(blob, node, "fsp,enable-dma1");
+	fsp_upd->enable_i2_c0 = fdtdec_get_bool(blob, node, "fsp,enable-i2c0");
+	fsp_upd->enable_i2_c1 = fdtdec_get_bool(blob, node, "fsp,enable-i2c1");
+	fsp_upd->enable_i2_c2 = fdtdec_get_bool(blob, node, "fsp,enable-i2c2");
+	fsp_upd->enable_i2_c3 = fdtdec_get_bool(blob, node, "fsp,enable-i2c3");
+	fsp_upd->enable_i2_c4 = fdtdec_get_bool(blob, node, "fsp,enable-i2c4");
+	fsp_upd->enable_i2_c5 = fdtdec_get_bool(blob, node, "fsp,enable-i2c5");
+	fsp_upd->enable_i2_c6 = fdtdec_get_bool(blob, node, "fsp,enable-i2c6");
+	fsp_upd->enable_pwm0 = fdtdec_get_bool(blob, node, "fsp,enable-pwm0");
+	fsp_upd->enable_pwm1 = fdtdec_get_bool(blob, node, "fsp,enable-pwm1");
+	fsp_upd->enable_hsi = fdtdec_get_bool(blob, node, "fsp,enable-hsi");
+	fsp_upd->igd_dvmt50_pre_alloc = fdtdec_get_int(blob, node,
+						       "fsp,igd-dvmt50-pre-alloc",
+						       2);
+	fsp_upd->aperture_size = fdtdec_get_int(blob, node, "fsp,aperture-size",
+						2);
+	fsp_upd->gtt_size = fdtdec_get_int(blob, node, "fsp,gtt-size", 2);
+	fsp_upd->serial_debug_port_address = fdtdec_get_int(blob, node,
+							    "fsp,serial-debug-port-address",
+							    0x3f8);
+	fsp_upd->serial_debug_port_type = fdtdec_get_int(blob, node,
+							 "fsp,serial-debug-port-type",
+							 1);
+	fsp_upd->mrc_debug_msg = fdtdec_get_bool(blob, node,
+						 "fsp,mrc-debug-msg");
+	fsp_upd->isp_enable = fdtdec_get_bool(blob, node, "fsp,isp-enable");
+	fsp_upd->scc_enable_pci_mode = fdtdec_get_bool(blob, node,
+						       "fsp,scc-enable-pci-mode");
+	fsp_upd->igd_render_standby = fdtdec_get_bool(blob, node,
+						      "fsp,igd-render-standby");
+	fsp_upd->txe_uma_enable = fdtdec_get_bool(blob, node,
+						  "fsp,txe-uma-enable");
+	fsp_upd->os_selection = fdtdec_get_int(blob, node, "fsp,os-selection", 4);
+	fsp_upd->emmc45_ddr50_enabled = fdtdec_get_bool(blob, node,
+							"fsp,emmc45-ddr50-enabled");
+	fsp_upd->emmc45_hs200_enabled = fdtdec_get_bool(blob, node,
+							"fsp,emmc45-hs200-enabled");
+	fsp_upd->emmc45_retune_timer_value = fdtdec_get_int(blob, node,
+							    "fsp,emmc45-retune-timer-value",
+							    8);
+	fsp_upd->enable_igd = fdtdec_get_bool(blob, node, "fsp,enable-igd");
 
 	mem = &fsp_upd->memory_params;
-	mem->enable_memory_down = 1;
-	mem->dram_speed = 1;
-	mem->dimm_width = 1;
-	mem->dimm_density = 2;
-	mem->dimm_tcl = 0xb;
-	mem->dimm_trpt_rcd = 0xb;
-	mem->dimm_twr = 0xc;
-	mem->dimm_twtr = 6;
-	mem->dimm_trrd = 6;
-	mem->dimm_trtp = 6;
-	mem->dimm_tfaw = 0x14;
+	mem->enable_memory_down = fdtdec_get_bool(blob, node,
+						  "fsp,enable-memory-down");
+	if (mem->enable_memory_down) {
+		node = fdtdec_next_compatible(blob, node,
+					      COMPAT_INTEL_BAYTRAIL_FSP_MDP);
+		if (node < 0) {
+			debug("%s: Cannot find FSP memory-down-params node\n",
+			      __func__);
+		} else {
+			mem->dram_speed = fdtdec_get_int(blob, node,
+							 "fsp,dram-speed",
+							 0x02);
+			mem->dram_type = fdtdec_get_int(blob, node,
+							"fsp,dram-type", 0x01);
+			mem->dimm_0_enable = fdtdec_get_bool(blob, node,
+							     "fsp,dimm-0-enable");
+			mem->dimm_1_enable = fdtdec_get_bool(blob, node,
+							     "fsp,dimm-1-enable");
+			mem->dimm_width = fdtdec_get_int(blob, node,
+							 "fsp,dimm-width",
+							 0x00);
+			mem->dimm_density = fdtdec_get_int(blob, node,
+							   "fsp,dimm-density",
+							   0x01);
+			mem->dimm_bus_width = fdtdec_get_int(blob, node,
+							     "fsp,dimm-bus-width",
+							     0x03);
+			mem->dimm_sides = fdtdec_get_int(blob, node,
+							 "fsp,dimm-sides",
+							 0x00);
+			mem->dimm_tcl = fdtdec_get_int(blob, node,
+						       "fsp,dimm-tcl", 0x09);
+			mem->dimm_trpt_rcd = fdtdec_get_int(blob, node,
+							    "fsp,dimm-trpt-rcd",
+							    0x09);
+			mem->dimm_twr = fdtdec_get_int(blob, node,
+						       "fsp,dimm-twr", 0x0A);
+			mem->dimm_twtr = fdtdec_get_int(blob, node,
+							"fsp,dimm-twtr", 0x05);
+			mem->dimm_trrd = fdtdec_get_int(blob, node,
+							"fsp,dimm-trrd", 0x04);
+			mem->dimm_trtp = fdtdec_get_int(blob, node,
+							"fsp,dimm-trtp", 0x05);
+			mem->dimm_tfaw = fdtdec_get_int(blob, node,
+							"fsp,dimm-tfaw", 0x14);
+		}
+	}
 }
diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index 9f8fa70..0ca7c3e 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -188,6 +188,46 @@
 		};
 	};
 
+	fsp {
+		compatible = "intel,baytrail-fsp";
+		fsp,mrc-init-tseg-size = <0>;
+		fsp,mrc-init-mmio-size = <0x800>;
+		fsp,mrc-init-spd-addr1 = <0xa0>;
+		fsp,mrc-init-spd-addr2 = <0xa2>;
+		fsp,emmc-boot-mode = <2>;
+		fsp,enable-sdio;
+		fsp,enable-sdcard;
+		fsp,enable-hsuart1;
+		fsp,enable-spi;
+		fsp,enable-sata;
+		fsp,sata-mode = <1>;
+		fsp,enable-xhci;
+		fsp,enable-lpe;
+		fsp,lpss-sio-enable-pci-mode;
+		fsp,enable-dma0;
+		fsp,enable-dma1;
+		fsp,enable-i2c0;
+		fsp,enable-i2c1;
+		fsp,enable-i2c2;
+		fsp,enable-i2c3;
+		fsp,enable-i2c4;
+		fsp,enable-i2c5;
+		fsp,enable-i2c6;
+		fsp,enable-pwm0;
+		fsp,enable-pwm1;
+		fsp,igd-dvmt50-pre-alloc = <2>;
+		fsp,aperture-size = <2>;
+		fsp,gtt-size = <2>;
+		fsp,serial-debug-port-address = <0x3f8>;
+		fsp,serial-debug-port-type = <1>;
+		fsp,mrc-debug-msg;
+		fsp,scc-enable-pci-mode;
+		fsp,os-selection = <4>;
+		fsp,emmc45-ddr50-enabled;
+		fsp,emmc45-retune-timer-value = <8>;
+		fsp,enable-igd;
+	};
+
 	microcode {
 		update at 0 {
 #include "microcode/m0230671117.dtsi"
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index 9527233..4c9e265 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -122,6 +122,64 @@
 			0x01000000 0x0 0x2000 0x2000 0 0xe000>;
 	};
 
+	fsp {
+		compatible = "intel,baytrail-fsp";
+		fsp,mrc-init-tseg-size = <0>;
+		fsp,mrc-init-mmio-size = <0x800>;
+		fsp,mrc-init-spd-addr1 = <0xa0>;
+		fsp,mrc-init-spd-addr2 = <0xa2>;
+		fsp,emmc-boot-mode = <2>;
+		fsp,enable-sdio;
+		fsp,enable-sdcard;
+		fsp,enable-hsuart1;
+		fsp,enable-spi;
+		fsp,enable-sata;
+		fsp,sata-mode = <1>;
+		fsp,enable-xhci;
+		fsp,enable-lpe;
+		fsp,lpss-sio-enable-pci-mode;
+		fsp,enable-dma0;
+		fsp,enable-dma1;
+		fsp,enable-i2c0;
+		fsp,enable-i2c1;
+		fsp,enable-i2c2;
+		fsp,enable-i2c3;
+		fsp,enable-i2c4;
+		fsp,enable-i2c5;
+		fsp,enable-i2c6;
+		fsp,enable-pwm0;
+		fsp,enable-pwm1;
+		fsp,igd-dvmt50-pre-alloc = <2>;
+		fsp,aperture-size = <2>;
+		fsp,gtt-size = <2>;
+		fsp,serial-debug-port-address = <0x3f8>;
+		fsp,serial-debug-port-type = <1>;
+		fsp,mrc-debug-msg;
+		fsp,scc-enable-pci-mode;
+		fsp,os-selection = <4>;
+		fsp,emmc45-ddr50-enabled;
+		fsp,emmc45-retune-timer-value = <8>;
+		fsp,enable-igd;
+		fsp,enable-memory-down;
+		fsp,memory-down-params {
+			compatible = "intel,baytrail-fsp-mdp";
+			fsp,dram-speed = <1>;
+			fsp,dram-type = <1>;
+			fsp,dimm-0-enable;
+			fsp,dimm-width = <1>;
+			fsp,dimm-density = <2>;
+			fsp,dimm-bus-width = <3>;
+			fsp,dimm-sides = <0>;
+			fsp,dimm-tcl = <0xb>;
+			fsp,dimm-trpt-rcd = <0xb>;
+			fsp,dimm-twr = <0xc>;
+			fsp,dimm-twtr = <6>;
+			fsp,dimm-trrd = <6>;
+			fsp,dimm-trtp = <6>;
+			fsp,dimm-tfaw = <0x14>;
+		};
+	};
+
 	spi {
 		#address-cells = <1>;
 		#size-cells = <0>;
diff --git a/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt b/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
new file mode 100644
index 0000000..b44b5b5
--- /dev/null
+++ b/doc/device-tree-bindings/misc/intel,baytrail-fsp.txt
@@ -0,0 +1,158 @@
+Intel Bay Trail FSP UPD Binding
+===============================
+
+The device tree node which describes the overriding of the Intel Bay Trail FSP
+UPD data for configuring the SoC.
+
+All properties can be found within the `upd-region` struct in
+arch/x86/include/asm/arch-baytrail/fsp/fsp_vpd.h, under the same names, and in
+Intel's FSP Binary Configuration Tool for Bay Trail.  This list of properties is
+matched up to Intel's E3800 FSPv4 release.
+
+# Boolean properties:
+
+- fsp,enable-sdio
+- fsp,enable-sdcard
+- fsp,enable-hsuart0
+- fsp,enable-hsuart1
+- fsp,enable-spi
+- fsp,enable-sata
+- fsp,enable-azalia
+- fsp,enable-xhci
+- fsp,enable-lpe
+- fsp,lpss-sio-enable-pci-mode
+- fsp,enable-dma0
+- fsp,enable-dma1
+- fsp,enable-i2-c0
+- fsp,enable-i2-c1
+- fsp,enable-i2-c2
+- fsp,enable-i2-c3
+- fsp,enable-i2-c4
+- fsp,enable-i2-c5
+- fsp,enable-i2-c6
+- fsp,enable-pwm0
+- fsp,enable-pwm1
+- fsp,enable-hsi
+- fsp,mrc-debug-msg
+- fsp,isp-enable
+- fsp,scc-enable-pci-mode
+- fsp,igd-render-standby
+- fsp,txe-uma-enable
+- fsp,emmc45-ddr50-enabled
+- fsp,emmc45-hs200-enabled
+- fsp,enable-igd
+- fsp,enable-memory-down
+
+If you set "fsp,enable-memory-down" you are strongly encouraged to provide an
+"fsp,memory-down-params{};" to specify how your memory is configured.  If you do
+not set "fsp,enable-memory-down", then the DIMM SPD information will be
+discovered by the FSP and used to setup main memory.
+
+
+# Integer properties:
+
+- fsp,mrc-init-tseg-size
+- fsp,mrc-init-mmio-size
+- fsp,mrc-init-spd-addr1
+- fsp,mrc-init-spd-addr2
+- fsp,emmc-boot-mode
+- fsp,sata-mode
+- fsp,igd-dvmt50-pre-alloc
+- fsp,aperture-size
+- fsp,gtt-size
+- fsp,serial-debug-port-address
+- fsp,serial-debug-port-type
+- fsp,os-selection
+- fsp,emmc45-retune-timer-value
+
+- fsp,memory-down-params {
+
+	# Boolean properties:
+
+	- fsp,dimm-0-enable
+	- fsp,dimm-1-enable
+
+	# Integer properties:
+
+	- fsp,dram-speed
+	- fsp,dram-type
+	- fsp,dimm-width
+	- fsp,dimm-density
+	- fsp,dimm-bus-width
+	- fsp,dimm-sides
+	- fsp,dimm-tcl
+	- fsp,dimm-trpt-rcd
+	- fsp,dimm-twr
+	- fsp,dimm-twtr
+	- fsp,dimm-trrd
+	- fsp,dimm-trtp
+	- fsp,dimm-tfaw
+};
+
+
+Example (from MinnowMax Dual Core):
+-----------------------------------
+
+/ {
+	...
+
+	fsp {
+		compatible = "intel,baytrail-fsp";
+		fsp,mrc-init-tseg-size = <0>;
+		fsp,mrc-init-mmio-size = <0x800>;
+		fsp,mrc-init-spd-addr1 = <0xa0>;
+		fsp,mrc-init-spd-addr2 = <0xa2>;
+		fsp,emmc-boot-mode = <2>;
+		fsp,enable-sdio;
+		fsp,enable-sdcard;
+		fsp,enable-hsuart1;
+		fsp,enable-spi;
+		fsp,enable-sata;
+		fsp,sata-mode = <1>;
+		fsp,enable-xhci;
+		fsp,enable-lpe;
+		fsp,lpss-sio-enable-pci-mode;
+		fsp,enable-dma0;
+		fsp,enable-dma1;
+		fsp,enable-i2c0;
+		fsp,enable-i2c1;
+		fsp,enable-i2c2;
+		fsp,enable-i2c3;
+		fsp,enable-i2c4;
+		fsp,enable-i2c5;
+		fsp,enable-i2c6;
+		fsp,enable-pwm0;
+		fsp,enable-pwm1;
+		fsp,igd-dvmt50-pre-alloc = <2>;
+		fsp,aperture-size = <2>;
+		fsp,gtt-size = <2>;
+		fsp,serial-debug-port-address = <0x3f8>;
+		fsp,serial-debug-port-type = <1>;
+		fsp,mrc-debug-msg;
+		fsp,scc-enable-pci-mode;
+		fsp,os-selection = <4>;
+		fsp,emmc45-ddr50-enabled;
+		fsp,emmc45-retune-timer-value = <8>;
+		fsp,enable-igd;
+		fsp,enable-memory-down;
+		fsp,memory-down-params {
+			compatible = "intel,baytrail-fsp-mdp";
+			fsp,dram-speed = <1>;
+			fsp,dram-type = <1>;
+			fsp,dimm-0-enable;
+			fsp,dimm-width = <1>;
+			fsp,dimm-density = <2>;
+			fsp,dimm-bus-width = <3>;
+			fsp,dimm-sides = <0>;
+			fsp,dimm-tcl = <0xb>;
+			fsp,dimm-trpt-rcd = <0xb>;
+			fsp,dimm-twr = <0xc>;
+			fsp,dimm-twtr = <6>;
+			fsp,dimm-trrd = <6>;
+			fsp,dimm-trtp = <6>;
+			fsp,dimm-tfaw = <0x14>;
+		};
+	};
+
+	...
+};
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 4b3f8d1..987d51a 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -186,6 +186,8 @@ enum fdt_compat_id {
 	COMPAT_SOCIONEXT_XHCI,		/* Socionext UniPhier xHCI */
 	COMPAT_INTEL_PCH,		/* Intel PCH */
 	COMPAT_INTEL_IRQ_ROUTER,	/* Intel Interrupt Router */
+	COMPAT_INTEL_BAYTRAIL_FSP,	/* Intel Bay Trail FSP */
+	COMPAT_INTEL_BAYTRAIL_FSP_MDP,	/* Intel Bay Trail FSP memory-down params */
 
 	COMPAT_COUNT,
 };
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 48667ef..42e8a8b 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -78,6 +78,8 @@ static const char * const compat_names[COMPAT_COUNT] = {
 	COMPAT(SOCIONEXT_XHCI, "socionext,uniphier-xhci"),
 	COMPAT(COMPAT_INTEL_PCH, "intel,bd82x6x"),
 	COMPAT(COMPAT_INTEL_IRQ_ROUTER, "intel,irq-router"),
+	COMPAT(COMPAT_INTEL_BAYTRAIL_FSP, "intel,baytrail-fsp"),
+	COMPAT(COMPAT_INTEL_BAYTRAIL_FSP_MDP, "intel,baytrail-fsp-mdp"),
 };
 
 const char *fdtdec_get_compatible(enum fdt_compat_id id)
-- 
1.9.1

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng]

On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
<andrew@bradfordembedded.com> wrote:
> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>
> Allow for configuration of FSP UPD from the device tree which will
> override any settings which the FSP was built with itself.
>
> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
> settings from the Intel FSPv4 Gold release to the respective dts files,
> with the condition that the memory-down parameters for MinnowMax are
> also used.
>
> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
> ---
>

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>

[snip]

Regards,
Bin

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi,

On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
> <andrew@bradfordembedded.com> wrote:
>> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>
>> Allow for configuration of FSP UPD from the device tree which will
>> override any settings which the FSP was built with itself.
>>
>> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>> settings from the Intel FSPv4 Gold release to the respective dts files,
>> with the condition that the memory-down parameters for MinnowMax are
>> also used.
>>
>> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> ---
>>
>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>

Acked-by: Simon Glass <sjg@chromium.org>
Tested on minnowmax:
Tested-by: Simon Glass <sjg@chromium.org>

I found that I need to remove two properties from the minnowmax.dts:

- fsp,enable-xhci needs to be removed as this does not work in U-Boot
at present and stops EHCI from working
- fsp,mrc-debug-msg needs to be removed to prevent debug information
being displayed

I plan to apply this with these changes - please let me know if this
doesn't suit.

Regards,
Simon

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Andrew Bradford]

Hi Simon,

On 08/08 10:18, Simon Glass wrote:
> Hi,
> 
> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
> > <andrew@bradfordembedded.com> wrote:
> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >>
> >> Allow for configuration of FSP UPD from the device tree which will
> >> override any settings which the FSP was built with itself.
> >>
> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
> >> settings from the Intel FSPv4 Gold release to the respective dts files,
> >> with the condition that the memory-down parameters for MinnowMax are
> >> also used.
> >>
> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >> ---
> >>
> >
> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
> >
> 
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested on minnowmax:
> Tested-by: Simon Glass <sjg@chromium.org>
> 
> I found that I need to remove two properties from the minnowmax.dts:
> 
> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
> at present and stops EHCI from working
> - fsp,mrc-debug-msg needs to be removed to prevent debug information
> being displayed
> 
> I plan to apply this with these changes - please let me know if this
> doesn't suit.

I'm OK with disabling xhci and the MRC debug output in the FSP.

But if xhci is disabled then I believe when Linux boots that the USB 3.0
port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
yet have working XHCI on E3800 means there is a tradeoff and I wasn't
sure which was a better choice.

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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng]

Hi Simon,

On Sun, Aug 9, 2015 at 12:18 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi,
>
> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>> <andrew@bradfordembedded.com> wrote:
>>> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>
>>> Allow for configuration of FSP UPD from the device tree which will
>>> override any settings which the FSP was built with itself.
>>>
>>> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>> settings from the Intel FSPv4 Gold release to the respective dts files,
>>> with the condition that the memory-down parameters for MinnowMax are
>>> also used.
>>>
>>> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>> ---
>>>
>>
>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>
>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested on minnowmax:
> Tested-by: Simon Glass <sjg@chromium.org>
>
> I found that I need to remove two properties from the minnowmax.dts:
>
> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
> at present and stops EHCI from working

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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng]

Hi Andrew,

On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
<andrew@bradfordembedded.com> wrote:
> Hi Simon,
>
> On 08/08 10:18, Simon Glass wrote:
>> Hi,
>>
>> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>> > <andrew@bradfordembedded.com> wrote:
>> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> >>
>> >> Allow for configuration of FSP UPD from the device tree which will
>> >> override any settings which the FSP was built with itself.
>> >>
>> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>> >> with the condition that the memory-down parameters for MinnowMax are
>> >> also used.
>> >>
>> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> >> ---
>> >>
>> >
>> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>> >
>>
>> Acked-by: Simon Glass <sjg@chromium.org>
>> Tested on minnowmax:
>> Tested-by: Simon Glass <sjg@chromium.org>
>>
>> I found that I need to remove two properties from the minnowmax.dts:
>>
>> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>> at present and stops EHCI from working
>> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>> being displayed
>>
>> I plan to apply this with these changes - please let me know if this
>> doesn't suit.
>
> I'm OK with disabling xhci and the MRC debug output in the FSP.
>
> But if xhci is disabled then I believe when Linux boots that the USB 3.0
> port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
> yet have working XHCI on E3800 means there is a tradeoff and I wasn't
> sure which was a better choice.

Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
works, I'd rather we keep fsp,enable-xhci in the U-Boot.

>
> I 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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Andrew Bradford]

Hi Bin,

On 08/09 10:52, Bin Meng wrote:
> Hi Andrew,
> 
> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
> <andrew@bradfordembedded.com> wrote:
> > Hi Simon,
> >
> > On 08/08 10:18, Simon Glass wrote:
> >> Hi,
> >>
> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
> >> > <andrew@bradfordembedded.com> wrote:
> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >> >>
> >> >> Allow for configuration of FSP UPD from the device tree which will
> >> >> override any settings which the FSP was built with itself.
> >> >>
> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
> >> >> with the condition that the memory-down parameters for MinnowMax are
> >> >> also used.
> >> >>
> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >> >> ---
> >> >>
> >> >
> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
> >> >
> >>
> >> Acked-by: Simon Glass <sjg@chromium.org>
> >> Tested on minnowmax:
> >> Tested-by: Simon Glass <sjg@chromium.org>
> >>
> >> I found that I need to remove two properties from the minnowmax.dts:
> >>
> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
> >> at present and stops EHCI from working
> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
> >> being displayed
> >>
> >> I plan to apply this with these changes - please let me know if this
> >> doesn't suit.
> >
> > I'm OK with disabling xhci and the MRC debug output in the FSP.
> >
> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
> > sure which was a better choice.
> 
> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
> works, I'd rather we keep fsp,enable-xhci in the U-Boot.

I believe that the xhci port does work on Minnow Max in Linux but I do
not have a board so I'm unable to test, sorry.

Thanks,
Andrew

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng]

Hi Andrew,

On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
<andrew@bradfordembedded.com> wrote:
> Hi Bin,
>
> On 08/09 10:52, Bin Meng wrote:
>> Hi Andrew,
>>
>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>> <andrew@bradfordembedded.com> wrote:
>> > Hi Simon,
>> >
>> > On 08/08 10:18, Simon Glass wrote:
>> >> Hi,
>> >>
>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>> >> > <andrew@bradfordembedded.com> wrote:
>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> >> >>
>> >> >> Allow for configuration of FSP UPD from the device tree which will
>> >> >> override any settings which the FSP was built with itself.
>> >> >>
>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>> >> >> with the condition that the memory-down parameters for MinnowMax are
>> >> >> also used.
>> >> >>
>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> >> >> ---
>> >> >>
>> >> >
>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>> >> >
>> >>
>> >> Acked-by: Simon Glass <sjg@chromium.org>
>> >> Tested on minnowmax:
>> >> Tested-by: Simon Glass <sjg@chromium.org>
>> >>
>> >> I found that I need to remove two properties from the minnowmax.dts:
>> >>
>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>> >> at present and stops EHCI from working
>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>> >> being displayed
>> >>
>> >> I plan to apply this with these changes - please let me know if this
>> >> doesn't suit.
>> >
>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>> >
>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>> > sure which was a better choice.
>>
>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>
> I believe that the xhci port does work on Minnow Max in Linux but I do
> not have a board so I'm unable to test, sorry.
>

OK, my test shows that ehci works fine in U-Boot on Bayley Bay.

Hi Simon,

What do you think regarding to xhci vs. ehci in U-Boot?

Regards,
Bin

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Bin,

On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Andrew,
>
> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
> <andrew@bradfordembedded.com> wrote:
>> Hi Bin,
>>
>> On 08/09 10:52, Bin Meng wrote:
>>> Hi Andrew,
>>>
>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>> <andrew@bradfordembedded.com> wrote:
>>> > Hi Simon,
>>> >
>>> > On 08/08 10:18, Simon Glass wrote:
>>> >> Hi,
>>> >>
>>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>> >> > <andrew@bradfordembedded.com> wrote:
>>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>> >> >>
>>> >> >> Allow for configuration of FSP UPD from the device tree which will
>>> >> >> override any settings which the FSP was built with itself.
>>> >> >>
>>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>>> >> >> with the condition that the memory-down parameters for MinnowMax are
>>> >> >> also used.
>>> >> >>
>>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>> >> >> ---
>>> >> >>
>>> >> >
>>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>> >> >
>>> >>
>>> >> Acked-by: Simon Glass <sjg@chromium.org>
>>> >> Tested on minnowmax:
>>> >> Tested-by: Simon Glass <sjg@chromium.org>
>>> >>
>>> >> I found that I need to remove two properties from the minnowmax.dts:
>>> >>
>>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>> >> at present and stops EHCI from working
>>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>> >> being displayed
>>> >>
>>> >> I plan to apply this with these changes - please let me know if this
>>> >> doesn't suit.
>>> >
>>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>>> >
>>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>> > sure which was a better choice.
>>>
>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>
>> I believe that the xhci port does work on Minnow Max in Linux but I do
>> not have a board so I'm unable to test, sorry.
>>
>
> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>
> Hi Simon,
>
> What do you think regarding to xhci vs. ehci in U-Boot?

The problem is that USB is then broken in U-Boot. I think it is better
to limit the speed for the moment until we have that fixed. It is
quite useful to be able to use a keyboard or USB stick in U-Boot.

With my testing the bottom (blue) port works fine but the top port
does not. This happens regardless of the xhci setting.

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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng]

Hi Simon,

On Tue, Aug 11, 2015 at 11:07 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Andrew,
>>
>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>> <andrew@bradfordembedded.com> wrote:
>>> Hi Bin,
>>>
>>> On 08/09 10:52, Bin Meng wrote:
>>>> Hi Andrew,
>>>>
>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>> <andrew@bradfordembedded.com> wrote:
>>>> > Hi Simon,
>>>> >
>>>> > On 08/08 10:18, Simon Glass wrote:
>>>> >> Hi,
>>>> >>
>>>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>> >> > <andrew@bradfordembedded.com> wrote:
>>>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>> >> >>
>>>> >> >> Allow for configuration of FSP UPD from the device tree which will
>>>> >> >> override any settings which the FSP was built with itself.
>>>> >> >>
>>>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>> >> >> with the condition that the memory-down parameters for MinnowMax are
>>>> >> >> also used.
>>>> >> >>
>>>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>> >> >> ---
>>>> >> >>
>>>> >> >
>>>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>> >> >
>>>> >>
>>>> >> Acked-by: Simon Glass <sjg@chromium.org>
>>>> >> Tested on minnowmax:
>>>> >> Tested-by: Simon Glass <sjg@chromium.org>
>>>> >>
>>>> >> I found that I need to remove two properties from the minnowmax.dts:
>>>> >>
>>>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>> >> at present and stops EHCI from working
>>>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>> >> being displayed
>>>> >>
>>>> >> I plan to apply this with these changes - please let me know if this
>>>> >> doesn't suit.
>>>> >
>>>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>> >
>>>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>>>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>> > sure which was a better choice.
>>>>
>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>
>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>> not have a board so I'm unable to test, sorry.
>>>
>>
>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>
>> Hi Simon,
>>
>> What do you think regarding to xhci vs. ehci in U-Boot?
>
> The problem is that USB is then broken in U-Boot. I think it is better
> to limit the speed for the moment until we have that fixed. It is
> quite useful to be able to use a keyboard or USB stick in U-Boot.
>
> With my testing the bottom (blue) port works fine but the top port
> does not. This happens regardless of the xhci setting.

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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Bin,

On 10 August 2015 at 21:17, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Tue, Aug 11, 2015 at 11:07 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Andrew,
>>>
>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>> <andrew@bradfordembedded.com> wrote:
>>>> Hi Bin,
>>>>
>>>> On 08/09 10:52, Bin Meng wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>>> <andrew@bradfordembedded.com> wrote:
>>>>> > Hi Simon,
>>>>> >
>>>>> > On 08/08 10:18, Simon Glass wrote:
>>>>> >> Hi,
>>>>> >>
>>>>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>>> >> > <andrew@bradfordembedded.com> wrote:
>>>>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>> >> >>
>>>>> >> >> Allow for configuration of FSP UPD from the device tree which will
>>>>> >> >> override any settings which the FSP was built with itself.
>>>>> >> >>
>>>>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>>> >> >> with the condition that the memory-down parameters for MinnowMax are
>>>>> >> >> also used.
>>>>> >> >>
>>>>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>> >> >> ---
>>>>> >> >>
>>>>> >> >
>>>>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>>> >> >
>>>>> >>
>>>>> >> Acked-by: Simon Glass <sjg@chromium.org>
>>>>> >> Tested on minnowmax:
>>>>> >> Tested-by: Simon Glass <sjg@chromium.org>
>>>>> >>
>>>>> >> I found that I need to remove two properties from the minnowmax.dts:
>>>>> >>
>>>>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>>> >> at present and stops EHCI from working
>>>>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>>> >> being displayed
>>>>> >>
>>>>> >> I plan to apply this with these changes - please let me know if this
>>>>> >> doesn't suit.
>>>>> >
>>>>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>>> >
>>>>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>>>>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>>> > sure which was a better choice.
>>>>>
>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>>
>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>>> not have a board so I'm unable to test, sorry.
>>>>
>>>
>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>
>>> Hi Simon,
>>>
>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>
>> The problem is that USB is then broken in U-Boot. I think it is better
>> to limit the speed for the moment until we have that fixed. It is
>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>
>> With my testing the bottom (blue) port works fine but the top port
>> does not. This happens regardless of the xhci setting.
>
> 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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng]

Hi Simon,

On Tue, Aug 11, 2015 at 11:24 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 10 August 2015 at 21:17, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Tue, Aug 11, 2015 at 11:07 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Andrew,
>>>>
>>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>>> <andrew@bradfordembedded.com> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 08/09 10:52, Bin Meng wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>> > Hi Simon,
>>>>>> >
>>>>>> > On 08/08 10:18, Simon Glass wrote:
>>>>>> >> Hi,
>>>>>> >>
>>>>>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>>>> >> > <andrew@bradfordembedded.com> wrote:
>>>>>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>> >> >>
>>>>>> >> >> Allow for configuration of FSP UPD from the device tree which will
>>>>>> >> >> override any settings which the FSP was built with itself.
>>>>>> >> >>
>>>>>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>>>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>>>> >> >> with the condition that the memory-down parameters for MinnowMax are
>>>>>> >> >> also used.
>>>>>> >> >>
>>>>>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>> >> >> ---
>>>>>> >> >>
>>>>>> >> >
>>>>>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>> >> >
>>>>>> >>
>>>>>> >> Acked-by: Simon Glass <sjg@chromium.org>
>>>>>> >> Tested on minnowmax:
>>>>>> >> Tested-by: Simon Glass <sjg@chromium.org>
>>>>>> >>
>>>>>> >> I found that I need to remove two properties from the minnowmax.dts:
>>>>>> >>
>>>>>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>>>> >> at present and stops EHCI from working
>>>>>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>>>> >> being displayed
>>>>>> >>
>>>>>> >> I plan to apply this with these changes - please let me know if this
>>>>>> >> doesn't suit.
>>>>>> >
>>>>>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>>>> >
>>>>>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>>>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>>>>>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>>>> > sure which was a better choice.
>>>>>>
>>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>>>
>>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>>>> not have a board so I'm unable to test, sorry.
>>>>>
>>>>
>>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>>
>>>> Hi Simon,
>>>>
>>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>>
>>> The problem is that USB is then broken in U-Boot. I think it is better
>>> to limit the speed for the moment until we have that fixed. It is
>>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>>
>>> With my testing the bottom (blue) port works fine but the top port
>>> does not. This happens regardless of the xhci setting.
>>
>> 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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Bin,

On 10 August 2015 at 21:31, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Tue, Aug 11, 2015 at 11:24 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 10 August 2015 at 21:17, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Tue, Aug 11, 2015 at 11:07 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 08/09 10:52, Bin Meng wrote:
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>> > Hi Simon,
>>>>>>> >
>>>>>>> > On 08/08 10:18, Simon Glass wrote:
>>>>>>> >> Hi,
>>>>>>> >>
>>>>>>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>>>>> >> > <andrew@bradfordembedded.com> wrote:
>>>>>>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>>> >> >>
>>>>>>> >> >> Allow for configuration of FSP UPD from the device tree which will
>>>>>>> >> >> override any settings which the FSP was built with itself.
>>>>>>> >> >>
>>>>>>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>>>>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>>>>> >> >> with the condition that the memory-down parameters for MinnowMax are
>>>>>>> >> >> also used.
>>>>>>> >> >>
>>>>>>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>>> >> >> ---
>>>>>>> >> >>
>>>>>>> >> >
>>>>>>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >> Acked-by: Simon Glass <sjg@chromium.org>
>>>>>>> >> Tested on minnowmax:
>>>>>>> >> Tested-by: Simon Glass <sjg@chromium.org>
>>>>>>> >>
>>>>>>> >> I found that I need to remove two properties from the minnowmax.dts:
>>>>>>> >>
>>>>>>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>>>>> >> at present and stops EHCI from working
>>>>>>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>>>>> >> being displayed
>>>>>>> >>
>>>>>>> >> I plan to apply this with these changes - please let me know if this
>>>>>>> >> doesn't suit.
>>>>>>> >
>>>>>>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>>>>> >
>>>>>>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>>>>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>>>>>>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>>>>> > sure which was a better choice.
>>>>>>>
>>>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>>>>
>>>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>>>>> not have a board so I'm unable to test, sorry.
>>>>>>
>>>>>
>>>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>>>
>>>> The problem is that USB is then broken in U-Boot. I think it is better
>>>> to limit the speed for the moment until we have that fixed. It is
>>>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>>>
>>>> With my testing the bottom (blue) port works fine but the top port
>>>> does not. This happens regardless of the xhci setting.
>>>
>>> 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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Andrew Bradford]

Hi Simon,

On 08/10 21:07, Simon Glass wrote:
> Hi Bin,
> 
> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
> > Hi Andrew,
> >
> > On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
> > <andrew@bradfordembedded.com> wrote:
> >> Hi Bin,
> >>
> >> On 08/09 10:52, Bin Meng wrote:
> >>> Hi Andrew,
> >>>
> >>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
> >>> <andrew@bradfordembedded.com> wrote:
> >>> > Hi Simon,
> >>> >
> >>> > On 08/08 10:18, Simon Glass wrote:
> >>> >> Hi,
> >>> >>
> >>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
> >>> >> > <andrew@bradfordembedded.com> wrote:
> >>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >>> >> >>
> >>> >> >> Allow for configuration of FSP UPD from the device tree which will
> >>> >> >> override any settings which the FSP was built with itself.
> >>> >> >>
> >>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
> >>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
> >>> >> >> with the condition that the memory-down parameters for MinnowMax are
> >>> >> >> also used.
> >>> >> >>
> >>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >>> >> >> ---
> >>> >> >>
> >>> >> >
> >>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
> >>> >> >
> >>> >>
> >>> >> Acked-by: Simon Glass <sjg@chromium.org>
> >>> >> Tested on minnowmax:
> >>> >> Tested-by: Simon Glass <sjg@chromium.org>
> >>> >>
> >>> >> I found that I need to remove two properties from the minnowmax.dts:
> >>> >>
> >>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
> >>> >> at present and stops EHCI from working
> >>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
> >>> >> being displayed
> >>> >>
> >>> >> I plan to apply this with these changes - please let me know if this
> >>> >> doesn't suit.
> >>> >
> >>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
> >>> >
> >>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
> >>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
> >>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
> >>> > sure which was a better choice.
> >>>
> >>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
> >>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
> >>
> >> I believe that the xhci port does work on Minnow Max in Linux but I do
> >> not have a board so I'm unable to test, sorry.
> >>
> >
> > OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
> >
> > Hi Simon,
> >
> > What do you think regarding to xhci vs. ehci in U-Boot?
> 
> The problem is that USB is then broken in U-Boot. I think it is better
> to limit the speed for the moment until we have that fixed. It is
> quite useful to be able to use a keyboard or USB stick in U-Boot.
> 
> With my testing the bottom (blue) port works fine but the top port
> does not. This happens regardless of the xhci setting.

Minnowmax has a USB power switch enable which determines if the VBUS2
net is turned on or not, which will supply or not supply power to the
USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
and the USB ports themselves are located on page 16 of the schematic
that I have.

The switches to enable the VBUS for each port are active high and pulled
down.  So to turn them on, I believe that's the point of the pinmuxing
and GPIO settings which are used in the minnowmax.dts.  Can you verify
if these are correctly turning on VBUS2 (since it sounds like they are
turning on VBUS1)?  If not, when you turn these GPIO on manually, does
the USB 2.0 port work correctly?

> 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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Andrew Bradford]

Hi Simon,

On 08/10 21:39, Simon Glass wrote:
> Hi Bin,
> 
> On 10 August 2015 at 21:31, Bin Meng <bmeng.cn@gmail.com> wrote:
> > Hi Simon,
> >
> > On Tue, Aug 11, 2015 at 11:24 AM, Simon Glass <sjg@chromium.org> wrote:
> >> Hi Bin,
> >>
> >> On 10 August 2015 at 21:17, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>> Hi Simon,
> >>>
> >>> On Tue, Aug 11, 2015 at 11:07 AM, Simon Glass <sjg@chromium.org> wrote:
> >>>> Hi Bin,
> >>>>
> >>>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>> Hi Andrew,
> >>>>>
> >>>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
> >>>>> <andrew@bradfordembedded.com> wrote:
> >>>>>> Hi Bin,
> >>>>>>
> >>>>>> On 08/09 10:52, Bin Meng wrote:
> >>>>>>> Hi Andrew,
> >>>>>>>
> >>>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
> >>>>>>> <andrew@bradfordembedded.com> wrote:
> >>>>>>> > Hi Simon,
> >>>>>>> >
> >>>>>>> > On 08/08 10:18, Simon Glass wrote:
> >>>>>>> >> Hi,
> >>>>>>> >>
> >>>>>>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>>>>>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
> >>>>>>> >> > <andrew@bradfordembedded.com> wrote:
> >>>>>>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >>>>>>> >> >>
> >>>>>>> >> >> Allow for configuration of FSP UPD from the device tree which will
> >>>>>>> >> >> override any settings which the FSP was built with itself.
> >>>>>>> >> >>
> >>>>>>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
> >>>>>>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
> >>>>>>> >> >> with the condition that the memory-down parameters for MinnowMax are
> >>>>>>> >> >> also used.
> >>>>>>> >> >>
> >>>>>>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >>>>>>> >> >> ---
> >>>>>>> >> >>
> >>>>>>> >> >
> >>>>>>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >>>>>>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>> >> Acked-by: Simon Glass <sjg@chromium.org>
> >>>>>>> >> Tested on minnowmax:
> >>>>>>> >> Tested-by: Simon Glass <sjg@chromium.org>
> >>>>>>> >>
> >>>>>>> >> I found that I need to remove two properties from the minnowmax.dts:
> >>>>>>> >>
> >>>>>>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
> >>>>>>> >> at present and stops EHCI from working
> >>>>>>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
> >>>>>>> >> being displayed
> >>>>>>> >>
> >>>>>>> >> I plan to apply this with these changes - please let me know if this
> >>>>>>> >> doesn't suit.
> >>>>>>> >
> >>>>>>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
> >>>>>>> >
> >>>>>>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
> >>>>>>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
> >>>>>>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
> >>>>>>> > sure which was a better choice.
> >>>>>>>
> >>>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
> >>>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
> >>>>>>
> >>>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
> >>>>>> not have a board so I'm unable to test, sorry.
> >>>>>>
> >>>>>
> >>>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
> >>>>>
> >>>>> Hi Simon,
> >>>>>
> >>>>> What do you think regarding to xhci vs. ehci in U-Boot?
> >>>>
> >>>> The problem is that USB is then broken in U-Boot. I think it is better
> >>>> to limit the speed for the moment until we have that fixed. It is
> >>>> quite useful to be able to use a keyboard or USB stick in U-Boot.
> >>>>
> >>>> With my testing the bottom (blue) port works fine but the top port
> >>>> does not. This happens regardless of the xhci setting.
> >>>
> >>> 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.

Thanks, looks good! :)
-Andrew

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Andrew,

On 11 August 2015 at 06:08, Andrew Bradford <andrew@bradfordembedded.com> wrote:
> Hi Simon,
>
> On 08/10 21:07, Simon Glass wrote:
>> Hi Bin,
>>
>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>> > Hi Andrew,
>> >
>> > On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>> > <andrew@bradfordembedded.com> wrote:
>> >> Hi Bin,
>> >>
>> >> On 08/09 10:52, Bin Meng wrote:
>> >>> Hi Andrew,
>> >>>
>> >>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>> >>> <andrew@bradfordembedded.com> wrote:
>> >>> > Hi Simon,
>> >>> >
>> >>> > On 08/08 10:18, Simon Glass wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>> >>> >> > <andrew@bradfordembedded.com> wrote:
>> >>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> >>> >> >>
>> >>> >> >> Allow for configuration of FSP UPD from the device tree which will
>> >>> >> >> override any settings which the FSP was built with itself.
>> >>> >> >>
>> >>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>> >>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>> >>> >> >> with the condition that the memory-down parameters for MinnowMax are
>> >>> >> >> also used.
>> >>> >> >>
>> >>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> >>> >> >> ---
>> >>> >> >>
>> >>> >> >
>> >>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>> >>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>> >>> >> >
>> >>> >>
>> >>> >> Acked-by: Simon Glass <sjg@chromium.org>
>> >>> >> Tested on minnowmax:
>> >>> >> Tested-by: Simon Glass <sjg@chromium.org>
>> >>> >>
>> >>> >> I found that I need to remove two properties from the minnowmax.dts:
>> >>> >>
>> >>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>> >>> >> at present and stops EHCI from working
>> >>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>> >>> >> being displayed
>> >>> >>
>> >>> >> I plan to apply this with these changes - please let me know if this
>> >>> >> doesn't suit.
>> >>> >
>> >>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>> >>> >
>> >>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>> >>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>> >>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>> >>> > sure which was a better choice.
>> >>>
>> >>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>> >>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>> >>
>> >> I believe that the xhci port does work on Minnow Max in Linux but I do
>> >> not have a board so I'm unable to test, sorry.
>> >>
>> >
>> > OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>> >
>> > Hi Simon,
>> >
>> > What do you think regarding to xhci vs. ehci in U-Boot?
>>
>> The problem is that USB is then broken in U-Boot. I think it is better
>> to limit the speed for the moment until we have that fixed. It is
>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>
>> With my testing the bottom (blue) port works fine but the top port
>> does not. This happens regardless of the xhci setting.
>
> Minnowmax has a USB power switch enable which determines if the VBUS2
> net is turned on or not, which will supply or not supply power to the
> USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
> and the USB ports themselves are located on page 16 of the schematic
> that I have.
>
> The switches to enable the VBUS for each port are active high and pulled
> down.  So to turn them on, I believe that's the point of the pinmuxing
> and GPIO settings which are used in the minnowmax.dts.  Can you verify
> if these are correctly turning on VBUS2 (since it sounds like they are
> turning on VBUS1)?  If not, when you turn these GPIO on manually, does
> the USB 2.0 port work correctly?

I see power on the bottom port but not the top one.

>
>> 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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Andrew Bradford]

Hi Simon,

On 08/11 08:06, Simon Glass wrote:
> Hi Andrew,
> 
> On 11 August 2015 at 06:08, Andrew Bradford <andrew@bradfordembedded.com> wrote:
> > Hi Simon,
> >
> > On 08/10 21:07, Simon Glass wrote:
> >> Hi Bin,
> >>
> >> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> > Hi Andrew,
> >> >
> >> > On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
> >> > <andrew@bradfordembedded.com> wrote:
> >> >> Hi Bin,
> >> >>
> >> >> On 08/09 10:52, Bin Meng wrote:
> >> >>> Hi Andrew,
> >> >>>
> >> >>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
> >> >>> <andrew@bradfordembedded.com> wrote:
> >> >>> > Hi Simon,
> >> >>> >
> >> >>> > On 08/08 10:18, Simon Glass wrote:
> >> >>> >> Hi,
> >> >>> >>
> >> >>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
> >> >>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
> >> >>> >> > <andrew@bradfordembedded.com> wrote:
> >> >>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >> >>> >> >>
> >> >>> >> >> Allow for configuration of FSP UPD from the device tree which will
> >> >>> >> >> override any settings which the FSP was built with itself.
> >> >>> >> >>
> >> >>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
> >> >>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
> >> >>> >> >> with the condition that the memory-down parameters for MinnowMax are
> >> >>> >> >> also used.
> >> >>> >> >>
> >> >>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
> >> >>> >> >> ---
> >> >>> >> >>
> >> >>> >> >
> >> >>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >> >>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
> >> >>> >> >
> >> >>> >>
> >> >>> >> Acked-by: Simon Glass <sjg@chromium.org>
> >> >>> >> Tested on minnowmax:
> >> >>> >> Tested-by: Simon Glass <sjg@chromium.org>
> >> >>> >>
> >> >>> >> I found that I need to remove two properties from the minnowmax.dts:
> >> >>> >>
> >> >>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
> >> >>> >> at present and stops EHCI from working
> >> >>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
> >> >>> >> being displayed
> >> >>> >>
> >> >>> >> I plan to apply this with these changes - please let me know if this
> >> >>> >> doesn't suit.
> >> >>> >
> >> >>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
> >> >>> >
> >> >>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
> >> >>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
> >> >>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
> >> >>> > sure which was a better choice.
> >> >>>
> >> >>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
> >> >>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
> >> >>
> >> >> I believe that the xhci port does work on Minnow Max in Linux but I do
> >> >> not have a board so I'm unable to test, sorry.
> >> >>
> >> >
> >> > OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
> >> >
> >> > Hi Simon,
> >> >
> >> > What do you think regarding to xhci vs. ehci in U-Boot?
> >>
> >> The problem is that USB is then broken in U-Boot. I think it is better
> >> to limit the speed for the moment until we have that fixed. It is
> >> quite useful to be able to use a keyboard or USB stick in U-Boot.
> >>
> >> With my testing the bottom (blue) port works fine but the top port
> >> does not. This happens regardless of the xhci setting.
> >
> > Minnowmax has a USB power switch enable which determines if the VBUS2
> > net is turned on or not, which will supply or not supply power to the
> > USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
> > and the USB ports themselves are located on page 16 of the schematic
> > that I have.
> >
> > The switches to enable the VBUS for each port are active high and pulled
> > down.  So to turn them on, I believe that's the point of the pinmuxing
> > and GPIO settings which are used in the minnowmax.dts.  Can you verify
> > if these are correctly turning on VBUS2 (since it sounds like they are
> > turning on VBUS1)?  If not, when you turn these GPIO on manually, does
> > the USB 2.0 port work correctly?
> 
> I see power on the bottom port but not the top one.

OK, that's odd, but likely can be fixed with changes to the pin mux and
pad settings in the dts.  I believe that the "pad-offset" for
pin_usb_host_en1 at 0 is wrong and that it should be 0x250 instead of
0x258.

diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index d0c0fe6..4988163 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -39,7 +39,7 @@
 
                pin_usb_host_en1 at 0 {
                        gpio-offset = <0x80 9>;
-                       pad-offset = <0x258>;
+                       pad-offset = <0x250>;
                        mode-gpio;
                        output-value = <1>;
                        direction = <PIN_OUTPUT>;

Does that fix it?

Thanks,
Andrew

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

+Gabriel

Hi Andrew,

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

I dug into this a bit and it all seems quite broken:

- PCI bus configuration does not work in gpio_ich6_pinctrl_init(). I
will send a patch for this
- gpio_ich6_get_base() returns a 16-bit word but function is also used
to read the memory address which holds a 32-bit word
- Intel's hardware won't let you read the status of an output!

The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We
need to mirror the lvl register in order to be able to read it.

I confirmed that with the 'correct' value in the lvl registers both
USB ports work.

Regards,
Simon

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Andrew Bradford]

Hi Simon,

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

I thought that if you cleared bit 2 in the "pad value" register (iinenb)
for a GPIO that you could read back outputs.  Or am I misunderstanding?

> The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We
> need to mirror the lvl register in order to be able to read it.
> 
> I confirmed that with the 'correct' value in the lvl registers both
> USB ports work.

OK, well that's good at least.

Thanks,
Andrew

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Andrew,

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

That looks right. So Intel's hardware is fine, it just requires
additional configuration. I wonder why we are not setting this?

>
>> The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We
>> need to mirror the lvl register in order to be able to read it.
>>
>> I confirmed that with the 'correct' value in the lvl registers both
>> USB ports work.
>
> OK, well that's good at least.
>
> Thanks,
> Andrew

Regards,
Simon

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng]

Hi Andrew,

On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
<andrew@bradfordembedded.com> wrote:
> Hi Bin,
>
> On 08/09 10:52, Bin Meng wrote:
>> Hi Andrew,
>>
>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>> <andrew@bradfordembedded.com> wrote:
>> > Hi Simon,
>> >
>> > On 08/08 10:18, Simon Glass wrote:
>> >> Hi,
>> >>
>> >> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>> >> > On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>> >> > <andrew@bradfordembedded.com> wrote:
>> >> >> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> >> >>
>> >> >> Allow for configuration of FSP UPD from the device tree which will
>> >> >> override any settings which the FSP was built with itself.
>> >> >>
>> >> >> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>> >> >> settings from the Intel FSPv4 Gold release to the respective dts files,
>> >> >> with the condition that the memory-down parameters for MinnowMax are
>> >> >> also used.
>> >> >>
>> >> >> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>> >> >> ---
>> >> >>
>> >> >
>> >> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>> >> > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>> >> >
>> >>
>> >> Acked-by: Simon Glass <sjg@chromium.org>
>> >> Tested on minnowmax:
>> >> Tested-by: Simon Glass <sjg@chromium.org>
>> >>
>> >> I found that I need to remove two properties from the minnowmax.dts:
>> >>
>> >> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>> >> at present and stops EHCI from working
>> >> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>> >> being displayed
>> >>
>> >> I plan to apply this with these changes - please let me know if this
>> >> doesn't suit.
>> >
>> > I'm OK with disabling xhci and the MRC debug output in the FSP.
>> >
>> > But if xhci is disabled then I believe when Linux boots that the USB 3.0
>> > port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>> > yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>> > sure which was a better choice.
>>
>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>
> I believe that the xhci port does work on Minnow Max in Linux but I do
> not have a board so I'm unable to test, sorry.
>

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] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Bin Meng]

Hi Simon,

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

I believe it indeed worked in the past but with the DM PCI conversion
on MinnowMax recently it was broken. That's also why I sent a patch
[1] previously saying that we should explicitly trigger the PCI
enumeration process, as not all DM PCI APIs can trigger the PCI
enumeration, which it is supposed to be as per DM concept.

> - gpio_ich6_get_base() returns a 16-bit word but function is also used
> to read the memory address which holds a 32-bit word
> - Intel's hardware won't let you read the status of an output!
>
> The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We
> need to mirror the lvl register in order to be able to read it.
>
> I confirmed that with the 'correct' value in the lvl registers both
> USB ports work.
>

[1]: http://lists.denx.de/pipermail/u-boot/2015-July/220542.html

Regards,
Bin

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Stefan Roese]

Hi Simon, Hi Bin,

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

I'm currently struggling with the USB EHCI ports on my custom Bay
Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
only some of the USB EHCI ports are enabled / available. Here
the "usb tree" output with 3 USB keys installed:

=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller 
  |
  +-2  Hub (480 Mb/s, 0mA)
    |
    +-3  Hub (480 Mb/s, 100mA)
    | |
    | +-4  Hub (12 Mb/s, 100mA)
    |    
    +-5  Mass Storage (480 Mb/s, 200mA)
         JetFlash Mass Storage Device 3281440601

When I first start the original (AMI) BIOS on this custom board,
and then reboot into U-Boot (without a power-cycle), I see this
configuration:

=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller 
  |
  +-2  Hub (480 Mb/s, 0mA)
    |
    +-3  Hub (480 Mb/s, 100mA)
    | |
    | +-4  Hub (12 Mb/s, 100mA)
    |    
    +-5  Hub (480 Mb/s, 0mA)
    | |
    | +-6  Mass Storage (480 Mb/s, 200mA)
    | |    Kingston DataTraveler 2.0 50E549C688C4BE7189942766
    | |  
    | +-7  Mass Storage (480 Mb/s, 98mA)
    |      USBest Technology USB Mass Storage Device 09092207fbf0c4
    |    
    +-8  Mass Storage (480 Mb/s, 200mA)
         JetFlash Mass Storage Device 3281440601

So now all 3 USB sticks are detected.

It doesn't seem to be a problem with missing USB power switch
enabling via some GPIOs. I've checked the schematics and all ports
should have power enabled.

Do you have any quick ideas, what might be missing to enable all
4 EHCI ports on Bay Trail? There seems to be a per-port disable
feature which might be involved. I'm still pretty new to x86, and
I'm struggling with finding the correct datasheet for this. So any
hints are really appreciated.

Thanks,
Stefan

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Stefan,

On 8 March 2016 at 09:45, Stefan Roese <sr@denx.de> wrote:
> Hi Simon, Hi Bin,
>
> On 12.08.2015 05:54, Simon Glass wrote:
>> +Gabriel
>>
>> Hi Andrew,
>>
>> On 11 August 2015 at 09:20, Andrew Bradford <andrew@bradfordembedded.com> wrote:
>>> Hi Simon,
>>>
>>> On 08/11 08:06, Simon Glass wrote:
>>>> Hi Andrew,
>>>>
>>>> On 11 August 2015 at 06:08, Andrew Bradford <andrew@bradfordembedded.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On 08/10 21:07, Simon Glass wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Andrew,
>>>>>>>
>>>>>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 08/09 10:52, Bin Meng wrote:
>>>>>>>>> Hi Andrew,
>>>>>>>>>
>>>>>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On 08/08 10:18, Simon Glass wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>>> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>>>>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>>>>>>> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Allow for configuration of FSP UPD from the device tree which will
>>>>>>>>>>>>> override any settings which the FSP was built with itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>>>>>>>>>>> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>>>>>>>>>>> with the condition that the memory-down parameters for MinnowMax are
>>>>>>>>>>>>> also used.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>>>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Acked-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>> Tested on minnowmax:
>>>>>>>>>>> Tested-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>
>>>>>>>>>>> I found that I need to remove two properties from the minnowmax.dts:
>>>>>>>>>>>
>>>>>>>>>>> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>>>>>>>>> at present and stops EHCI from working
>>>>>>>>>>> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>>>>>>>>> being displayed
>>>>>>>>>>>
>>>>>>>>>>> I plan to apply this with these changes - please let me know if this
>>>>>>>>>>> doesn't suit.
>>>>>>>>>>
>>>>>>>>>> I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>>>>>>>>
>>>>>>>>>> But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>>>>>>>> port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>>>>>>>>>> yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>>>>>>>> sure which was a better choice.
>>>>>>>>>
>>>>>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>>>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>>>>>>
>>>>>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>>>>>>> not have a board so I'm unable to test, sorry.
>>>>>>>>
>>>>>>>
>>>>>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>>>>>
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>>>>>
>>>>>> The problem is that USB is then broken in U-Boot. I think it is better
>>>>>> to limit the speed for the moment until we have that fixed. It is
>>>>>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>>>>>
>>>>>> With my testing the bottom (blue) port works fine but the top port
>>>>>> does not. This happens regardless of the xhci setting.
>>>>>
>>>>> Minnowmax has a USB power switch enable which determines if the VBUS2
>>>>> net is turned on or not, which will supply or not supply power to the
>>>>> USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
>>>>> and the USB ports themselves are located on page 16 of the schematic
>>>>> that I have.
>>>>>
>>>>> The switches to enable the VBUS for each port are active high and pulled
>>>>> down.  So to turn them on, I believe that's the point of the pinmuxing
>>>>> and GPIO settings which are used in the minnowmax.dts.  Can you verify
>>>>> if these are correctly turning on VBUS2 (since it sounds like they are
>>>>> turning on VBUS1)?  If not, when you turn these GPIO on manually, does
>>>>> the USB 2.0 port work correctly?
>>>>
>>>> I see power on the bottom port but not the top one.
>>>
>>> OK, that's odd, but likely can be fixed with changes to the pin mux and
>>> pad settings in the dts.  I believe that the "pad-offset" for
>>> pin_usb_host_en1 at 0 is wrong and that it should be 0x250 instead of
>>> 0x258.
>>>
>>> diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
>>> index d0c0fe6..4988163 100644
>>> --- a/arch/x86/dts/minnowmax.dts
>>> +++ b/arch/x86/dts/minnowmax.dts
>>> @@ -39,7 +39,7 @@
>>>
>>>                  pin_usb_host_en1 at 0 {
>>>                          gpio-offset = <0x80 9>;
>>> -                       pad-offset = <0x258>;
>>> +                       pad-offset = <0x250>;
>>>                          mode-gpio;
>>>                          output-value = <1>;
>>>                          direction = <PIN_OUTPUT>;
>>>
>>> Does that fix it?
>>
>> I dug into this a bit and it all seems quite broken:
>>
>> - PCI bus configuration does not work in gpio_ich6_pinctrl_init(). I
>> will send a patch for this
>> - gpio_ich6_get_base() returns a 16-bit word but function is also used
>> to read the memory address which holds a 32-bit word
>> - Intel's hardware won't let you read the status of an output!
>>
>> The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We
>> need to mirror the lvl register in order to be able to read it.
>>
>> I confirmed that with the 'correct' value in the lvl registers both
>> USB ports work.
>
> I'm currently struggling with the USB EHCI ports on my custom Bay
> Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
> only some of the USB EHCI ports are enabled / available. Here
> the "usb tree" output with 3 USB keys installed:
>
> => usb tree
> USB device tree:
>   1  Hub (480 Mb/s, 0mA)
>   |  u-boot EHCI Host Controller
>   |
>   +-2  Hub (480 Mb/s, 0mA)
>     |
>     +-3  Hub (480 Mb/s, 100mA)
>     | |
>     | +-4  Hub (12 Mb/s, 100mA)
>     |
>     +-5  Mass Storage (480 Mb/s, 200mA)
>          JetFlash Mass Storage Device 3281440601
>
> When I first start the original (AMI) BIOS on this custom board,
> and then reboot into U-Boot (without a power-cycle), I see this
> configuration:
>
> => usb tree
> USB device tree:
>   1  Hub (480 Mb/s, 0mA)
>   |  u-boot EHCI Host Controller
>   |
>   +-2  Hub (480 Mb/s, 0mA)
>     |
>     +-3  Hub (480 Mb/s, 100mA)
>     | |
>     | +-4  Hub (12 Mb/s, 100mA)
>     |
>     +-5  Hub (480 Mb/s, 0mA)
>     | |
>     | +-6  Mass Storage (480 Mb/s, 200mA)
>     | |    Kingston DataTraveler 2.0 50E549C688C4BE7189942766
>     | |
>     | +-7  Mass Storage (480 Mb/s, 98mA)
>     |      USBest Technology USB Mass Storage Device 09092207fbf0c4
>     |
>     +-8  Mass Storage (480 Mb/s, 200mA)
>          JetFlash Mass Storage Device 3281440601
>
> So now all 3 USB sticks are detected.
>
> It doesn't seem to be a problem with missing USB power switch
> enabling via some GPIOs. I've checked the schematics and all ports
> should have power enabled.
>
> Do you have any quick ideas, what might be missing to enable all
> 4 EHCI ports on Bay Trail? There seems to be a per-port disable
> feature which might be involved. I'm still pretty new to x86, and
> I'm struggling with finding the correct datasheet for this. So any
> hints are really appreciated.

It might be worth checking the pci bus device list in both cases.
Perhaps one of the USB ports is disabled?

Regards,
Simon

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Stefan Roese]

Hi Simon,

On 08.03.2016 17:54, Simon Glass wrote:
> Hi Stefan,
> 
> On 8 March 2016 at 09:45, Stefan Roese <sr@denx.de> wrote:
>> Hi Simon, Hi Bin,
>>
>> On 12.08.2015 05:54, Simon Glass wrote:
>>> +Gabriel
>>>
>>> Hi Andrew,
>>>
>>> On 11 August 2015 at 09:20, Andrew Bradford <andrew@bradfordembedded.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On 08/11 08:06, Simon Glass wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> On 11 August 2015 at 06:08, Andrew Bradford <andrew@bradfordembedded.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On 08/10 21:07, Simon Glass wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Andrew,
>>>>>>>>
>>>>>>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>>> Hi Bin,
>>>>>>>>>
>>>>>>>>> On 08/09 10:52, Bin Meng wrote:
>>>>>>>>>> Hi Andrew,
>>>>>>>>>>
>>>>>>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>
>>>>>>>>>>> On 08/08 10:18, Simon Glass wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>>>> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>>>>>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>>>>>>>> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Allow for configuration of FSP UPD from the device tree which will
>>>>>>>>>>>>>> override any settings which the FSP was built with itself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>>>>>>>>>>>> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>>>>>>>>>>>> with the condition that the memory-down parameters for MinnowMax are
>>>>>>>>>>>>>> also used.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>>>>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Acked-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>> Tested on minnowmax:
>>>>>>>>>>>> Tested-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>>
>>>>>>>>>>>> I found that I need to remove two properties from the minnowmax.dts:
>>>>>>>>>>>>
>>>>>>>>>>>> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>>>>>>>>>> at present and stops EHCI from working
>>>>>>>>>>>> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>>>>>>>>>> being displayed
>>>>>>>>>>>>
>>>>>>>>>>>> I plan to apply this with these changes - please let me know if this
>>>>>>>>>>>> doesn't suit.
>>>>>>>>>>>
>>>>>>>>>>> I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>>>>>>>>>
>>>>>>>>>>> But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>>>>>>>>> port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>>>>>>>>>>> yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>>>>>>>>> sure which was a better choice.
>>>>>>>>>>
>>>>>>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>>>>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>>>>>>>
>>>>>>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>>>>>>>> not have a board so I'm unable to test, sorry.
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>>>>>>
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>>>>>>
>>>>>>> The problem is that USB is then broken in U-Boot. I think it is better
>>>>>>> to limit the speed for the moment until we have that fixed. It is
>>>>>>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>>>>>>
>>>>>>> With my testing the bottom (blue) port works fine but the top port
>>>>>>> does not. This happens regardless of the xhci setting.
>>>>>>
>>>>>> Minnowmax has a USB power switch enable which determines if the VBUS2
>>>>>> net is turned on or not, which will supply or not supply power to the
>>>>>> USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
>>>>>> and the USB ports themselves are located on page 16 of the schematic
>>>>>> that I have.
>>>>>>
>>>>>> The switches to enable the VBUS for each port are active high and pulled
>>>>>> down.  So to turn them on, I believe that's the point of the pinmuxing
>>>>>> and GPIO settings which are used in the minnowmax.dts.  Can you verify
>>>>>> if these are correctly turning on VBUS2 (since it sounds like they are
>>>>>> turning on VBUS1)?  If not, when you turn these GPIO on manually, does
>>>>>> the USB 2.0 port work correctly?
>>>>>
>>>>> I see power on the bottom port but not the top one.
>>>>
>>>> OK, that's odd, but likely can be fixed with changes to the pin mux and
>>>> pad settings in the dts.  I believe that the "pad-offset" for
>>>> pin_usb_host_en1 at 0 is wrong and that it should be 0x250 instead of
>>>> 0x258.
>>>>
>>>> diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
>>>> index d0c0fe6..4988163 100644
>>>> --- a/arch/x86/dts/minnowmax.dts
>>>> +++ b/arch/x86/dts/minnowmax.dts
>>>> @@ -39,7 +39,7 @@
>>>>
>>>>                   pin_usb_host_en1 at 0 {
>>>>                           gpio-offset = <0x80 9>;
>>>> -                       pad-offset = <0x258>;
>>>> +                       pad-offset = <0x250>;
>>>>                           mode-gpio;
>>>>                           output-value = <1>;
>>>>                           direction = <PIN_OUTPUT>;
>>>>
>>>> Does that fix it?
>>>
>>> I dug into this a bit and it all seems quite broken:
>>>
>>> - PCI bus configuration does not work in gpio_ich6_pinctrl_init(). I
>>> will send a patch for this
>>> - gpio_ich6_get_base() returns a 16-bit word but function is also used
>>> to read the memory address which holds a 32-bit word
>>> - Intel's hardware won't let you read the status of an output!
>>>
>>> The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We
>>> need to mirror the lvl register in order to be able to read it.
>>>
>>> I confirmed that with the 'correct' value in the lvl registers both
>>> USB ports work.
>>
>> I'm currently struggling with the USB EHCI ports on my custom Bay
>> Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
>> only some of the USB EHCI ports are enabled / available. Here
>> the "usb tree" output with 3 USB keys installed:
>>
>> => usb tree
>> USB device tree:
>>    1  Hub (480 Mb/s, 0mA)
>>    |  u-boot EHCI Host Controller
>>    |
>>    +-2  Hub (480 Mb/s, 0mA)
>>      |
>>      +-3  Hub (480 Mb/s, 100mA)
>>      | |
>>      | +-4  Hub (12 Mb/s, 100mA)
>>      |
>>      +-5  Mass Storage (480 Mb/s, 200mA)
>>           JetFlash Mass Storage Device 3281440601
>>
>> When I first start the original (AMI) BIOS on this custom board,
>> and then reboot into U-Boot (without a power-cycle), I see this
>> configuration:
>>
>> => usb tree
>> USB device tree:
>>    1  Hub (480 Mb/s, 0mA)
>>    |  u-boot EHCI Host Controller
>>    |
>>    +-2  Hub (480 Mb/s, 0mA)
>>      |
>>      +-3  Hub (480 Mb/s, 100mA)
>>      | |
>>      | +-4  Hub (12 Mb/s, 100mA)
>>      |
>>      +-5  Hub (480 Mb/s, 0mA)
>>      | |
>>      | +-6  Mass Storage (480 Mb/s, 200mA)
>>      | |    Kingston DataTraveler 2.0 50E549C688C4BE7189942766
>>      | |
>>      | +-7  Mass Storage (480 Mb/s, 98mA)
>>      |      USBest Technology USB Mass Storage Device 09092207fbf0c4
>>      |
>>      +-8  Mass Storage (480 Mb/s, 200mA)
>>           JetFlash Mass Storage Device 3281440601
>>
>> So now all 3 USB sticks are detected.
>>
>> It doesn't seem to be a problem with missing USB power switch
>> enabling via some GPIOs. I've checked the schematics and all ports
>> should have power enabled.
>>
>> Do you have any quick ideas, what might be missing to enable all
>> 4 EHCI ports on Bay Trail? There seems to be a per-port disable
>> feature which might be involved. I'm still pretty new to x86, and
>> I'm struggling with finding the correct datasheet for this. So any
>> hints are really appreciated.
> 
> It might be worth checking the pci bus device list in both cases.
> Perhaps one of the USB ports is disabled?

IIUTC, its only one PCI device, that handles all EHCI USB 2.0 ports.
In both cases its this output:

=> pci
Scanning PCI devices on bus 0                                                                                                                                                       
BusDevFun  VendorId   DeviceId   Device Class       Sub-Class                                                                                                                       
_____________________________________________________________
00.1f.00   0x8086     0x0f1c     Bridge device           0x01
00.00.00   0x8086     0x0f00     Bridge device           0x00
00.02.00   0x8086     0x0f31     Display controller      0x00
00.11.00   0x8086     0x0f15     Base system peripheral  0x05
00.12.00   0x8086     0x0f16     Base system peripheral  0x05
00.13.00   0x8086     0x0f23     Mass storage controller 0x06
00.15.00   0x8086     0x0f28     Multimedia device       0x01
00.18.00   0x8086     0x0f40     Base system peripheral  0x01
00.18.01   0x8086     0x0f41     Serial bus controller   0x80
00.18.02   0x8086     0x0f42     Serial bus controller   0x80
00.18.03   0x8086     0x0f43     Serial bus controller   0x80
00.18.04   0x8086     0x0f44     Serial bus controller   0x80
00.18.05   0x8086     0x0f45     Serial bus controller   0x80
00.18.06   0x8086     0x0f46     Serial bus controller   0x80
00.18.07   0x8086     0x0f47     Serial bus controller   0x80
00.1a.00   0x8086     0x0f18     Cryptographic device    0x80
00.1c.00   0x8086     0x0f48     Bridge device           0x04
00.1c.03   0x8086     0x0f4e     Bridge device           0x04
00.1d.00   0x8086     0x0f34     Serial bus controller   0x03
00.1e.00   0x8086     0x0f06     Base system peripheral  0x01
00.1e.01   0x8086     0x0f08     Serial bus controller   0x80
00.1e.02   0x8086     0x0f09     Serial bus controller   0x80
00.1e.04   0x8086     0x0f0c     Simple comm. controller 0x80
00.1e.05   0x8086     0x0f0e     Serial bus controller   0x80
00.1f.03   0x8086     0x0f12     Serial bus controller   0x05

Here 00.1d.00 is the EHCI controller. The "pci long" output
is also identical. So its not that simple I'm afraid.

The Intel Atom Processor Z3600 and Z3700 Series Datasheet Vol 1
mentions in chapter "10.3.1 EHCI USB 2.0 Controller Features" on
page 150:

? Per port USB disable

Perhaps this feature is biting me here. I'm wondering how this can
be configured.

Any further ideas are welcome.

Thanks,
Stefan

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Stefan,

On 8 March 2016 at 10:41, Stefan Roese <sr@denx.de> wrote:
> Hi Simon,
>
> On 08.03.2016 17:54, Simon Glass wrote:
>> Hi Stefan,
>>
>> On 8 March 2016 at 09:45, Stefan Roese <sr@denx.de> wrote:
>>> Hi Simon, Hi Bin,
>>>
>>> On 12.08.2015 05:54, Simon Glass wrote:
>>>> +Gabriel
>>>>
>>>> Hi Andrew,
>>>>
>>>> On 11 August 2015 at 09:20, Andrew Bradford <andrew@bradfordembedded.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On 08/11 08:06, Simon Glass wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> On 11 August 2015 at 06:08, Andrew Bradford <andrew@bradfordembedded.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On 08/10 21:07, Simon Glass wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 10 August 2015 at 20:53, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>> Hi Andrew,
>>>>>>>>>
>>>>>>>>> On Mon, Aug 10, 2015 at 7:32 PM, Andrew Bradford
>>>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>>>> Hi Bin,
>>>>>>>>>>
>>>>>>>>>> On 08/09 10:52, Bin Meng wrote:
>>>>>>>>>>> Hi Andrew,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Aug 9, 2015 at 9:08 AM, Andrew Bradford
>>>>>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/08 10:18, Simon Glass wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7 August 2015 at 06:44, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>>>>> On Fri, Aug 7, 2015 at 8:36 PM, Andrew Bradford
>>>>>>>>>>>>>> <andrew@bradfordembedded.com> wrote:
>>>>>>>>>>>>>>> From: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Allow for configuration of FSP UPD from the device tree which will
>>>>>>>>>>>>>>> override any settings which the FSP was built with itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Modify the MinnowMax and BayleyBay boards to transfer sensible UPD
>>>>>>>>>>>>>>> settings from the Intel FSPv4 Gold release to the respective dts files,
>>>>>>>>>>>>>>> with the condition that the memory-down parameters for MinnowMax are
>>>>>>>>>>>>>>> also used.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>>>>>>> Tested-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Acked-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>>> Tested on minnowmax:
>>>>>>>>>>>>> Tested-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I found that I need to remove two properties from the minnowmax.dts:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - fsp,enable-xhci needs to be removed as this does not work in U-Boot
>>>>>>>>>>>>> at present and stops EHCI from working
>>>>>>>>>>>>> - fsp,mrc-debug-msg needs to be removed to prevent debug information
>>>>>>>>>>>>> being displayed
>>>>>>>>>>>>>
>>>>>>>>>>>>> I plan to apply this with these changes - please let me know if this
>>>>>>>>>>>>> doesn't suit.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm OK with disabling xhci and the MRC debug output in the FSP.
>>>>>>>>>>>>
>>>>>>>>>>>> But if xhci is disabled then I believe when Linux boots that the USB 3.0
>>>>>>>>>>>> port on Minnow Max will only act as a USB 2.0 port.  That u-boot doesn't
>>>>>>>>>>>> yet have working XHCI on E3800 means there is a tradeoff and I wasn't
>>>>>>>>>>>> sure which was a better choice.
>>>>>>>>>>>
>>>>>>>>>>> Does these xHCI ports on MinnowMax work fully on Linux kernel? If it
>>>>>>>>>>> works, I'd rather we keep fsp,enable-xhci in the U-Boot.
>>>>>>>>>>
>>>>>>>>>> I believe that the xhci port does work on Minnow Max in Linux but I do
>>>>>>>>>> not have a board so I'm unable to test, sorry.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> OK, my test shows that ehci works fine in U-Boot on Bayley Bay.
>>>>>>>>>
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> What do you think regarding to xhci vs. ehci in U-Boot?
>>>>>>>>
>>>>>>>> The problem is that USB is then broken in U-Boot. I think it is better
>>>>>>>> to limit the speed for the moment until we have that fixed. It is
>>>>>>>> quite useful to be able to use a keyboard or USB stick in U-Boot.
>>>>>>>>
>>>>>>>> With my testing the bottom (blue) port works fine but the top port
>>>>>>>> does not. This happens regardless of the xhci setting.
>>>>>>>
>>>>>>> Minnowmax has a USB power switch enable which determines if the VBUS2
>>>>>>> net is turned on or not, which will supply or not supply power to the
>>>>>>> USB 2.0 port.  The blue USB 3.0 port also has an enable.  Both enables
>>>>>>> and the USB ports themselves are located on page 16 of the schematic
>>>>>>> that I have.
>>>>>>>
>>>>>>> The switches to enable the VBUS for each port are active high and pulled
>>>>>>> down.  So to turn them on, I believe that's the point of the pinmuxing
>>>>>>> and GPIO settings which are used in the minnowmax.dts.  Can you verify
>>>>>>> if these are correctly turning on VBUS2 (since it sounds like they are
>>>>>>> turning on VBUS1)?  If not, when you turn these GPIO on manually, does
>>>>>>> the USB 2.0 port work correctly?
>>>>>>
>>>>>> I see power on the bottom port but not the top one.
>>>>>
>>>>> OK, that's odd, but likely can be fixed with changes to the pin mux and
>>>>> pad settings in the dts.  I believe that the "pad-offset" for
>>>>> pin_usb_host_en1 at 0 is wrong and that it should be 0x250 instead of
>>>>> 0x258.
>>>>>
>>>>> diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
>>>>> index d0c0fe6..4988163 100644
>>>>> --- a/arch/x86/dts/minnowmax.dts
>>>>> +++ b/arch/x86/dts/minnowmax.dts
>>>>> @@ -39,7 +39,7 @@
>>>>>
>>>>>                   pin_usb_host_en1 at 0 {
>>>>>                           gpio-offset = <0x80 9>;
>>>>> -                       pad-offset = <0x258>;
>>>>> +                       pad-offset = <0x250>;
>>>>>                           mode-gpio;
>>>>>                           output-value = <1>;
>>>>>                           direction = <PIN_OUTPUT>;
>>>>>
>>>>> Does that fix it?
>>>>
>>>> I dug into this a bit and it all seems quite broken:
>>>>
>>>> - PCI bus configuration does not work in gpio_ich6_pinctrl_init(). I
>>>> will send a patch for this
>>>> - gpio_ich6_get_base() returns a 16-bit word but function is also used
>>>> to read the memory address which holds a 32-bit word
>>>> - Intel's hardware won't let you read the status of an output!
>>>>
>>>> The last point means that _gpio_ich6_pinctrl_cfg_pin cannot work. We
>>>> need to mirror the lvl register in order to be able to read it.
>>>>
>>>> I confirmed that with the 'correct' value in the lvl registers both
>>>> USB ports work.
>>>
>>> I'm currently struggling with the USB EHCI ports on my custom Bay
>>> Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
>>> only some of the USB EHCI ports are enabled / available. Here
>>> the "usb tree" output with 3 USB keys installed:
>>>
>>> => usb tree
>>> USB device tree:
>>>    1  Hub (480 Mb/s, 0mA)
>>>    |  u-boot EHCI Host Controller
>>>    |
>>>    +-2  Hub (480 Mb/s, 0mA)
>>>      |
>>>      +-3  Hub (480 Mb/s, 100mA)
>>>      | |
>>>      | +-4  Hub (12 Mb/s, 100mA)
>>>      |
>>>      +-5  Mass Storage (480 Mb/s, 200mA)
>>>           JetFlash Mass Storage Device 3281440601
>>>
>>> When I first start the original (AMI) BIOS on this custom board,
>>> and then reboot into U-Boot (without a power-cycle), I see this
>>> configuration:
>>>
>>> => usb tree
>>> USB device tree:
>>>    1  Hub (480 Mb/s, 0mA)
>>>    |  u-boot EHCI Host Controller
>>>    |
>>>    +-2  Hub (480 Mb/s, 0mA)
>>>      |
>>>      +-3  Hub (480 Mb/s, 100mA)
>>>      | |
>>>      | +-4  Hub (12 Mb/s, 100mA)
>>>      |
>>>      +-5  Hub (480 Mb/s, 0mA)
>>>      | |
>>>      | +-6  Mass Storage (480 Mb/s, 200mA)
>>>      | |    Kingston DataTraveler 2.0 50E549C688C4BE7189942766
>>>      | |
>>>      | +-7  Mass Storage (480 Mb/s, 98mA)
>>>      |      USBest Technology USB Mass Storage Device 09092207fbf0c4
>>>      |
>>>      +-8  Mass Storage (480 Mb/s, 200mA)
>>>           JetFlash Mass Storage Device 3281440601
>>>
>>> So now all 3 USB sticks are detected.
>>>
>>> It doesn't seem to be a problem with missing USB power switch
>>> enabling via some GPIOs. I've checked the schematics and all ports
>>> should have power enabled.
>>>
>>> Do you have any quick ideas, what might be missing to enable all
>>> 4 EHCI ports on Bay Trail? There seems to be a per-port disable
>>> feature which might be involved. I'm still pretty new to x86, and
>>> I'm struggling with finding the correct datasheet for this. So any
>>> hints are really appreciated.
>>
>> It might be worth checking the pci bus device list in both cases.
>> Perhaps one of the USB ports is disabled?
>
> IIUTC, its only one PCI device, that handles all EHCI USB 2.0 ports.
> In both cases its this output:
>
> => pci
> Scanning PCI devices on bus 0
> BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
> _____________________________________________________________
> 00.1f.00   0x8086     0x0f1c     Bridge device           0x01
> 00.00.00   0x8086     0x0f00     Bridge device           0x00
> 00.02.00   0x8086     0x0f31     Display controller      0x00
> 00.11.00   0x8086     0x0f15     Base system peripheral  0x05
> 00.12.00   0x8086     0x0f16     Base system peripheral  0x05
> 00.13.00   0x8086     0x0f23     Mass storage controller 0x06
> 00.15.00   0x8086     0x0f28     Multimedia device       0x01
> 00.18.00   0x8086     0x0f40     Base system peripheral  0x01
> 00.18.01   0x8086     0x0f41     Serial bus controller   0x80
> 00.18.02   0x8086     0x0f42     Serial bus controller   0x80
> 00.18.03   0x8086     0x0f43     Serial bus controller   0x80
> 00.18.04   0x8086     0x0f44     Serial bus controller   0x80
> 00.18.05   0x8086     0x0f45     Serial bus controller   0x80
> 00.18.06   0x8086     0x0f46     Serial bus controller   0x80
> 00.18.07   0x8086     0x0f47     Serial bus controller   0x80
> 00.1a.00   0x8086     0x0f18     Cryptographic device    0x80
> 00.1c.00   0x8086     0x0f48     Bridge device           0x04
> 00.1c.03   0x8086     0x0f4e     Bridge device           0x04
> 00.1d.00   0x8086     0x0f34     Serial bus controller   0x03
> 00.1e.00   0x8086     0x0f06     Base system peripheral  0x01
> 00.1e.01   0x8086     0x0f08     Serial bus controller   0x80
> 00.1e.02   0x8086     0x0f09     Serial bus controller   0x80
> 00.1e.04   0x8086     0x0f0c     Simple comm. controller 0x80
> 00.1e.05   0x8086     0x0f0e     Serial bus controller   0x80
> 00.1f.03   0x8086     0x0f12     Serial bus controller   0x05
>
> Here 00.1d.00 is the EHCI controller. The "pci long" output
> is also identical. So its not that simple I'm afraid.
>
> The Intel Atom Processor Z3600 and Z3700 Series Datasheet Vol 1
> mentions in chapter "10.3.1 EHCI USB 2.0 Controller Features" on
> page 150:
>
> ? Per port USB disable
>
> Perhaps this feature is biting me here. I'm wondering how this can
> be configured.

That sounds likely.

Also: xHCI and EHCI Port Mapping

suggests that you need to make sure the ports are being driven by EHCI
instead of XHCI.

It mentions USB2HCSEL but I cannot find that in the datasheet.

It does appear here though:

https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/perf_power.c

See  IOSF_PORT_0x5a here:

https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/broadwell_fsp/src/lib/reg_script.c

So it looks like you need to set up this port, and perhaps some others
asper that file.

>
> Any further ideas are welcome.
>
> Thanks,
> Stefan
>

Regards,
Simon

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Stefan Roese]

Hi Simon,

On 09.03.2016 00:33, Simon Glass wrote:

<snip>

>>>> I'm currently struggling with the USB EHCI ports on my custom Bay
>>>> Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
>>>> only some of the USB EHCI ports are enabled / available. Here
>>>> the "usb tree" output with 3 USB keys installed:
>>>>
>>>> => usb tree
>>>> USB device tree:
>>>>     1  Hub (480 Mb/s, 0mA)
>>>>     |  u-boot EHCI Host Controller
>>>>     |
>>>>     +-2  Hub (480 Mb/s, 0mA)
>>>>       |
>>>>       +-3  Hub (480 Mb/s, 100mA)
>>>>       | |
>>>>       | +-4  Hub (12 Mb/s, 100mA)
>>>>       |
>>>>       +-5  Mass Storage (480 Mb/s, 200mA)
>>>>            JetFlash Mass Storage Device 3281440601
>>>>
>>>> When I first start the original (AMI) BIOS on this custom board,
>>>> and then reboot into U-Boot (without a power-cycle), I see this
>>>> configuration:
>>>>
>>>> => usb tree
>>>> USB device tree:
>>>>     1  Hub (480 Mb/s, 0mA)
>>>>     |  u-boot EHCI Host Controller
>>>>     |
>>>>     +-2  Hub (480 Mb/s, 0mA)
>>>>       |
>>>>       +-3  Hub (480 Mb/s, 100mA)
>>>>       | |
>>>>       | +-4  Hub (12 Mb/s, 100mA)
>>>>       |
>>>>       +-5  Hub (480 Mb/s, 0mA)
>>>>       | |
>>>>       | +-6  Mass Storage (480 Mb/s, 200mA)
>>>>       | |    Kingston DataTraveler 2.0 50E549C688C4BE7189942766
>>>>       | |
>>>>       | +-7  Mass Storage (480 Mb/s, 98mA)
>>>>       |      USBest Technology USB Mass Storage Device 09092207fbf0c4
>>>>       |
>>>>       +-8  Mass Storage (480 Mb/s, 200mA)
>>>>            JetFlash Mass Storage Device 3281440601
>>>>
>>>> So now all 3 USB sticks are detected.
>>>>
>>>> It doesn't seem to be a problem with missing USB power switch
>>>> enabling via some GPIOs. I've checked the schematics and all ports
>>>> should have power enabled.
>>>>
>>>> Do you have any quick ideas, what might be missing to enable all
>>>> 4 EHCI ports on Bay Trail? There seems to be a per-port disable
>>>> feature which might be involved. I'm still pretty new to x86, and
>>>> I'm struggling with finding the correct datasheet for this. So any
>>>> hints are really appreciated.
>>>
>>> It might be worth checking the pci bus device list in both cases.
>>> Perhaps one of the USB ports is disabled?
>>
>> IIUTC, its only one PCI device, that handles all EHCI USB 2.0 ports.
>> In both cases its this output:
>>
>> => pci
>> Scanning PCI devices on bus 0
>> BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
>> _____________________________________________________________
>> 00.1f.00   0x8086     0x0f1c     Bridge device           0x01
>> 00.00.00   0x8086     0x0f00     Bridge device           0x00
>> 00.02.00   0x8086     0x0f31     Display controller      0x00
>> 00.11.00   0x8086     0x0f15     Base system peripheral  0x05
>> 00.12.00   0x8086     0x0f16     Base system peripheral  0x05
>> 00.13.00   0x8086     0x0f23     Mass storage controller 0x06
>> 00.15.00   0x8086     0x0f28     Multimedia device       0x01
>> 00.18.00   0x8086     0x0f40     Base system peripheral  0x01
>> 00.18.01   0x8086     0x0f41     Serial bus controller   0x80
>> 00.18.02   0x8086     0x0f42     Serial bus controller   0x80
>> 00.18.03   0x8086     0x0f43     Serial bus controller   0x80
>> 00.18.04   0x8086     0x0f44     Serial bus controller   0x80
>> 00.18.05   0x8086     0x0f45     Serial bus controller   0x80
>> 00.18.06   0x8086     0x0f46     Serial bus controller   0x80
>> 00.18.07   0x8086     0x0f47     Serial bus controller   0x80
>> 00.1a.00   0x8086     0x0f18     Cryptographic device    0x80
>> 00.1c.00   0x8086     0x0f48     Bridge device           0x04
>> 00.1c.03   0x8086     0x0f4e     Bridge device           0x04
>> 00.1d.00   0x8086     0x0f34     Serial bus controller   0x03
>> 00.1e.00   0x8086     0x0f06     Base system peripheral  0x01
>> 00.1e.01   0x8086     0x0f08     Serial bus controller   0x80
>> 00.1e.02   0x8086     0x0f09     Serial bus controller   0x80
>> 00.1e.04   0x8086     0x0f0c     Simple comm. controller 0x80
>> 00.1e.05   0x8086     0x0f0e     Serial bus controller   0x80
>> 00.1f.03   0x8086     0x0f12     Serial bus controller   0x05
>>
>> Here 00.1d.00 is the EHCI controller. The "pci long" output
>> is also identical. So its not that simple I'm afraid.
>>
>> The Intel Atom Processor Z3600 and Z3700 Series Datasheet Vol 1
>> mentions in chapter "10.3.1 EHCI USB 2.0 Controller Features" on
>> page 150:
>>
>> ? Per port USB disable
>>
>> Perhaps this feature is biting me here. I'm wondering how this can
>> be configured.
> 
> That sounds likely.
> 
> Also: xHCI and EHCI Port Mapping
> 
> suggests that you need to make sure the ports are being driven by EHCI
> instead of XHCI.
> 
> It mentions USB2HCSEL but I cannot find that in the datasheet.

Same here.
 
> It does appear here though:
> 
> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/perf_power.c
> 
> See  IOSF_PORT_0x5a here:
> 
> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/broadwell_fsp/src/lib/reg_script.c
> 
> So it looks like you need to set up this port, and perhaps some others
> asper that file.

I've looked into these coreboot files today. And ported parts of them
to U-Boot to run these configurations there as well. Unfortunately
without any (positive) effect. Some things I've tested are:

Configure 0x5a / 0xd0 (USB2HCSEL???) to different values. All
without effect.

Unfortunately this value can't be read-out. At least I read always
0 here. So I can't see, if the AMI BIOS version configures here
something different.

Then I've started looking into ehci.c:

https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/ehci.c

EHCI_USB2PDO (per-port disable) looked promising here. And writing
0xff into this reg results in all ports disabled:

=> usb tree
USB device tree:
  1  Hub (480 Mb/s, 0mA)
  |  u-boot EHCI Host Controller 
  |
  +-2  Hub (480 Mb/s, 0mA)

So this register at least has some effect. But its initialized with
0 and writing 0 into it does not fix the problem with the missing
ports.

I also ported the PHY values from usb2_phy_init() without any
changes. The values here are the default values, as I can read
them back. Also the AMI BIOS does not change these values, I've
double checked this as well.

So I'm nearly out of ideas right now what else to configure / test
to get all ports running. One idea is that the xHCI controller also
needs some configuration for this port muxing. See:

https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/xhci.c:

		/* USB3 SuperSpeed Enable */
		REG_PCI_WRITE32(XHCI_USB3PR, BYTM_USB3_PORT_MAP),
		/* USB2 Port Route to XHCI */
		REG_PCI_WRITE32(XHCI_USB2PR, BYTM_USB2_PORT_MAP),

and:

		/* Set USB2 Port Routing Mask */
		REG_PCI_WRITE32(XHCI_USB2PRM, BYTM_USB2_PORT_MAP),
		/* Set USB3 Port Routing Mask */
		REG_PCI_WRITE32(XHCI_USB3PRM, BYTM_USB3_PORT_MAP),
		/*
		 * Disable ports if requested
		 */
		/* Open per-port disable control override */
		REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~0, UPRWC_WR_EN),
		REG_PCI_WRITE32(XHCI_USB2PDO, config->usb2_port_disable_mask),
		REG_PCI_WRITE32(XHCI_USB3PDO, config->usb3_port_disable_mask),
		/* Close per-port disable control override */
		REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~UPRWC_WR_EN, 0),

But I can only either see the EHCI or the xHCI controller via
"pci". If I configure the FSP to enable xHCI (fsp,enable-xhci)
the EHCI PCI device is not listed. And without this DT property
the xHCI PCI device is missing. So I only have access to one
USB controller at the some time.

Any further ideas are really welcome! :)

BTW: Did you (or somebody else?) already start moving xHCI (PCI) to
DM yet? If yes, could you perhaps provide this version so that I
could continue with it.

Thanks,
Stefan

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Stefan,

On 9 March 2016 at 09:15, Stefan Roese <sr@denx.de> wrote:
>
> Hi Simon,
>
> On 09.03.2016 00:33, Simon Glass wrote:
>
> <snip>
>
> >>>> I'm currently struggling with the USB EHCI ports on my custom Bay
> >>>> Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
> >>>> only some of the USB EHCI ports are enabled / available. Here
> >>>> the "usb tree" output with 3 USB keys installed:
> >>>>
> >>>> => usb tree
> >>>> USB device tree:
> >>>>     1  Hub (480 Mb/s, 0mA)
> >>>>     |  u-boot EHCI Host Controller
> >>>>     |
> >>>>     +-2  Hub (480 Mb/s, 0mA)
> >>>>       |
> >>>>       +-3  Hub (480 Mb/s, 100mA)
> >>>>       | |
> >>>>       | +-4  Hub (12 Mb/s, 100mA)
> >>>>       |
> >>>>       +-5  Mass Storage (480 Mb/s, 200mA)
> >>>>            JetFlash Mass Storage Device 3281440601
> >>>>
> >>>> When I first start the original (AMI) BIOS on this custom board,
> >>>> and then reboot into U-Boot (without a power-cycle), I see this
> >>>> configuration:
> >>>>
> >>>> => usb tree
> >>>> USB device tree:
> >>>>     1  Hub (480 Mb/s, 0mA)
> >>>>     |  u-boot EHCI Host Controller
> >>>>     |
> >>>>     +-2  Hub (480 Mb/s, 0mA)
> >>>>       |
> >>>>       +-3  Hub (480 Mb/s, 100mA)
> >>>>       | |
> >>>>       | +-4  Hub (12 Mb/s, 100mA)
> >>>>       |
> >>>>       +-5  Hub (480 Mb/s, 0mA)
> >>>>       | |
> >>>>       | +-6  Mass Storage (480 Mb/s, 200mA)
> >>>>       | |    Kingston DataTraveler 2.0 50E549C688C4BE7189942766
> >>>>       | |
> >>>>       | +-7  Mass Storage (480 Mb/s, 98mA)
> >>>>       |      USBest Technology USB Mass Storage Device 09092207fbf0c4
> >>>>       |
> >>>>       +-8  Mass Storage (480 Mb/s, 200mA)
> >>>>            JetFlash Mass Storage Device 3281440601
> >>>>
> >>>> So now all 3 USB sticks are detected.
> >>>>
> >>>> It doesn't seem to be a problem with missing USB power switch
> >>>> enabling via some GPIOs. I've checked the schematics and all ports
> >>>> should have power enabled.
> >>>>
> >>>> Do you have any quick ideas, what might be missing to enable all
> >>>> 4 EHCI ports on Bay Trail? There seems to be a per-port disable
> >>>> feature which might be involved. I'm still pretty new to x86, and
> >>>> I'm struggling with finding the correct datasheet for this. So any
> >>>> hints are really appreciated.
> >>>
> >>> It might be worth checking the pci bus device list in both cases.
> >>> Perhaps one of the USB ports is disabled?
> >>
> >> IIUTC, its only one PCI device, that handles all EHCI USB 2.0 ports.
> >> In both cases its this output:
> >>
> >> => pci
> >> Scanning PCI devices on bus 0
> >> BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
> >> _____________________________________________________________
> >> 00.1f.00   0x8086     0x0f1c     Bridge device           0x01
> >> 00.00.00   0x8086     0x0f00     Bridge device           0x00
> >> 00.02.00   0x8086     0x0f31     Display controller      0x00
> >> 00.11.00   0x8086     0x0f15     Base system peripheral  0x05
> >> 00.12.00   0x8086     0x0f16     Base system peripheral  0x05
> >> 00.13.00   0x8086     0x0f23     Mass storage controller 0x06
> >> 00.15.00   0x8086     0x0f28     Multimedia device       0x01
> >> 00.18.00   0x8086     0x0f40     Base system peripheral  0x01
> >> 00.18.01   0x8086     0x0f41     Serial bus controller   0x80
> >> 00.18.02   0x8086     0x0f42     Serial bus controller   0x80
> >> 00.18.03   0x8086     0x0f43     Serial bus controller   0x80
> >> 00.18.04   0x8086     0x0f44     Serial bus controller   0x80
> >> 00.18.05   0x8086     0x0f45     Serial bus controller   0x80
> >> 00.18.06   0x8086     0x0f46     Serial bus controller   0x80
> >> 00.18.07   0x8086     0x0f47     Serial bus controller   0x80
> >> 00.1a.00   0x8086     0x0f18     Cryptographic device    0x80
> >> 00.1c.00   0x8086     0x0f48     Bridge device           0x04
> >> 00.1c.03   0x8086     0x0f4e     Bridge device           0x04
> >> 00.1d.00   0x8086     0x0f34     Serial bus controller   0x03
> >> 00.1e.00   0x8086     0x0f06     Base system peripheral  0x01
> >> 00.1e.01   0x8086     0x0f08     Serial bus controller   0x80
> >> 00.1e.02   0x8086     0x0f09     Serial bus controller   0x80
> >> 00.1e.04   0x8086     0x0f0c     Simple comm. controller 0x80
> >> 00.1e.05   0x8086     0x0f0e     Serial bus controller   0x80
> >> 00.1f.03   0x8086     0x0f12     Serial bus controller   0x05
> >>
> >> Here 00.1d.00 is the EHCI controller. The "pci long" output
> >> is also identical. So its not that simple I'm afraid.
> >>
> >> The Intel Atom Processor Z3600 and Z3700 Series Datasheet Vol 1
> >> mentions in chapter "10.3.1 EHCI USB 2.0 Controller Features" on
> >> page 150:
> >>
> >> ? Per port USB disable
> >>
> >> Perhaps this feature is biting me here. I'm wondering how this can
> >> be configured.
> >
> > That sounds likely.
> >
> > Also: xHCI and EHCI Port Mapping
> >
> > suggests that you need to make sure the ports are being driven by EHCI
> > instead of XHCI.
> >
> > It mentions USB2HCSEL but I cannot find that in the datasheet.
>
> Same here.
>
> > It does appear here though:
> >
> > https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/perf_power.c
> >
> > See  IOSF_PORT_0x5a here:
> >
> > https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/broadwell_fsp/src/lib/reg_script.c
> >
> > So it looks like you need to set up this port, and perhaps some others
> > asper that file.
>
> I've looked into these coreboot files today. And ported parts of them
> to U-Boot to run these configurations there as well. Unfortunately
> without any (positive) effect. Some things I've tested are:
>
> Configure 0x5a / 0xd0 (USB2HCSEL???) to different values. All
> without effect.
>
> Unfortunately this value can't be read-out. At least I read always
> 0 here. So I can't see, if the AMI BIOS version configures here
> something different.

That's really odd, because it looks like this is a read/write
interface. Worth digging int I think, and trying to find docs.

>
> Then I've started looking into ehci.c:
>
> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/ehci.c
>
> EHCI_USB2PDO (per-port disable) looked promising here. And writing
> 0xff into this reg results in all ports disabled:
>
> => usb tree
> USB device tree:
>   1  Hub (480 Mb/s, 0mA)
>   |  u-boot EHCI Host Controller
>   |
>   +-2  Hub (480 Mb/s, 0mA)
>
> So this register at least has some effect. But its initialized with
> 0 and writing 0 into it does not fix the problem with the missing
> ports.
>
> I also ported the PHY values from usb2_phy_init() without any
> changes. The values here are the default values, as I can read
> them back. Also the AMI BIOS does not change these values, I've
> double checked this as well.

BTW is the AMI BIOS UEFI? If so, for now I suppose you could boot into
U-Boot from that, and deal with the problem later.

>
> So I'm nearly out of ideas right now what else to configure / test
> to get all ports running. One idea is that the xHCI controller also
> needs some configuration for this port muxing. See:
>
> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/xhci.c:
>
>                 /* USB3 SuperSpeed Enable */
>                 REG_PCI_WRITE32(XHCI_USB3PR, BYTM_USB3_PORT_MAP),
>                 /* USB2 Port Route to XHCI */
>                 REG_PCI_WRITE32(XHCI_USB2PR, BYTM_USB2_PORT_MAP),
>
> and:
>
>                 /* Set USB2 Port Routing Mask */
>                 REG_PCI_WRITE32(XHCI_USB2PRM, BYTM_USB2_PORT_MAP),
>                 /* Set USB3 Port Routing Mask */
>                 REG_PCI_WRITE32(XHCI_USB3PRM, BYTM_USB3_PORT_MAP),
>                 /*
>                  * Disable ports if requested
>                  */
>                 /* Open per-port disable control override */
>                 REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~0, UPRWC_WR_EN),
>                 REG_PCI_WRITE32(XHCI_USB2PDO, config->usb2_port_disable_mask),
>                 REG_PCI_WRITE32(XHCI_USB3PDO, config->usb3_port_disable_mask),
>                 /* Close per-port disable control override */
>                 REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~UPRWC_WR_EN, 0),
>
> But I can only either see the EHCI or the xHCI controller via
> "pci". If I configure the FSP to enable xHCI (fsp,enable-xhci)
> the EHCI PCI device is not listed. And without this DT property
> the xHCI PCI device is missing. So I only have access to one
> USB controller at the some time.
>
> Any further ideas are really welcome! :)

I'm pretty short on time this month otherwise I would love to look at
this. Can you post a patch that adds all the init code you have found
to baytrail?

>
> BTW: Did you (or somebody else?) already start moving xHCI (PCI) to
> DM yet? If yes, could you perhaps provide this version so that I
> could continue with it.

Yes, see u-boot-x86/samus-working.

>
> Thanks,
> Stefan
>

Regards,
Simon

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Stefan Roese]

Hi Simon,

On 09.03.2016 18:11, Simon Glass wrote:
> On 9 March 2016 at 09:15, Stefan Roese <sr@denx.de> wrote:
>>
>> Hi Simon,
>>
>> On 09.03.2016 00:33, Simon Glass wrote:
>>
>> <snip>
>>
>>>>>> I'm currently struggling with the USB EHCI ports on my custom Bay
>>>>>> Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
>>>>>> only some of the USB EHCI ports are enabled / available. Here
>>>>>> the "usb tree" output with 3 USB keys installed:
>>>>>>
>>>>>> => usb tree
>>>>>> USB device tree:
>>>>>>      1  Hub (480 Mb/s, 0mA)
>>>>>>      |  u-boot EHCI Host Controller
>>>>>>      |
>>>>>>      +-2  Hub (480 Mb/s, 0mA)
>>>>>>        |
>>>>>>        +-3  Hub (480 Mb/s, 100mA)
>>>>>>        | |
>>>>>>        | +-4  Hub (12 Mb/s, 100mA)
>>>>>>        |
>>>>>>        +-5  Mass Storage (480 Mb/s, 200mA)
>>>>>>             JetFlash Mass Storage Device 3281440601
>>>>>>
>>>>>> When I first start the original (AMI) BIOS on this custom board,
>>>>>> and then reboot into U-Boot (without a power-cycle), I see this
>>>>>> configuration:
>>>>>>
>>>>>> => usb tree
>>>>>> USB device tree:
>>>>>>      1  Hub (480 Mb/s, 0mA)
>>>>>>      |  u-boot EHCI Host Controller
>>>>>>      |
>>>>>>      +-2  Hub (480 Mb/s, 0mA)
>>>>>>        |
>>>>>>        +-3  Hub (480 Mb/s, 100mA)
>>>>>>        | |
>>>>>>        | +-4  Hub (12 Mb/s, 100mA)
>>>>>>        |
>>>>>>        +-5  Hub (480 Mb/s, 0mA)
>>>>>>        | |
>>>>>>        | +-6  Mass Storage (480 Mb/s, 200mA)
>>>>>>        | |    Kingston DataTraveler 2.0 50E549C688C4BE7189942766
>>>>>>        | |
>>>>>>        | +-7  Mass Storage (480 Mb/s, 98mA)
>>>>>>        |      USBest Technology USB Mass Storage Device 09092207fbf0c4
>>>>>>        |
>>>>>>        +-8  Mass Storage (480 Mb/s, 200mA)
>>>>>>             JetFlash Mass Storage Device 3281440601
>>>>>>
>>>>>> So now all 3 USB sticks are detected.
>>>>>>
>>>>>> It doesn't seem to be a problem with missing USB power switch
>>>>>> enabling via some GPIOs. I've checked the schematics and all ports
>>>>>> should have power enabled.
>>>>>>
>>>>>> Do you have any quick ideas, what might be missing to enable all
>>>>>> 4 EHCI ports on Bay Trail? There seems to be a per-port disable
>>>>>> feature which might be involved. I'm still pretty new to x86, and
>>>>>> I'm struggling with finding the correct datasheet for this. So any
>>>>>> hints are really appreciated.
>>>>>
>>>>> It might be worth checking the pci bus device list in both cases.
>>>>> Perhaps one of the USB ports is disabled?
>>>>
>>>> IIUTC, its only one PCI device, that handles all EHCI USB 2.0 ports.
>>>> In both cases its this output:
>>>>
>>>> => pci
>>>> Scanning PCI devices on bus 0
>>>> BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
>>>> _____________________________________________________________
>>>> 00.1f.00   0x8086     0x0f1c     Bridge device           0x01
>>>> 00.00.00   0x8086     0x0f00     Bridge device           0x00
>>>> 00.02.00   0x8086     0x0f31     Display controller      0x00
>>>> 00.11.00   0x8086     0x0f15     Base system peripheral  0x05
>>>> 00.12.00   0x8086     0x0f16     Base system peripheral  0x05
>>>> 00.13.00   0x8086     0x0f23     Mass storage controller 0x06
>>>> 00.15.00   0x8086     0x0f28     Multimedia device       0x01
>>>> 00.18.00   0x8086     0x0f40     Base system peripheral  0x01
>>>> 00.18.01   0x8086     0x0f41     Serial bus controller   0x80
>>>> 00.18.02   0x8086     0x0f42     Serial bus controller   0x80
>>>> 00.18.03   0x8086     0x0f43     Serial bus controller   0x80
>>>> 00.18.04   0x8086     0x0f44     Serial bus controller   0x80
>>>> 00.18.05   0x8086     0x0f45     Serial bus controller   0x80
>>>> 00.18.06   0x8086     0x0f46     Serial bus controller   0x80
>>>> 00.18.07   0x8086     0x0f47     Serial bus controller   0x80
>>>> 00.1a.00   0x8086     0x0f18     Cryptographic device    0x80
>>>> 00.1c.00   0x8086     0x0f48     Bridge device           0x04
>>>> 00.1c.03   0x8086     0x0f4e     Bridge device           0x04
>>>> 00.1d.00   0x8086     0x0f34     Serial bus controller   0x03
>>>> 00.1e.00   0x8086     0x0f06     Base system peripheral  0x01
>>>> 00.1e.01   0x8086     0x0f08     Serial bus controller   0x80
>>>> 00.1e.02   0x8086     0x0f09     Serial bus controller   0x80
>>>> 00.1e.04   0x8086     0x0f0c     Simple comm. controller 0x80
>>>> 00.1e.05   0x8086     0x0f0e     Serial bus controller   0x80
>>>> 00.1f.03   0x8086     0x0f12     Serial bus controller   0x05
>>>>
>>>> Here 00.1d.00 is the EHCI controller. The "pci long" output
>>>> is also identical. So its not that simple I'm afraid.
>>>>
>>>> The Intel Atom Processor Z3600 and Z3700 Series Datasheet Vol 1
>>>> mentions in chapter "10.3.1 EHCI USB 2.0 Controller Features" on
>>>> page 150:
>>>>
>>>> ? Per port USB disable
>>>>
>>>> Perhaps this feature is biting me here. I'm wondering how this can
>>>> be configured.
>>>
>>> That sounds likely.
>>>
>>> Also: xHCI and EHCI Port Mapping
>>>
>>> suggests that you need to make sure the ports are being driven by EHCI
>>> instead of XHCI.
>>>
>>> It mentions USB2HCSEL but I cannot find that in the datasheet.
>>
>> Same here.
>>
>>> It does appear here though:
>>>
>>> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/perf_power.c
>>>
>>> See  IOSF_PORT_0x5a here:
>>>
>>> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/broadwell_fsp/src/lib/reg_script.c
>>>
>>> So it looks like you need to set up this port, and perhaps some others
>>> asper that file.
>>
>> I've looked into these coreboot files today. And ported parts of them
>> to U-Boot to run these configurations there as well. Unfortunately
>> without any (positive) effect. Some things I've tested are:
>>
>> Configure 0x5a / 0xd0 (USB2HCSEL???) to different values. All
>> without effect.
>>
>> Unfortunately this value can't be read-out. At least I read always
>> 0 here. So I can't see, if the AMI BIOS version configures here
>> something different.
>
> That's really odd, because it looks like this is a read/write
> interface. Worth digging int I think, and trying to find docs.

I've really tried to find some docs here. But all I can find on the
net are the links to the coreboot source.

I've also printed all 0x5a registers, well not all but from 0x00 to
0x200. And all of them are read as 0. Yes, this is odd but I can't
see that I'm doing something wrong here while reading those values.

>>
>> Then I've started looking into ehci.c:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/ehci.c
>>
>> EHCI_USB2PDO (per-port disable) looked promising here. And writing
>> 0xff into this reg results in all ports disabled:
>>
>> => usb tree
>> USB device tree:
>>    1  Hub (480 Mb/s, 0mA)
>>    |  u-boot EHCI Host Controller
>>    |
>>    +-2  Hub (480 Mb/s, 0mA)
>>
>> So this register at least has some effect. But its initialized with
>> 0 and writing 0 into it does not fix the problem with the missing
>> ports.
>>
>> I also ported the PHY values from usb2_phy_init() without any
>> changes. The values here are the default values, as I can read
>> them back. Also the AMI BIOS does not change these values, I've
>> double checked this as well.
>
> BTW is the AMI BIOS UEFI?

I think so - I need to check to be 100% sure though.

> If so, for now I suppose you could boot into
> U-Boot from that, and deal with the problem later.

Interesting idea. Right now I'm booting into the AMI BIOS once, and then
only doing reset's into U-Boot (I can toggle the SPI NOR chip via
a DIP switch, which is quite handy).

>>
>> So I'm nearly out of ideas right now what else to configure / test
>> to get all ports running. One idea is that the xHCI controller also
>> needs some configuration for this port muxing. See:
>>
>> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/xhci.c:
>>
>>                  /* USB3 SuperSpeed Enable */
>>                  REG_PCI_WRITE32(XHCI_USB3PR, BYTM_USB3_PORT_MAP),
>>                  /* USB2 Port Route to XHCI */
>>                  REG_PCI_WRITE32(XHCI_USB2PR, BYTM_USB2_PORT_MAP),
>>
>> and:
>>
>>                  /* Set USB2 Port Routing Mask */
>>                  REG_PCI_WRITE32(XHCI_USB2PRM, BYTM_USB2_PORT_MAP),
>>                  /* Set USB3 Port Routing Mask */
>>                  REG_PCI_WRITE32(XHCI_USB3PRM, BYTM_USB3_PORT_MAP),
>>                  /*
>>                   * Disable ports if requested
>>                   */
>>                  /* Open per-port disable control override */
>>                  REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~0, UPRWC_WR_EN),
>>                  REG_PCI_WRITE32(XHCI_USB2PDO, config->usb2_port_disable_mask),
>>                  REG_PCI_WRITE32(XHCI_USB3PDO, config->usb3_port_disable_mask),
>>                  /* Close per-port disable control override */
>>                  REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~UPRWC_WR_EN, 0),
>>
>> But I can only either see the EHCI or the xHCI controller via
>> "pci". If I configure the FSP to enable xHCI (fsp,enable-xhci)
>> the EHCI PCI device is not listed. And without this DT property
>> the xHCI PCI device is missing. So I only have access to one
>> USB controller at the some time.
>>
>> Any further ideas are really welcome! :)
>
> I'm pretty short on time this month otherwise I would love to look at
> this.

That would be great, thanks!

> Can you post a patch that adds all the init code you have found
> to baytrail?

I need to clean this mess up a bit before I can post something of
this. And I've used the last few days to implement the USB scanning
enhancements, as you will have noticed in your inbox. :)

I'll definitely come back to your offer beginning of next week
and will post this coreboot register access stuff I've added to
my platform code for testing.

>>
>> BTW: Did you (or somebody else?) already start moving xHCI (PCI) to
>> DM yet? If yes, could you perhaps provide this version so that I
>> could continue with it.
>
> Yes, see u-boot-x86/samus-working.

Thanks. I'll probably look into this next week.

Thanks,
Stefan

[U-Boot] [PATCH v4] x86: baytrail: Configure FSP UPD from device tree

[Simon Glass]

Hi Stefan,

On 11 March 2016 at 09:28, Stefan Roese <sr@denx.de> wrote:
> Hi Simon,
>
>
> On 09.03.2016 18:11, Simon Glass wrote:
>>
>> On 9 March 2016 at 09:15, Stefan Roese <sr@denx.de> wrote:
>>>
>>>
>>> Hi Simon,
>>>
>>> On 09.03.2016 00:33, Simon Glass wrote:
>>>
>>> <snip>
>>>
>>>>>>> I'm currently struggling with the USB EHCI ports on my custom Bay
>>>>>>> Trail x86 board. With the current U-Boot, cloned from the MinnowMAX,
>>>>>>> only some of the USB EHCI ports are enabled / available. Here
>>>>>>> the "usb tree" output with 3 USB keys installed:
>>>>>>>
>>>>>>> => usb tree
>>>>>>> USB device tree:
>>>>>>>      1  Hub (480 Mb/s, 0mA)
>>>>>>>      |  u-boot EHCI Host Controller
>>>>>>>      |
>>>>>>>      +-2  Hub (480 Mb/s, 0mA)
>>>>>>>        |
>>>>>>>        +-3  Hub (480 Mb/s, 100mA)
>>>>>>>        | |
>>>>>>>        | +-4  Hub (12 Mb/s, 100mA)
>>>>>>>        |
>>>>>>>        +-5  Mass Storage (480 Mb/s, 200mA)
>>>>>>>             JetFlash Mass Storage Device 3281440601
>>>>>>>
>>>>>>> When I first start the original (AMI) BIOS on this custom board,
>>>>>>> and then reboot into U-Boot (without a power-cycle), I see this
>>>>>>> configuration:
>>>>>>>
>>>>>>> => usb tree
>>>>>>> USB device tree:
>>>>>>>      1  Hub (480 Mb/s, 0mA)
>>>>>>>      |  u-boot EHCI Host Controller
>>>>>>>      |
>>>>>>>      +-2  Hub (480 Mb/s, 0mA)
>>>>>>>        |
>>>>>>>        +-3  Hub (480 Mb/s, 100mA)
>>>>>>>        | |
>>>>>>>        | +-4  Hub (12 Mb/s, 100mA)
>>>>>>>        |
>>>>>>>        +-5  Hub (480 Mb/s, 0mA)
>>>>>>>        | |
>>>>>>>        | +-6  Mass Storage (480 Mb/s, 200mA)
>>>>>>>        | |    Kingston DataTraveler 2.0 50E549C688C4BE7189942766
>>>>>>>        | |
>>>>>>>        | +-7  Mass Storage (480 Mb/s, 98mA)
>>>>>>>        |      USBest Technology USB Mass Storage Device
>>>>>>> 09092207fbf0c4
>>>>>>>        |
>>>>>>>        +-8  Mass Storage (480 Mb/s, 200mA)
>>>>>>>             JetFlash Mass Storage Device 3281440601
>>>>>>>
>>>>>>> So now all 3 USB sticks are detected.
>>>>>>>
>>>>>>> It doesn't seem to be a problem with missing USB power switch
>>>>>>> enabling via some GPIOs. I've checked the schematics and all ports
>>>>>>> should have power enabled.
>>>>>>>
>>>>>>> Do you have any quick ideas, what might be missing to enable all
>>>>>>> 4 EHCI ports on Bay Trail? There seems to be a per-port disable
>>>>>>> feature which might be involved. I'm still pretty new to x86, and
>>>>>>> I'm struggling with finding the correct datasheet for this. So any
>>>>>>> hints are really appreciated.
>>>>>>
>>>>>>
>>>>>> It might be worth checking the pci bus device list in both cases.
>>>>>> Perhaps one of the USB ports is disabled?
>>>>>
>>>>>
>>>>> IIUTC, its only one PCI device, that handles all EHCI USB 2.0 ports.
>>>>> In both cases its this output:
>>>>>
>>>>> => pci
>>>>> Scanning PCI devices on bus 0
>>>>> BusDevFun  VendorId   DeviceId   Device Class       Sub-Class
>>>>> _____________________________________________________________
>>>>> 00.1f.00   0x8086     0x0f1c     Bridge device           0x01
>>>>> 00.00.00   0x8086     0x0f00     Bridge device           0x00
>>>>> 00.02.00   0x8086     0x0f31     Display controller      0x00
>>>>> 00.11.00   0x8086     0x0f15     Base system peripheral  0x05
>>>>> 00.12.00   0x8086     0x0f16     Base system peripheral  0x05
>>>>> 00.13.00   0x8086     0x0f23     Mass storage controller 0x06
>>>>> 00.15.00   0x8086     0x0f28     Multimedia device       0x01
>>>>> 00.18.00   0x8086     0x0f40     Base system peripheral  0x01
>>>>> 00.18.01   0x8086     0x0f41     Serial bus controller   0x80
>>>>> 00.18.02   0x8086     0x0f42     Serial bus controller   0x80
>>>>> 00.18.03   0x8086     0x0f43     Serial bus controller   0x80
>>>>> 00.18.04   0x8086     0x0f44     Serial bus controller   0x80
>>>>> 00.18.05   0x8086     0x0f45     Serial bus controller   0x80
>>>>> 00.18.06   0x8086     0x0f46     Serial bus controller   0x80
>>>>> 00.18.07   0x8086     0x0f47     Serial bus controller   0x80
>>>>> 00.1a.00   0x8086     0x0f18     Cryptographic device    0x80
>>>>> 00.1c.00   0x8086     0x0f48     Bridge device           0x04
>>>>> 00.1c.03   0x8086     0x0f4e     Bridge device           0x04
>>>>> 00.1d.00   0x8086     0x0f34     Serial bus controller   0x03
>>>>> 00.1e.00   0x8086     0x0f06     Base system peripheral  0x01
>>>>> 00.1e.01   0x8086     0x0f08     Serial bus controller   0x80
>>>>> 00.1e.02   0x8086     0x0f09     Serial bus controller   0x80
>>>>> 00.1e.04   0x8086     0x0f0c     Simple comm. controller 0x80
>>>>> 00.1e.05   0x8086     0x0f0e     Serial bus controller   0x80
>>>>> 00.1f.03   0x8086     0x0f12     Serial bus controller   0x05
>>>>>
>>>>> Here 00.1d.00 is the EHCI controller. The "pci long" output
>>>>> is also identical. So its not that simple I'm afraid.
>>>>>
>>>>> The Intel Atom Processor Z3600 and Z3700 Series Datasheet Vol 1
>>>>> mentions in chapter "10.3.1 EHCI USB 2.0 Controller Features" on
>>>>> page 150:
>>>>>
>>>>> ? Per port USB disable
>>>>>
>>>>> Perhaps this feature is biting me here. I'm wondering how this can
>>>>> be configured.
>>>>
>>>>
>>>> That sounds likely.
>>>>
>>>> Also: xHCI and EHCI Port Mapping
>>>>
>>>> suggests that you need to make sure the ports are being driven by EHCI
>>>> instead of XHCI.
>>>>
>>>> It mentions USB2HCSEL but I cannot find that in the datasheet.
>>>
>>>
>>> Same here.
>>>
>>>> It does appear here though:
>>>>
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/perf_power.c
>>>>
>>>> See  IOSF_PORT_0x5a here:
>>>>
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/broadwell_fsp/src/lib/reg_script.c
>>>>
>>>> So it looks like you need to set up this port, and perhaps some others
>>>> asper that file.
>>>
>>>
>>> I've looked into these coreboot files today. And ported parts of them
>>> to U-Boot to run these configurations there as well. Unfortunately
>>> without any (positive) effect. Some things I've tested are:
>>>
>>> Configure 0x5a / 0xd0 (USB2HCSEL???) to different values. All
>>> without effect.
>>>
>>> Unfortunately this value can't be read-out. At least I read always
>>> 0 here. So I can't see, if the AMI BIOS version configures here
>>> something different.
>>
>>
>> That's really odd, because it looks like this is a read/write
>> interface. Worth digging int I think, and trying to find docs.
>
>
> I've really tried to find some docs here. But all I can find on the
> net are the links to the coreboot source.
>
> I've also printed all 0x5a registers, well not all but from 0x00 to
> 0x200. And all of them are read as 0. Yes, this is odd but I can't
> see that I'm doing something wrong here while reading those values.
>
>>>
>>> Then I've started looking into ehci.c:
>>>
>>>
>>> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/ehci.c
>>>
>>> EHCI_USB2PDO (per-port disable) looked promising here. And writing
>>> 0xff into this reg results in all ports disabled:
>>>
>>> => usb tree
>>> USB device tree:
>>>    1  Hub (480 Mb/s, 0mA)
>>>    |  u-boot EHCI Host Controller
>>>    |
>>>    +-2  Hub (480 Mb/s, 0mA)
>>>
>>> So this register at least has some effect. But its initialized with
>>> 0 and writing 0 into it does not fix the problem with the missing
>>> ports.
>>>
>>> I also ported the PHY values from usb2_phy_init() without any
>>> changes. The values here are the default values, as I can read
>>> them back. Also the AMI BIOS does not change these values, I've
>>> double checked this as well.
>>
>>
>> BTW is the AMI BIOS UEFI?
>
>
> I think so - I need to check to be 100% sure though.
>
>> If so, for now I suppose you could boot into
>> U-Boot from that, and deal with the problem later.
>
>
> Interesting idea. Right now I'm booting into the AMI BIOS once, and then
> only doing reset's into U-Boot (I can toggle the SPI NOR chip via
> a DIP switch, which is quite handy).
>
>
>>>
>>> So I'm nearly out of ideas right now what else to configure / test
>>> to get all ports running. One idea is that the xHCI controller also
>>> needs some configuration for this port muxing. See:
>>>
>>>
>>> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/chromeos-2013.04/src/soc/intel/baytrail/xhci.c:
>>>
>>>                  /* USB3 SuperSpeed Enable */
>>>                  REG_PCI_WRITE32(XHCI_USB3PR, BYTM_USB3_PORT_MAP),
>>>                  /* USB2 Port Route to XHCI */
>>>                  REG_PCI_WRITE32(XHCI_USB2PR, BYTM_USB2_PORT_MAP),
>>>
>>> and:
>>>
>>>                  /* Set USB2 Port Routing Mask */
>>>                  REG_PCI_WRITE32(XHCI_USB2PRM, BYTM_USB2_PORT_MAP),
>>>                  /* Set USB3 Port Routing Mask */
>>>                  REG_PCI_WRITE32(XHCI_USB3PRM, BYTM_USB3_PORT_MAP),
>>>                  /*
>>>                   * Disable ports if requested
>>>                   */
>>>                  /* Open per-port disable control override */
>>>                  REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~0,
>>> UPRWC_WR_EN),
>>>                  REG_PCI_WRITE32(XHCI_USB2PDO,
>>> config->usb2_port_disable_mask),
>>>                  REG_PCI_WRITE32(XHCI_USB3PDO,
>>> config->usb3_port_disable_mask),
>>>                  /* Close per-port disable control override */
>>>                  REG_IO_RMW16(ACPI_BASE_ADDRESS + UPRWC, ~UPRWC_WR_EN,
>>> 0),
>>>
>>> But I can only either see the EHCI or the xHCI controller via
>>> "pci". If I configure the FSP to enable xHCI (fsp,enable-xhci)
>>> the EHCI PCI device is not listed. And without this DT property
>>> the xHCI PCI device is missing. So I only have access to one
>>> USB controller at the some time.
>>>
>>> Any further ideas are really welcome! :)
>>
>>
>> I'm pretty short on time this month otherwise I would love to look at
>> this.
>
>
> That would be great, thanks!
>
>> Can you post a patch that adds all the init code you have found
>> to baytrail?
>
>
> I need to clean this mess up a bit before I can post something of
> this. And I've used the last few days to implement the USB scanning
> enhancements, as you will have noticed in your inbox. :)
>
> I'll definitely come back to your offer beginning of next week
> and will post this coreboot register access stuff I've added to
> my platform code for testing.

Actually I was saying that I am short on time, not that I can look at
ti soon :-)  I'm pretty tied up with travel etc. for the next 3 weeks,
sorry.

>
>>>
>>> BTW: Did you (or somebody else?) already start moving xHCI (PCI) to
>>> DM yet? If yes, could you perhaps provide this version so that I
>>> could continue with it.
>>
>>
>> Yes, see u-boot-x86/samus-working.
>
>
> Thanks. I'll probably look into this next week.
>
> Thanks,
> Stefan
>

Regards,
Simon