[U-Boot] [PATCH v3 0/2] Rpi: Add support for second sd host controller

All of lore.kernel.org
 help / color / mirror / Atom feed

* [U-Boot] [PATCH v3 0/2] Rpi: Add support for second sd host controller
@ 2018-01-23 17:05 Alexander Graf
  2018-01-23 17:05 ` [U-Boot] [PATCH v3 1/2] bcm283x: Add pinctrl driver Alexander Graf
  2018-01-23 17:05 ` [U-Boot] [PATCH v3 2/2] mmc: Add bcm2835 sdhost controller Alexander Graf
  0 siblings, 2 replies; 22+ messages in thread
From: Alexander Graf @ 2018-01-23 17:05 UTC (permalink / raw)
  To: u-boot

The Raspberry Pi (bcm283x SoC) family contains 2 IP blocks to drive SD
peripherals: A pretty standard SDHCI one called iProc and a home grown
one called "sdhost".

When driving U-Boot by the same device tree that we use for Linux, we
end up in situations where only the "sdhost" device is available for use.
In those situations, current U-Boot can simply not drive the SD card,
because the device tree disables the SDHCI device.

This patch set also adds a full pinctrl driver for pinmuxing the SD
devices properly to their respective pins. This is necessary because
the RPi firmware doesn't mux the SD pins according to the device tree
but instead expects the payload (usually Linux, U-Boot for us) to do that.

With this patch set, I can successfully use U-Boot on a RPi3 Compute
Module with CONFIG_OF_BOARD=y and a device tree generated by the RPi
firmware (plus a few overlays in config.txt for vc4, serial, etc).

v1 -> v2:

  - Introduce real pinctrl driver
  - Checkpatch fixes
  - Remove hand written pinctrl support

v2 -> v3:

  - Use SPDX license identifier
  - Sort headers
  - Remove useless comments
  - Comment style fixes
  - Add magic constant defines (SDHSTS_CLEAR_MASK, SDEDM_FIFO_FILL*,
                                edm_fifo_fill, SDHST_TIMEOUT_MAX_USEC)
  - Add comments in bcm2835_reset_internal()
  - Replace "r" with "ret"
  - Remove one useless while() indirection in bcm2835_transfer_block_pio()
  - Add comments what each loop does in bcm2835_transfer_block_pio()
  - Remove max_ms parameter in bcm2835_read_wait_sdcmd()
  - Only read once with full timeout in bcm2835_read_wait_sdcmd()
  - Check unsupported response type early in bcm2835_send_command()
  - Return -EBUSY on incomplete command in bcm2835_send_command()
  - Combine SDHSTS_REW_TIME_OUT and SDHSTS_CMD_TIME_OUT cases in
    bcm2835_check_cmd_error()
  - Unfold irq_* check/set in bcm2835_threaded_irq()
  - Declare bcm2835_add_host() as void
  - use dev_read
  - add comment on why GPIO failure is non-fatal

Alexander Graf (2):
  bcm283x: Add pinctrl driver
  mmc: Add bcm2835 sdhost controller

 MAINTAINERS                                |   2 +
 arch/arm/mach-bcm283x/include/mach/gpio.h  |   2 -
 board/raspberrypi/rpi/rpi.c                |   5 +-
 configs/rpi_0_w_defconfig                  |   4 +
 configs/rpi_2_defconfig                    |   4 +
 configs/rpi_3_32b_defconfig                |   4 +
 configs/rpi_3_defconfig                    |   4 +
 configs/rpi_defconfig                      |   4 +
 drivers/gpio/bcm2835_gpio.c                |  29 +-
 drivers/mmc/Kconfig                        |  14 +
 drivers/mmc/Makefile                       |   1 +
 drivers/mmc/bcm2835_sdhost.c               | 979 +++++++++++++++++++++++++++++
 drivers/pinctrl/Kconfig                    |   1 +
 drivers/pinctrl/Makefile                   |   1 +
 drivers/pinctrl/broadcom/Kconfig           |   7 +
 drivers/pinctrl/broadcom/Makefile          |   7 +
 drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 152 +++++
 17 files changed, 1197 insertions(+), 23 deletions(-)
 create mode 100644 drivers/mmc/bcm2835_sdhost.c
 create mode 100644 drivers/pinctrl/broadcom/Kconfig
 create mode 100644 drivers/pinctrl/broadcom/Makefile
 create mode 100644 drivers/pinctrl/broadcom/pinctrl-bcm283x.c

-- 
2.12.3

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [PATCH v3 1/2] bcm283x: Add pinctrl driver
  2018-01-23 17:05 [U-Boot] [PATCH v3 0/2] Rpi: Add support for second sd host controller Alexander Graf
@ 2018-01-23 17:05 ` Alexander Graf
  2018-01-28 18:54   ` [U-Boot] [U-Boot,v3,1/2] " Tom Rini
  2018-01-23 17:05 ` [U-Boot] [PATCH v3 2/2] mmc: Add bcm2835 sdhost controller Alexander Graf
  1 sibling, 1 reply; 22+ messages in thread
From: Alexander Graf @ 2018-01-23 17:05 UTC (permalink / raw)
  To: u-boot

The bcm283x family of SoCs have a GPIO controller that also acts as
pinctrl controller.

This patch introduces a new pinctrl driver that can actually properly mux
devices into their device tree defined pin states and is now the primary
owner of the gpio device. The previous GPIO driver gets moved into a
subdevice of the pinctrl driver, bound to the same OF node.

That way whenever a device asks for pinctrl support, it gets it
automatically from the pinctrl driver and GPIO support is still available
in the normal command line phase.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v2 -> v3:

  - use dev_read
  - add comment on why GPIO failure is non-fatal
---
 MAINTAINERS                                |   1 +
 arch/arm/mach-bcm283x/include/mach/gpio.h  |   2 -
 board/raspberrypi/rpi/rpi.c                |   5 +-
 configs/rpi_0_w_defconfig                  |   4 +
 configs/rpi_2_defconfig                    |   4 +
 configs/rpi_3_32b_defconfig                |   4 +
 configs/rpi_3_defconfig                    |   4 +
 configs/rpi_defconfig                      |   4 +
 drivers/gpio/bcm2835_gpio.c                |  29 ++----
 drivers/pinctrl/Kconfig                    |   1 +
 drivers/pinctrl/Makefile                   |   1 +
 drivers/pinctrl/broadcom/Kconfig           |   7 ++
 drivers/pinctrl/broadcom/Makefile          |   7 ++
 drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 152 +++++++++++++++++++++++++++++
 14 files changed, 202 insertions(+), 23 deletions(-)
 create mode 100644 drivers/pinctrl/broadcom/Kconfig
 create mode 100644 drivers/pinctrl/broadcom/Makefile
 create mode 100644 drivers/pinctrl/broadcom/pinctrl-bcm283x.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 754db5553d..1f2545191b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -100,6 +100,7 @@ F:	drivers/mmc/bcm2835_sdhci.c
 F:	drivers/serial/serial_bcm283x_mu.c
 F:	drivers/video/bcm2835.c
 F:	include/dm/platform_data/serial_bcm283x_mu.h
+F:	drivers/pinctrl/broadcom/
 
 ARM FREESCALE IMX
 M:	Stefano Babic <sbabic@denx.de>
diff --git a/arch/arm/mach-bcm283x/include/mach/gpio.h b/arch/arm/mach-bcm283x/include/mach/gpio.h
index daaee52f81..7b4ddc9246 100644
--- a/arch/arm/mach-bcm283x/include/mach/gpio.h
+++ b/arch/arm/mach-bcm283x/include/mach/gpio.h
@@ -61,6 +61,4 @@ struct bcm2835_gpio_platdata {
 	unsigned long base;
 };
 
-int bcm2835_gpio_get_func_id(struct udevice *dev, unsigned gpio);
-
 #endif /* _BCM2835_GPIO_H_ */
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 3b7a54f519..c8924d4362 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -24,6 +24,7 @@
 #include <asm/armv8/mmu.h>
 #endif
 #include <watchdog.h>
+#include <dm/pinctrl.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -430,10 +431,10 @@ static bool rpi_is_serial_active(void)
 	 * out whether it is available is to check if the RX pin is muxed.
 	 */
 
-	if (uclass_first_device(UCLASS_GPIO, &dev) || !dev)
+	if (uclass_first_device(UCLASS_PINCTRL, &dev) || !dev)
 		return true;
 
-	if (bcm2835_gpio_get_func_id(dev, serial_gpio) != BCM2835_GPIO_ALT5)
+	if (pinctrl_get_gpio_mux(dev, 0, serial_gpio) != BCM2835_GPIO_ALT5)
 		return false;
 
 	return true;
diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index 12482944af..8ed7a58659 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -32,3 +32,7 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_FULL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_BCM283X=y
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index c45ffb65af..b30e6e144c 100644
--- a/configs/rpi_2_defconfig
+++ b/configs/rpi_2_defconfig
@@ -32,3 +32,7 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_FULL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_BCM283X=y
diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
index f7aed35797..bb40644064 100644
--- a/configs/rpi_3_32b_defconfig
+++ b/configs/rpi_3_32b_defconfig
@@ -34,3 +34,7 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_FULL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_BCM283X=y
diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
index 9416e3b8fe..8306bc251d 100644
--- a/configs/rpi_3_defconfig
+++ b/configs/rpi_3_defconfig
@@ -34,3 +34,7 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_FULL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_BCM283X=y
diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
index 3bfa745c2e..a7a079ddab 100644
--- a/configs/rpi_defconfig
+++ b/configs/rpi_defconfig
@@ -32,3 +32,7 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_FULL=y
+# CONFIG_PINCTRL_GENERIC is not set
+CONFIG_PINCTRL_BCM283X=y
diff --git a/drivers/gpio/bcm2835_gpio.c b/drivers/gpio/bcm2835_gpio.c
index beaa21853a..d68f8df32d 100644
--- a/drivers/gpio/bcm2835_gpio.c
+++ b/drivers/gpio/bcm2835_gpio.c
@@ -7,6 +7,7 @@
 
 #include <common.h>
 #include <dm.h>
+#include <dm/pinctrl.h>
 #include <errno.h>
 #include <asm/gpio.h>
 #include <asm/io.h>
@@ -14,6 +15,7 @@
 
 struct bcm2835_gpios {
 	struct bcm2835_gpio_regs *reg;
+	struct udevice *pinctrl;
 };
 
 static int bcm2835_gpio_direction_input(struct udevice *dev, unsigned gpio)
@@ -29,7 +31,7 @@ static int bcm2835_gpio_direction_input(struct udevice *dev, unsigned gpio)
 	return 0;
 }
 
-static int bcm2835_gpio_direction_output(struct udevice *dev, unsigned gpio,
+static int bcm2835_gpio_direction_output(struct udevice *dev, unsigned int gpio,
 					 int value)
 {
 	struct bcm2835_gpios *gpios = dev_get_priv(dev);
@@ -73,19 +75,12 @@ static int bcm2835_gpio_set_value(struct udevice *dev, unsigned gpio,
 	return 0;
 }
 
-int bcm2835_gpio_get_func_id(struct udevice *dev, unsigned gpio)
-{
-	struct bcm2835_gpios *gpios = dev_get_priv(dev);
-	u32 val;
-
-	val = readl(&gpios->reg->gpfsel[BCM2835_GPIO_FSEL_BANK(gpio)]);
-
-	return (val >> BCM2835_GPIO_FSEL_SHIFT(gpio) & BCM2835_GPIO_FSEL_MASK);
-}
-
 static int bcm2835_gpio_get_function(struct udevice *dev, unsigned offset)
 {
-	int funcid = bcm2835_gpio_get_func_id(dev, offset);
+	struct bcm2835_gpios *priv = dev_get_priv(dev);
+	int funcid;
+
+	funcid = pinctrl_get_gpio_mux(priv->pinctrl, 0, offset);
 
 	switch (funcid) {
 	case BCM2835_GPIO_OUTPUT:
@@ -97,7 +92,6 @@ static int bcm2835_gpio_get_function(struct udevice *dev, unsigned offset)
 	}
 }
 
-
 static const struct dm_gpio_ops gpio_bcm2835_ops = {
 	.direction_input	= bcm2835_gpio_direction_input,
 	.direction_output	= bcm2835_gpio_direction_output,
@@ -116,15 +110,13 @@ static int bcm2835_gpio_probe(struct udevice *dev)
 	uc_priv->gpio_count = BCM2835_GPIO_COUNT;
 	gpios->reg = (struct bcm2835_gpio_regs *)plat->base;
 
+	/* We know we're spawned by the pinctrl driver */
+	gpios->pinctrl = dev->parent;
+
 	return 0;
 }
 
 #if CONFIG_IS_ENABLED(OF_CONTROL)
-static const struct udevice_id bcm2835_gpio_id[] = {
-	{.compatible = "brcm,bcm2835-gpio"},
-	{}
-};
-
 static int bcm2835_gpio_ofdata_to_platdata(struct udevice *dev)
 {
 	struct bcm2835_gpio_platdata *plat = dev_get_platdata(dev);
@@ -142,7 +134,6 @@ static int bcm2835_gpio_ofdata_to_platdata(struct udevice *dev)
 U_BOOT_DRIVER(gpio_bcm2835) = {
 	.name	= "gpio_bcm2835",
 	.id	= UCLASS_GPIO,
-	.of_match = of_match_ptr(bcm2835_gpio_id),
 	.ofdata_to_platdata = of_match_ptr(bcm2835_gpio_ofdata_to_platdata),
 	.platdata_auto_alloc_size = sizeof(struct bcm2835_gpio_platdata),
 	.ops	= &gpio_bcm2835_ops,
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 7e8e4b0b27..0a4dd3c0cf 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -306,5 +306,6 @@ source "drivers/pinctrl/renesas/Kconfig"
 source "drivers/pinctrl/uniphier/Kconfig"
 source "drivers/pinctrl/exynos/Kconfig"
 source "drivers/pinctrl/mvebu/Kconfig"
+source "drivers/pinctrl/broadcom/Kconfig"
 
 endmenu
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 8c04028dfb..c7135d29f8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_ARCH_MVEBU)	+= mvebu/
 obj-$(CONFIG_PINCTRL_SINGLE)	+= pinctrl-single.o
 obj-$(CONFIG_PINCTRL_STI)	+= pinctrl-sti.o
 obj-$(CONFIG_PINCTRL_STM32)	+= pinctrl_stm32.o
+obj-y				+= broadcom/
diff --git a/drivers/pinctrl/broadcom/Kconfig b/drivers/pinctrl/broadcom/Kconfig
new file mode 100644
index 0000000000..4056782213
--- /dev/null
+++ b/drivers/pinctrl/broadcom/Kconfig
@@ -0,0 +1,7 @@
+config PINCTRL_BCM283X
+	depends on ARCH_BCM283X && PINCTRL_FULL && OF_CONTROL
+	default y
+	bool "Broadcom 283x family pin control driver"
+	help
+	   Support pin multiplexing and pin configuration control on
+	   Broadcom's 283x family of SoCs.
diff --git a/drivers/pinctrl/broadcom/Makefile b/drivers/pinctrl/broadcom/Makefile
new file mode 100644
index 0000000000..2a1e550f88
--- /dev/null
+++ b/drivers/pinctrl/broadcom/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2018 Alexander Graf <agraf@suse.de>
+#
+# SPDX-License-Identifier:	GPL-2.0
+# https://spdx.org/licenses
+
+obj-$(CONFIG_PINCTRL_BCM283X) += pinctrl-bcm283x.o
diff --git a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
new file mode 100644
index 0000000000..83dde2302e
--- /dev/null
+++ b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (C) 2018 Alexander Graf <agraf@suse.de>
+ *
+ * Based on drivers/pinctrl/mvebu/pinctrl-mvebu.c and
+ *          drivers/gpio/bcm2835_gpio.c
+ *
+ * This driver gets instantiated by the GPIO driver, because both devices
+ * share the same device node.
+ *
+ * SPDX-License-Identifier:	GPL-2.0
+ * https://spdx.org/licenses
+ */
+
+#include <common.h>
+#include <config.h>
+#include <errno.h>
+#include <dm.h>
+#include <dm/pinctrl.h>
+#include <dm/root.h>
+#include <dm/device-internal.h>
+#include <dm/lists.h>
+#include <asm/system.h>
+#include <asm/io.h>
+#include <asm/gpio.h>
+
+struct bcm283x_pinctrl_priv {
+	u32 *base_reg;
+};
+
+#define MAX_PINS_PER_BANK 16
+
+static void bcm2835_gpio_set_func_id(struct udevice *dev, unsigned int gpio,
+				     int func)
+{
+	struct bcm283x_pinctrl_priv *priv = dev_get_priv(dev);
+	int reg_offset;
+	int field_offset;
+
+	reg_offset = BCM2835_GPIO_FSEL_BANK(gpio);
+	field_offset = BCM2835_GPIO_FSEL_SHIFT(gpio);
+
+	clrsetbits_le32(&priv->base_reg[reg_offset],
+			BCM2835_GPIO_FSEL_MASK << field_offset,
+			(func & BCM2835_GPIO_FSEL_MASK) << field_offset);
+}
+
+static int bcm2835_gpio_get_func_id(struct udevice *dev, unsigned int gpio)
+{
+	struct bcm283x_pinctrl_priv *priv = dev_get_priv(dev);
+	u32 val;
+
+	val = readl(&priv->base_reg[BCM2835_GPIO_FSEL_BANK(gpio)]);
+
+	return (val >> BCM2835_GPIO_FSEL_SHIFT(gpio) & BCM2835_GPIO_FSEL_MASK);
+}
+
+/*
+ * bcm283x_pinctrl_set_state: configure pin functions.
+ * @dev: the pinctrl device to be configured.
+ * @config: the state to be configured.
+ * @return: 0 in success
+ */
+int bcm283x_pinctrl_set_state(struct udevice *dev, struct udevice *config)
+{
+	u32 pin_arr[MAX_PINS_PER_BANK];
+	u32 function;
+	int i, len, pin_count = 0;
+
+	if (!dev_read_prop(config, "brcm,pins", &len) || !len ||
+	    len & 0x3 || dev_read_u32_array(config, "brcm,pins", pin_arr,
+						  len / sizeof(u32))) {
+		debug("Failed reading pins array for pinconfig %s (%d)\n",
+		      config->name, len);
+		return -EINVAL;
+	}
+
+	pin_count = len / sizeof(u32);
+
+	function = dev_read_u32_default(config, "brcm,function", -1);
+	if (function < 0) {
+		debug("Failed reading function for pinconfig %s (%d)\n",
+		      config->name, function);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < pin_count; i++)
+		bcm2835_gpio_set_func_id(dev, pin_arr[i], function);
+
+	return 0;
+}
+
+static int bcm283x_pinctrl_get_gpio_mux(struct udevice *dev, int banknum,
+					int index)
+{
+	if (banknum != 0)
+		return -EINVAL;
+
+	return bcm2835_gpio_get_func_id(dev, index);
+}
+
+static const struct udevice_id bcm2835_pinctrl_id[] = {
+	{.compatible = "brcm,bcm2835-gpio"},
+	{}
+};
+
+int bcm283x_pinctl_probe(struct udevice *dev)
+{
+	struct bcm283x_pinctrl_priv *priv;
+	int ret;
+	struct udevice *pdev;
+
+	priv = dev_get_priv(dev);
+	if (!priv) {
+		debug("%s: Failed to get private\n", __func__);
+		return -EINVAL;
+	}
+
+	priv->base_reg = dev_read_addr_ptr(dev);
+	if (priv->base_reg == (void *)FDT_ADDR_T_NONE) {
+		debug("%s: Failed to get base address\n", __func__);
+		return -EINVAL;
+	}
+
+	/* Create GPIO device as well */
+	ret = device_bind(dev, lists_driver_lookup_name("gpio_bcm2835"),
+			  "gpio_bcm2835", NULL, dev_of_offset(dev), &pdev);
+	if (ret) {
+		/*
+		 * While we really want the pinctrl driver to work to make
+		 * devices go where they should go, the GPIO controller is
+		 * not quite as crucial as it's only rarely used, so don't
+		 * fail here.
+		 */
+		printf("Failed to bind GPIO driver\n");
+	}
+
+	return 0;
+}
+
+static struct pinctrl_ops bcm283x_pinctrl_ops = {
+	.set_state	= bcm283x_pinctrl_set_state,
+	.get_gpio_mux	= bcm283x_pinctrl_get_gpio_mux,
+};
+
+U_BOOT_DRIVER(pinctrl_bcm283x) = {
+	.name		= "bcm283x_pinctrl",
+	.id		= UCLASS_PINCTRL,
+	.of_match	= of_match_ptr(bcm2835_pinctrl_id),
+	.priv_auto_alloc_size = sizeof(struct bcm283x_pinctrl_priv),
+	.ops		= &bcm283x_pinctrl_ops,
+	.probe		= bcm283x_pinctl_probe
+};
-- 
2.12.3

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [U-Boot] [PATCH v3 2/2] mmc: Add bcm2835 sdhost controller
  2018-01-23 17:05 [U-Boot] [PATCH v3 0/2] Rpi: Add support for second sd host controller Alexander Graf
  2018-01-23 17:05 ` [U-Boot] [PATCH v3 1/2] bcm283x: Add pinctrl driver Alexander Graf
