[U-Boot] [PATCH v3 0/2] Rpi: Add support for second sd host controller
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
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 +};
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!
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.
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
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 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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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@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@7e201000 mmc [ + ] bcm2835-sd | |-- mmc@7e202000 blk [ + ] mmc_blk | | `-- mmc@7e202000.blk serial [ + ] serial_bcm | |-- serial@7e215040 mmc [ + ] sdhci-bcm2 | |-- sdhci@7e300000 blk [ ] mmc_blk | | `-- sdhci@7e300000.blk video [ + ] bcm2835_vi | |-- hdmi@7e902000 vidconsole [ + ] vidconsole | | `-- hdmi@7e902000.vidconsole0 usb [ + ] dwc2_usb | `-- usb@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
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 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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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
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 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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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)
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@lists.denx.de https://lists.denx.de/listinfo/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 ...
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
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.
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@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@7e300000.blk... unhandled parent class: sdhci@7e300000.blk (13) unhandled parent class: sdhci@7e300000.blk (13) unhandled parent class: sdhci@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
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@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@7e300000.blk... unhandled parent class: sdhci@7e300000.blk (13) unhandled parent class: sdhci@7e300000.blk (13) unhandled parent class: sdhci@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
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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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@9000000 Out: pl011@9000000 Err: pl011@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
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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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@9000000 Out: pl011@9000000 Err: pl011@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
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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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.
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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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.
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@7e202000: 0, sdhci@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@7e202000.blk... Card did not respond to voltage select! mmc_init: -95, time 25 Scanning disk sdhci@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
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.
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, +};
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!
participants (5)
-
Alexander Graf -
Heinrich Schuchardt -
Jonathan Gray -
Mark Kettenis -
Tom Rini