@ 2018-01-23 17:05 ` Alexander Graf
  2018-01-28 18:54   ` [U-Boot] [U-Boot,v3,2/2] " Tom Rini
  1 sibling, 1 reply; 22+ messages in thread
From: Alexander Graf @ 2018-01-23 17:05 UTC (permalink / raw)
  To: u-boot

The BCM2835 family of SoCs has 2 different SD controllers: One based on
the SDHCI spec and a custom, home-grown one.

This patch implements a driver for the latter based on the Linux driver.
This is needed so that we can make use of device trees that assume driver
presence of both SD controllers.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - Remove hand written pinctrl support
  - Checkpatch fixes

v2 -> v3:

  - Use SPDX license identifier
  - Sort headers
  - Remove useless comments
  - Comment style fixes
  - Add magic constant defines (SDHSTS_CLEAR_MASK, SDEDM_FIFO_FILL*,
                                edm_fifo_fill, SDHST_TIMEOUT_MAX_USEC)
  - Add comments in bcm2835_reset_internal()
  - Replace "r" with "ret"
  - Remove one useless while() indirection in bcm2835_transfer_block_pio()
  - Add comments what each loop does in bcm2835_transfer_block_pio()
  - Remove max_ms parameter in bcm2835_read_wait_sdcmd()
  - Only read once with full timeout in bcm2835_read_wait_sdcmd()
  - Check unsupported response type early in bcm2835_send_command()
  - Return -EBUSY on incomplete command in bcm2835_send_command()
  - Combine SDHSTS_REW_TIME_OUT and SDHSTS_CMD_TIME_OUT cases in
    bcm2835_check_cmd_error()
  - Unfold irq_* check/set in bcm2835_threaded_irq()
  - Declare bcm2835_add_host() as void
---
 MAINTAINERS                  |   1 +
 drivers/mmc/Kconfig          |  14 +
 drivers/mmc/Makefile         |   1 +
 drivers/mmc/bcm2835_sdhost.c | 979 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 995 insertions(+)
 create mode 100644 drivers/mmc/bcm2835_sdhost.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1f2545191b..728d38aebf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -97,6 +97,7 @@ S:	Orphaned (Since 2017-07)
 F:	arch/arm/mach-bcm283x/
 F:	drivers/gpio/bcm2835_gpio.c
 F:	drivers/mmc/bcm2835_sdhci.c
+F:	drivers/mmc/bcm2835_sdhost.c
 F:	drivers/serial/serial_bcm283x_mu.c
 F:	drivers/video/bcm2835.c
 F:	include/dm/platform_data/serial_bcm283x_mu.h
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index ab0627a8af..9b90db908b 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -256,6 +256,20 @@ config MMC_UNIPHIER
 	  This selects support for the Matsushita SD/MMC Host Controller on
 	  SocioNext UniPhier and Renesas RCar SoCs.
 
+config MMC_BCM2835
+	bool "BCM2835 family custom SD/MMC Host Controller support"
+	depends on ARCH_BCM283X
+	depends on BLK && DM_MMC
+	depends on OF_CONTROL
+	default y
+	help
+	  This selects support for the custom SD host controller in the BCM2835
+	  family of devices.
+
+	  If you have a BCM2835 platform with SD or MMC devices, say Y here.
+
+	  If unsure, say N.
+
 config MMC_SANDBOX
 	bool "Sandbox MMC support"
 	depends on SANDBOX
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 64b6f21c61..42113e2603 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_MMC_SDHCI_ZYNQ)		+= zynq_sdhci.o
 
 obj-$(CONFIG_MMC_SUNXI)			+= sunxi_mmc.o
 obj-$(CONFIG_MMC_UNIPHIER)		+= uniphier-sd.o
+obj-$(CONFIG_MMC_BCM2835)		+= bcm2835_sdhost.o
diff --git a/drivers/mmc/bcm2835_sdhost.c b/drivers/mmc/bcm2835_sdhost.c
new file mode 100644
index 0000000000..1bf52a3019
--- /dev/null
+++ b/drivers/mmc/bcm2835_sdhost.c
@@ -0,0 +1,979 @@
+/*
+ * bcm2835 sdhost driver.
+ *
+ * The 2835 has two SD controllers: The Arasan sdhci controller
+ * (supported by the iproc driver) and a custom sdhost controller
+ * (supported by this driver).
+ *
+ * The sdhci controller supports both sdcard and sdio.  The sdhost
+ * controller supports the sdcard only, but has better performance.
+ * Also note that the rpi3 has sdio wifi, so driving the sdcard with
+ * the sdhost controller allows to use the sdhci controller for wifi
+ * support.
+ *
+ * The configuration is done by devicetree via pin muxing.  Both
+ * SD controller are available on the same pins (2 pin groups = pin 22
+ * to 27 + pin 48 to 53).  So it's possible to use both SD controllers
+ * at the same time with different pin groups.
+ *
+ * This code was ported to U-Boot by
+ *  Alexander Graf <agraf@suse.de>
+ * and is based on drivers/mmc/host/bcm2835.c in Linux which is written by
+ *  Phil Elwell <phil@raspberrypi.org>
+ *  Copyright (C) 2015-2016 Raspberry Pi (Trading) Ltd.
+ * which is based on
+ *  mmc-bcm2835.c by Gellert Weisz
+ * which is, in turn, based on
+ *  sdhci-bcm2708.c by Broadcom
+ *  sdhci-bcm2835.c by Stephen Warren and Oleksandr Tymoshenko
+ *  sdhci.c and sdhci-pci.c by Pierre Ossman
+ *
+ * SPDX-License-Identifier:    GPL-2.0
+ */
+#include <clk.h>
+#include <common.h>
+#include <dm.h>
+#include <mmc.h>
+#include <asm/arch/msg.h>
+#include <asm/unaligned.h>
+#include <linux/compat.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/sizes.h>
+#include <mach/gpio.h>
+#include <power/regulator.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define msleep(a) udelay(a * 1000)
+
+#define SDCMD  0x00 /* Command to SD card              - 16 R/W */
+#define SDARG  0x04 /* Argument to SD card             - 32 R/W */
+#define SDTOUT 0x08 /* Start value for timeout counter - 32 R/W */
+#define SDCDIV 0x0c /* Start value for clock divider   - 11 R/W */
+#define SDRSP0 0x10 /* SD card response (31:0)         - 32 R   */
+#define SDRSP1 0x14 /* SD card response (63:32)        - 32 R   */
+#define SDRSP2 0x18 /* SD card response (95:64)        - 32 R   */
+#define SDRSP3 0x1c /* SD card response (127:96)       - 32 R   */
+#define SDHSTS 0x20 /* SD host status                  - 11 R/W */
+#define SDVDD  0x30 /* SD card power control           -  1 R/W */
+#define SDEDM  0x34 /* Emergency Debug Mode            - 13 R/W */
+#define SDHCFG 0x38 /* Host configuration              -  2 R/W */
+#define SDHBCT 0x3c /* Host byte count (debug)         - 32 R/W */
+#define SDDATA 0x40 /* Data to/from SD card            - 32 R/W */
+#define SDHBLC 0x50 /* Host block count (SDIO/SDHC)    -  9 R/W */
+
+#define SDCMD_NEW_FLAG			0x8000
+#define SDCMD_FAIL_FLAG			0x4000
+#define SDCMD_BUSYWAIT			0x800
+#define SDCMD_NO_RESPONSE		0x400
+#define SDCMD_LONG_RESPONSE		0x200
+#define SDCMD_WRITE_CMD			0x80
+#define SDCMD_READ_CMD			0x40
+#define SDCMD_CMD_MASK			0x3f
+
+#define SDCDIV_MAX_CDIV			0x7ff
+
+#define SDHSTS_BUSY_IRPT		0x400
+#define SDHSTS_BLOCK_IRPT		0x200
+#define SDHSTS_SDIO_IRPT		0x100
+#define SDHSTS_REW_TIME_OUT		0x80
+#define SDHSTS_CMD_TIME_OUT		0x40
+#define SDHSTS_CRC16_ERROR		0x20
+#define SDHSTS_CRC7_ERROR		0x10
+#define SDHSTS_FIFO_ERROR		0x08
+#define SDHSTS_DATA_FLAG		0x01
+
+#define SDHSTS_CLEAR_MASK		(SDHSTS_BUSY_IRPT | \
+					 SDHSTS_BLOCK_IRPT | \
+					 SDHSTS_SDIO_IRPT | \
+					 SDHSTS_REW_TIME_OUT | \
+					 SDHSTS_CMD_TIME_OUT | \
+					 SDHSTS_CRC16_ERROR | \
+					 SDHSTS_CRC7_ERROR | \
+					 SDHSTS_FIFO_ERROR)
+
+#define SDHSTS_TRANSFER_ERROR_MASK	(SDHSTS_CRC7_ERROR | \
+					 SDHSTS_CRC16_ERROR | \
+					 SDHSTS_REW_TIME_OUT | \
+					 SDHSTS_FIFO_ERROR)
+
+#define SDHSTS_ERROR_MASK		(SDHSTS_CMD_TIME_OUT | \
+					 SDHSTS_TRANSFER_ERROR_MASK)
+
+#define SDHCFG_BUSY_IRPT_EN	BIT(10)
+#define SDHCFG_BLOCK_IRPT_EN	BIT(8)
+#define SDHCFG_SDIO_IRPT_EN	BIT(5)
+#define SDHCFG_DATA_IRPT_EN	BIT(4)
+#define SDHCFG_SLOW_CARD	BIT(3)
+#define SDHCFG_WIDE_EXT_BUS	BIT(2)
+#define SDHCFG_WIDE_INT_BUS	BIT(1)
+#define SDHCFG_REL_CMD_LINE	BIT(0)
+
+#define SDVDD_POWER_OFF		0
+#define SDVDD_POWER_ON		1
+
+#define SDEDM_FORCE_DATA_MODE	BIT(19)
+#define SDEDM_CLOCK_PULSE	BIT(20)
+#define SDEDM_BYPASS		BIT(21)
+
+#define SDEDM_FIFO_FILL_SHIFT	4
+#define SDEDM_FIFO_FILL_MASK	0x1f
+static u32 edm_fifo_fill(u32 edm)
+{
+	return (edm >> SDEDM_FIFO_FILL_SHIFT) & SDEDM_FIFO_FILL_MASK;
+}
+
+#define SDEDM_WRITE_THRESHOLD_SHIFT	9
+#define SDEDM_READ_THRESHOLD_SHIFT	14
+#define SDEDM_THRESHOLD_MASK		0x1f
+
+#define SDEDM_FSM_MASK		0xf
+#define SDEDM_FSM_IDENTMODE	0x0
+#define SDEDM_FSM_DATAMODE	0x1
+#define SDEDM_FSM_READDATA	0x2
+#define SDEDM_FSM_WRITEDATA	0x3
+#define SDEDM_FSM_READWAIT	0x4
+#define SDEDM_FSM_READCRC	0x5
+#define SDEDM_FSM_WRITECRC	0x6
+#define SDEDM_FSM_WRITEWAIT1	0x7
+#define SDEDM_FSM_POWERDOWN	0x8
+#define SDEDM_FSM_POWERUP	0x9
+#define SDEDM_FSM_WRITESTART1	0xa
+#define SDEDM_FSM_WRITESTART2	0xb
+#define SDEDM_FSM_GENPULSES	0xc
+#define SDEDM_FSM_WRITEWAIT2	0xd
+#define SDEDM_FSM_STARTPOWDOWN	0xf
+
+#define SDDATA_FIFO_WORDS	16
+
+#define FIFO_READ_THRESHOLD	4
+#define FIFO_WRITE_THRESHOLD	4
+#define SDDATA_FIFO_PIO_BURST	8
+
+#define SDHST_TIMEOUT_MAX_USEC	100000
+
+struct bcm2835_plat {
+	struct mmc_config cfg;
+	struct mmc mmc;
+};
+
+struct bcm2835_host {
+	void __iomem		*ioaddr;
+	u32			phys_addr;
+
+	int			clock;		/* Current clock speed */
+	unsigned int		max_clk;	/* Max possible freq */
+	unsigned int		blocks;		/* remaining PIO blocks */
+	int			irq;		/* Device IRQ */
+
+	u32			ns_per_fifo_word;
+
+	/* cached registers */
+	u32			hcfg;
+	u32			cdiv;
+
+	struct mmc_cmd	*cmd;		/* Current command */
+	struct mmc_data		*data;		/* Current data request */
+	bool			data_complete:1;/* Data finished before cmd */
+	bool			use_busy:1;	/* Wait for busy interrupt */
+	bool			wait_data_complete:1;	/* Wait for data */
+
+	/* for threaded irq handler */
+	bool			irq_block;
+	bool			irq_busy;
+	bool			irq_data;
+
+	struct udevice		*dev;
+	struct mmc		*mmc;
+	struct bcm2835_plat	*plat;
+};
+
+static void bcm2835_dumpregs(struct bcm2835_host *host)
+{
+	dev_dbg(dev, "=========== REGISTER DUMP ===========\n");
+	dev_dbg(dev, "SDCMD  0x%08x\n", readl(host->ioaddr + SDCMD));
+	dev_dbg(dev, "SDARG  0x%08x\n", readl(host->ioaddr + SDARG));
+	dev_dbg(dev, "SDTOUT 0x%08x\n", readl(host->ioaddr + SDTOUT));
+	dev_dbg(dev, "SDCDIV 0x%08x\n", readl(host->ioaddr + SDCDIV));
+	dev_dbg(dev, "SDRSP0 0x%08x\n", readl(host->ioaddr + SDRSP0));
+	dev_dbg(dev, "SDRSP1 0x%08x\n", readl(host->ioaddr + SDRSP1));
+	dev_dbg(dev, "SDRSP2 0x%08x\n", readl(host->ioaddr + SDRSP2));
+	dev_dbg(dev, "SDRSP3 0x%08x\n", readl(host->ioaddr + SDRSP3));
+	dev_dbg(dev, "SDHSTS 0x%08x\n", readl(host->ioaddr + SDHSTS));
+	dev_dbg(dev, "SDVDD  0x%08x\n", readl(host->ioaddr + SDVDD));
+	dev_dbg(dev, "SDEDM  0x%08x\n", readl(host->ioaddr + SDEDM));
+	dev_dbg(dev, "SDHCFG 0x%08x\n", readl(host->ioaddr + SDHCFG));
+	dev_dbg(dev, "SDHBCT 0x%08x\n", readl(host->ioaddr + SDHBCT));
+	dev_dbg(dev, "SDHBLC 0x%08x\n", readl(host->ioaddr + SDHBLC));
+	dev_dbg(dev, "===========================================\n");
+}
+
+static void bcm2835_reset_internal(struct bcm2835_host *host)
+{
+	u32 temp;
+
+	writel(SDVDD_POWER_OFF, host->ioaddr + SDVDD);
+	writel(0, host->ioaddr + SDCMD);
+	writel(0, host->ioaddr + SDARG);
+	/* Set timeout to a big enough value so we don't hit it */
+	writel(0xf00000, host->ioaddr + SDTOUT);
+	writel(0, host->ioaddr + SDCDIV);
+	/* Clear status register */
+	writel(SDHSTS_CLEAR_MASK, host->ioaddr + SDHSTS);
+	writel(0, host->ioaddr + SDHCFG);
+	writel(0, host->ioaddr + SDHBCT);
+	writel(0, host->ioaddr + SDHBLC);
+
+	/* Limit fifo usage due to silicon bug */
+	temp = readl(host->ioaddr + SDEDM);
+	temp &= ~((SDEDM_THRESHOLD_MASK << SDEDM_READ_THRESHOLD_SHIFT) |
+		  (SDEDM_THRESHOLD_MASK << SDEDM_WRITE_THRESHOLD_SHIFT));
+	temp |= (FIFO_READ_THRESHOLD << SDEDM_READ_THRESHOLD_SHIFT) |
+		(FIFO_WRITE_THRESHOLD << SDEDM_WRITE_THRESHOLD_SHIFT);
+	writel(temp, host->ioaddr + SDEDM);
+	/* Wait for FIFO threshold to populate */
+	msleep(20);
+	writel(SDVDD_POWER_ON, host->ioaddr + SDVDD);
+	/* Wait for all components to go through power on cycle */
+	msleep(20);
+	host->clock = 0;
+	writel(host->hcfg, host->ioaddr + SDHCFG);
+	writel(host->cdiv, host->ioaddr + SDCDIV);
+}
+
+static int bcm2835_finish_command(struct bcm2835_host *host);
+
+static void bcm2835_wait_transfer_complete(struct bcm2835_host *host)
+{
+	int timediff;
+	u32 alternate_idle;
+
+	alternate_idle = (host->data->flags & MMC_DATA_READ) ?
+		SDEDM_FSM_READWAIT : SDEDM_FSM_WRITESTART1;
+
+	timediff = 0;
+
+	while (1) {
+		u32 edm, fsm;
+
+		edm = readl(host->ioaddr + SDEDM);
+		fsm = edm & SDEDM_FSM_MASK;
+
+		if ((fsm == SDEDM_FSM_IDENTMODE) ||
+		    (fsm == SDEDM_FSM_DATAMODE))
+			break;
+		if (fsm == alternate_idle) {
+			writel(edm | SDEDM_FORCE_DATA_MODE,
+			       host->ioaddr + SDEDM);
+			break;
+		}
+
+		/* Error out after 100000 register reads (~1s) */
+		if (timediff++ == 100000) {
+			dev_err(host->dev,
+				"wait_transfer_complete - still waiting after %d retries\n",
+				timediff);
+			bcm2835_dumpregs(host);
+			return;
+		}
+	}
+}
+
+static int bcm2835_transfer_block_pio(struct bcm2835_host *host, bool is_read)
+{
+	struct mmc_data *data = host->data;
+	size_t blksize = data->blocksize;
+	int copy_words;
+	u32 hsts = 0;
+	u32 *buf;
+
+	if (blksize % sizeof(u32))
+		return -EINVAL;
+
+	buf = is_read ? (u32 *)data->dest : (u32 *)data->src;
+
+	if (is_read)
+		data->dest += blksize;
+	else
+		data->src += blksize;
+
+	copy_words = blksize / sizeof(u32);
+
+	/*
+	 * Copy all contents from/to the FIFO as far as it reaches,
+	 * then wait for it to fill/empty again and rewind.
+	 */
+	while (copy_words) {
+		int burst_words, words;
+		u32 edm;
+
+		burst_words = min(SDDATA_FIFO_PIO_BURST, copy_words);
+		edm = readl(host->ioaddr + SDEDM);
+		if (is_read)
+			words = edm_fifo_fill(edm);
+		else
+			words = SDDATA_FIFO_WORDS - edm_fifo_fill(edm);
+
+		if (words < burst_words) {
+			int fsm_state = (edm & SDEDM_FSM_MASK);
+
+			if ((is_read &&
+			     (fsm_state != SDEDM_FSM_READDATA &&
+			      fsm_state != SDEDM_FSM_READWAIT &&
+			      fsm_state != SDEDM_FSM_READCRC)) ||
+			    (!is_read &&
+			     (fsm_state != SDEDM_FSM_WRITEDATA &&
+			      fsm_state != SDEDM_FSM_WRITESTART1 &&
+			      fsm_state != SDEDM_FSM_WRITESTART2))) {
+				hsts = readl(host->ioaddr + SDHSTS);
+				printf("fsm %x, hsts %08x\n", fsm_state, hsts);
+				if (hsts & SDHSTS_ERROR_MASK)
+					break;
+			}
+
+			continue;
+		} else if (words > copy_words) {
+			words = copy_words;
+		}
+
+		copy_words -= words;
+
+		/* Copy current chunk to/from the FIFO */
+		while (words) {
+			if (is_read)
+				*(buf++) = readl(host->ioaddr + SDDATA);
+			else
+				writel(*(buf++), host->ioaddr + SDDATA);
+			words--;
+		}
+	}
+
+	return 0;
+}
+
+static int bcm2835_transfer_pio(struct bcm2835_host *host)
+{
+	u32 sdhsts;
+	bool is_read;
+	int ret = 0;
+
+	is_read = (host->data->flags & MMC_DATA_READ) != 0;
+	ret = bcm2835_transfer_block_pio(host, is_read);
+
+	if (host->wait_data_complete)
+		bcm2835_wait_transfer_complete(host);
+
+	sdhsts = readl(host->ioaddr + SDHSTS);
+	if (sdhsts & (SDHSTS_CRC16_ERROR |
+		      SDHSTS_CRC7_ERROR |
+		      SDHSTS_FIFO_ERROR)) {
+		printf("%s transfer error - HSTS %08x\n",
+		       is_read ? "read" : "write", sdhsts);
+		ret =  -EILSEQ;
+	} else if ((sdhsts & (SDHSTS_CMD_TIME_OUT |
+			      SDHSTS_REW_TIME_OUT))) {
+		printf("%s timeout error - HSTS %08x\n",
+		       is_read ? "read" : "write", sdhsts);
+		ret = -ETIMEDOUT;
+	}
+
+	return ret;
+}
+
+static void bcm2835_set_transfer_irqs(struct bcm2835_host *host)
+{
+	u32 all_irqs = SDHCFG_DATA_IRPT_EN | SDHCFG_BLOCK_IRPT_EN |
+		SDHCFG_BUSY_IRPT_EN;
+
+	host->hcfg = (host->hcfg & ~all_irqs) |
+		SDHCFG_DATA_IRPT_EN |
+		SDHCFG_BUSY_IRPT_EN;
+
+	writel(host->hcfg, host->ioaddr + SDHCFG);
+}
+
+static
+void bcm2835_prepare_data(struct bcm2835_host *host, struct mmc_cmd *cmd,
+			  struct mmc_data *data)
+{
+	WARN_ON(host->data);
+
+	host->data = data;
+	if (!data)
+		return;
+
+	host->wait_data_complete = cmd->cmdidx != MMC_CMD_READ_MULTIPLE_BLOCK;
+	host->data_complete = false;
+
+	/* Use PIO */
+	host->blocks = data->blocks;
+
+	bcm2835_set_transfer_irqs(host);
+
+	writel(data->blocksize, host->ioaddr + SDHBCT);
+	writel(data->blocks, host->ioaddr + SDHBLC);
+}
+
+static u32 bcm2835_read_wait_sdcmd(struct bcm2835_host *host)
+{
+	u32 value;
+	int ret;
+	int timeout_us = SDHST_TIMEOUT_MAX_USEC;
+
+	ret = readl_poll_timeout(host->ioaddr + SDCMD, value,
+				 !(value & SDCMD_NEW_FLAG), timeout_us);
+	if (ret == -ETIMEDOUT)
+		printf("%s: timeout (%d us)\n", __func__, timeout_us);
+
+	return value;
+}
+
+static int bcm2835_send_command(struct bcm2835_host *host, struct mmc_cmd *cmd,
+				struct mmc_data *data)
+{
+	u32 sdcmd, sdhsts;
+
+	WARN_ON(host->cmd);
+
+	if ((cmd->resp_type & MMC_RSP_136) && (cmd->resp_type & MMC_RSP_BUSY)) {
+		printf("unsupported response type!\n");
+		return -EINVAL;
+	}
+
+	sdcmd = bcm2835_read_wait_sdcmd(host);
+	if (sdcmd & SDCMD_NEW_FLAG) {
+		printf("previous command never completed.\n");
+		bcm2835_dumpregs(host);
+		return -EBUSY;
+	}
+
+	host->cmd = cmd;
+
+	/* Clear any error flags */
+	sdhsts = readl(host->ioaddr + SDHSTS);
+	if (sdhsts & SDHSTS_ERROR_MASK)
+		writel(sdhsts, host->ioaddr + SDHSTS);
+
+	bcm2835_prepare_data(host, cmd, data);
+
+	writel(cmd->cmdarg, host->ioaddr + SDARG);
+
+	sdcmd = cmd->cmdidx & SDCMD_CMD_MASK;
+
+	host->use_busy = false;
+	if (!(cmd->resp_type & MMC_RSP_PRESENT)) {
+		sdcmd |= SDCMD_NO_RESPONSE;
+	} else {
+		if (cmd->resp_type & MMC_RSP_136)
+			sdcmd |= SDCMD_LONG_RESPONSE;
+		if (cmd->resp_type & MMC_RSP_BUSY) {
+			sdcmd |= SDCMD_BUSYWAIT;
+			host->use_busy = true;
+		}
+	}
+
+	if (data) {
+		if (data->flags & MMC_DATA_WRITE)
+			sdcmd |= SDCMD_WRITE_CMD;
+		if (data->flags & MMC_DATA_READ)
+			sdcmd |= SDCMD_READ_CMD;
+	}
+
+	writel(sdcmd | SDCMD_NEW_FLAG, host->ioaddr + SDCMD);
+
+	return 0;
+}
+
+static int bcm2835_transfer_complete(struct bcm2835_host *host)
+{
+	int ret = 0;
+
+	WARN_ON(!host->data_complete);
+
+	host->data = NULL;
+
+	return ret;
+}
+
+static void bcm2835_finish_data(struct bcm2835_host *host)
+{
+	host->hcfg &= ~(SDHCFG_DATA_IRPT_EN | SDHCFG_BLOCK_IRPT_EN);
+	writel(host->hcfg, host->ioaddr + SDHCFG);
+
+	host->data_complete = true;
+
+	if (host->cmd) {
+		/* Data managed to finish before the
+		 * command completed. Make sure we do
+		 * things in the proper order.
+		 */
+		dev_dbg(dev, "Finished early - HSTS %08x\n",
+			readl(host->ioaddr + SDHSTS));
+	} else {
+		bcm2835_transfer_complete(host);
+	}
+}
+
+static int bcm2835_finish_command(struct bcm2835_host *host)
+{
+	struct mmc_cmd *cmd = host->cmd;
+	u32 sdcmd;
+	int ret = 0;
+
+	sdcmd = bcm2835_read_wait_sdcmd(host);
+
+	/* Check for errors */
+	if (sdcmd & SDCMD_NEW_FLAG) {
+		printf("command never completed.\n");
+		bcm2835_dumpregs(host);
+		return -EIO;
+	} else if (sdcmd & SDCMD_FAIL_FLAG) {
+		u32 sdhsts = readl(host->ioaddr + SDHSTS);
+
+		/* Clear the errors */
+		writel(SDHSTS_ERROR_MASK, host->ioaddr + SDHSTS);
+
+		if (!(sdhsts & SDHSTS_CRC7_ERROR) ||
+		    (host->cmd->cmdidx != MMC_CMD_SEND_OP_COND)) {
+			if (sdhsts & SDHSTS_CMD_TIME_OUT) {
+				ret = -ETIMEDOUT;
+			} else {
+				printf("unexpected command %d error\n",
+				       host->cmd->cmdidx);
+				bcm2835_dumpregs(host);
+				ret = -EILSEQ;
+			}
+
+			return ret;
+		}
+	}
+
+	if (cmd->resp_type & MMC_RSP_PRESENT) {
+		if (cmd->resp_type & MMC_RSP_136) {
+			int i;
+
+			for (i = 0; i < 4; i++) {
+				cmd->response[3 - i] =
+					readl(host->ioaddr + SDRSP0 + i * 4);
+			}
+		} else {
+			cmd->response[0] = readl(host->ioaddr + SDRSP0);
+		}
+	}
+
+	/* Processed actual command. */
+	host->cmd = NULL;
+	if (host->data && host->data_complete)
+		ret = bcm2835_transfer_complete(host);
+
+	return ret;
+}
+
+static int bcm2835_check_cmd_error(struct bcm2835_host *host, u32 intmask)
+{
+	int ret = -EINVAL;
+
+	if (!(intmask & SDHSTS_ERROR_MASK))
+		return 0;
+
+	if (!host->cmd)
+		return -EINVAL;
+
+	printf("sdhost_busy_irq: intmask %08x\n", intmask);
+	if (intmask & SDHSTS_CRC7_ERROR) {
+		ret = -EILSEQ;
+	} else if (intmask & (SDHSTS_CRC16_ERROR |
+			      SDHSTS_FIFO_ERROR)) {
+		ret = -EILSEQ;
+	} else if (intmask & (SDHSTS_REW_TIME_OUT | SDHSTS_CMD_TIME_OUT)) {
+		ret = -ETIMEDOUT;
+	}
+	bcm2835_dumpregs(host);
+	return ret;
+}
+
+static int bcm2835_check_data_error(struct bcm2835_host *host, u32 intmask)
+{
+	int ret = 0;
+
+	if (!host->data)
+		return 0;
+	if (intmask & (SDHSTS_CRC16_ERROR | SDHSTS_FIFO_ERROR))
+		ret = -EILSEQ;
+	if (intmask & SDHSTS_REW_TIME_OUT)
+		ret = -ETIMEDOUT;
+
+	if (ret)
+		printf("%s:%d %d\n", __func__, __LINE__, ret);
+
+	return ret;
+}
+
+static void bcm2835_busy_irq(struct bcm2835_host *host)
+{
+	if (WARN_ON(!host->cmd)) {
+		bcm2835_dumpregs(host);
+		return;
+	}
+
+	if (WARN_ON(!host->use_busy)) {
+		bcm2835_dumpregs(host);
+		return;
+	}
+	host->use_busy = false;
+
+	bcm2835_finish_command(host);
+}
+
+static void bcm2835_data_irq(struct bcm2835_host *host, u32 intmask)
+{
+	int ret;
+
+	/*
+	 * There are no dedicated data/space available interrupt
+	 * status bits, so it is necessary to use the single shared
+	 * data/space available FIFO status bits. It is therefore not
+	 * an error to get here when there is no data transfer in
+	 * progress.
+	 */
+	if (!host->data)
+		return;
+
+	ret = bcm2835_check_data_error(host, intmask);
+	if (ret)
+		goto finished;
+
+	if (host->data->flags & MMC_DATA_WRITE) {
+		/* Use the block interrupt for writes after the first block */
+		host->hcfg &= ~(SDHCFG_DATA_IRPT_EN);
+		host->hcfg |= SDHCFG_BLOCK_IRPT_EN;
+		writel(host->hcfg, host->ioaddr + SDHCFG);
+		bcm2835_transfer_pio(host);
+	} else {
+		bcm2835_transfer_pio(host);
+		host->blocks--;
+		if ((host->blocks == 0))
+			goto finished;
+	}
+	return;
+
+finished:
+	host->hcfg &= ~(SDHCFG_DATA_IRPT_EN | SDHCFG_BLOCK_IRPT_EN);
+	writel(host->hcfg, host->ioaddr + SDHCFG);
+}
+
+static void bcm2835_data_threaded_irq(struct bcm2835_host *host)
+{
+	if (!host->data)
+		return;
+	if ((host->blocks == 0))
+		bcm2835_finish_data(host);
+}
+
+static void bcm2835_block_irq(struct bcm2835_host *host)
+{
+	if (WARN_ON(!host->data)) {
+		bcm2835_dumpregs(host);
+		return;
+	}
+
+	WARN_ON(!host->blocks);
+	if ((--host->blocks == 0))
+		bcm2835_finish_data(host);
+	else
+		bcm2835_transfer_pio(host);
+}
+
+static irqreturn_t bcm2835_irq(int irq, void *dev_id)
+{
+	irqreturn_t result = IRQ_NONE;
+	struct bcm2835_host *host = dev_id;
+	u32 intmask;
+
+	intmask = readl(host->ioaddr + SDHSTS);
+
+	writel(SDHSTS_BUSY_IRPT |
+	       SDHSTS_BLOCK_IRPT |
+	       SDHSTS_SDIO_IRPT |
+	       SDHSTS_DATA_FLAG,
+	       host->ioaddr + SDHSTS);
+
+	if (intmask & SDHSTS_BLOCK_IRPT) {
+		bcm2835_check_data_error(host, intmask);
+		host->irq_block = true;
+		result = IRQ_WAKE_THREAD;
+	}
+
+	if (intmask & SDHSTS_BUSY_IRPT) {
+		if (!bcm2835_check_cmd_error(host, intmask)) {
+			host->irq_busy = true;
+			result = IRQ_WAKE_THREAD;
+		} else {
+			result = IRQ_HANDLED;
+		}
+	}
+
+	/* There is no true data interrupt status bit, so it is
+	 * necessary to qualify the data flag with the interrupt
+	 * enable bit.
+	 */
+	if ((intmask & SDHSTS_DATA_FLAG) &&
+	    (host->hcfg & SDHCFG_DATA_IRPT_EN)) {
+		bcm2835_data_irq(host, intmask);
+		host->irq_data = true;
+		result = IRQ_WAKE_THREAD;
+	}
+
+	return result;
+}
+
+static irqreturn_t bcm2835_threaded_irq(int irq, void *dev_id)
+{
+	struct bcm2835_host *host = dev_id;
+
+	if (host->irq_block) {
+		host->irq_block = false;
+		bcm2835_block_irq(host);
+	}
+
+	if (host->irq_busy) {
+		host->irq_busy = false;
+		bcm2835_busy_irq(host);
+	}
+
+	if (host->irq_data) {
+		host->irq_data = false;
+		bcm2835_data_threaded_irq(host);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static void bcm2835_irq_poll(struct bcm2835_host *host)
+{
+	u32 intmask;
+
+	while (1) {
+		intmask = readl(host->ioaddr + SDHSTS);
+		if (intmask & (SDHSTS_BUSY_IRPT | SDHSTS_BLOCK_IRPT |
+			       SDHSTS_SDIO_IRPT | SDHSTS_DATA_FLAG)) {
+			bcm2835_irq(0, host);
+			bcm2835_threaded_irq(0, host);
+			return;
+		}
+	}
+}
+
+static void bcm2835_set_clock(struct bcm2835_host *host, unsigned int clock)
+{
+	int div;
+
+	/* The SDCDIV register has 11 bits, and holds (div - 2).  But
+	 * in data mode the max is 50MHz wihout a minimum, and only
+	 * the bottom 3 bits are used. Since the switch over is
+	 * automatic (unless we have marked the card as slow...),
+	 * chosen values have to make sense in both modes.  Ident mode
+	 * must be 100-400KHz, so can range check the requested
+	 * clock. CMD15 must be used to return to data mode, so this
+	 * can be monitored.
+	 *
+	 * clock 250MHz -> 0->125MHz, 1->83.3MHz, 2->62.5MHz, 3->50.0MHz
+	 *                 4->41.7MHz, 5->35.7MHz, 6->31.3MHz, 7->27.8MHz
+	 *
+	 *		 623->400KHz/27.8MHz
+	 *		 reset value (507)->491159/50MHz
+	 *
+	 * BUT, the 3-bit clock divisor in data mode is too small if
+	 * the core clock is higher than 250MHz, so instead use the
+	 * SLOW_CARD configuration bit to force the use of the ident
+	 * clock divisor at all times.
+	 */
+
+	if (clock < 100000) {
+		/* Can't stop the clock, but make it as slow as possible
+		 * to show willing
+		 */
+		host->cdiv = SDCDIV_MAX_CDIV;
+		writel(host->cdiv, host->ioaddr + SDCDIV);
+		return;
+	}
+
+	div = host->max_clk / clock;
+	if (div < 2)
+		div = 2;
+	if ((host->max_clk / div) > clock)
+		div++;
+	div -= 2;
+
+	if (div > SDCDIV_MAX_CDIV)
+		div = SDCDIV_MAX_CDIV;
+
+	clock = host->max_clk / (div + 2);
+	host->mmc->clock = clock;
+
+	/* Calibrate some delays */
+
+	host->ns_per_fifo_word = (1000000000 / clock) *
+		((host->mmc->card_caps & MMC_MODE_4BIT) ? 8 : 32);
+
+	host->cdiv = div;
+	writel(host->cdiv, host->ioaddr + SDCDIV);
+
+	/* Set the timeout to 500ms */
+	writel(host->mmc->clock / 2, host->ioaddr + SDTOUT);
+}
+
+static inline int is_power_of_2(u64 x)
+{
+	return !(x & (x - 1));
+}
+
+static int bcm2835_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+			    struct mmc_data *data)
+{
+	struct bcm2835_host *host = dev_get_priv(dev);
+	u32 edm, fsm;
+	int ret = 0;
+
+	if (data && !is_power_of_2(data->blocksize)) {
+		printf("unsupported block size (%d bytes)\n", data->blocksize);
+
+		if (cmd)
+			return -EINVAL;
+	}
+
+	edm = readl(host->ioaddr + SDEDM);
+	fsm = edm & SDEDM_FSM_MASK;
+
+	if ((fsm != SDEDM_FSM_IDENTMODE) &&
+	    (fsm != SDEDM_FSM_DATAMODE) &&
+	    (cmd && cmd->cmdidx != MMC_CMD_STOP_TRANSMISSION)) {
+		printf("previous command (%d) not complete (EDM %08x)\n",
+		       readl(host->ioaddr + SDCMD) & SDCMD_CMD_MASK, edm);
+		bcm2835_dumpregs(host);
+
+		if (cmd)
+			return -EILSEQ;
+
+		return 0;
+	}
+
+	if (cmd) {
+		ret = bcm2835_send_command(host, cmd, data);
+		if (!ret && !host->use_busy)
+			ret = bcm2835_finish_command(host);
+	}
+
+	/* Wait for completion of busy signal or data transfer */
+	while (host->use_busy || host->data)
+		bcm2835_irq_poll(host);
+
+	return ret;
+}
+
+static int bcm2835_set_ios(struct udevice *dev)
+{
+	struct bcm2835_host *host = dev_get_priv(dev);
+	struct mmc *mmc = mmc_get_mmc_dev(dev);
+
+	if (!mmc->clock || mmc->clock != host->clock) {
+		bcm2835_set_clock(host, mmc->clock);
+		host->clock = mmc->clock;
+	}
+
+	/* set bus width */
+	host->hcfg &= ~SDHCFG_WIDE_EXT_BUS;
+	if (mmc->bus_width == 4)
+		host->hcfg |= SDHCFG_WIDE_EXT_BUS;
+
+	host->hcfg |= SDHCFG_WIDE_INT_BUS;
+
+	/* Disable clever clock switching, to cope with fast core clocks */
+	host->hcfg |= SDHCFG_SLOW_CARD;
+
+	writel(host->hcfg, host->ioaddr + SDHCFG);
+
+	return 0;
+}
+
+static void bcm2835_add_host(struct bcm2835_host *host)
+{
+	struct mmc_config *cfg = &host->plat->cfg;
+
+	cfg->f_max = host->max_clk;
+	cfg->f_min = host->max_clk / SDCDIV_MAX_CDIV;
+	cfg->b_max = 65535;
+
+	dev_dbg(dev, "f_max %d, f_min %d\n",
+		cfg->f_max, cfg->f_min);
+
+	/* host controller capabilities */
+	cfg->host_caps = MMC_MODE_4BIT | MMC_MODE_HS | MMC_MODE_HS_52MHz;
+
+	/* report supported voltage ranges */
+	cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
+
+	/* Set interrupt enables */
+	host->hcfg = SDHCFG_BUSY_IRPT_EN;
+
+	bcm2835_reset_internal(host);
+}
+
+static int bcm2835_probe(struct udevice *dev)
+{
+	struct bcm2835_plat *plat = dev_get_platdata(dev);
+	struct bcm2835_host *host = dev_get_priv(dev);
+	struct mmc *mmc = mmc_get_mmc_dev(dev);
+	struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+
+	host->dev = dev;
+	host->mmc = mmc;
+	host->plat = plat;
+	upriv->mmc = &plat->mmc;
+	plat->cfg.name = dev->name;
+
+	host->phys_addr = devfdt_get_addr(dev);
+	if (host->phys_addr == FDT_ADDR_T_NONE)
+		return -EINVAL;
+
+	host->ioaddr = devm_ioremap(dev, host->phys_addr, SZ_256);
+	if (!host->ioaddr)
+		return -ENOMEM;
+
+	host->max_clk = bcm2835_get_mmc_clock();
+
+	bcm2835_add_host(host);
+
+	dev_dbg(dev, "%s -> OK\n", __func__);
+
+	return 0;
+}
+
+static const struct udevice_id bcm2835_match[] = {
+	{ .compatible = "brcm,bcm2835-sdhost" },
+	{ }
+};
+
+static const struct dm_mmc_ops bcm2835_ops = {
+	.send_cmd = bcm2835_send_cmd,
+	.set_ios = bcm2835_set_ios,
+};
+
+static int bcm2835_bind(struct udevice *dev)
+{
+	struct bcm2835_plat *plat = dev_get_platdata(dev);
+
+	return mmc_bind(dev, &plat->mmc, &plat->cfg);
+}
+
+U_BOOT_DRIVER(bcm2835_sdhost) = {
+	.name = "bcm2835-sdhost",
+	.id = UCLASS_MMC,
+	.of_match = bcm2835_match,
+	.bind = bcm2835_bind,
+	.probe = bcm2835_probe,
+	.priv_auto_alloc_size = sizeof(struct bcm2835_host),
+	.platdata_auto_alloc_size = sizeof(struct bcm2835_plat),
+	.ops = &bcm2835_ops,
+};
-- 
2.12.3

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-01-23 17:05 ` [U-Boot] [PATCH v3 1/2] bcm283x: Add pinctrl driver Alexander Graf
@ 2018-01-28 18:54   ` Tom Rini
  2018-02-03  1:47     ` Jonathan Gray
  0 siblings, 1 reply; 22+ messages in thread
From: Tom Rini @ 2018-01-28 18:54 UTC (permalink / raw)
  To: u-boot

On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:

> The bcm283x family of SoCs have a GPIO controller that also acts as
> pinctrl controller.
> 
> This patch introduces a new pinctrl driver that can actually properly mux
> devices into their device tree defined pin states and is now the primary
> owner of the gpio device. The previous GPIO driver gets moved into a
> subdevice of the pinctrl driver, bound to the same OF node.
> 
> That way whenever a device asks for pinctrl support, it gets it
> automatically from the pinctrl driver and GPIO support is still available
> in the normal command line phase.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180128/2876c0cc/attachment.sig>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,2/2] mmc: Add bcm2835 sdhost controller
  2018-01-23 17:05 ` [U-Boot] [PATCH v3 2/2] mmc: Add bcm2835 sdhost controller Alexander Graf
@ 2018-01-28 18:54   ` Tom Rini
  0 siblings, 0 replies; 22+ messages in thread
From: Tom Rini @ 2018-01-28 18:54 UTC (permalink / raw)
  To: u-boot

On Tue, Jan 23, 2018 at 06:05:22PM +0100, Alexander Graf wrote:

> The BCM2835 family of SoCs has 2 different SD controllers: One based on
> the SDHCI spec and a custom, home-grown one.
> 
> This patch implements a driver for the latter based on the Linux driver.
> This is needed so that we can make use of device trees that assume driver
> presence of both SD controllers.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180128/33642db2/attachment.sig>

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-01-28 18:54   ` [U-Boot] [U-Boot,v3,1/2] " Tom Rini
@ 2018-02-03  1:47     ` Jonathan Gray
  2018-02-03  8:02       ` Alexander Graf
  2018-02-09 23:02       ` Jonathan Gray
  0 siblings, 2 replies; 22+ messages in thread
From: Jonathan Gray @ 2018-02-03  1:47 UTC (permalink / raw)
  To: u-boot

On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> 
> > The bcm283x family of SoCs have a GPIO controller that also acts as
> > pinctrl controller.
> > 
> > This patch introduces a new pinctrl driver that can actually properly mux
> > devices into their device tree defined pin states and is now the primary
> > owner of the gpio device. The previous GPIO driver gets moved into a
> > subdevice of the pinctrl driver, bound to the same OF node.
> > 
> > That way whenever a device asks for pinctrl support, it gets it
> > automatically from the pinctrl driver and GPIO support is still available
> > in the normal command line phase.
> > 
> > Signed-off-by: Alexander Graf <agraf@suse.de>
> 
> Applied to u-boot/master, thanks!

It seems one of the recent commits here has broken booting on rpi_3 with
the vendor supplied device tree via efi_loader.

last working commit seems to be:

8996975ff8422e07f43eb8b3b0c7ed8c2b35442f
powerpc: Drop CONFIG_WALNUT and other related dead code

After that were

caf2233b281c03e3e359061a3dfa537d8a25c273
bcm283x: Add pinctrl driver

c8a73a26d6dd9b7d489e66529fe1412425d8f2d1
mmc: Add bcm2835 sdhost controller

These can't easily be reverted due to other changes.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-03  1:47     ` Jonathan Gray
@ 2018-02-03  8:02       ` Alexander Graf
  2018-02-03 11:38         ` Jonathan Gray
  2018-02-09 23:02       ` Jonathan Gray
  1 sibling, 1 reply; 22+ messages in thread
From: Alexander Graf @ 2018-02-03  8:02 UTC (permalink / raw)
  To: u-boot



On 03.02.18 02:47, Jonathan Gray wrote:
> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
>> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
>>
>>> The bcm283x family of SoCs have a GPIO controller that also acts as
>>> pinctrl controller.
>>>
>>> This patch introduces a new pinctrl driver that can actually properly mux
>>> devices into their device tree defined pin states and is now the primary
>>> owner of the gpio device. The previous GPIO driver gets moved into a
>>> subdevice of the pinctrl driver, bound to the same OF node.
>>>
>>> That way whenever a device asks for pinctrl support, it gets it
>>> automatically from the pinctrl driver and GPIO support is still available
>>> in the normal command line phase.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>
>> Applied to u-boot/master, thanks!
> 
> It seems one of the recent commits here has broken booting on rpi_3 with
> the vendor supplied device tree via efi_loader.

Do you have a pointer to the dtb? I'm actually using the vendor supplied
device tree to boot, but I don't specify it, I just leave it to the RPi
fw to pass it in.

Can you please go into detail on your setup?


Alex

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-03  8:02       ` Alexander Graf
@ 2018-02-03 11:38         ` Jonathan Gray
  2018-02-05  8:37           ` Alexander Graf
  0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Gray @ 2018-02-03 11:38 UTC (permalink / raw)
  To: u-boot

On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
> 
> 
> On 03.02.18 02:47, Jonathan Gray wrote:
> > On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> >> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> >>
> >>> The bcm283x family of SoCs have a GPIO controller that also acts as
> >>> pinctrl controller.
> >>>
> >>> This patch introduces a new pinctrl driver that can actually properly mux
> >>> devices into their device tree defined pin states and is now the primary
> >>> owner of the gpio device. The previous GPIO driver gets moved into a
> >>> subdevice of the pinctrl driver, bound to the same OF node.
> >>>
> >>> That way whenever a device asks for pinctrl support, it gets it
> >>> automatically from the pinctrl driver and GPIO support is still available
> >>> in the normal command line phase.
> >>>
> >>> Signed-off-by: Alexander Graf <agraf@suse.de>
> >>
> >> Applied to u-boot/master, thanks!
> > 
> > It seems one of the recent commits here has broken booting on rpi_3 with
> > the vendor supplied device tree via efi_loader.
> 
> Do you have a pointer to the dtb? I'm actually using the vendor supplied
> device tree to boot, but I don't specify it, I just leave it to the RPi
> fw to pass it in.
> 
> Can you please go into detail on your setup?
> 
> 
> Alex

Sure.  Using the most recent release of the firmware
https://github.com/raspberrypi/firmware/releases/tag/1.20171029

https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb

dtb is placed in the root of the fat partition and loaded by the
firmware, it is not placed in a 'broadcom' or 'dtb' directory.

MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb
MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508
MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de
MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a

$ cat config.txt                                                            
arm_control=0x200
enable_uart=1
device_tree_address=0x100
kernel=u-boot.bin

These files are included in the installation disk image for OpenBSD/arm64
(along with u-boot.bin):

https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

In the setup I use U-Boot is loaded off sd card with boot target set to
prefer usb (fuse to enable usb boot isn't blown).  distro bootcmd finds
bootaa64.efi and loads that.

With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:

U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
Loading Environment from FAT... OK
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:	Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0
U-Boot> printenv
arch=arm
baudrate=115200
board=rpi
board_name=3 Model B
board_rev=0x8
board_rev_scheme=1
board_revision=0xA02082
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=usb0 mmc0 pxe dhcp
bootcmd=run distro_bootcmd
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=2
bootfstype=fat
cpu=armv8
devnum=0
devplist=1
devtype=usb
dhcpuboot=usb start; dhcp u-boot.uimg; bootm
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={ro,boot}(blob)0000000000000000
efi_dtb_prefixes=/ /dtb/ /dtb/current/
efi_fdtfile=broadcom/bcm2837-rpi-3-b.dtb
ethaddr=b8:27:eb:18:54:ea
fdt_addr=100
fdt_addr_r=0x00000100
fdt_high=ffffffff
fdtaddr=100
fdtcontroladdr=3b3a3960
fdtfile=broadcom/bcm2837-rpi-3-b.dtb
fileaddr=1000000
filesize=1346f
initrd_high=ffffffff
kernel_addr_r=0x01000000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x00200000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
preboot=usb start
pxefile_addr_r=0x00100000
ramdisk_addr_r=0x02100000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x02000000
serial#=00000000eb1854ea
soc=bcm283x
stderr=serial,vidconsole
stdin=serial,usbkbd
stdout=serial,vidconsole
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
usbethaddr=b8:27:eb:18:54:ea
vendor=raspberrypi

Environment size: 4081/16380 bytes
U-Boot> boot

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
	    Type: Removable Hard Disk
	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
78335 bytes read in 79 ms (967.8 KiB/s)
## Starting EFI application at 01000000 ...
Scanning disk mmc at 7e202000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 25
Scanning disk sdhci at 7e300000.blk...
>> OpenBSD/arm64 BOOTAA64 0.8
boot>
cannot open sd0a:/etc/random.seed: Device not configured
booting sd0a:/bsd: open sd0a:/bsd: Device not configured
 failed(6). will try /bsd
boot>

U-Boot> part list mmc 0

Partition Map for MMC device 0  --   Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            8192            00000000-01     0c Boot
  4     16384           26624           00000000-04     a6
U-Boot> part list usb 0

Partition Map for USB device 0  --   Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            32768           00000000-01     0c Boot
  4     40960           60021540        00000000-04     a6
U-Boot> ls mmc 0:1 /
    50248   bootcode.bin
  2820196   start.elf
     6551   fixup.dat
    17794   bcm2710-rpi-3-b.dtb
    16380   bcm2710-rpi-cm3.dtb
   441248   u-boot.bin
            efi/
       76   config.txt
    16384   uboot.env

8 file(s), 1 dir(s)
U-Boot> bdinfo
arch_number = 0x00000000
boot_params = 0x00000100
DRAM bank   = 0x00000000
-> start    = 0x00000000
-> size     = 0x3B400000
baudrate    = 115200 bps
TLB addr    = 0x3B3F0000
relocaddr   = 0x3B349000
reloc off   = 0x3B2C9000
irq_sp      = 0x3AF44DE0
sp start    = 0x3AF44DE0
Early malloc usage: 5d0 / 2000
fdt_blob = 000000003b3a3960

U-Boot> dm tree
 Class	    Probed  Driver	Name
----------------------------------------
 root	    [ + ]   root_drive	root_driver
 simple_bus [ + ]   generic_si	|-- soc
 pinctrl    [ + ]   bcm283x_pi	|   |-- gpio at 7e200000
 pinconfig  [	]   pinconfig	|   |	|-- dpi_gpio0
 pinconfig  [	]   pinconfig	|   |	|-- emmc_gpio22
 pinconfig  [ + ]   pinconfig	|   |	|-- emmc_gpio34
 pinconfig  [	]   pinconfig	|   |	|-- emmc_gpio48
 pinconfig  [	]   pinconfig	|   |	|-- gpclk0_gpio4
 pinconfig  [	]   pinconfig	|   |	|-- gpclk1_gpio5
 pinconfig  [	]   pinconfig	|   |	|-- gpclk1_gpio42
 pinconfig  [	]   pinconfig	|   |	|-- gpclk1_gpio44
 pinconfig  [	]   pinconfig	|   |	|-- gpclk2_gpio6
 pinconfig  [ + ]   pinconfig	|   |	|-- gpclk2_gpio43
 pinconfig  [	]   pinconfig	|   |	|-- i2c0_gpio0
 pinconfig  [	]   pinconfig	|   |	|-- i2c0_gpio28
 pinconfig  [	]   pinconfig	|   |	|-- i2c0_gpio44
 pinconfig  [	]   pinconfig	|   |	|-- i2c1_gpio2
 pinconfig  [	]   pinconfig	|   |	|-- i2c1_gpio44
 pinconfig  [	]   pinconfig	|   |	|-- i2c_slave_gpio18
 pinconfig  [	]   pinconfig	|   |	|-- jtag_gpio4
 pinconfig  [	]   pinconfig	|   |	|-- jtag_gpio22
 pinconfig  [	]   pinconfig	|   |	|-- pcm_gpio18
 pinconfig  [	]   pinconfig	|   |	|-- pcm_gpio28
 pinconfig  [	]   pinconfig	|   |	|-- pwm0_gpio12
 pinconfig  [	]   pinconfig	|   |	|-- pwm0_gpio18
 pinconfig  [	]   pinconfig	|   |	|-- pwm0_gpio40
 pinconfig  [	]   pinconfig	|   |	|-- pwm1_gpio13
 pinconfig  [	]   pinconfig	|   |	|-- pwm1_gpio19
 pinconfig  [	]   pinconfig	|   |	|-- pwm1_gpio41
 pinconfig  [	]   pinconfig	|   |	|-- pwm1_gpio45
 pinconfig  [ + ]   pinconfig	|   |	|-- sdhost_gpio48
 pinconfig  [	]   pinconfig	|   |	|-- spi0_gpio7
 pinconfig  [	]   pinconfig	|   |	|-- spi0_gpio35
 pinconfig  [	]   pinconfig	|   |	|-- spi1_gpio16
 pinconfig  [	]   pinconfig	|   |	|-- spi2_gpio40
 pinconfig  [	]   pinconfig	|   |	|-- uart0_gpio14
 pinconfig  [	]   pinconfig	|   |	|-- uart0_ctsrts_gpio16
 pinconfig  [	]   pinconfig	|   |	|-- uart0_ctsrts_gpio30
 pinconfig  [ + ]   pinconfig	|   |	|-- uart0_gpio32
 pinconfig  [	]   pinconfig	|   |	|-- uart0_gpio36
 pinconfig  [	]   pinconfig	|   |	|-- uart0_ctsrts_gpio38
 pinconfig  [ + ]   pinconfig	|   |	|-- uart1_gpio14
 pinconfig  [	]   pinconfig	|   |	|-- uart1_ctsrts_gpio16
 pinconfig  [	]   pinconfig	|   |	|-- uart1_gpio32
 pinconfig  [	]   pinconfig	|   |	|-- uart1_ctsrts_gpio30
 pinconfig  [	]   pinconfig	|   |	|-- uart1_gpio40
 pinconfig  [	]   pinconfig	|   |	|-- uart1_ctsrts_gpio42
 pinconfig  [	]   pinconfig	|   |	|-- gpioout
 pinconfig  [	]   pinconfig	|   |	|-- alt0
 gpio	    [	]   gpio_bcm28	|   |	`-- gpio_bcm2835
 serial	    [	]   bcm283x_pl	|   |-- serial at 7e201000
 mmc	    [ + ]   bcm2835-sd	|   |-- mmc at 7e202000
 blk	    [ + ]   mmc_blk	|   |	`-- mmc at 7e202000.blk
 serial	    [ + ]   serial_bcm	|   |-- serial at 7e215040
 mmc	    [ + ]   sdhci-bcm2	|   |-- sdhci at 7e300000
 blk	    [	]   mmc_blk	|   |	`-- sdhci at 7e300000.blk
 video	    [ + ]   bcm2835_vi	|   |-- hdmi at 7e902000
 vidconsole [ + ]   vidconsole	|   |	`-- hdmi at 7e902000.vidconsole0
 usb	    [ + ]   dwc2_usb	|   `-- usb at 7e980000
 usb_hub    [ + ]   usb_hub	|	`-- usb_hub
 usb_hub    [ + ]   usb_hub	|	    `-- usb_hub
 eth	    [ + ]   smsc95xx_e	|		|-- smsc95xx_eth
 usb_mass_s [ + ]   usb_mass_s	|		`-- usb_mass_storage
 blk	    [ + ]   usb_storag	|		    `-- usb_mass_storage.lun0
 simple_bus [	]   generic_si	`-- clocks

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-03 11:38         ` Jonathan Gray
@ 2018-02-05  8:37           ` Alexander Graf
  2018-02-05 10:06             ` Jonathan Gray
  0 siblings, 1 reply; 22+ messages in thread
From: Alexander Graf @ 2018-02-05  8:37 UTC (permalink / raw)
  To: u-boot



On 03.02.18 12:38, Jonathan Gray wrote:
> On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
>>
>>
>> On 03.02.18 02:47, Jonathan Gray wrote:
>>> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
>>>> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
>>>>
>>>>> The bcm283x family of SoCs have a GPIO controller that also acts as
>>>>> pinctrl controller.
>>>>>
>>>>> This patch introduces a new pinctrl driver that can actually properly mux
>>>>> devices into their device tree defined pin states and is now the primary
>>>>> owner of the gpio device. The previous GPIO driver gets moved into a
>>>>> subdevice of the pinctrl driver, bound to the same OF node.
>>>>>
>>>>> That way whenever a device asks for pinctrl support, it gets it
>>>>> automatically from the pinctrl driver and GPIO support is still available
>>>>> in the normal command line phase.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>
>>>> Applied to u-boot/master, thanks!
>>>
>>> It seems one of the recent commits here has broken booting on rpi_3 with
>>> the vendor supplied device tree via efi_loader.
>>
>> Do you have a pointer to the dtb? I'm actually using the vendor supplied
>> device tree to boot, but I don't specify it, I just leave it to the RPi
>> fw to pass it in.
>>
>> Can you please go into detail on your setup?
>>
>>
>> Alex
> 
> Sure.  Using the most recent release of the firmware
> https://github.com/raspberrypi/firmware/releases/tag/1.20171029
> 
> https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb
> 
> dtb is placed in the root of the fat partition and loaded by the
> firmware, it is not placed in a 'broadcom' or 'dtb' directory.
> 
> MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb
> MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508
> MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de
> MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a
> 
> $ cat config.txt                                                            
> arm_control=0x200
> enable_uart=1
> device_tree_address=0x100
> kernel=u-boot.bin
> 
> These files are included in the installation disk image for OpenBSD/arm64
> (along with u-boot.bin):
> 
> https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
> 
> In the setup I use U-Boot is loaded off sd card with boot target set to
> prefer usb (fuse to enable usb boot isn't blown).  distro bootcmd finds
> bootaa64.efi and loads that.
> 
> With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:

Are you using the defconfig or do you set CONFIG_OF_BOARD to fetch the
U-Boot DT from firmware?

> 
> U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
> Loading Environment from FAT... OK
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:	Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
>        scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> U-Boot> printenv
> arch=arm
> baudrate=115200
> board=rpi
> board_name=3 Model B
> board_rev=0x8
> board_rev_scheme=1
> board_revision=0xA02082
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
> boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
> boot_net_usb_start=usb start
> boot_prefixes=/ /boot/
> boot_script_dhcp=boot.scr.uimg
> boot_scripts=boot.scr.uimg boot.scr
> boot_targets=usb0 mmc0 pxe dhcp
> bootcmd=run distro_bootcmd
> bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
> bootcmd_mmc0=setenv devnum 0; run mmc_boot
> bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> bootcmd_usb0=setenv devnum 0; run usb_boot
> bootdelay=2
> bootfstype=fat
> cpu=armv8
> devnum=0
> devplist=1
> devtype=usb
> dhcpuboot=usb start; dhcp u-boot.uimg; bootm
> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
> efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={ro,boot}(blob)0000000000000000
> efi_dtb_prefixes=/ /dtb/ /dtb/current/
> efi_fdtfile=broadcom/bcm2837-rpi-3-b.dtb
> ethaddr=b8:27:eb:18:54:ea
> fdt_addr=100
> fdt_addr_r=0x00000100
> fdt_high=ffffffff
> fdtaddr=100
> fdtcontroladdr=3b3a3960
> fdtfile=broadcom/bcm2837-rpi-3-b.dtb
> fileaddr=1000000
> filesize=1346f
> initrd_high=ffffffff
> kernel_addr_r=0x01000000
> load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
> loadaddr=0x00200000
> mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
> preboot=usb start
> pxefile_addr_r=0x00100000
> ramdisk_addr_r=0x02100000
> scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
> scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
> scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
> scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
> scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
> scriptaddr=0x02000000
> serial#=00000000eb1854ea
> soc=bcm283x
> stderr=serial,vidconsole
> stdin=serial,usbkbd
> stdout=serial,vidconsole
> usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
> usbethaddr=b8:27:eb:18:54:ea
> vendor=raspberrypi
> 
> Environment size: 4081/16380 bytes
> U-Boot> boot
> 
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> 	    Type: Removable Hard Disk
> 	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> 78335 bytes read in 79 ms (967.8 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk mmc at 7e202000.blk...
> Card did not respond to voltage select!
> mmc_init: -95, time 25
> Scanning disk sdhci at 7e300000.blk...
>>> OpenBSD/arm64 BOOTAA64 0.8
> boot>
> cannot open sd0a:/etc/random.seed: Device not configured

What does that mean? Which EFI call returns which error code here?

> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
>  failed(6). will try /bsd

How do you find out that it's sd0a instead of sd1a?

The only thing I can think of that changed with this commit is that now
we're honoring the device tree's pinmuxing rules. So if the DT wants to
use the sdhost mmc controller instead of the sdhci one, it will actually
get muxed there. Before, we didn't mux, so on the rpi3 we just happened
to run on the sdhci.

At least the default Linux dtb uses sdhost for SD card access.

So maybe all that happened was a change in device numbers because we end
up creating device nodes for mmc devices that don't have a card plugged
in (sdhci).

In that case however, I guess it means you really were booting from MMC
before, rather than USB?

> boot>
> 
> U-Boot> part list mmc 0
> 
> Partition Map for MMC device 0  --   Partition Type: DOS
> 
> Part    Start Sector    Num Sectors     UUID            Type
>   1     8192            8192            00000000-01     0c Boot
>   4     16384           26624           00000000-04     a6
> U-Boot> part list usb 0
> 
> Partition Map for USB device 0  --   Partition Type: DOS
> 
> Part    Start Sector    Num Sectors     UUID            Type
>   1     8192            32768           00000000-01     0c Boot
>   4     40960           60021540        00000000-04     a6
> U-Boot> ls mmc 0:1 /

I assume "ls usb 0:1 /" also works?


Alex

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-05  8:37           ` Alexander Graf
@ 2018-02-05 10:06             ` Jonathan Gray
  2018-02-05 10:31               ` Mark Kettenis
  0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Gray @ 2018-02-05 10:06 UTC (permalink / raw)
  To: u-boot

On Mon, Feb 05, 2018 at 09:37:15AM +0100, Alexander Graf wrote:
> 
> 
> On 03.02.18 12:38, Jonathan Gray wrote:
> > On Sat, Feb 03, 2018 at 09:02:25AM +0100, Alexander Graf wrote:
> >>
> >>
> >> On 03.02.18 02:47, Jonathan Gray wrote:
> >>> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> >>>> On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> >>>>
> >>>>> The bcm283x family of SoCs have a GPIO controller that also acts as
> >>>>> pinctrl controller.
> >>>>>
> >>>>> This patch introduces a new pinctrl driver that can actually properly mux
> >>>>> devices into their device tree defined pin states and is now the primary
> >>>>> owner of the gpio device. The previous GPIO driver gets moved into a
> >>>>> subdevice of the pinctrl driver, bound to the same OF node.
> >>>>>
> >>>>> That way whenever a device asks for pinctrl support, it gets it
> >>>>> automatically from the pinctrl driver and GPIO support is still available
> >>>>> in the normal command line phase.
> >>>>>
> >>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
> >>>>
> >>>> Applied to u-boot/master, thanks!
> >>>
> >>> It seems one of the recent commits here has broken booting on rpi_3 with
> >>> the vendor supplied device tree via efi_loader.
> >>
> >> Do you have a pointer to the dtb? I'm actually using the vendor supplied
> >> device tree to boot, but I don't specify it, I just leave it to the RPi
> >> fw to pass it in.
> >>
> >> Can you please go into detail on your setup?
> >>
> >>
> >> Alex
> > 
> > Sure.  Using the most recent release of the firmware
> > https://github.com/raspberrypi/firmware/releases/tag/1.20171029
> > 
> > https://github.com/raspberrypi/firmware/raw/1.20171029/boot/bcm2710-rpi-3-b.dtb
> > 
> > dtb is placed in the root of the fat partition and loaded by the
> > firmware, it is not placed in a 'broadcom' or 'dtb' directory.
> > 
> > MD5 (bcm2710-rpi-3-b.dtb) = dfa51a479a28d66868e1ff0baab3d6eb
> > MD5 (bootcode.bin) = fd01b240fcc5d4c83560676415081508
> > MD5 (fixup.dat) = 226cbdc001b39c58a9730675befbe0de
> > MD5 (start.elf) = a65f795ac3ba99373d2194cee1034f8a
> > 
> > $ cat config.txt                                                            
> > arm_control=0x200
> > enable_uart=1
> > device_tree_address=0x100
> > kernel=u-boot.bin
> > 
> > These files are included in the installation disk image for OpenBSD/arm64
> > (along with u-boot.bin):
> > 
> > https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
> > 
> > In the setup I use U-Boot is loaded off sd card with boot target set to
> > prefer usb (fuse to enable usb boot isn't blown).  distro bootcmd finds
> > bootaa64.efi and loads that.
> > 
> > With a U-Boot built from 2e87980580d0bf4781ad0d63efd456aa1a73d03f:
> 
> Are you using the defconfig or do you set CONFIG_OF_BOARD to fetch the
> U-Boot DT from firmware?

defconfig with no changes

> 
> > 
> > U-Boot 2018.03-rc1-00058-g36d3bd9514 (Feb 03 2018 - 22:13:26 +1100)
> > 
> > DRAM:  948 MiB
> > RPI 3 Model B (0xa02082)
> > MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
> > Loading Environment from FAT... OK
> > In:    serial
> > Out:   vidconsole
> > Err:   vidconsole
> > Net:   No ethernet found.
> > starting USB...
> > USB0:	Core Release: 2.80a
> > scanning bus 0 for devices... 4 USB Device(s) found
> >        scanning usb for storage devices... 1 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > U-Boot> printenv
> > arch=arm
> > baudrate=115200
> > board=rpi
> > board_name=3 Model B
> > board_rev=0x8
> > board_rev_scheme=1
> > board_revision=0xA02082
> > boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
> > boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
> > boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
> > boot_net_usb_start=usb start
> > boot_prefixes=/ /boot/
> > boot_script_dhcp=boot.scr.uimg
> > boot_scripts=boot.scr.uimg boot.scr
> > boot_targets=usb0 mmc0 pxe dhcp
> > bootcmd=run distro_bootcmd
> > bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
> > bootcmd_mmc0=setenv devnum 0; run mmc_boot
> > bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> > bootcmd_usb0=setenv devnum 0; run usb_boot
> > bootdelay=2
> > bootfstype=fat
> > cpu=armv8
> > devnum=0
> > devplist=1
> > devtype=usb
> > dhcpuboot=usb start; dhcp u-boot.uimg; bootm
> > distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
> > efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={ro,boot}(blob)0000000000000000
> > efi_dtb_prefixes=/ /dtb/ /dtb/current/
> > efi_fdtfile=broadcom/bcm2837-rpi-3-b.dtb
> > ethaddr=b8:27:eb:18:54:ea
> > fdt_addr=100
> > fdt_addr_r=0x00000100
> > fdt_high=ffffffff
> > fdtaddr=100
> > fdtcontroladdr=3b3a3960
> > fdtfile=broadcom/bcm2837-rpi-3-b.dtb
> > fileaddr=1000000
> > filesize=1346f
> > initrd_high=ffffffff
> > kernel_addr_r=0x01000000
> > load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
> > loadaddr=0x00200000
> > mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
> > preboot=usb start
> > pxefile_addr_r=0x00100000
> > ramdisk_addr_r=0x02100000
> > scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
> > scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
> > scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then echo Found EFI removable media binary efi/boot/bootaa64.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
> > scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
> > scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
> > scriptaddr=0x02000000
> > serial#=00000000eb1854ea
> > soc=bcm283x
> > stderr=serial,vidconsole
> > stdin=serial,usbkbd
> > stdout=serial,vidconsole
> > usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
> > usbethaddr=b8:27:eb:18:54:ea
> > vendor=raspberrypi
> > 
> > Environment size: 4081/16380 bytes
> > U-Boot> boot
> > 
> > Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> > 	    Type: Removable Hard Disk
> > 	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> > ... is now current device
> > Scanning usb 0:1...
> > Found EFI removable media binary efi/boot/bootaa64.efi
> > 78335 bytes read in 79 ms (967.8 KiB/s)
> > ## Starting EFI application at 01000000 ...
> > Scanning disk mmc at 7e202000.blk...
> > Card did not respond to voltage select!
> > mmc_init: -95, time 25
> > Scanning disk sdhci at 7e300000.blk...
> >>> OpenBSD/arm64 BOOTAA64 0.8
> > boot>
> > cannot open sd0a:/etc/random.seed: Device not configured
> 
> What does that mean? Which EFI call returns which error code here?

I suspect it means the boot device path has an issue again.

> 
> > booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> >  failed(6). will try /bsd
> 
> How do you find out that it's sd0a instead of sd1a?

The loaded image protocol I believe.

> 
> The only thing I can think of that changed with this commit is that now
> we're honoring the device tree's pinmuxing rules. So if the DT wants to
> use the sdhost mmc controller instead of the sdhci one, it will actually
> get muxed there. Before, we didn't mux, so on the rpi3 we just happened
> to run on the sdhci.
> 
> At least the default Linux dtb uses sdhost for SD card access.
> 
> So maybe all that happened was a change in device numbers because we end
> up creating device nodes for mmc devices that don't have a card plugged
> in (sdhci).
> 
> In that case however, I guess it means you really were booting from MMC
> before, rather than USB?

There is no driver for either broadcom mmc controller in OpenBSD.
U-Boot is loaded of the sd card, then bootaa64.efi is loaded
from usb via "boot_targets=usb0 mmc0 pxe dhcp" and distro bootcmd.
Root filesystem is then on usb.

> 
> > boot>
> > 
> > U-Boot> part list mmc 0
> > 
> > Partition Map for MMC device 0  --   Partition Type: DOS
> > 
> > Part    Start Sector    Num Sectors     UUID            Type
> >   1     8192            8192            00000000-01     0c Boot
> >   4     16384           26624           00000000-04     a6
> > U-Boot> part list usb 0
> > 
> > Partition Map for USB device 0  --   Partition Type: DOS
> > 
> > Part    Start Sector    Num Sectors     UUID            Type
> >   1     8192            32768           00000000-01     0c Boot
> >   4     40960           60021540        00000000-04     a6
> > U-Boot> ls mmc 0:1 /
> 
> I assume "ls usb 0:1 /" also works?

U-Boot> ls usb 0:1 /
            efi/
    50248   bootcode.bin
  2820196   start.elf
     6551   fixup.dat
    17794   bcm2710-rpi-3-b.dtb
    16550   bcm2710-rpi-cm3.dtb
   422776   u-boot.bin
       76   config.txt

7 file(s), 1 dir(s)

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-05 10:06             ` Jonathan Gray
@ 2018-02-05 10:31               ` Mark Kettenis
  2018-02-08  5:49                 ` Jonathan Gray
  0 siblings, 1 reply; 22+ messages in thread
From: Mark Kettenis @ 2018-02-05 10:31 UTC (permalink / raw)
  To: u-boot

> Date: Mon, 5 Feb 2018 21:06:59 +1100
> From: Jonathan Gray <jsg@jsg.id.au>
> 
> > > booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > >  failed(6). will try /bsd
> > 
> > How do you find out that it's sd0a instead of sd1a?
> 
> The loaded image protocol I believe.

Actually the OpenBSD bootloader currently only supports loading the
bsd kernel from the same device as the bootloader.  It will always
call that device sd0.  It invokes the device path protocol on the
loaded image handle and then matches that path to a device that
supports the block io protocol.

> > The only thing I can think of that changed with this commit is that now
> > we're honoring the device tree's pinmuxing rules. So if the DT wants to
> > use the sdhost mmc controller instead of the sdhci one, it will actually
> > get muxed there. Before, we didn't mux, so on the rpi3 we just happened
> > to run on the sdhci.
> > 
> > At least the default Linux dtb uses sdhost for SD card access.
> > 
> > So maybe all that happened was a change in device numbers because we end
> > up creating device nodes for mmc devices that don't have a card plugged
> > in (sdhci).
> > 
> > In that case however, I guess it means you really were booting from MMC
> > before, rather than USB?
> 
> There is no driver for either broadcom mmc controller in OpenBSD.
> U-Boot is loaded of the sd card, then bootaa64.efi is loaded
> from usb via "boot_targets=usb0 mmc0 pxe dhcp" and distro bootcmd.
> Root filesystem is then on usb.

Right.  So what the bootloader calls sd0 above is really the usb disk.

> > > boot>
> > > 
> > > U-Boot> part list mmc 0
> > > 
> > > Partition Map for MMC device 0  --   Partition Type: DOS
> > > 
> > > Part    Start Sector    Num Sectors     UUID            Type
> > >   1     8192            8192            00000000-01     0c Boot
> > >   4     16384           26624           00000000-04     a6
> > > U-Boot> part list usb 0
> > > 
> > > Partition Map for USB device 0  --   Partition Type: DOS
> > > 
> > > Part    Start Sector    Num Sectors     UUID            Type
> > >   1     8192            32768           00000000-01     0c Boot
> > >   4     40960           60021540        00000000-04     a6
> > > U-Boot> ls mmc 0:1 /
> > 
> > I assume "ls usb 0:1 /" also works?
> 
> U-Boot> ls usb 0:1 /
>             efi/
>     50248   bootcode.bin
>   2820196   start.elf
>      6551   fixup.dat
>     17794   bcm2710-rpi-3-b.dtb
>     16550   bcm2710-rpi-cm3.dtb
>    422776   u-boot.bin
>        76   config.txt
> 
> 7 file(s), 1 dir(s)
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-05 10:31               ` Mark Kettenis
@ 2018-02-08  5:49                 ` Jonathan Gray
  2018-02-08  8:11                   ` Alexander Graf
  0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Gray @ 2018-02-08  5:49 UTC (permalink / raw)
  To: u-boot

On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> > Date: Mon, 5 Feb 2018 21:06:59 +1100
> > From: Jonathan Gray <jsg@jsg.id.au>
> > 
> > > > booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > > >  failed(6). will try /bsd
> > > 
> > > How do you find out that it's sd0a instead of sd1a?
> > 
> > The loaded image protocol I believe.
> 
> Actually the OpenBSD bootloader currently only supports loading the
> bsd kernel from the same device as the bootloader.  It will always
> call that device sd0.  It invokes the device path protocol on the
> loaded image handle and then matches that path to a device that
> supports the block io protocol.

Perhaps the problem is elsewhere as U-Boot master also broke
vexpress_ca15_tc2 and mx6cuboxi targets:

$ qemu-system-arm -m 1024 -nographic -M vexpress-a15 -dtb /usr/local/share/dtb/arm/vexpress-v2p-ca15-tc1.dtb -kernel /usr/local/share/u-boot/vexpress_ca15_tc2/u-boot -sd /tmp/miniroot-am335x-62.fs
WARNING: Image format was not specified for '/tmp/miniroot-am335x-62.fs' and probing guessed raw.
	 Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
	 Specify the 'raw' format explicitly to remove the restrictions.


U-Boot 2018.01 (Feb 06 2018 - 23:26:43 -0700)

DRAM:  1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC:   MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   smc911x-0
Hit any key to stop autoboot:  0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
reading fdt.dtb
13384 bytes read in 2153 ms (5.9 KiB/s)
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
reading efi/boot/bootarm.efi
76528 bytes read in 51 ms (1.4 MiB/s)
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 3 disks
WARNING: Invalid device tree, expect boot to fail
>> OpenBSD/armv7 BOOTARM 1.0
boot>
cannot open sd0a:/etc/random.seed: No such file or directory
booting sd0a:/bsd: 2648671+8030940+445060 [168774+90+179792+153619]=0xb1812c

$ qemu-system-arm -m 1024 -nographic -M vexpress-a15 -dtb /usr/local/share/dtb/arm/vexpress-v2p-ca15-tc1.dtb -kernel vexpress_ca15_tc2/u-boot -sd /tmp/miniroot-am335x-62.fs
WARNING: Image format was not specified for '/tmp/miniroot-am335x-62.fs' and probing guessed raw.
	 Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
	 Specify the 'raw' format explicitly to remove the restrictions.


U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 18:24:11 +1300)

DRAM:  1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC:   MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   smc911x-0
Hit any key to stop autoboot:  0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
unable to select a mode
mmc_init: -524, time 22
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
unable to select a mode
mmc_init: -524, time 21
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disks on mmc...
unable to select a mode
mmc_init: -524, time 21
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: Invalid device tree, expect boot to fail
efi_load_pe: Invalid DOS Signature
## Application terminated, r = 2147483646

U-Boot SPL 2018.01 (Feb 06 2018 - 23:13:29)
Trying to boot from MMC1


U-Boot 2018.01 (Feb 06 2018 - 23:13:29 -0700)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 54C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
reading /imx6q-cubox-i.dtb
37503 bytes read in 19 ms (1.9 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Scanning disks on sata...
Found 8 disks
reading efi/boot/bootarm.efi
76528 bytes read in 32 ms (2.3 MiB/s)
## Starting EFI application at 12000000 ...
>> OpenBSD/armv7 BOOTARM 1.0
boot>
booting sd0a:/bsd: 4531856+203028+560156\[277405+90+281904+244582]=0x5d6b88


U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 17:54:19 +1300)
Trying to boot from MMC1


U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 08 2018 - 17:54:19 +1300)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 53C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
Loading Environment from MMC... OK
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
37503 bytes read in 17 ms (2.1 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
76528 bytes read in 30 ms (2.4 MiB/s)
## Starting EFI application at 12000000 ...
BS->LocateHandle() returns -2147483634
undefined instruction
pc : [<8e560348>]	   lr : [<8e56444c>]
reloc pc : [<15de4348>]	   lr : [<15de844c>]
sp : 8f57af10  ip : 8ffc2474	 fp : 8f57af1c
r10: 0000b000  r9 : 8f57bee0	 r8 : 0000000b
r7 : 8ffa1a9d  r6 : 8ffa16ad	 r5 : 8e56f0d0	r4 : 8e56e88a
r3 : 8e56dac8  r2 : 00000001	 r1 : 00000000	r0 : 00000000
Flags: nZCv  IRQs off  FIQs off	 Mode SVC_32
Resetting CPU ...

resetting ...

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-08  5:49                 ` Jonathan Gray
@ 2018-02-08  8:11                   ` Alexander Graf
  2018-02-08  9:10                     ` Jonathan Gray
  0 siblings, 1 reply; 22+ messages in thread
From: Alexander Graf @ 2018-02-08  8:11 UTC (permalink / raw)
  To: u-boot



> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
> 
> On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
>>> Date: Mon, 5 Feb 2018 21:06:59 +1100
>>> From: Jonathan Gray <jsg@jsg.id.au>
>>> 
>>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
>>>>> failed(6). will try /bsd
>>>> 
>>>> How do you find out that it's sd0a instead of sd1a?
>>> 
>>> The loaded image protocol I believe.
>> 
>> Actually the OpenBSD bootloader currently only supports loading the
>> bsd kernel from the same device as the bootloader.  It will always
>> call that device sd0.  It invokes the device path protocol on the
>> loaded image handle and then matches that path to a device that
>> supports the block io protocol.
> 
> Perhaps the problem is elsewhere as U-Boot master also broke
> vexpress_ca15_tc2 and mx6cuboxi targets:

Perfect, so can you quickly bisect it now that the bisect doesnâ€˜t end at the pinctrl driver?

Alex

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-08  8:11                   ` Alexander Graf
@ 2018-02-08  9:10                     ` Jonathan Gray
  2018-02-08  9:49                       ` Jonathan Gray
  0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Gray @ 2018-02-08  9:10 UTC (permalink / raw)
  To: u-boot

On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> 
> 
> > Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
> > 
> > On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> >>> Date: Mon, 5 Feb 2018 21:06:59 +1100
> >>> From: Jonathan Gray <jsg@jsg.id.au>
> >>> 
> >>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> >>>>> failed(6). will try /bsd
> >>>> 
> >>>> How do you find out that it's sd0a instead of sd1a?
> >>> 
> >>> The loaded image protocol I believe.
> >> 
> >> Actually the OpenBSD bootloader currently only supports loading the
> >> bsd kernel from the same device as the bootloader.  It will always
> >> call that device sd0.  It invokes the device path protocol on the
> >> loaded image handle and then matches that path to a device that
> >> supports the block io protocol.
> > 
> > Perhaps the problem is elsewhere as U-Boot master also broke
> > vexpress_ca15_tc2 and mx6cuboxi targets:
> 
> Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?

On cubox a bisect points to

commit 64e4db0f119151a1345e1da19d152eda550394e7
Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
Date:   Fri Jan 19 20:24:47 2018 +0100

    efi_loader: make efi_disk_create_partitions a global symbol
    
    Up to now we have been using efi_disk_create_partitions() to create
    partitions for block devices that existed before starting an EFI
    application.
    
    We need to call it for block devices created by EFI
    applications at run time. The EFI application will define the
    handle for the block device and install a device path protocol
    on it. We have to use this device path as stem for the partition
    device paths.
    
    Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Signed-off-by: Alexander Graf <agraf@suse.de>

 include/efi_loader.h      |  4 +++
 lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++----------------
 2 files changed, 64 insertions(+), 24 deletions(-)

If I revert this commit a image built from master works.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-08  9:10                     ` Jonathan Gray
@ 2018-02-08  9:49                       ` Jonathan Gray
  2018-02-08 14:44                         ` Heinrich Schuchardt
  0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Gray @ 2018-02-08  9:49 UTC (permalink / raw)
  To: u-boot

On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> > 
> > 
> > > Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
> > > 
> > > On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> > >>> Date: Mon, 5 Feb 2018 21:06:59 +1100
> > >>> From: Jonathan Gray <jsg@jsg.id.au>
> > >>> 
> > >>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > >>>>> failed(6). will try /bsd
> > >>>> 
> > >>>> How do you find out that it's sd0a instead of sd1a?
> > >>> 
> > >>> The loaded image protocol I believe.
> > >> 
> > >> Actually the OpenBSD bootloader currently only supports loading the
> > >> bsd kernel from the same device as the bootloader.  It will always
> > >> call that device sd0.  It invokes the device path protocol on the
> > >> loaded image handle and then matches that path to a device that
> > >> supports the block io protocol.
> > > 
> > > Perhaps the problem is elsewhere as U-Boot master also broke
> > > vexpress_ca15_tc2 and mx6cuboxi targets:
> > 
> > Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?
> 
> On cubox a bisect points to
> 
> commit 64e4db0f119151a1345e1da19d152eda550394e7
> Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Date:   Fri Jan 19 20:24:47 2018 +0100
> 
>     efi_loader: make efi_disk_create_partitions a global symbol
>     
>     Up to now we have been using efi_disk_create_partitions() to create
>     partitions for block devices that existed before starting an EFI
>     application.
>     
>     We need to call it for block devices created by EFI
>     applications at run time. The EFI application will define the
>     handle for the block device and install a device path protocol
>     on it. We have to use this device path as stem for the partition
>     device paths.
>     
>     Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>     Signed-off-by: Alexander Graf <agraf@suse.de>
> 
>  include/efi_loader.h      |  4 +++
>  lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++----------------
>  2 files changed, 64 insertions(+), 24 deletions(-)
> 
> If I revert this commit a image built from master works.

Actually master doesn't build with just that reverted, seems I had stale
object files.

rpi3 with the commit just before boots

98d48bdf415e318a11f9f9a44dff2b70aef3fb10
efi_loader: provide a function to create a partition node

U-Boot 2018.01-00408-gb7b3517a7f (Feb 08 2018 - 22:35:55 +1300)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   sdhci at 7e300000: 0
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:	Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
	    Type: Removable Hard Disk
	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
unhandled parent class: usb_mass_storage.lun0 (13)
82748 bytes read in 89 ms (907.2 KiB/s)
## Starting EFI application at 01000000 ...
Scanning disk sdhci at 7e300000.blk...
unhandled parent class: sdhci at 7e300000.blk (13)
unhandled parent class: sdhci at 7e300000.blk (13)
unhandled parent class: sdhci at 7e300000.blk (13)
Scanning disk usb_mass_storage.lun0...
unhandled parent class: usb_mass_storage.lun0 (13)
unhandled parent class: usb_mass_storage.lun0 (13)
unhandled parent class: usb_mass_storage.lun0 (13)
Found 6 disks
>> OpenBSD/arm64 BOOTAA64 0.11
boot>
booting sd0a:/bsd: 3917796+579072+585220+806860-[280094+96+459168+244083]=0x8442a8

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-08  9:49                       ` Jonathan Gray
@ 2018-02-08 14:44                         ` Heinrich Schuchardt
  2018-02-08 23:55                           ` Jonathan Gray
  0 siblings, 1 reply; 22+ messages in thread
From: Heinrich Schuchardt @ 2018-02-08 14:44 UTC (permalink / raw)
  To: u-boot

On 02/08/2018 10:49 AM, Jonathan Gray wrote:
> On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
>> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
>>>
>>>
>>>> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
>>>>
>>>> On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
>>>>>> Date: Mon, 5 Feb 2018 21:06:59 +1100
>>>>>> From: Jonathan Gray <jsg@jsg.id.au>
>>>>>>
>>>>>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
>>>>>>>> failed(6). will try /bsd
>>>>>>>
>>>>>>> How do you find out that it's sd0a instead of sd1a?
>>>>>>
>>>>>> The loaded image protocol I believe.
>>>>>
>>>>> Actually the OpenBSD bootloader currently only supports loading the
>>>>> bsd kernel from the same device as the bootloader.  It will always
>>>>> call that device sd0.  It invokes the device path protocol on the
>>>>> loaded image handle and then matches that path to a device that
>>>>> supports the block io protocol.
>>>>
>>>> Perhaps the problem is elsewhere as U-Boot master also broke
>>>> vexpress_ca15_tc2 and mx6cuboxi targets:
>>>
>>> Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?
>>
>> On cubox a bisect points to
>>
>> commit 64e4db0f119151a1345e1da19d152eda550394e7
>> Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> Date:   Fri Jan 19 20:24:47 2018 +0100
>>
>>     efi_loader: make efi_disk_create_partitions a global symbol
>>     
>>     Up to now we have been using efi_disk_create_partitions() to create
>>     partitions for block devices that existed before starting an EFI
>>     application.
>>     
>>     We need to call it for block devices created by EFI
>>     applications at run time. The EFI application will define the
>>     handle for the block device and install a device path protocol
>>     on it. We have to use this device path as stem for the partition
>>     device paths.
>>     
>>     Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>     Signed-off-by: Alexander Graf <agraf@suse.de>
>>
>>  include/efi_loader.h      |  4 +++
>>  lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++----------------
>>  2 files changed, 64 insertions(+), 24 deletions(-)
>>
>> If I revert this commit a image built from master works.
> 
> Actually master doesn't build with just that reverted, seems I had stale
> object files.

When bisecting running
'make mrproper && make foo_defconfig && make'
in each round is recommendable.

Do you still assume a problem that requires a change in U-Boot?
Or can we close the topic?

Best regards

Heinrich


> 
> rpi3 with the commit just before boots
> 
> 98d48bdf415e318a11f9f9a44dff2b70aef3fb10
> efi_loader: provide a function to create a partition node
> 
> U-Boot 2018.01-00408-gb7b3517a7f (Feb 08 2018 - 22:35:55 +1300)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   sdhci at 7e300000: 0
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:	Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
>        scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> 
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> 	    Type: Removable Hard Disk
> 	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> unhandled parent class: usb_mass_storage.lun0 (13)
> 82748 bytes read in 89 ms (907.2 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk sdhci at 7e300000.blk...
> unhandled parent class: sdhci at 7e300000.blk (13)
> unhandled parent class: sdhci at 7e300000.blk (13)
> unhandled parent class: sdhci at 7e300000.blk (13)
> Scanning disk usb_mass_storage.lun0...
> unhandled parent class: usb_mass_storage.lun0 (13)
> unhandled parent class: usb_mass_storage.lun0 (13)
> unhandled parent class: usb_mass_storage.lun0 (13)
> Found 6 disks
>>> OpenBSD/arm64 BOOTAA64 0.11
> boot>
> booting sd0a:/bsd: 3917796+579072+585220+806860-[280094+96+459168+244083]=0x8442a8
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-08 14:44                         ` Heinrich Schuchardt
@ 2018-02-08 23:55                           ` Jonathan Gray
  2018-02-09  3:43                             ` Heinrich Schuchardt
  0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Gray @ 2018-02-08 23:55 UTC (permalink / raw)
  To: u-boot

On Thu, Feb 08, 2018 at 03:44:32PM +0100, Heinrich Schuchardt wrote:
> On 02/08/2018 10:49 AM, Jonathan Gray wrote:
> > On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
> >> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> >>>
> >>>
> >>>> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
> >>>>
> >>>> On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> >>>>>> Date: Mon, 5 Feb 2018 21:06:59 +1100
> >>>>>> From: Jonathan Gray <jsg@jsg.id.au>
> >>>>>>
> >>>>>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> >>>>>>>> failed(6). will try /bsd
> >>>>>>>
> >>>>>>> How do you find out that it's sd0a instead of sd1a?
> >>>>>>
> >>>>>> The loaded image protocol I believe.
> >>>>>
> >>>>> Actually the OpenBSD bootloader currently only supports loading the
> >>>>> bsd kernel from the same device as the bootloader.  It will always
> >>>>> call that device sd0.  It invokes the device path protocol on the
> >>>>> loaded image handle and then matches that path to a device that
> >>>>> supports the block io protocol.
> >>>>
> >>>> Perhaps the problem is elsewhere as U-Boot master also broke
> >>>> vexpress_ca15_tc2 and mx6cuboxi targets:
> >>>
> >>> Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?
> >>
> >> On cubox a bisect points to
> >>
> >> commit 64e4db0f119151a1345e1da19d152eda550394e7
> >> Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> Date:   Fri Jan 19 20:24:47 2018 +0100
> >>
> >>     efi_loader: make efi_disk_create_partitions a global symbol
> >>     
> >>     Up to now we have been using efi_disk_create_partitions() to create
> >>     partitions for block devices that existed before starting an EFI
> >>     application.
> >>     
> >>     We need to call it for block devices created by EFI
> >>     applications at run time. The EFI application will define the
> >>     handle for the block device and install a device path protocol
> >>     on it. We have to use this device path as stem for the partition
> >>     device paths.
> >>     
> >>     Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>     Signed-off-by: Alexander Graf <agraf@suse.de>
> >>
> >>  include/efi_loader.h      |  4 +++
> >>  lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++----------------
> >>  2 files changed, 64 insertions(+), 24 deletions(-)
> >>
> >> If I revert this commit a image built from master works.
> > 
> > Actually master doesn't build with just that reverted, seems I had stale
> > object files.
> 
> When bisecting running
> 'make mrproper && make foo_defconfig && make'
> in each round is recommendable.
> 
> Do you still assume a problem that requires a change in U-Boot?
> Or can we close the topic?
> 
> Best regards
> 
> Heinrich

There are multiple regressions with U-Boot master compared to 2018.01.

sopine_baseboard (pinebook), reported to me I don't have hardware
rpi_3
mx6cuboxi
vexpress_ca15_tc2

While qemu_arm64 works.

Bisecting rpi_3 again, removing obj dir between runs and skipping
commits where nothing shows up on serial again gives the same:

commit caf2233b281c03e3e359061a3dfa537d8a25c273
Author:     Alexander Graf <agraf@suse.de>
AuthorDate: Tue Jan 23 18:05:21 2018 +0100
Commit:     Tom Rini <trini@konsulko.com>
CommitDate: Sun Jan 28 12:27:32 2018 -0500

    bcm283x: Add pinctrl driver
    
    The bcm283x family of SoCs have a GPIO controller that also acts as
    pinctrl controller.
    
    This patch introduces a new pinctrl driver that can actually properly mux
    devices into their device tree defined pin states and is now the primary
    owner of the gpio device. The previous GPIO driver gets moved into a
    subdevice of the pinctrl driver, bound to the same OF node.
    
    That way whenever a device asks for pinctrl support, it gets it
    automatically from the pinctrl driver and GPIO support is still available
    in the normal command line phase.
    
    Signed-off-by: Alexander Graf <agraf@suse.de>

with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5

U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:36:18 +1300)

DRAM:  948 MiB
RPI 3 Model B (0xa02082)
MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
Loading Environment from FAT... OK
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:	Core Release: 2.80a
scanning bus 0 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0

Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
	    Type: Removable Hard Disk
	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
... is now current device
Scanning usb 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
82748 bytes read in 89 ms (907.2 KiB/s)
## Starting EFI application at 01000000 ...
Scanning disk mmc at 7e202000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 25
Scanning disk sdhci at 7e300000.blk...
>> OpenBSD/arm64 BOOTAA64 0.11
open(tftp0a:/etc/boot.conf): Operation not permitted
boot>
booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
 failed(1). will try /bsd

with vexpress_ca15_tc2, bisects to

commit d0c221fe7336fc7d9ada57d96f4a8911a3aac041
Author:     Jean-Jacques Hiblot <jjhiblot@ti.com>
AuthorDate: Thu Sep 21 16:29:57 2017 +0200
Commit:     Jaehoon Chung <jh80.chung@samsung.com>
CommitDate: Fri Jan 12 18:11:04 2018 +0900

    mmc: refactor SD startup to make it easier to support new modes
    
    The SDcard startup process currently handles only 2 modes. To make it
    easier to add support for more modes, let's make the process more generic
    and use a list of the modes to try.
    The major functional change is that when a mode fails we try the next one.
    Not all modes are tried, only those supported by the card and the host.
    
    Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
    Reviewed-by: Simon Glass <sjg@chromium.org>

with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5

U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:31:54 +1300)

DRAM:  1 GiB
WARNING: Caches not enabled
Flash: 128 MiB
MMC:   MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   smc911x-0
Hit any key to stop autoboot:  0
=> load mmc 0:1 ${ramdisk_addr} fdt.dtb
unable to select a mode
mmc_init: -524, time 23
unable to select a mode
mmc_init: -524, time 22
** Bad device mmc 0 **
=> load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
unable to select a mode
mmc_init: -524, time 21
unable to select a mode
mmc_init: -524, time 21
** Bad device mmc 0 **
=> bootefi ${loadaddr} ${ramdisk_addr}
## Starting EFI application at a0008000 ...
WARNING: using memory device/image path, this may confuse some payloads!
Scanning disks on mmc...
unable to select a mode
mmc_init: -524, time 21
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
WARNING: Invalid device tree, expect boot to fail
efi_load_pe: Invalid DOS Signature

with mx6cuboxi, bisects to

commit 64e4db0f119151a1345e1da19d152eda550394e7
Author:     Heinrich Schuchardt <xypron.glpk@gmx.de>
AuthorDate: Fri Jan 19 20:24:47 2018 +0100
Commit:     Alexander Graf <agraf@suse.de>
CommitDate: Mon Jan 22 23:09:14 2018 +0100

    efi_loader: make efi_disk_create_partitions a global symbol
    
    Up to now we have been using efi_disk_create_partitions() to create
    partitions for block devices that existed before starting an EFI
    application.
    
    We need to call it for block devices created by EFI
    applications at run time. The EFI application will define the
    handle for the block device and install a device path protocol
    on it. We have to use this device path as stem for the partition
    device paths.
    
    Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
    Signed-off-by: Alexander Graf <agraf@suse.de>

with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5

U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)
Trying to boot from MMC1


U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 24C
Reset cause: POR
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
Loading Environment from MMC... OK
No panel detected: default to HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
37503 bytes read in 17 ms (2.1 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disks on usb...
76528 bytes read in 31 ms (2.4 MiB/s)
## Starting EFI application at 12000000 ...
BS->LocateHandle() returns -2147483634
undefined instruction
pc : [<8e560348>]	   lr : [<8e56444c>]
reloc pc : [<15de4348>]	   lr : [<15de844c>]
sp : 8f57af10  ip : 8ffc2474	 fp : 8f57af1c
r10: 0000b000  r9 : 8f57bee0	 r8 : 0000000b
r7 : 8ffa1a9d  r6 : 8ffa16ad	 r5 : 8e56f0d0	r4 : 8e56e88a
r3 : 8e56dac8  r2 : 00000001	 r1 : 00000000	r0 : 00000000
Flags: nZCv  IRQs off  FIQs off	 Mode SVC_32
Resetting CPU ...

resetting ...

(undefined instruction is used to reset as efi reset was not
present in earlier U-Boot versions)

qemu_arm64 with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5

U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 12:21:06 +1300)

DRAM:  2 GiB
In:    pl011 at 9000000
Out:   pl011 at 9000000
Err:   pl011 at 9000000
Net:   No ethernet found.
Hit any key to stop autoboot:  0
scanning bus for devices...
Target spinup took 0 ms.
SATA link 1 timeout.
SATA link 2 timeout.
SATA link 3 timeout.
SATA link 4 timeout.
SATA link 5 timeout.
AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
flags: 64bit ncq only
  Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
	    Type: Hard Disk
	    Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)

Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
	    Type: Hard Disk
	    Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
... is now current device
Scanning scsi 0:1...
load - load binary file from a filesystem

Usage:
load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
    - Load binary file 'filename' from partition 'part' on device
       type 'interface' instance 'dev' to address 'addr' in memory.
      'bytes' gives the size to load in bytes.
      If 'bytes' is 0 or omitted, the file is read until the end.
      'pos' gives the file byte position to start reading from.
      If 'pos' is 0 or omitted, the file is read from the start.
Found EFI removable media binary efi/boot/bootaa64.efi
Scanning disk ahci_scsi.id0lun0...
Found 3 disks
82748 bytes read in 11 ms (7.2 MiB/s)
## Starting EFI application at 40400000 ...
>> OpenBSD/arm64 BOOTAA64 0.11
boot>
booting sd0a:/bsd: 3913300+580492+583920+806432/[279463+96+459168+244083]=0x843970

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-08 23:55                           ` Jonathan Gray
@ 2018-02-09  3:43                             ` Heinrich Schuchardt
  2018-02-09  4:12                               ` Jonathan Gray
  0 siblings, 1 reply; 22+ messages in thread
From: Heinrich Schuchardt @ 2018-02-09  3:43 UTC (permalink / raw)
  To: u-boot

On 02/09/2018 12:55 AM, Jonathan Gray wrote:
> On Thu, Feb 08, 2018 at 03:44:32PM +0100, Heinrich Schuchardt wrote:
>> On 02/08/2018 10:49 AM, Jonathan Gray wrote:
>>> On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
>>>> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
>>>>>
>>>>>
>>>>>> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
>>>>>>
>>>>>> On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
>>>>>>>> Date: Mon, 5 Feb 2018 21:06:59 +1100
>>>>>>>> From: Jonathan Gray <jsg@jsg.id.au>
>>>>>>>>
>>>>>>>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
>>>>>>>>>> failed(6). will try /bsd
>>>>>>>>>
>>>>>>>>> How do you find out that it's sd0a instead of sd1a?
>>>>>>>>
>>>>>>>> The loaded image protocol I believe.
>>>>>>>
>>>>>>> Actually the OpenBSD bootloader currently only supports loading the
>>>>>>> bsd kernel from the same device as the bootloader.  It will always
>>>>>>> call that device sd0.  It invokes the device path protocol on the
>>>>>>> loaded image handle and then matches that path to a device that
>>>>>>> supports the block io protocol.
>>>>>>
>>>>>> Perhaps the problem is elsewhere as U-Boot master also broke
>>>>>> vexpress_ca15_tc2 and mx6cuboxi targets:
>>>>>
>>>>> Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?
>>>>
>>>> On cubox a bisect points to
>>>>
>>>> commit 64e4db0f119151a1345e1da19d152eda550394e7
>>>> Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>> Date:   Fri Jan 19 20:24:47 2018 +0100
>>>>
>>>>      efi_loader: make efi_disk_create_partitions a global symbol
>>>>      
>>>>      Up to now we have been using efi_disk_create_partitions() to create
>>>>      partitions for block devices that existed before starting an EFI
>>>>      application.
>>>>      
>>>>      We need to call it for block devices created by EFI
>>>>      applications at run time. The EFI application will define the
>>>>      handle for the block device and install a device path protocol
>>>>      on it. We have to use this device path as stem for the partition
>>>>      device paths.
>>>>      
>>>>      Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>      Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>
>>>>   include/efi_loader.h      |  4 +++
>>>>   lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++----------------
>>>>   2 files changed, 64 insertions(+), 24 deletions(-)
>>>>
>>>> If I revert this commit a image built from master works.
>>>
>>> Actually master doesn't build with just that reverted, seems I had stale
>>> object files.
>>
>> When bisecting running
>> 'make mrproper && make foo_defconfig && make'
>> in each round is recommendable.
>>
>> Do you still assume a problem that requires a change in U-Boot?
>> Or can we close the topic?
>>
>> Best regards
>>
>> Heinrich
> 
> There are multiple regressions with U-Boot master compared to 2018.01.

U-Boot master is a moving target. Please, state the commit.

> 
> sopine_baseboard (pinebook), reported to me I don't have hardware
> rpi_3
> mx6cuboxi
> vexpress_ca15_tc2

It is unclear what this sentence means.

Do you expect to that a pinebook can boot from a U-Boot that is compiled 
with rpi_3_defconfig?

Wouldn't you use a U-Boot image compiled with sopine_baseboard_defconfig 
for your pinebook?

> 
> While qemu_arm64 works.
> 
> Bisecting rpi_3 again, removing obj dir between runs and skipping

What do you mean by obj dir?

> commits where nothing shows up on serial again gives the same:
> 
> commit caf2233b281c03e3e359061a3dfa537d8a25c273
> Author:     Alexander Graf <agraf@suse.de>
> AuthorDate: Tue Jan 23 18:05:21 2018 +0100
> Commit:     Tom Rini <trini@konsulko.com>
> CommitDate: Sun Jan 28 12:27:32 2018 -0500
> 
>      bcm283x: Add pinctrl driver
>      
>      The bcm283x family of SoCs have a GPIO controller that also acts as
>      pinctrl controller.
>      
>      This patch introduces a new pinctrl driver that can actually properly mux
>      devices into their device tree defined pin states and is now the primary
>      owner of the gpio device. The previous GPIO driver gets moved into a
>      subdevice of the pinctrl driver, bound to the same OF node.
>      
>      That way whenever a device asks for pinctrl support, it gets it
>      automatically from the pinctrl driver and GPIO support is still available
>      in the normal command line phase.
>      
>      Signed-off-by: Alexander Graf <agraf@suse.de>
> 
> with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:36:18 +1300)
> 
> DRAM:  948 MiB
> RPI 3 Model B (0xa02082)
> MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
> Loading Environment from FAT... OK
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   No ethernet found.
> starting USB...
> USB0:	Core Release: 2.80a
> scanning bus 0 for devices... 4 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> 
> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> 	    Type: Removable Hard Disk
> 	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> 82748 bytes read in 89 ms (907.2 KiB/s)
> ## Starting EFI application at 01000000 ...
> Scanning disk mmc at 7e202000.blk...
> Card did not respond to voltage select!
> mmc_init: -95, time 25
> Scanning disk sdhci at 7e300000.blk...
>>> OpenBSD/arm64 BOOTAA64 0.11
> open(tftp0a:/etc/boot.conf): Operation not permitted

With this little output it is impossible to analyze what is going on. 
Please, enable debug output using

#define DEBUG 1

in the relevant U-Boot files before the first include.

To disable output for some time critical routines in the same source 
file you could use:

#undef _DEBUG
#define _DEBUG 0

... time critical code ...

#undef _DEBUG
#define _DEBUG 1

I guess Alex has a rpi_3 available. Can he use the following disk image 
for testing?

https://ftp.eu.openbsd.org/pub/OpenBSD/6.2/arm64/miniroot62.fs

Best regards

Heinrich

> boot>
> booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
>   failed(1). will try /bsd
> 
> with vexpress_ca15_tc2, bisects to
> 
> commit d0c221fe7336fc7d9ada57d96f4a8911a3aac041
> Author:     Jean-Jacques Hiblot <jjhiblot@ti.com>
> AuthorDate: Thu Sep 21 16:29:57 2017 +0200
> Commit:     Jaehoon Chung <jh80.chung@samsung.com>
> CommitDate: Fri Jan 12 18:11:04 2018 +0900
> 
>      mmc: refactor SD startup to make it easier to support new modes
>      
>      The SDcard startup process currently handles only 2 modes. To make it
>      easier to add support for more modes, let's make the process more generic
>      and use a list of the modes to try.
>      The major functional change is that when a mode fails we try the next one.
>      Not all modes are tried, only those supported by the card and the host.
>      
>      Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
>      Reviewed-by: Simon Glass <sjg@chromium.org>
> 
> with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:31:54 +1300)
> 
> DRAM:  1 GiB
> WARNING: Caches not enabled
> Flash: 128 MiB
> MMC:   MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Net:   smc911x-0
> Hit any key to stop autoboot:  0
> => load mmc 0:1 ${ramdisk_addr} fdt.dtb
> unable to select a mode
> mmc_init: -524, time 23
> unable to select a mode
> mmc_init: -524, time 22
> ** Bad device mmc 0 **
> => load mmc 0:1 ${loadaddr} efi/boot/bootarm.efi
> unable to select a mode
> mmc_init: -524, time 21
> unable to select a mode
> mmc_init: -524, time 21
> ** Bad device mmc 0 **
> => bootefi ${loadaddr} ${ramdisk_addr}
> ## Starting EFI application at a0008000 ...
> WARNING: using memory device/image path, this may confuse some payloads!
> Scanning disks on mmc...
> unable to select a mode
> mmc_init: -524, time 21
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 0 disks
> WARNING: Invalid device tree, expect boot to fail
> efi_load_pe: Invalid DOS Signature
> 
> with mx6cuboxi, bisects to
> 
> commit 64e4db0f119151a1345e1da19d152eda550394e7
> Author:     Heinrich Schuchardt <xypron.glpk@gmx.de>
> AuthorDate: Fri Jan 19 20:24:47 2018 +0100
> Commit:     Alexander Graf <agraf@suse.de>
> CommitDate: Mon Jan 22 23:09:14 2018 +0100
> 
>      efi_loader: make efi_disk_create_partitions a global symbol
>      
>      Up to now we have been using efi_disk_create_partitions() to create
>      partitions for block devices that existed before starting an EFI
>      application.
>      
>      We need to call it for block devices created by EFI
>      applications at run time. The EFI application will define the
>      handle for the block device and install a device path protocol
>      on it. We have to use this device path as stem for the partition
>      device paths.
>      
>      Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>      Signed-off-by: Alexander Graf <agraf@suse.de>
> 
> with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
> U-Boot SPL 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)
> Trying to boot from MMC1
> 
> 
> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:43:18 +1300)
> 
> CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> CPU:   Extended Commercial temperature grade (-20C to 105C) at 24C
> Reset cause: POR
> Board: MX6 Cubox-i
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0
> Loading Environment from MMC... OK
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> 37503 bytes read in 17 ms (2.1 MiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> Scanning disks on usb...
> 76528 bytes read in 31 ms (2.4 MiB/s)
> ## Starting EFI application at 12000000 ...
> BS->LocateHandle() returns -2147483634
> undefined instruction
> pc : [<8e560348>]	   lr : [<8e56444c>]
> reloc pc : [<15de4348>]	   lr : [<15de844c>]
> sp : 8f57af10  ip : 8ffc2474	 fp : 8f57af1c
> r10: 0000b000  r9 : 8f57bee0	 r8 : 0000000b
> r7 : 8ffa1a9d  r6 : 8ffa16ad	 r5 : 8e56f0d0	r4 : 8e56e88a
> r3 : 8e56dac8  r2 : 00000001	 r1 : 00000000	r0 : 00000000
> Flags: nZCv  IRQs off  FIQs off	 Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> (undefined instruction is used to reset as efi reset was not
> present in earlier U-Boot versions)
> 
> qemu_arm64 with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 12:21:06 +1300)
> 
> DRAM:  2 GiB
> In:    pl011 at 9000000
> Out:   pl011 at 9000000
> Err:   pl011 at 9000000
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> scanning bus for devices...
> Target spinup took 0 ms.
> SATA link 1 timeout.
> SATA link 2 timeout.
> SATA link 3 timeout.
> SATA link 4 timeout.
> SATA link 5 timeout.
> AHCI 0001.0000 32 slots 6 ports 1.5 Gbps 0x3f impl SATA mode
> flags: 64bit ncq only
>    Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
> 	    Type: Hard Disk
> 	    Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
> 
> Device 0: (0:0) Vendor: ATA Prod.: QEMU HARDDISK Rev: 2.5+
> 	    Type: Hard Disk
> 	    Capacity: 4096.0 MB = 4.0 GB (8388608 x 512)
> ... is now current device
> Scanning scsi 0:1...
> load - load binary file from a filesystem
> 
> Usage:
> load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]]
>      - Load binary file 'filename' from partition 'part' on device
>         type 'interface' instance 'dev' to address 'addr' in memory.
>        'bytes' gives the size to load in bytes.
>        If 'bytes' is 0 or omitted, the file is read until the end.
>        'pos' gives the file byte position to start reading from.
>        If 'pos' is 0 or omitted, the file is read from the start.
> Found EFI removable media binary efi/boot/bootaa64.efi
> Scanning disk ahci_scsi.id0lun0...
> Found 3 disks
> 82748 bytes read in 11 ms (7.2 MiB/s)
> ## Starting EFI application at 40400000 ...
>>> OpenBSD/arm64 BOOTAA64 0.11
> boot>
> booting sd0a:/bsd: 3913300+580492+583920+806432/[279463+96+459168+244083]=0x843970
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-09  3:43                             ` Heinrich Schuchardt
@ 2018-02-09  4:12                               ` Jonathan Gray
  2018-02-09  4:41                                 ` Heinrich Schuchardt
  0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Gray @ 2018-02-09  4:12 UTC (permalink / raw)
  To: u-boot

On Fri, Feb 09, 2018 at 04:43:09AM +0100, Heinrich Schuchardt wrote:
> On 02/09/2018 12:55 AM, Jonathan Gray wrote:
> > On Thu, Feb 08, 2018 at 03:44:32PM +0100, Heinrich Schuchardt wrote:
> > > On 02/08/2018 10:49 AM, Jonathan Gray wrote:
> > > > On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
> > > > > On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
> > > > > > 
> > > > > > 
> > > > > > > Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
> > > > > > > 
> > > > > > > On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
> > > > > > > > > Date: Mon, 5 Feb 2018 21:06:59 +1100
> > > > > > > > > From: Jonathan Gray <jsg@jsg.id.au>
> > > > > > > > > 
> > > > > > > > > > > booting sd0a:/bsd: open sd0a:/bsd: Device not configured
> > > > > > > > > > > failed(6). will try /bsd
> > > > > > > > > > 
> > > > > > > > > > How do you find out that it's sd0a instead of sd1a?
> > > > > > > > > 
> > > > > > > > > The loaded image protocol I believe.
> > > > > > > > 
> > > > > > > > Actually the OpenBSD bootloader currently only supports loading the
> > > > > > > > bsd kernel from the same device as the bootloader.  It will always
> > > > > > > > call that device sd0.  It invokes the device path protocol on the
> > > > > > > > loaded image handle and then matches that path to a device that
> > > > > > > > supports the block io protocol.
> > > > > > > 
> > > > > > > Perhaps the problem is elsewhere as U-Boot master also broke
> > > > > > > vexpress_ca15_tc2 and mx6cuboxi targets:
> > > > > > 
> > > > > > Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?
> > > > > 
> > > > > On cubox a bisect points to
> > > > > 
> > > > > commit 64e4db0f119151a1345e1da19d152eda550394e7
> > > > > Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > > > > Date:   Fri Jan 19 20:24:47 2018 +0100
> > > > > 
> > > > >      efi_loader: make efi_disk_create_partitions a global symbol
> > > > >      Up to now we have been using efi_disk_create_partitions() to create
> > > > >      partitions for block devices that existed before starting an EFI
> > > > >      application.
> > > > >      We need to call it for block devices created by EFI
> > > > >      applications at run time. The EFI application will define the
> > > > >      handle for the block device and install a device path protocol
> > > > >      on it. We have to use this device path as stem for the partition
> > > > >      device paths.
> > > > >      Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > > > >      Signed-off-by: Alexander Graf <agraf@suse.de>
> > > > > 
> > > > >   include/efi_loader.h      |  4 +++
> > > > >   lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++----------------
> > > > >   2 files changed, 64 insertions(+), 24 deletions(-)
> > > > > 
> > > > > If I revert this commit a image built from master works.
> > > > 
> > > > Actually master doesn't build with just that reverted, seems I had stale
> > > > object files.
> > > 
> > > When bisecting running
> > > 'make mrproper && make foo_defconfig && make'
> > > in each round is recommendable.
> > > 
> > > Do you still assume a problem that requires a change in U-Boot?
> > > Or can we close the topic?
> > > 
> > > Best regards
> > > 
> > > Heinrich
> > 
> > There are multiple regressions with U-Boot master compared to 2018.01.
> 
> U-Boot master is a moving target. Please, state the commit.

The commit was mentioned three times in the mail but you seem
to have missed that.

again e24bd1e79e223aa89854c0be95a53e2d538144a5

> 
> > 
> > sopine_baseboard (pinebook), reported to me I don't have hardware
> > rpi_3
> > mx6cuboxi
> > vexpress_ca15_tc2
> 
> It is unclear what this sentence means.
> 
> Do you expect to that a pinebook can boot from a U-Boot that is compiled
> with rpi_3_defconfig?
> 
> Wouldn't you use a U-Boot image compiled with sopine_baseboard_defconfig for
> your pinebook?

Please read the above.  A sopine_baseboard image was used on the pinebook
and not by me.

> 
> > 
> > While qemu_arm64 works.
> > 
> > Bisecting rpi_3 again, removing obj dir between runs and skipping
> 
> What do you mean by obj dir?

build directory, dir used with O= on make calls

> 
> > commits where nothing shows up on serial again gives the same:
> > 
> > commit caf2233b281c03e3e359061a3dfa537d8a25c273
> > Author:     Alexander Graf <agraf@suse.de>
> > AuthorDate: Tue Jan 23 18:05:21 2018 +0100
> > Commit:     Tom Rini <trini@konsulko.com>
> > CommitDate: Sun Jan 28 12:27:32 2018 -0500
> > 
> >      bcm283x: Add pinctrl driver
> >      The bcm283x family of SoCs have a GPIO controller that also acts as
> >      pinctrl controller.
> >      This patch introduces a new pinctrl driver that can actually properly mux
> >      devices into their device tree defined pin states and is now the primary
> >      owner of the gpio device. The previous GPIO driver gets moved into a
> >      subdevice of the pinctrl driver, bound to the same OF node.
> >      That way whenever a device asks for pinctrl support, it gets it
> >      automatically from the pinctrl driver and GPIO support is still available
> >      in the normal command line phase.
> >      Signed-off-by: Alexander Graf <agraf@suse.de>
> > 
> > with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
> > 
> > U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:36:18 +1300)
> > 
> > DRAM:  948 MiB
> > RPI 3 Model B (0xa02082)
> > MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
> > Loading Environment from FAT... OK
> > In:    serial
> > Out:   vidconsole
> > Err:   vidconsole
> > Net:   No ethernet found.
> > starting USB...
> > USB0:	Core Release: 2.80a
> > scanning bus 0 for devices... 4 USB Device(s) found
> >         scanning usb for storage devices... 1 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > 
> > Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
> > 	    Type: Removable Hard Disk
> > 	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
> > ... is now current device
> > Scanning usb 0:1...
> > Found EFI removable media binary efi/boot/bootaa64.efi
> > 82748 bytes read in 89 ms (907.2 KiB/s)
> > ## Starting EFI application at 01000000 ...
> > Scanning disk mmc at 7e202000.blk...
> > Card did not respond to voltage select!
> > mmc_init: -95, time 25
> > Scanning disk sdhci at 7e300000.blk...
> > > > OpenBSD/arm64 BOOTAA64 0.11
> > open(tftp0a:/etc/boot.conf): Operation not permitted
> 
> With this little output it is impossible to analyze what is going on.
> Please, enable debug output using
> 
> #define DEBUG 1
> 
> in the relevant U-Boot files before the first include.
> 
> To disable output for some time critical routines in the same source file
> you could use:
> 
> #undef _DEBUG
> #define _DEBUG 0
> 
> ... time critical code ...
> 
> #undef _DEBUG
> #define _DEBUG 1
> 
> I guess Alex has a rpi_3 available. Can he use the following disk image for
> testing?
> 
> https://ftp.eu.openbsd.org/pub/OpenBSD/6.2/arm64/miniroot62.fs

https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

includes U-Boot 2018.01, raspberry pi 3 firmware files/dtb, and is
suitable for dd'ing to a sd card.  It is an installer image for
OpenBSD/arm64.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-09  4:12                               ` Jonathan Gray
@ 2018-02-09  4:41                                 ` Heinrich Schuchardt
  2018-02-09 16:49                                   ` Heinrich Schuchardt
  0 siblings, 1 reply; 22+ messages in thread
From: Heinrich Schuchardt @ 2018-02-09  4:41 UTC (permalink / raw)
  To: u-boot

On 02/09/2018 05:12 AM, Jonathan Gray wrote:
> On Fri, Feb 09, 2018 at 04:43:09AM +0100, Heinrich Schuchardt wrote:
>> On 02/09/2018 12:55 AM, Jonathan Gray wrote:
>>> On Thu, Feb 08, 2018 at 03:44:32PM +0100, Heinrich Schuchardt wrote:
>>>> On 02/08/2018 10:49 AM, Jonathan Gray wrote:
>>>>> On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
>>>>>> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
>>>>>>>>
>>>>>>>> On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
>>>>>>>>>> Date: Mon, 5 Feb 2018 21:06:59 +1100
>>>>>>>>>> From: Jonathan Gray <jsg@jsg.id.au>
>>>>>>>>>>
>>>>>>>>>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
>>>>>>>>>>>> failed(6). will try /bsd
>>>>>>>>>>>
>>>>>>>>>>> How do you find out that it's sd0a instead of sd1a?
>>>>>>>>>>
>>>>>>>>>> The loaded image protocol I believe.
>>>>>>>>>
>>>>>>>>> Actually the OpenBSD bootloader currently only supports loading the
>>>>>>>>> bsd kernel from the same device as the bootloader.  It will always
>>>>>>>>> call that device sd0.  It invokes the device path protocol on the
>>>>>>>>> loaded image handle and then matches that path to a device that
>>>>>>>>> supports the block io protocol.
>>>>>>>>
>>>>>>>> Perhaps the problem is elsewhere as U-Boot master also broke
>>>>>>>> vexpress_ca15_tc2 and mx6cuboxi targets:
>>>>>>>
>>>>>>> Perfect, so can you quickly bisect it now that the bisect doesn???t end at the pinctrl driver?
>>>>>>
>>>>>> On cubox a bisect points to
>>>>>>
>>>>>> commit 64e4db0f119151a1345e1da19d152eda550394e7
>>>>>> Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>> Date:   Fri Jan 19 20:24:47 2018 +0100
>>>>>>
>>>>>>       efi_loader: make efi_disk_create_partitions a global symbol
>>>>>>       Up to now we have been using efi_disk_create_partitions() to create
>>>>>>       partitions for block devices that existed before starting an EFI
>>>>>>       application.
>>>>>>       We need to call it for block devices created by EFI
>>>>>>       applications at run time. The EFI application will define the
>>>>>>       handle for the block device and install a device path protocol
>>>>>>       on it. We have to use this device path as stem for the partition
>>>>>>       device paths.
>>>>>>       Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>       Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>
>>>>>>    include/efi_loader.h      |  4 +++
>>>>>>    lib/efi_loader/efi_disk.c | 84 +++++++++++++++++++++++++++++++++++++++----------------
>>>>>>    2 files changed, 64 insertions(+), 24 deletions(-)
>>>>>>
>>>>>> If I revert this commit a image built from master works.
>>>>>
>>>>> Actually master doesn't build with just that reverted, seems I had stale
>>>>> object files.
>>>>
>>>> When bisecting running
>>>> 'make mrproper && make foo_defconfig && make'
>>>> in each round is recommendable.
>>>>
>>>> Do you still assume a problem that requires a change in U-Boot?
>>>> Or can we close the topic?
>>>>
>>>> Best regards
>>>>
>>>> Heinrich
>>>
>>> There are multiple regressions with U-Boot master compared to 2018.01.
>>
>> U-Boot master is a moving target. Please, state the commit.
> 
> The commit was mentioned three times in the mail but you seem
> to have missed that.
> 
> again e24bd1e79e223aa89854c0be95a53e2d538144a5
> 
>>
>>>
>>> sopine_baseboard (pinebook), reported to me I don't have hardware
>>> rpi_3
>>> mx6cuboxi
>>> vexpress_ca15_tc2
>>
>> It is unclear what this sentence means.
>>
>> Do you expect to that a pinebook can boot from a U-Boot that is compiled
>> with rpi_3_defconfig?
>>
>> Wouldn't you use a U-Boot image compiled with sopine_baseboard_defconfig for
>> your pinebook?
> 
> Please read the above.  A sopine_baseboard image was used on the pinebook
> and not by me.
> 
>>
>>>
>>> While qemu_arm64 works.
>>>
>>> Bisecting rpi_3 again, removing obj dir between runs and skipping
>>
>> What do you mean by obj dir?
> 
> build directory, dir used with O= on make calls
> 
>>
>>> commits where nothing shows up on serial again gives the same:
>>>
>>> commit caf2233b281c03e3e359061a3dfa537d8a25c273
>>> Author:     Alexander Graf <agraf@suse.de>
>>> AuthorDate: Tue Jan 23 18:05:21 2018 +0100
>>> Commit:     Tom Rini <trini@konsulko.com>
>>> CommitDate: Sun Jan 28 12:27:32 2018 -0500
>>>
>>>       bcm283x: Add pinctrl driver
>>>       The bcm283x family of SoCs have a GPIO controller that also acts as
>>>       pinctrl controller.
>>>       This patch introduces a new pinctrl driver that can actually properly mux
>>>       devices into their device tree defined pin states and is now the primary
>>>       owner of the gpio device. The previous GPIO driver gets moved into a
>>>       subdevice of the pinctrl driver, bound to the same OF node.
>>>       That way whenever a device asks for pinctrl support, it gets it
>>>       automatically from the pinctrl driver and GPIO support is still available
>>>       in the normal command line phase.
>>>       Signed-off-by: Alexander Graf <agraf@suse.de>
>>>
>>> with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
>>>
>>> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:36:18 +1300)
>>>
>>> DRAM:  948 MiB
>>> RPI 3 Model B (0xa02082)
>>> MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
>>> Loading Environment from FAT... OK
>>> In:    serial
>>> Out:   vidconsole
>>> Err:   vidconsole
>>> Net:   No ethernet found.
>>> starting USB...
>>> USB0:	Core Release: 2.80a
>>> scanning bus 0 for devices... 4 USB Device(s) found
>>>          scanning usb for storage devices... 1 Storage Device(s) found
>>> Hit any key to stop autoboot:  0
>>>
>>> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
>>> 	    Type: Removable Hard Disk
>>> 	    Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
>>> ... is now current device
>>> Scanning usb 0:1...
>>> Found EFI removable media binary efi/boot/bootaa64.efi
>>> 82748 bytes read in 89 ms (907.2 KiB/s)
>>> ## Starting EFI application at 01000000 ...
>>> Scanning disk mmc at 7e202000.blk...
>>> Card did not respond to voltage select!
>>> mmc_init: -95, time 25
>>> Scanning disk sdhci at 7e300000.blk...
>>>>> OpenBSD/arm64 BOOTAA64 0.11
>>> open(tftp0a:/etc/boot.conf): Operation not permitted
>>
>> With this little output it is impossible to analyze what is going on.
>> Please, enable debug output using
>>
>> #define DEBUG 1
>>
>> in the relevant U-Boot files before the first include.
>>
>> To disable output for some time critical routines in the same source file
>> you could use:
>>
>> #undef _DEBUG
>> #define _DEBUG 0
>>
>> ... time critical code ...
>>
>> #undef _DEBUG
>> #define _DEBUG 1
>>
>> I guess Alex has a rpi_3 available. Can he use the following disk image for
>> testing?
>>
>> https://ftp.eu.openbsd.org/pub/OpenBSD/6.2/arm64/miniroot62.fs
> 
> https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs

This is an image that changes every day.

For testing we should have a stable reference. So I copied the file to
https://www.xypron.de/temp/openbsd/

> 
> includes U-Boot 2018.01, raspberry pi 3 firmware files/dtb, and is
> suitable for dd'ing to a sd card.  It is an installer image for
> OpenBSD/arm64.
> 

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-09  4:41                                 ` Heinrich Schuchardt
@ 2018-02-09 16:49                                   ` Heinrich Schuchardt
  0 siblings, 0 replies; 22+ messages in thread
From: Heinrich Schuchardt @ 2018-02-09 16:49 UTC (permalink / raw)
  To: u-boot

On 02/09/2018 05:41 AM, Heinrich Schuchardt wrote:
> On 02/09/2018 05:12 AM, Jonathan Gray wrote:
>> On Fri, Feb 09, 2018 at 04:43:09AM +0100, Heinrich Schuchardt wrote:
>>> On 02/09/2018 12:55 AM, Jonathan Gray wrote:
>>>> On Thu, Feb 08, 2018 at 03:44:32PM +0100, Heinrich Schuchardt wrote:
>>>>> On 02/08/2018 10:49 AM, Jonathan Gray wrote:
>>>>>> On Thu, Feb 08, 2018 at 08:10:47PM +1100, Jonathan Gray wrote:
>>>>>>> On Thu, Feb 08, 2018 at 09:11:20AM +0100, Alexander Graf wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Am 08.02.2018 um 06:49 schrieb Jonathan Gray <jsg@jsg.id.au>:
>>>>>>>>>
>>>>>>>>> On Mon, Feb 05, 2018 at 11:31:42AM +0100, Mark Kettenis wrote:
>>>>>>>>>>> Date: Mon, 5 Feb 2018 21:06:59 +1100
>>>>>>>>>>> From: Jonathan Gray <jsg@jsg.id.au>
>>>>>>>>>>>
>>>>>>>>>>>>> booting sd0a:/bsd: open sd0a:/bsd: Device not configured
>>>>>>>>>>>>> failed(6). will try /bsd
>>>>>>>>>>>>
>>>>>>>>>>>> How do you find out that it's sd0a instead of sd1a?
>>>>>>>>>>>
>>>>>>>>>>> The loaded image protocol I believe.
>>>>>>>>>>
>>>>>>>>>> Actually the OpenBSD bootloader currently only supports
>>>>>>>>>> loading the
>>>>>>>>>> bsd kernel from the same device as the bootloader.  It will
>>>>>>>>>> always
>>>>>>>>>> call that device sd0.  It invokes the device path protocol on the
>>>>>>>>>> loaded image handle and then matches that path to a device that
>>>>>>>>>> supports the block io protocol.
>>>>>>>>>
>>>>>>>>> Perhaps the problem is elsewhere as U-Boot master also broke
>>>>>>>>> vexpress_ca15_tc2 and mx6cuboxi targets:
>>>>>>>>
>>>>>>>> Perfect, so can you quickly bisect it now that the bisect
>>>>>>>> doesn???t end at the pinctrl driver?
>>>>>>>
>>>>>>> On cubox a bisect points to
>>>>>>>
>>>>>>> commit 64e4db0f119151a1345e1da19d152eda550394e7
>>>>>>> Author: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>> Date:   Fri Jan 19 20:24:47 2018 +0100
>>>>>>>
>>>>>>>       efi_loader: make efi_disk_create_partitions a global symbol
>>>>>>>       Up to now we have been using efi_disk_create_partitions()
>>>>>>> to create
>>>>>>>       partitions for block devices that existed before starting
>>>>>>> an EFI
>>>>>>>       application.
>>>>>>>       We need to call it for block devices created by EFI
>>>>>>>       applications at run time. The EFI application will define the
>>>>>>>       handle for the block device and install a device path protocol
>>>>>>>       on it. We have to use this device path as stem for the
>>>>>>> partition
>>>>>>>       device paths.
>>>>>>>       Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>>       Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>>
>>>>>>>    include/efi_loader.h      |  4 +++
>>>>>>>    lib/efi_loader/efi_disk.c | 84
>>>>>>> +++++++++++++++++++++++++++++++++++++++----------------
>>>>>>>    2 files changed, 64 insertions(+), 24 deletions(-)
>>>>>>>
>>>>>>> If I revert this commit a image built from master works.
>>>>>>
>>>>>> Actually master doesn't build with just that reverted, seems I had
>>>>>> stale
>>>>>> object files.
>>>>>
>>>>> When bisecting running
>>>>> 'make mrproper && make foo_defconfig && make'
>>>>> in each round is recommendable.
>>>>>
>>>>> Do you still assume a problem that requires a change in U-Boot?
>>>>> Or can we close the topic?
>>>>>
>>>>> Best regards
>>>>>
>>>>> Heinrich
>>>>
>>>> There are multiple regressions with U-Boot master compared to 2018.01.
>>>
>>> U-Boot master is a moving target. Please, state the commit.
>>
>> The commit was mentioned three times in the mail but you seem
>> to have missed that.
>>
>> again e24bd1e79e223aa89854c0be95a53e2d538144a5
>>
>>>
>>>>
>>>> sopine_baseboard (pinebook), reported to me I don't have hardware
>>>> rpi_3
>>>> mx6cuboxi
>>>> vexpress_ca15_tc2
>>>
>>> It is unclear what this sentence means.
>>>
>>> Do you expect to that a pinebook can boot from a U-Boot that is compiled
>>> with rpi_3_defconfig?
>>>
>>> Wouldn't you use a U-Boot image compiled with
>>> sopine_baseboard_defconfig for
>>> your pinebook?
>>
>> Please read the above.  A sopine_baseboard image was used on the pinebook
>> and not by me.
>>
>>>
>>>>
>>>> While qemu_arm64 works.
>>>>
>>>> Bisecting rpi_3 again, removing obj dir between runs and skipping
>>>
>>> What do you mean by obj dir?
>>
>> build directory, dir used with O= on make calls
>>
>>>
>>>> commits where nothing shows up on serial again gives the same:
>>>>
>>>> commit caf2233b281c03e3e359061a3dfa537d8a25c273
>>>> Author:     Alexander Graf <agraf@suse.de>
>>>> AuthorDate: Tue Jan 23 18:05:21 2018 +0100
>>>> Commit:     Tom Rini <trini@konsulko.com>
>>>> CommitDate: Sun Jan 28 12:27:32 2018 -0500
>>>>
>>>>       bcm283x: Add pinctrl driver
>>>>       The bcm283x family of SoCs have a GPIO controller that also
>>>> acts as
>>>>       pinctrl controller.
>>>>       This patch introduces a new pinctrl driver that can actually
>>>> properly mux
>>>>       devices into their device tree defined pin states and is now
>>>> the primary
>>>>       owner of the gpio device. The previous GPIO driver gets moved
>>>> into a
>>>>       subdevice of the pinctrl driver, bound to the same OF node.
>>>>       That way whenever a device asks for pinctrl support, it gets it
>>>>       automatically from the pinctrl driver and GPIO support is
>>>> still available
>>>>       in the normal command line phase.
>>>>       Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>
>>>> with master as of e24bd1e79e223aa89854c0be95a53e2d538144a5
>>>>
>>>> U-Boot 2018.03-rc1-00185-g1e19c70639 (Feb 09 2018 - 11:36:18 +1300)
>>>>
>>>> DRAM:  948 MiB
>>>> RPI 3 Model B (0xa02082)
>>>> MMC:   mmc at 7e202000: 0, sdhci at 7e300000: 1
>>>> Loading Environment from FAT... OK
>>>> In:    serial
>>>> Out:   vidconsole
>>>> Err:   vidconsole
>>>> Net:   No ethernet found.
>>>> starting USB...
>>>> USB0:    Core Release: 2.80a
>>>> scanning bus 0 for devices... 4 USB Device(s) found
>>>>          scanning usb for storage devices... 1 Storage Device(s) found
>>>> Hit any key to stop autoboot:  0
>>>>
>>>> Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
>>>>         Type: Removable Hard Disk
>>>>         Capacity: 29327.3 MB = 28.6 GB (60062500 x 512)
>>>> ... is now current device
>>>> Scanning usb 0:1...
>>>> Found EFI removable media binary efi/boot/bootaa64.efi
>>>> 82748 bytes read in 89 ms (907.2 KiB/s)
>>>> ## Starting EFI application at 01000000 ...
>>>> Scanning disk mmc at 7e202000.blk...
>>>> Card did not respond to voltage select!
>>>> mmc_init: -95, time 25
>>>> Scanning disk sdhci at 7e300000.blk...
>>>>>> OpenBSD/arm64 BOOTAA64 0.11
>>>> open(tftp0a:/etc/boot.conf): Operation not permitted
>>>
>>> With this little output it is impossible to analyze what is going on.
>>> Please, enable debug output using
>>>
>>> #define DEBUG 1
>>>
>>> in the relevant U-Boot files before the first include.
>>>
>>> To disable output for some time critical routines in the same source
>>> file
>>> you could use:
>>>
>>> #undef _DEBUG
>>> #define _DEBUG 0
>>>
>>> ... time critical code ...
>>>
>>> #undef _DEBUG
>>> #define _DEBUG 1
>>>
>>> I guess Alex has a rpi_3 available. Can he use the following disk
>>> image for
>>> testing?
>>>
>>> https://ftp.eu.openbsd.org/pub/OpenBSD/6.2/arm64/miniroot62.fs
>>
>> https://fastly.cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot62.fs
> 
> This is an image that changes every day.
> 
> For testing we should have a stable reference. So I copied the file to
> https://www.xypron.de/temp/openbsd/
> 
>>
>> includes U-Boot 2018.01, raspberry pi 3 firmware files/dtb, and is
>> suitable for dd'ing to a sd card.  It is an installer image for
>> OpenBSD/arm64.
>>
> 
> 

Resolved with patch
efi_loader: correct efi_disk_register
https://lists.denx.de/pipermail/u-boot/2018-February/320035.html

Thanks for reporting the problem.
Could you, please, confirm the fix works for you.

Best regards

Heinrich

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [U-Boot] [U-Boot,v3,1/2] bcm283x: Add pinctrl driver
  2018-02-03  1:47     ` Jonathan Gray
  2018-02-03  8:02       ` Alexander Graf
@ 2018-02-09 23:02       ` Jonathan Gray
  1 sibling, 0 replies; 22+ messages in thread
From: Jonathan Gray @ 2018-02-09 23:02 UTC (permalink / raw)
  To: u-boot

On Sat, Feb 03, 2018 at 12:47:48PM +1100, Jonathan Gray wrote:
> On Sun, Jan 28, 2018 at 01:54:25PM -0500, Tom Rini wrote:
> > On Tue, Jan 23, 2018 at 06:05:21PM +0100, Alexander Graf wrote:
> > 
> > > The bcm283x family of SoCs have a GPIO controller that also acts as
> > > pinctrl controller.
> > > 
> > > This patch introduces a new pinctrl driver that can actually properly mux
> > > devices into their device tree defined pin states and is now the primary
> > > owner of the gpio device. The previous GPIO driver gets moved into a
> > > subdevice of the pinctrl driver, bound to the same OF node.
> > > 
> > > That way whenever a device asks for pinctrl support, it gets it
> > > automatically from the pinctrl driver and GPIO support is still available
> > > in the normal command line phase.
> > > 
> > > Signed-off-by: Alexander Graf <agraf@suse.de>
> > 
> > Applied to u-boot/master, thanks!
> 
> It seems one of the recent commits here has broken booting on rpi_3 with
> the vendor supplied device tree via efi_loader.
> 
> last working commit seems to be:
> 
> 8996975ff8422e07f43eb8b3b0c7ed8c2b35442f
> powerpc: Drop CONFIG_WALNUT and other related dead code
> 
> After that were
> 
> caf2233b281c03e3e359061a3dfa537d8a25c273
> bcm283x: Add pinctrl driver
> 
> c8a73a26d6dd9b7d489e66529fe1412425d8f2d1
> mmc: Add bcm2835 sdhost controller
> 
> These can't easily be reverted due to other changes.

This turns out to have been efi loader changes, and is resolved
by 'efi_loader: correct efi_disk_register'
https://lists.denx.de/pipermail/u-boot/2018-February/320043.html

Still not clear on why git bisect kept pointing at these pinctrl changes
on rpi_3.

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2018-02-09 23:02 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-23 17:05 [U-Boot] [PATCH v3 0/2] Rpi: Add support for second sd host controller Alexander Graf
2018-01-23 17:05 ` [U-Boot] [PATCH v3 1/2] bcm283x: Add pinctrl driver Alexander Graf
2018-01-28 18:54   ` [U-Boot] [U-Boot,v3,1/2] " Tom Rini
2018-02-03  1:47     ` Jonathan Gray
2018-02-03  8:02       ` Alexander Graf
2018-02-03 11:38         ` Jonathan Gray
2018-02-05  8:37           ` Alexander Graf
2018-02-05 10:06             ` Jonathan Gray
2018-02-05 10:31               ` Mark Kettenis
2018-02-08  5:49                 ` Jonathan Gray
2018-02-08  8:11                   ` Alexander Graf
2018-02-08  9:10                     ` Jonathan Gray
2018-02-08  9:49                       ` Jonathan Gray
2018-02-08 14:44                         ` Heinrich Schuchardt
2018-02-08 23:55                           ` Jonathan Gray
2018-02-09  3:43                             ` Heinrich Schuchardt
2018-02-09  4:12                               ` Jonathan Gray
2018-02-09  4:41                                 ` Heinrich Schuchardt
2018-02-09 16:49                                   ` Heinrich Schuchardt
2018-02-09 23:02       ` Jonathan Gray
2018-01-23 17:05 ` [U-Boot] [PATCH v3 2/2] mmc: Add bcm2835 sdhost controller Alexander Graf
2018-01-28 18:54   ` [U-Boot] [U-Boot,v3,2/2] " Tom Rini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.