All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
@ 2019-01-23 21:13 Adam Ford
  2019-01-23 21:21 ` Tom Rini
  2019-01-24 13:19 ` Felix Brack
  0 siblings, 2 replies; 13+ messages in thread
From: Adam Ford @ 2019-01-23 21:13 UTC (permalink / raw)
  To: u-boot

By removing EXT support from SPL, it makes room for the extra
overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
enabled, extra options need to be added to the device tree to
tell it which portions of the tree are needed early in boot time

Unfortunately, with these options as-is, the system doesn't boot
nor does it display anything on the UART.  I don't have a debugger
readily available, but I have seen others with AM33x boards which
are similar to OMAP3 boards. This is posted as an RFC just in case
anyone has any suggestions on what  might be missing.

Signed-off-by: Adam Ford <aford173@gmail.com>

diff --git a/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi b/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
index 6445048fe0..e53c7065cb 100644
--- a/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
+++ b/arch/arm/dts/logicpd-som-lv-37xx-devkit-u-boot.dtsi
@@ -8,6 +8,18 @@
 	chosen {
 		stdout-path = &uart1;
 	};
+
+	ocp {
+		u-boot,dm-pre-reloc;
+	};
+};
+
+&l4_core {
+	u-boot,dm-pre-reloc;
+};
+
+&scm {
+	u-boot,dm-pre-reloc;
 };
 
 &i2c1 {
@@ -19,9 +31,14 @@
 };
 
 &mmc1 {
+	u-boot,dm-pre-reloc;
 	cd-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>;		/* gpio_110 */
 };
 
+&mmc1_pins {
+	u-boot,dm-pre-reloc;
+};
+
 &mmc2 {
       status = "disabled";
 };
@@ -30,3 +47,23 @@
       status = "disabled";
 };
 
+&omap3_pmx_wkup {
+	u-boot,dm-pre-reloc;
+};
+
+&omap3_pmx_core {
+	u-boot,dm-pre-reloc;
+};
+
+&omap3_pmx_core2 {
+	u-boot,dm-pre-reloc;
+};
+
+&uart1 {
+	u-boot,dm-pre-reloc;
+};
+
+&uart1_pins {
+	u-boot,dm-pre-reloc;
+};
+
diff --git a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi b/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
index 4990ed90dc..fcb35834e2 100644
--- a/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
+++ b/arch/arm/dts/logicpd-som-lv-baseboard.dtsi
@@ -222,6 +222,13 @@
 			OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT_PULLDOWN | PIN_OFF_OUTPUT_LOW | MUX_MODE0)   /* dss_data15.dss_data15 */
 		>;
 	};
+	uart1_pins: pinmux_uart1_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | MUX_MODE0)                /* uart1_rx.uart1_rx */
+			OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE0)               /* uart1_tx.uart1_tx */
+		>;
+	};
+
 };
 
 &omap3_pmx_wkup {
@@ -240,6 +247,8 @@
 
 
 &uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>;
 	interrupts-extended = <&intc 72 &omap3_pmx_core OMAP3_UART1_RX>;
 };
 
diff --git a/board/logicpd/omap3som/omap3logic.c b/board/logicpd/omap3som/omap3logic.c
index 144e6f68a4..ee77ce077c 100644
--- a/board/logicpd/omap3som/omap3logic.c
+++ b/board/logicpd/omap3som/omap3logic.c
@@ -56,36 +56,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define LOGIC_MT28_OMAP35_ASYNC_GPMC_CONFIG6	0x09030000
 #define LOGIC_MT28_OMAP35_ASYNC_GPMC_CONFIG7	0x00000C50
 
-/* This is only needed until SPL gets OF support */
-#ifdef CONFIG_SPL_BUILD
-static const struct ns16550_platdata omap3logic_serial = {
-	.base = OMAP34XX_UART1,
-	.reg_shift = 2,
-	.clock = V_NS16550_CLK,
-	.fcr = UART_FCR_DEFVAL,
-};
-
-U_BOOT_DEVICE(omap3logic_uart) = {
-	"omap_serial",
-	&omap3logic_serial
-};
-
-static const struct omap_hsmmc_plat omap3_logic_mmc0_platdata = {
-	.base_addr = (struct hsmmc *)OMAP_HSMMC1_BASE,
-	.cfg.host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS | MMC_MODE_4BIT,
-	.cfg.f_min = 400000,
-	.cfg.f_max = 52000000,
-	.cfg.voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195,
-	.cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
-};
-
-U_BOOT_DEVICE(omap3_logic_mmc0) = {
-	.name = "omap_hsmmc",
-	.platdata = &omap3_logic_mmc0_platdata,
-};
-
-#endif
-
 #ifdef CONFIG_SPL_OS_BOOT
 int spl_start_uboot(void)
 {
diff --git a/configs/omap3_logic_somlv_defconfig b/configs/omap3_logic_somlv_defconfig
index 6602af6abe..31a3909098 100644
--- a/configs/omap3_logic_somlv_defconfig
+++ b/configs/omap3_logic_somlv_defconfig
@@ -14,6 +14,7 @@ CONFIG_ANDROID_BOOT_IMAGE=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+# CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="OMAP Logic # "
@@ -29,6 +30,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0,nor0=physmap-flash.0"
 CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(MLO),1792k(u-boot),128k(spl-os),128k(u-boot-env),6m(kernel),-(fs);physmap-flash.0:-(nor)"
 CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="logicpd-som-lv-37xx-devkit"
 # CONFIG_ENV_IS_IN_FAT is not set
 CONFIG_ENV_IS_IN_NAND=y
@@ -52,6 +54,7 @@ CONFIG_SMC911X=y
 CONFIG_SMC911X_BASE=0x08000000
 CONFIG_SMC911X_32_BIT=y
 CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_DM_PMIC=y
 # CONFIG_SPL_PMIC_CHILDREN is not set
-- 
2.17.1

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-23 21:13 [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL Adam Ford
@ 2019-01-23 21:21 ` Tom Rini
  2019-01-24 15:56   ` Adam Ford
  2019-01-24 13:19 ` Felix Brack
  1 sibling, 1 reply; 13+ messages in thread
From: Tom Rini @ 2019-01-23 21:21 UTC (permalink / raw)
  To: u-boot

On Wed, Jan 23, 2019 at 03:13:52PM -0600, Adam Ford wrote:

> By removing EXT support from SPL, it makes room for the extra
> overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> enabled, extra options need to be added to the device tree to
> tell it which portions of the tree are needed early in boot time
> 
> Unfortunately, with these options as-is, the system doesn't boot
> nor does it display anything on the UART.  I don't have a debugger
> readily available, but I have seen others with AM33x boards which
> are similar to OMAP3 boards. This is posted as an RFC just in case
> anyone has any suggestions on what  might be missing.
> 
> Signed-off-by: Adam Ford <aford173@gmail.com>
> 

Hmm.  Here's what I have for omap3_beagle that has SPL booting, but
cannot boot its own full U-Boot.  Mixing new SPL and old U-Boot does
work.  There's probably something silly I didn't get right that's
causing that problem:

diff --git a/arch/arm/dts/omap3-beagle-u-boot.dtsi b/arch/arm/dts/omap3-beagle-u-boot.dtsi
index 41beaf0900c3..2c03701c896a 100644
--- a/arch/arm/dts/omap3-beagle-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-u-boot.dtsi
@@ -5,20 +5,10 @@
  * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
  */
 
+#include "omap3-u-boot.dtsi"
+
 / {
 	chosen {
 		stdout-path = &uart3;
 	};
 };
-
-&uart1 {
-	reg-shift = <2>;
-};
-
-&uart2 {
-	reg-shift = <2>;
-};
-
-&uart3 {
-	reg-shift = <2>;
-};
diff --git a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
index 41beaf0900c3..2c03701c896a 100644
--- a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
@@ -5,20 +5,10 @@
  * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
  */
 
+#include "omap3-u-boot.dtsi"
+
 / {
 	chosen {
 		stdout-path = &uart3;
 	};
 };
-
-&uart1 {
-	reg-shift = <2>;
-};
-
-&uart2 {
-	reg-shift = <2>;
-};
-
-&uart3 {
-	reg-shift = <2>;
-};
diff --git a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
index 41beaf0900c3..2c03701c896a 100644
--- a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
+++ b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
@@ -5,20 +5,10 @@
  * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
  */
 
+#include "omap3-u-boot.dtsi"
+
 / {
 	chosen {
 		stdout-path = &uart3;
 	};
 };
-
-&uart1 {
-	reg-shift = <2>;
-};
-
-&uart2 {
-	reg-shift = <2>;
-};
-
-&uart3 {
-	reg-shift = <2>;
-};
diff --git a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
index de411316d83a..b9e433f873b7 100644
--- a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
+++ b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
@@ -5,20 +5,10 @@
  * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
  */
 
+#include "omap3-u-boot.dtsi"
+
 / {
 	chosen {
 		stdout-path = &uart1;
 	};
 };
-
-&uart1 {
-	reg-shift = <2>;
-};
-
-&uart2 {
-	reg-shift = <2>;
-};
-
-&uart3 {
-	reg-shift = <2>;
-};
diff --git a/arch/arm/dts/omap3-evm-u-boot.dtsi b/arch/arm/dts/omap3-evm-u-boot.dtsi
index de411316d83a..b9e433f873b7 100644
--- a/arch/arm/dts/omap3-evm-u-boot.dtsi
+++ b/arch/arm/dts/omap3-evm-u-boot.dtsi
@@ -5,20 +5,10 @@
  * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
  */
 
+#include "omap3-u-boot.dtsi"
+
 / {
 	chosen {
 		stdout-path = &uart1;
 	};
 };
-
-&uart1 {
-	reg-shift = <2>;
-};
-
-&uart2 {
-	reg-shift = <2>;
-};
-
-&uart3 {
-	reg-shift = <2>;
-};
diff --git a/arch/arm/dts/omap3-u-boot.dtsi b/arch/arm/dts/omap3-u-boot.dtsi
new file mode 100644
index 000000000000..32bea6b6d9b8
--- /dev/null
+++ b/arch/arm/dts/omap3-u-boot.dtsi
@@ -0,0 +1,81 @@
+/*
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on "omap5-u-boot.dtsi"
+ */
+
+/{
+	ocp at 68000000 {
+		u-boot,dm-spl;
+
+		bandgap at 48002524 {
+			u-boot,dm-spl;
+		};
+	};
+};
+
+&uart1 {
+	u-boot,dm-spl;
+	reg-shift = <2>;
+};
+
+&uart2 {
+	u-boot,dm-spl;
+	reg-shift = <2>;
+};
+
+&uart3 {
+	u-boot,dm-spl;
+	reg-shift = <2>;
+};
+
+&mmc1 {
+	u-boot,dm-spl;
+};
+
+&mmc2 {
+	u-boot,dm-spl;
+};
+
+&l4_core {
+	u-boot,dm-spl;
+};
+
+&scm {
+	u-boot,dm-spl;
+};
+
+&scm_conf {
+	u-boot,dm-spl;
+};
+
+&gpio1 {
+	u-boot,dm-spl;
+};
+
+&gpio2 {
+	u-boot,dm-spl;
+};
+
+&gpio3 {
+	u-boot,dm-spl;
+};
+
+&gpio4 {
+	u-boot,dm-spl;
+};
+
+&gpio5 {
+	u-boot,dm-spl;
+};
+
+&gpio6 {
+	u-boot,dm-spl;
+};
+
+&i2c1 {
+	u-boot,dm-spl;
+};
diff --git a/configs/omap3_beagle_defconfig b/configs/omap3_beagle_defconfig
index 9581dd953730..54f999e1b0c7 100644
--- a/configs/omap3_beagle_defconfig
+++ b/configs/omap3_beagle_defconfig
@@ -1,4 +1,6 @@
 CONFIG_ARM=y
+# CONFIG_SPL_USE_ARCH_MEMCPY is not set
+# CONFIG_SPL_USE_ARCH_MEMSET is not set
 CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_SYS_TEXT_BASE=0x80100000
 CONFIG_TARGET_OMAP3_BEAGLE=y
@@ -7,11 +9,12 @@ CONFIG_DISTRO_DEFAULTS=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
-CONFIG_DEFAULT_FDT_FILE="omap3-beagle.dtb"
+CONFIG_DEFAULT_FDT_FILE="omap3-beagle-xm-ab.dtb"
 CONFIG_VERSION_VARIABLE=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_SPL_MTD_SUPPORT=y
-CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="BeagleBoard # "
 CONFIG_CMD_SPL=y
 CONFIG_CMD_SPL_NAND_OFS=0x280000
@@ -33,10 +36,18 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
 CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(spl),1920k(u-boot),128k(u-boot-env),128k(dtb),6m(kernel),-(rootfs)"
 CONFIG_CMD_UBI=y
 # CONFIG_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SPL_PARTITION_UUIDS=y
 CONFIG_OF_CONTROL=y
-CONFIG_DEFAULT_DEVICE_TREE="omap3-beagle"
-CONFIG_ENV_IS_IN_NAND=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="omap3-beagle-xm-ab"
+CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
+CONFIG_ENV_IS_IN_FAT=y
+CONFIG_ENV_FAT_INTERFACE="mmc"
+CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
 CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x82000000
 CONFIG_LED_STATUS=y
@@ -52,6 +63,7 @@ CONFIG_LED_STATUS_GREEN_ENABLE=y
 CONFIG_LED_STATUS_GREEN=2
 CONFIG_LED_STATUS_CMD=y
 CONFIG_TWL4030_LED=y
+CONFIG_DM_MMC=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
@@ -76,6 +88,4 @@ CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_VIDEO_OMAP3=y
-CONFIG_FAT_WRITE=y
 CONFIG_BCH=y
-CONFIG_SPL_OF_LIBFDT=y

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

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-23 21:13 [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL Adam Ford
  2019-01-23 21:21 ` Tom Rini
@ 2019-01-24 13:19 ` Felix Brack
  2019-01-25 21:39   ` Adam Ford
  1 sibling, 1 reply; 13+ messages in thread
From: Felix Brack @ 2019-01-24 13:19 UTC (permalink / raw)
  To: u-boot

Hello Adam,

On 23.01.2019 22:13, Adam Ford wrote:
> By removing EXT support from SPL, it makes room for the extra
> overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> enabled, extra options need to be added to the device tree to
> tell it which portions of the tree are needed early in boot time
> 
> Unfortunately, with these options as-is, the system doesn't boot
> nor does it display anything on the UART.  I don't have a debugger
> readily available, but I have seen others with AM33x boards which
> are similar to OMAP3 boards. This is posted as an RFC just in case
> anyone has any suggestions on what  might be missing.
>
On an AM335x board I had problems when moving from embedded to separate
DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
If this works you could go back to CONFIG_OF_SEPARATE and probably give
CONFIG_SPL_SEPARATE_BSS a try.
Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
help me quite a lot.

regards Felix

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-23 21:21 ` Tom Rini
@ 2019-01-24 15:56   ` Adam Ford
  0 siblings, 0 replies; 13+ messages in thread
From: Adam Ford @ 2019-01-24 15:56 UTC (permalink / raw)
  To: u-boot

On Wed, Jan 23, 2019 at 3:21 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Jan 23, 2019 at 03:13:52PM -0600, Adam Ford wrote:
>
> > By removing EXT support from SPL, it makes room for the extra
> > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > enabled, extra options need to be added to the device tree to
> > tell it which portions of the tree are needed early in boot time
> >
> > Unfortunately, with these options as-is, the system doesn't boot
> > nor does it display anything on the UART.  I don't have a debugger
> > readily available, but I have seen others with AM33x boards which
> > are similar to OMAP3 boards. This is posted as an RFC just in case
> > anyone has any suggestions on what  might be missing.
> >
> > Signed-off-by: Adam Ford <aford173@gmail.com>
> >
>
> Hmm.  Here's what I have for omap3_beagle that has SPL booting, but
> cannot boot its own full U-Boot.  Mixing new SPL and old U-Boot does
> work.  There's probably something silly I didn't get right that's
> causing that problem:

Patchwork isn't letting me download the patch.  Could you e-mail your
patch directly?  I'd like to run some tests.

Thanks

adam
>
> diff --git a/arch/arm/dts/omap3-beagle-u-boot.dtsi b/arch/arm/dts/omap3-beagle-u-boot.dtsi
> index 41beaf0900c3..2c03701c896a 100644
> --- a/arch/arm/dts/omap3-beagle-u-boot.dtsi
> +++ b/arch/arm/dts/omap3-beagle-u-boot.dtsi
> @@ -5,20 +5,10 @@
>   * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
>   */
>
> +#include "omap3-u-boot.dtsi"
> +
>  / {
>         chosen {
>                 stdout-path = &uart3;
>         };
>  };
> -
> -&uart1 {
> -       reg-shift = <2>;
> -};
> -
> -&uart2 {
> -       reg-shift = <2>;
> -};
> -
> -&uart3 {
> -       reg-shift = <2>;
> -};
> diff --git a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
> index 41beaf0900c3..2c03701c896a 100644
> --- a/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
> +++ b/arch/arm/dts/omap3-beagle-xm-ab-u-boot.dtsi
> @@ -5,20 +5,10 @@
>   * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
>   */
>
> +#include "omap3-u-boot.dtsi"
> +
>  / {
>         chosen {
>                 stdout-path = &uart3;
>         };
>  };
> -
> -&uart1 {
> -       reg-shift = <2>;
> -};
> -
> -&uart2 {
> -       reg-shift = <2>;
> -};
> -
> -&uart3 {
> -       reg-shift = <2>;
> -};
> diff --git a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
> index 41beaf0900c3..2c03701c896a 100644
> --- a/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
> +++ b/arch/arm/dts/omap3-beagle-xm-u-boot.dtsi
> @@ -5,20 +5,10 @@
>   * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
>   */
>
> +#include "omap3-u-boot.dtsi"
> +
>  / {
>         chosen {
>                 stdout-path = &uart3;
>         };
>  };
> -
> -&uart1 {
> -       reg-shift = <2>;
> -};
> -
> -&uart2 {
> -       reg-shift = <2>;
> -};
> -
> -&uart3 {
> -       reg-shift = <2>;
> -};
> diff --git a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
> index de411316d83a..b9e433f873b7 100644
> --- a/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
> +++ b/arch/arm/dts/omap3-evm-37xx-u-boot.dtsi
> @@ -5,20 +5,10 @@
>   * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
>   */
>
> +#include "omap3-u-boot.dtsi"
> +
>  / {
>         chosen {
>                 stdout-path = &uart1;
>         };
>  };
> -
> -&uart1 {
> -       reg-shift = <2>;
> -};
> -
> -&uart2 {
> -       reg-shift = <2>;
> -};
> -
> -&uart3 {
> -       reg-shift = <2>;
> -};
> diff --git a/arch/arm/dts/omap3-evm-u-boot.dtsi b/arch/arm/dts/omap3-evm-u-boot.dtsi
> index de411316d83a..b9e433f873b7 100644
> --- a/arch/arm/dts/omap3-evm-u-boot.dtsi
> +++ b/arch/arm/dts/omap3-evm-u-boot.dtsi
> @@ -5,20 +5,10 @@
>   * (C) Copyright 2017 Derald D. Woods <woods.technical@gmail.com>
>   */
>
> +#include "omap3-u-boot.dtsi"
> +
>  / {
>         chosen {
>                 stdout-path = &uart1;
>         };
>  };
> -
> -&uart1 {
> -       reg-shift = <2>;
> -};
> -
> -&uart2 {
> -       reg-shift = <2>;
> -};
> -
> -&uart3 {
> -       reg-shift = <2>;
> -};
> diff --git a/arch/arm/dts/omap3-u-boot.dtsi b/arch/arm/dts/omap3-u-boot.dtsi
> new file mode 100644
> index 000000000000..32bea6b6d9b8
> --- /dev/null
> +++ b/arch/arm/dts/omap3-u-boot.dtsi
> @@ -0,0 +1,81 @@
> +/*
> + * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + * Based on "omap5-u-boot.dtsi"
> + */
> +
> +/{
> +       ocp at 68000000 {
> +               u-boot,dm-spl;
> +
> +               bandgap at 48002524 {
> +                       u-boot,dm-spl;
> +               };
> +       };
> +};
> +
> +&uart1 {
> +       u-boot,dm-spl;
> +       reg-shift = <2>;
> +};
> +
> +&uart2 {
> +       u-boot,dm-spl;
> +       reg-shift = <2>;
> +};
> +
> +&uart3 {
> +       u-boot,dm-spl;
> +       reg-shift = <2>;
> +};
> +
> +&mmc1 {
> +       u-boot,dm-spl;
> +};
> +
> +&mmc2 {
> +       u-boot,dm-spl;
> +};
> +
> +&l4_core {
> +       u-boot,dm-spl;
> +};
> +
> +&scm {
> +       u-boot,dm-spl;
> +};
> +
> +&scm_conf {
> +       u-boot,dm-spl;
> +};
> +
> +&gpio1 {
> +       u-boot,dm-spl;
> +};
> +
> +&gpio2 {
> +       u-boot,dm-spl;
> +};
> +
> +&gpio3 {
> +       u-boot,dm-spl;
> +};
> +
> +&gpio4 {
> +       u-boot,dm-spl;
> +};
> +
> +&gpio5 {
> +       u-boot,dm-spl;
> +};
> +
> +&gpio6 {
> +       u-boot,dm-spl;
> +};
> +
> +&i2c1 {
> +       u-boot,dm-spl;
> +};
> diff --git a/configs/omap3_beagle_defconfig b/configs/omap3_beagle_defconfig
> index 9581dd953730..54f999e1b0c7 100644
> --- a/configs/omap3_beagle_defconfig
> +++ b/configs/omap3_beagle_defconfig
> @@ -1,4 +1,6 @@
>  CONFIG_ARM=y
> +# CONFIG_SPL_USE_ARCH_MEMCPY is not set
> +# CONFIG_SPL_USE_ARCH_MEMSET is not set
>  CONFIG_ARCH_OMAP2PLUS=y
>  CONFIG_SYS_TEXT_BASE=0x80100000
>  CONFIG_TARGET_OMAP3_BEAGLE=y
> @@ -7,11 +9,12 @@ CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_NR_DRAM_BANKS=2
>  CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd"
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> -CONFIG_DEFAULT_FDT_FILE="omap3-beagle.dtb"
> +CONFIG_DEFAULT_FDT_FILE="omap3-beagle-xm-ab.dtb"
>  CONFIG_VERSION_VARIABLE=y
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> +CONFIG_SPL_SEPARATE_BSS=y
>  # CONFIG_SPL_EXT_SUPPORT is not set
>  CONFIG_SPL_MTD_SUPPORT=y
> -CONFIG_SPL_OS_BOOT=y
>  CONFIG_SYS_PROMPT="BeagleBoard # "
>  CONFIG_CMD_SPL=y
>  CONFIG_CMD_SPL_NAND_OFS=0x280000
> @@ -33,10 +36,18 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
>  CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(spl),1920k(u-boot),128k(u-boot-env),128k(dtb),6m(kernel),-(rootfs)"
>  CONFIG_CMD_UBI=y
>  # CONFIG_ISO_PARTITION is not set
> +# CONFIG_SPL_EFI_PARTITION is not set
> +CONFIG_SPL_PARTITION_UUIDS=y
>  CONFIG_OF_CONTROL=y
> -CONFIG_DEFAULT_DEVICE_TREE="omap3-beagle"
> -CONFIG_ENV_IS_IN_NAND=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="omap3-beagle-xm-ab"
> +CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
> +CONFIG_ENV_IS_IN_FAT=y
> +CONFIG_ENV_FAT_INTERFACE="mmc"
> +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
>  CONFIG_SPL_DM=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_SPL_OF_TRANSLATE=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
>  CONFIG_FASTBOOT_BUF_ADDR=0x82000000
>  CONFIG_LED_STATUS=y
> @@ -52,6 +63,7 @@ CONFIG_LED_STATUS_GREEN_ENABLE=y
>  CONFIG_LED_STATUS_GREEN=2
>  CONFIG_LED_STATUS_CMD=y
>  CONFIG_TWL4030_LED=y
> +CONFIG_DM_MMC=y
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_NAND=y
>  CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
> @@ -76,6 +88,4 @@ CONFIG_USB_ETHER_ASIX=y
>  CONFIG_USB_ETHER_MCS7830=y
>  CONFIG_USB_ETHER_SMSC95XX=y
>  CONFIG_VIDEO_OMAP3=y
> -CONFIG_FAT_WRITE=y
>  CONFIG_BCH=y
> -CONFIG_SPL_OF_LIBFDT=y
>
> --
> Tom

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-24 13:19 ` Felix Brack
@ 2019-01-25 21:39   ` Adam Ford
  2019-01-28 15:08     ` Adam Ford
  0 siblings, 1 reply; 13+ messages in thread
From: Adam Ford @ 2019-01-25 21:39 UTC (permalink / raw)
  To: u-boot

On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
>
> Hello Adam,
>
> On 23.01.2019 22:13, Adam Ford wrote:
> > By removing EXT support from SPL, it makes room for the extra
> > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > enabled, extra options need to be added to the device tree to
> > tell it which portions of the tree are needed early in boot time
> >
> > Unfortunately, with these options as-is, the system doesn't boot
> > nor does it display anything on the UART.  I don't have a debugger
> > readily available, but I have seen others with AM33x boards which
> > are similar to OMAP3 boards. This is posted as an RFC just in case
> > anyone has any suggestions on what  might be missing.
> >
> On an AM335x board I had problems when moving from embedded to separate
> DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> If this works you could go back to CONFIG_OF_SEPARATE and probably give
> CONFIG_SPL_SEPARATE_BSS a try.
> Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> help me quite a lot.

I had to turn off DM_SERIAL temporarily to get some debugging going.
I 'think' there is something wrong with fetching data from the device
tree.

I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.

U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
Trying to boot from MMC1
uclass_find_device_by_seq: 0 0
   - not found
uclass_find_device_by_seq: 1 0
   - not found
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I can see the mmc0 device is appearing in my SPL dtb file.

I am not sure what these values are support to be, but I was able to
do a dump of my spl device tree:

 dtc -I dtb -O dts spl/u-boot-spl.dtb


/dts-v1/;

/ {
compatible = "ti,am3517-evm\0ti,am3517\0ti,omap3";
#address-cells = < 0x01 >;
#size-cells = < 0x01 >;
model = "TI AM3517 EVM (AM3517/05 TMDSEVM3517)";

chosen {
stdout-path = "/ocp at 68000000/serial at 49020000";
};

aliases {
i2c0 = "/ocp at 68000000/i2c at 48070000";
serial0 = "/ocp at 68000000/serial at 4806a000";
serial1 = "/ocp at 68000000/serial at 4806c000";
serial2 = "/ocp at 68000000/serial at 49020000";
};

ocp at 68000000 {
compatible = "ti,omap3-l3-smx\0simple-bus";
reg = < 0x68000000 0x10000 >;
interrupts = < 0x09 0x0a >;
#address-cells = < 0x01 >;
#size-cells = < 0x01 >;
ranges;
ti,hwmods = "l3_main";
u-boot,dm-spl;

l4 at 48000000 {
compatible = "ti,omap3-l4-core\0simple-bus";
#address-cells = < 0x01 >;
#size-cells = < 0x01 >;
ranges = < 0x00 0x48000000 0x1000000 >;
u-boot,dm-spl;

scm at 2000 {
compatible = "ti,omap3-scm\0simple-bus";
reg = < 0x2000 0x2000 >;
#address-cells = < 0x01 >;
#size-cells = < 0x01 >;
ranges = < 0x00 0x2000 0x2000 >;
u-boot,dm-spl;

scm_conf at 270 {
compatible = "syscon\0simple-bus";
reg = < 0x270 0x330 >;
#address-cells = < 0x01 >;
#size-cells = < 0x01 >;
ranges = < 0x00 0x270 0x330 >;
u-boot,dm-spl;
phandle = < 0x05 >;
};
};
};

gpio at 48310000 {
compatible = "ti,omap3-gpio";
reg = < 0x48310000 0x200 >;
interrupts = < 0x1d >;
ti,hwmods = "gpio1";
ti,gpio-always-on;
gpio-controller;
#gpio-cells = < 0x02 >;
interrupt-controller;
#interrupt-cells = < 0x02 >;
u-boot,dm-spl;
phandle = < 0xec >;
};

gpio at 49050000 {
compatible = "ti,omap3-gpio";
reg = < 0x49050000 0x200 >;
interrupts = < 0x1e >;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = < 0x02 >;
interrupt-controller;
#interrupt-cells = < 0x02 >;
u-boot,dm-spl;
phandle = < 0xd0 >;
};

gpio at 49052000 {
compatible = "ti,omap3-gpio";
reg = < 0x49052000 0x200 >;
interrupts = < 0x1f >;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = < 0x02 >;
interrupt-controller;
#interrupt-cells = < 0x02 >;
u-boot,dm-spl;
phandle = < 0xd4 >;
};

gpio at 49054000 {
compatible = "ti,omap3-gpio";
reg = < 0x49054000 0x200 >;
interrupts = < 0x20 >;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = < 0x02 >;
interrupt-controller;
#interrupt-cells = < 0x02 >;
u-boot,dm-spl;
phandle = < 0xd8 >;
};

gpio at 49056000 {
compatible = "ti,omap3-gpio";
reg = < 0x49056000 0x200 >;
interrupts = < 0x21 >;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = < 0x02 >;
interrupt-controller;
#interrupt-cells = < 0x02 >;
u-boot,dm-spl;
phandle = < 0xe9 >;
};

gpio at 49058000 {
compatible = "ti,omap3-gpio";
reg = < 0x49058000 0x200 >;
interrupts = < 0x22 >;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = < 0x02 >;
interrupt-controller;
#interrupt-cells = < 0x02 >;
u-boot,dm-spl;
phandle = < 0xdb >;
};

serial at 4806a000 {
compatible = "ti,omap3-uart";
reg = < 0x4806a000 0x2000 >;
interrupts-extended = < 0x01 0x48 >;
dmas = < 0x17 0x31 0x17 0x32 >;
dma-names = "tx\0rx";
ti,hwmods = "uart1";
clock-frequency = < 0x2dc6c00 >;
u-boot,dm-spl;
reg-shift = < 0x02 >;
};

serial at 4806c000 {
compatible = "ti,omap3-uart";
reg = < 0x4806c000 0x400 >;
interrupts-extended = < 0x01 0x49 >;
dmas = < 0x17 0x33 0x17 0x34 >;
dma-names = "tx\0rx";
ti,hwmods = "uart2";
clock-frequency = < 0x2dc6c00 >;
pinctrl-names = "default";
pinctrl-0 = < 0xcf >;
u-boot,dm-spl;
reg-shift = < 0x02 >;
};

serial at 49020000 {
compatible = "ti,omap3-uart";
reg = < 0x49020000 0x400 >;
interrupts-extended = < 0x01 0x4a >;
dmas = < 0x17 0x35 0x17 0x36 >;
dma-names = "tx\0rx";
ti,hwmods = "uart3";
clock-frequency = < 0x2dc6c00 >;
u-boot,dm-spl;
reg-shift = < 0x02 >;
};

i2c at 48070000 {
compatible = "ti,omap3-i2c";
reg = < 0x48070000 0x80 >;
interrupts = < 0x38 >;
dmas = < 0x17 0x1b 0x17 0x1c >;
dma-names = "tx\0rx";
#address-cells = < 0x01 >;
#size-cells = < 0x00 >;
ti,hwmods = "i2c1";
clock-frequency = < 0x61a80 >;
u-boot,dm-spl;
};

mmc at 4809c000 {
compatible = "ti,omap3-hsmmc";
reg = < 0x4809c000 0x200 >;
interrupts = < 0x53 >;
ti,hwmods = "mmc1";
ti,dual-volt;
dmas = < 0x17 0x3d 0x17 0x3e >;
dma-names = "tx\0rx";
pbias-supply = < 0xd5 >;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = < 0xd6 >;
vmmc-supply = < 0xd7 >;
bus-width = < 0x04 >;
wp-gpios = < 0xd8 0x1e 0x00 >;
cd-gpios = < 0xd8 0x1f 0x01 >;
u-boot,dm-spl;
};

mmc at 480b4000 {
compatible = "ti,omap3-hsmmc";
reg = < 0x480b4000 0x200 >;
interrupts = < 0x56 >;
ti,hwmods = "mmc2";
dmas = < 0x17 0x2f 0x17 0x30 >;
dma-names = "tx\0rx";
interrupts-extended = < 0x01 0x56 >;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = < 0xd9 >;
vmmc-supply = < 0xda >;
non-removable;
bus-width = < 0x04 >;
cap-power-off-card;
#address-cells = < 0x01 >;
#size-cells = < 0x00 >;
u-boot,dm-spl;
};

bandgap at 48002524 {
u-boot,dm-spl;
};
};
};


>
> regards Felix

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-25 21:39   ` Adam Ford
@ 2019-01-28 15:08     ` Adam Ford
  2019-01-28 15:14       ` Tom Rini
  0 siblings, 1 reply; 13+ messages in thread
From: Adam Ford @ 2019-01-28 15:08 UTC (permalink / raw)
  To: u-boot

On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173@gmail.com> wrote:
>
> On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
> >
> > Hello Adam,
> >
> > On 23.01.2019 22:13, Adam Ford wrote:
> > > By removing EXT support from SPL, it makes room for the extra
> > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > enabled, extra options need to be added to the device tree to
> > > tell it which portions of the tree are needed early in boot time
> > >
> > > Unfortunately, with these options as-is, the system doesn't boot
> > > nor does it display anything on the UART.  I don't have a debugger
> > > readily available, but I have seen others with AM33x boards which
> > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > anyone has any suggestions on what  might be missing.
> > >
> > On an AM335x board I had problems when moving from embedded to separate
> > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > CONFIG_SPL_SEPARATE_BSS a try.
> > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > help me quite a lot.
>
> I had to turn off DM_SERIAL temporarily to get some debugging going.
> I 'think' there is something wrong with fetching data from the device
> tree.
>
> I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
>
> U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> Trying to boot from MMC1
> uclass_find_device_by_seq: 0 0
>    - not found
> uclass_find_device_by_seq: 1 0
>    - not found
> spl: could not find mmc device 0. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> I can see the mmc0 device is appearing in my SPL dtb file.
>
> I am not sure what these values are support to be, but I was able to
> do a dump of my spl device tree:
>
>  dtc -I dtb -O dts spl/u-boot-spl.dtb

Looking at Tom's defconfig file changes for the beagle, I noticed he
disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
to get my device tree based SPL to initialize both serial and MMC.
With Falcon mode enabled, it immediately stops booting and/or showing
anything.  There seems to be some correlation, because disabling it
again make it work.

With DM_SERIAL off, I can see the dumps to the screen and with the
debugging enabled, I can see that it is not able to locate the MMC
device.  I am going to assume that if it cannot find the MMC device,
it probably cannot find the serial device which may explain why
disabling DM_SERIAL in SPL with Falcon mode on shows text.

Might someone have any suggestions as to how to get both SPL_OF_CONFIG
with Falcon working?  I'd really like to keep that enabled by default.

adam
>
>
> /dts-v1/;
>
> / {
> compatible = "ti,am3517-evm\0ti,am3517\0ti,omap3";
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> model = "TI AM3517 EVM (AM3517/05 TMDSEVM3517)";
>
> chosen {
> stdout-path = "/ocp at 68000000/serial at 49020000";
> };
>
> aliases {
> i2c0 = "/ocp at 68000000/i2c at 48070000";
> serial0 = "/ocp at 68000000/serial at 4806a000";
> serial1 = "/ocp at 68000000/serial at 4806c000";
> serial2 = "/ocp at 68000000/serial at 49020000";
> };
>
> ocp at 68000000 {
> compatible = "ti,omap3-l3-smx\0simple-bus";
> reg = < 0x68000000 0x10000 >;
> interrupts = < 0x09 0x0a >;
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> ranges;
> ti,hwmods = "l3_main";
> u-boot,dm-spl;
>
> l4 at 48000000 {
> compatible = "ti,omap3-l4-core\0simple-bus";
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> ranges = < 0x00 0x48000000 0x1000000 >;
> u-boot,dm-spl;
>
> scm at 2000 {
> compatible = "ti,omap3-scm\0simple-bus";
> reg = < 0x2000 0x2000 >;
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> ranges = < 0x00 0x2000 0x2000 >;
> u-boot,dm-spl;
>
> scm_conf at 270 {
> compatible = "syscon\0simple-bus";
> reg = < 0x270 0x330 >;
> #address-cells = < 0x01 >;
> #size-cells = < 0x01 >;
> ranges = < 0x00 0x270 0x330 >;
> u-boot,dm-spl;
> phandle = < 0x05 >;
> };
> };
> };
>
> gpio at 48310000 {
> compatible = "ti,omap3-gpio";
> reg = < 0x48310000 0x200 >;
> interrupts = < 0x1d >;
> ti,hwmods = "gpio1";
> ti,gpio-always-on;
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xec >;
> };
>
> gpio at 49050000 {
> compatible = "ti,omap3-gpio";
> reg = < 0x49050000 0x200 >;
> interrupts = < 0x1e >;
> ti,hwmods = "gpio2";
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xd0 >;
> };
>
> gpio at 49052000 {
> compatible = "ti,omap3-gpio";
> reg = < 0x49052000 0x200 >;
> interrupts = < 0x1f >;
> ti,hwmods = "gpio3";
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xd4 >;
> };
>
> gpio at 49054000 {
> compatible = "ti,omap3-gpio";
> reg = < 0x49054000 0x200 >;
> interrupts = < 0x20 >;
> ti,hwmods = "gpio4";
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xd8 >;
> };
>
> gpio at 49056000 {
> compatible = "ti,omap3-gpio";
> reg = < 0x49056000 0x200 >;
> interrupts = < 0x21 >;
> ti,hwmods = "gpio5";
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xe9 >;
> };
>
> gpio at 49058000 {
> compatible = "ti,omap3-gpio";
> reg = < 0x49058000 0x200 >;
> interrupts = < 0x22 >;
> ti,hwmods = "gpio6";
> gpio-controller;
> #gpio-cells = < 0x02 >;
> interrupt-controller;
> #interrupt-cells = < 0x02 >;
> u-boot,dm-spl;
> phandle = < 0xdb >;
> };
>
> serial at 4806a000 {
> compatible = "ti,omap3-uart";
> reg = < 0x4806a000 0x2000 >;
> interrupts-extended = < 0x01 0x48 >;
> dmas = < 0x17 0x31 0x17 0x32 >;
> dma-names = "tx\0rx";
> ti,hwmods = "uart1";
> clock-frequency = < 0x2dc6c00 >;
> u-boot,dm-spl;
> reg-shift = < 0x02 >;
> };
>
> serial at 4806c000 {
> compatible = "ti,omap3-uart";
> reg = < 0x4806c000 0x400 >;
> interrupts-extended = < 0x01 0x49 >;
> dmas = < 0x17 0x33 0x17 0x34 >;
> dma-names = "tx\0rx";
> ti,hwmods = "uart2";
> clock-frequency = < 0x2dc6c00 >;
> pinctrl-names = "default";
> pinctrl-0 = < 0xcf >;
> u-boot,dm-spl;
> reg-shift = < 0x02 >;
> };
>
> serial at 49020000 {
> compatible = "ti,omap3-uart";
> reg = < 0x49020000 0x400 >;
> interrupts-extended = < 0x01 0x4a >;
> dmas = < 0x17 0x35 0x17 0x36 >;
> dma-names = "tx\0rx";
> ti,hwmods = "uart3";
> clock-frequency = < 0x2dc6c00 >;
> u-boot,dm-spl;
> reg-shift = < 0x02 >;
> };
>
> i2c at 48070000 {
> compatible = "ti,omap3-i2c";
> reg = < 0x48070000 0x80 >;
> interrupts = < 0x38 >;
> dmas = < 0x17 0x1b 0x17 0x1c >;
> dma-names = "tx\0rx";
> #address-cells = < 0x01 >;
> #size-cells = < 0x00 >;
> ti,hwmods = "i2c1";
> clock-frequency = < 0x61a80 >;
> u-boot,dm-spl;
> };
>
> mmc at 4809c000 {
> compatible = "ti,omap3-hsmmc";
> reg = < 0x4809c000 0x200 >;
> interrupts = < 0x53 >;
> ti,hwmods = "mmc1";
> ti,dual-volt;
> dmas = < 0x17 0x3d 0x17 0x3e >;
> dma-names = "tx\0rx";
> pbias-supply = < 0xd5 >;
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = < 0xd6 >;
> vmmc-supply = < 0xd7 >;
> bus-width = < 0x04 >;
> wp-gpios = < 0xd8 0x1e 0x00 >;
> cd-gpios = < 0xd8 0x1f 0x01 >;
> u-boot,dm-spl;
> };
>
> mmc at 480b4000 {
> compatible = "ti,omap3-hsmmc";
> reg = < 0x480b4000 0x200 >;
> interrupts = < 0x56 >;
> ti,hwmods = "mmc2";
> dmas = < 0x17 0x2f 0x17 0x30 >;
> dma-names = "tx\0rx";
> interrupts-extended = < 0x01 0x56 >;
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = < 0xd9 >;
> vmmc-supply = < 0xda >;
> non-removable;
> bus-width = < 0x04 >;
> cap-power-off-card;
> #address-cells = < 0x01 >;
> #size-cells = < 0x00 >;
> u-boot,dm-spl;
> };
>
> bandgap at 48002524 {
> u-boot,dm-spl;
> };
> };
> };
>
>
> >
> > regards Felix

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-28 15:08     ` Adam Ford
@ 2019-01-28 15:14       ` Tom Rini
  2019-01-28 20:23         ` Adam Ford
  0 siblings, 1 reply; 13+ messages in thread
From: Tom Rini @ 2019-01-28 15:14 UTC (permalink / raw)
  To: u-boot

On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
> > >
> > > Hello Adam,
> > >
> > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > By removing EXT support from SPL, it makes room for the extra
> > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > enabled, extra options need to be added to the device tree to
> > > > tell it which portions of the tree are needed early in boot time
> > > >
> > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > nor does it display anything on the UART.  I don't have a debugger
> > > > readily available, but I have seen others with AM33x boards which
> > > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > > anyone has any suggestions on what  might be missing.
> > > >
> > > On an AM335x board I had problems when moving from embedded to separate
> > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > > CONFIG_SPL_SEPARATE_BSS a try.
> > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > > help me quite a lot.
> >
> > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > I 'think' there is something wrong with fetching data from the device
> > tree.
> >
> > I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
> >
> > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> > Trying to boot from MMC1
> > uclass_find_device_by_seq: 0 0
> >    - not found
> > uclass_find_device_by_seq: 1 0
> >    - not found
> > spl: could not find mmc device 0. error: -19
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
> >
> > I can see the mmc0 device is appearing in my SPL dtb file.
> >
> > I am not sure what these values are support to be, but I was able to
> > do a dump of my spl device tree:
> >
> >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> 
> Looking at Tom's defconfig file changes for the beagle, I noticed he
> disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> to get my device tree based SPL to initialize both serial and MMC.
> With Falcon mode enabled, it immediately stops booting and/or showing
> anything.  There seems to be some correlation, because disabling it
> again make it work.
> 
> With DM_SERIAL off, I can see the dumps to the screen and with the
> debugging enabled, I can see that it is not able to locate the MMC
> device.  I am going to assume that if it cannot find the MMC device,
> it probably cannot find the serial device which may explain why
> disabling DM_SERIAL in SPL with Falcon mode on shows text.
> 
> Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> with Falcon working?  I'd really like to keep that enabled by default.

Note that I disabled Falcon for the space savings to keep MLO small
enough, not that I noticed it failing to work.  Given that with my
patches what does work is loading an un-patched-for-DM-and-SPL u-boot
and doesn't work is booting the u-boot.img I just built if there's not
some overlap there.  Perhaps the addresses being used for
BSS/malloc/whatever are stomping on the image and that's wrecking
things?

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

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-28 15:14       ` Tom Rini
@ 2019-01-28 20:23         ` Adam Ford
  2019-01-28 20:33           ` Tom Rini
  0 siblings, 1 reply; 13+ messages in thread
From: Adam Ford @ 2019-01-28 20:23 UTC (permalink / raw)
  To: u-boot

On Mon, Jan 28, 2019 at 9:14 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
> > > >
> > > > Hello Adam,
> > > >
> > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > enabled, extra options need to be added to the device tree to
> > > > > tell it which portions of the tree are needed early in boot time
> > > > >
> > > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > > nor does it display anything on the UART.  I don't have a debugger
> > > > > readily available, but I have seen others with AM33x boards which
> > > > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > > > anyone has any suggestions on what  might be missing.
> > > > >
> > > > On an AM335x board I had problems when moving from embedded to separate
> > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > > > help me quite a lot.
> > >
> > > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > > I 'think' there is something wrong with fetching data from the device
> > > tree.
> > >
> > > I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
> > >
> > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> > > Trying to boot from MMC1
> > > uclass_find_device_by_seq: 0 0
> > >    - not found
> > > uclass_find_device_by_seq: 1 0
> > >    - not found
> > > spl: could not find mmc device 0. error: -19
> > > SPL: failed to boot from all boot devices
> > > ### ERROR ### Please RESET the board ###
> > >
> > > I can see the mmc0 device is appearing in my SPL dtb file.
> > >
> > > I am not sure what these values are support to be, but I was able to
> > > do a dump of my spl device tree:
> > >
> > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> >
> > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > to get my device tree based SPL to initialize both serial and MMC.
> > With Falcon mode enabled, it immediately stops booting and/or showing
> > anything.  There seems to be some correlation, because disabling it
> > again make it work.
> >
> > With DM_SERIAL off, I can see the dumps to the screen and with the
> > debugging enabled, I can see that it is not able to locate the MMC
> > device.  I am going to assume that if it cannot find the MMC device,
> > it probably cannot find the serial device which may explain why
> > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> >
> > Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> > with Falcon working?  I'd really like to keep that enabled by default.
>
> Note that I disabled Falcon for the space savings to keep MLO small
> enough, not that I noticed it failing to work.  Given that with my
> patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> and doesn't work is booting the u-boot.img I just built if there's not
> some overlap there.  Perhaps the addresses being used for
> BSS/malloc/whatever are stomping on the image and that's wrecking
> things?
>

Is there an easy way to debug memory utilization?  We're not quite
getting to the point of loading u-boot.img since it cannot find the
MMC driver.

Interestingly enough, when I rebased my quasi-working image with the
master, it died.  I can still build DM_SPL without SPL_OF_CONTROL but
now even with Falcon disabled, any attempts to build with
SPL_OF_CONTROL fail.
I even tried using OF_PLATDATA hoping it might reduce the memory footprint.

I'm going to go back to 2019.01 and run some tests, but any pointers
on how to debug memory allocation might be helpful.

adam
> --
> Tom

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-28 20:23         ` Adam Ford
@ 2019-01-28 20:33           ` Tom Rini
  2019-01-29 13:36             ` Adam Ford
  0 siblings, 1 reply; 13+ messages in thread
From: Tom Rini @ 2019-01-28 20:33 UTC (permalink / raw)
  To: u-boot

On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> On Mon, Jan 28, 2019 at 9:14 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
> > > > >
> > > > > Hello Adam,
> > > > >
> > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > enabled, extra options need to be added to the device tree to
> > > > > > tell it which portions of the tree are needed early in boot time
> > > > > >
> > > > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > > > nor does it display anything on the UART.  I don't have a debugger
> > > > > > readily available, but I have seen others with AM33x boards which
> > > > > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > > > > anyone has any suggestions on what  might be missing.
> > > > > >
> > > > > On an AM335x board I had problems when moving from embedded to separate
> > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > > > > help me quite a lot.
> > > >
> > > > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > > > I 'think' there is something wrong with fetching data from the device
> > > > tree.
> > > >
> > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
> > > >
> > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> > > > Trying to boot from MMC1
> > > > uclass_find_device_by_seq: 0 0
> > > >    - not found
> > > > uclass_find_device_by_seq: 1 0
> > > >    - not found
> > > > spl: could not find mmc device 0. error: -19
> > > > SPL: failed to boot from all boot devices
> > > > ### ERROR ### Please RESET the board ###
> > > >
> > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > >
> > > > I am not sure what these values are support to be, but I was able to
> > > > do a dump of my spl device tree:
> > > >
> > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > >
> > > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > > to get my device tree based SPL to initialize both serial and MMC.
> > > With Falcon mode enabled, it immediately stops booting and/or showing
> > > anything.  There seems to be some correlation, because disabling it
> > > again make it work.
> > >
> > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > debugging enabled, I can see that it is not able to locate the MMC
> > > device.  I am going to assume that if it cannot find the MMC device,
> > > it probably cannot find the serial device which may explain why
> > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > >
> > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> > > with Falcon working?  I'd really like to keep that enabled by default.
> >
> > Note that I disabled Falcon for the space savings to keep MLO small
> > enough, not that I noticed it failing to work.  Given that with my
> > patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> > and doesn't work is booting the u-boot.img I just built if there's not
> > some overlap there.  Perhaps the addresses being used for
> > BSS/malloc/whatever are stomping on the image and that's wrecking
> > things?
> >
> 
> Is there an easy way to debug memory utilization?  We're not quite
> getting to the point of loading u-boot.img since it cannot find the
> MMC driver.
> 
> Interestingly enough, when I rebased my quasi-working image with the
> master, it died.  I can still build DM_SPL without SPL_OF_CONTROL but
> now even with Falcon disabled, any attempts to build with
> SPL_OF_CONTROL fail.
> I even tried using OF_PLATDATA hoping it might reduce the memory footprint.
> 
> I'm going to go back to 2019.01 and run some tests, but any pointers
> on how to debug memory allocation might be helpful.

When I've had to do this before I've written them out, picked values
that must fit the hardware and rest of the situation and confirmed or
denied my hypothesis.

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

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-28 20:33           ` Tom Rini
@ 2019-01-29 13:36             ` Adam Ford
  2019-02-12  3:40               ` Adam Ford
  0 siblings, 1 reply; 13+ messages in thread
From: Adam Ford @ 2019-01-29 13:36 UTC (permalink / raw)
  To: u-boot

On Mon, Jan 28, 2019 at 2:33 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
> > > > > >
> > > > > > Hello Adam,
> > > > > >
> > > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > > enabled, extra options need to be added to the device tree to
> > > > > > > tell it which portions of the tree are needed early in boot time
> > > > > > >
> > > > > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > > > > nor does it display anything on the UART.  I don't have a debugger
> > > > > > > readily available, but I have seen others with AM33x boards which
> > > > > > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > > > > > anyone has any suggestions on what  might be missing.
> > > > > > >
> > > > > > On an AM335x board I had problems when moving from embedded to separate
> > > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > > > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > > > > > help me quite a lot.
> > > > >
> > > > > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > > > > I 'think' there is something wrong with fetching data from the device
> > > > > tree.
> > > > >
> > > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
> > > > >
> > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> > > > > Trying to boot from MMC1
> > > > > uclass_find_device_by_seq: 0 0
> > > > >    - not found
> > > > > uclass_find_device_by_seq: 1 0
> > > > >    - not found
> > > > > spl: could not find mmc device 0. error: -19
> > > > > SPL: failed to boot from all boot devices
> > > > > ### ERROR ### Please RESET the board ###
> > > > >
> > > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > > >
> > > > > I am not sure what these values are support to be, but I was able to
> > > > > do a dump of my spl device tree:
> > > > >
> > > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > > >
> > > > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > > > to get my device tree based SPL to initialize both serial and MMC.
> > > > With Falcon mode enabled, it immediately stops booting and/or showing
> > > > anything.  There seems to be some correlation, because disabling it
> > > > again make it work.
> > > >
> > > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > > debugging enabled, I can see that it is not able to locate the MMC
> > > > device.  I am going to assume that if it cannot find the MMC device,
> > > > it probably cannot find the serial device which may explain why
> > > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > > >
> > > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> > > > with Falcon working?  I'd really like to keep that enabled by default.
> > >
> > > Note that I disabled Falcon for the space savings to keep MLO small
> > > enough, not that I noticed it failing to work.  Given that with my
> > > patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> > > and doesn't work is booting the u-boot.img I just built if there's not
> > > some overlap there.  Perhaps the addresses being used for
> > > BSS/malloc/whatever are stomping on the image and that's wrecking
> > > things?
> > >
> >
> > Is there an easy way to debug memory utilization?  We're not quite
> > getting to the point of loading u-boot.img since it cannot find the
> > MMC driver.
> >
> > Interestingly enough, when I rebased my quasi-working image with the
> > master, it died.  I can still build DM_SPL without SPL_OF_CONTROL but
> > now even with Falcon disabled, any attempts to build with
> > SPL_OF_CONTROL fail.
> > I even tried using OF_PLATDATA hoping it might reduce the memory footprint.
> >
> > I'm going to go back to 2019.01 and run some tests, but any pointers
> > on how to debug memory allocation might be helpful.
>
> When I've had to do this before I've written them out, picked values
> that must fit the hardware and rest of the situation and confirmed or
> denied my hypothesis.

I've tried to make the memory maps for logic pd boards (including
AM3517-evm) use the TI defaults as much as I can.  Interestingly
enough, when I enable DM in SPL without SPL_OF_CONTROL breaks booting
the AM3517 even when I manually add the platform data, and it doesn't
have Falcon mode enabled, so I wonder if there is something off a bit
in the omap3 initialization and/or memory usage.

When I pulled in the latest from origin/master, the part that I had
working with SPL_OF_CONTROL on the omap3_logic board stopped working.

adam
>
> --
> Tom

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-01-29 13:36             ` Adam Ford
@ 2019-02-12  3:40               ` Adam Ford
  2019-02-12 17:05                 ` Tom Rini
  0 siblings, 1 reply; 13+ messages in thread
From: Adam Ford @ 2019-02-12  3:40 UTC (permalink / raw)
  To: u-boot

On Tue, Jan 29, 2019 at 7:36 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Mon, Jan 28, 2019 at 2:33 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> > > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
> > > > > > >
> > > > > > > Hello Adam,
> > > > > > >
> > > > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > > > enabled, extra options need to be added to the device tree to
> > > > > > > > tell it which portions of the tree are needed early in boot time
> > > > > > > >
> > > > > > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > > > > > nor does it display anything on the UART.  I don't have a debugger
> > > > > > > > readily available, but I have seen others with AM33x boards which
> > > > > > > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > > > > > > anyone has any suggestions on what  might be missing.
> > > > > > > >
> > > > > > > On an AM335x board I had problems when moving from embedded to separate
> > > > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > > > > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > > > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > > > > > > help me quite a lot.
> > > > > >
> > > > > > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > > > > > I 'think' there is something wrong with fetching data from the device
> > > > > > tree.
> > > > > >
> > > > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
> > > > > >
> > > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> > > > > > Trying to boot from MMC1
> > > > > > uclass_find_device_by_seq: 0 0
> > > > > >    - not found
> > > > > > uclass_find_device_by_seq: 1 0
> > > > > >    - not found
> > > > > > spl: could not find mmc device 0. error: -19
> > > > > > SPL: failed to boot from all boot devices
> > > > > > ### ERROR ### Please RESET the board ###
> > > > > >
> > > > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > > > >
> > > > > > I am not sure what these values are support to be, but I was able to
> > > > > > do a dump of my spl device tree:
> > > > > >
> > > > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > > > >
> > > > > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > > > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > > > > to get my device tree based SPL to initialize both serial and MMC.
> > > > > With Falcon mode enabled, it immediately stops booting and/or showing
> > > > > anything.  There seems to be some correlation, because disabling it
> > > > > again make it work.
> > > > >
> > > > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > > > debugging enabled, I can see that it is not able to locate the MMC
> > > > > device.  I am going to assume that if it cannot find the MMC device,
> > > > > it probably cannot find the serial device which may explain why
> > > > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > > > >
> > > > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> > > > > with Falcon working?  I'd really like to keep that enabled by default.
> > > >
> > > > Note that I disabled Falcon for the space savings to keep MLO small
> > > > enough, not that I noticed it failing to work.  Given that with my
> > > > patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> > > > and doesn't work is booting the u-boot.img I just built if there's not
> > > > some overlap there.  Perhaps the addresses being used for
> > > > BSS/malloc/whatever are stomping on the image and that's wrecking
> > > > things?
> > > >
> > >
> > > Is there an easy way to debug memory utilization?  We're not quite
> > > getting to the point of loading u-boot.img since it cannot find the
> > > MMC driver.
> > >
> > > Interestingly enough, when I rebased my quasi-working image with the
> > > master, it died.  I can still build DM_SPL without SPL_OF_CONTROL but
> > > now even with Falcon disabled, any attempts to build with
> > > SPL_OF_CONTROL fail.
> > > I even tried using OF_PLATDATA hoping it might reduce the memory footprint.
> > >
> > > I'm going to go back to 2019.01 and run some tests, but any pointers
> > > on how to debug memory allocation might be helpful.
> >
> > When I've had to do this before I've written them out, picked values
> > that must fit the hardware and rest of the situation and confirmed or
> > denied my hypothesis.
>
> I've tried to make the memory maps for logic pd boards (including
> AM3517-evm) use the TI defaults as much as I can.  Interestingly
> enough, when I enable DM in SPL without SPL_OF_CONTROL breaks booting
> the AM3517 even when I manually add the platform data, and it doesn't
> have Falcon mode enabled, so I wonder if there is something off a bit
> in the omap3 initialization and/or memory usage.
>
> When I pulled in the latest from origin/master, the part that I had
> working with SPL_OF_CONTROL on the omap3_logic board stopped working.

Tom,

Do you know if your beagle patch still works when based on the current
origin/master? Is so, would you be willing to push your
omap3-u-boot.dtsi file?  I was able to get some limited functionality
by disabling features with 2019.01, but when I use the same
configuration, origin/master fails.  I wonder if it's related to the
size thread regarding the SPL size when dtb is added.

I also submitted a question about omap3 memory mapping, and I was
curious to know if you had any feedback.  I am trying to remap the
omap3_logic board to squeeze as much space for SPL.

adam
>
> adam
> >
> > --
> > Tom

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-02-12  3:40               ` Adam Ford
@ 2019-02-12 17:05                 ` Tom Rini
  2019-02-12 17:19                   ` Tom Rini
  0 siblings, 1 reply; 13+ messages in thread
From: Tom Rini @ 2019-02-12 17:05 UTC (permalink / raw)
  To: u-boot

On Mon, Feb 11, 2019 at 09:40:17PM -0600, Adam Ford wrote:
> On Tue, Jan 29, 2019 at 7:36 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Mon, Jan 28, 2019 at 2:33 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> > > > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173@gmail.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
> > > > > > > >
> > > > > > > > Hello Adam,
> > > > > > > >
> > > > > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > > > > enabled, extra options need to be added to the device tree to
> > > > > > > > > tell it which portions of the tree are needed early in boot time
> > > > > > > > >
> > > > > > > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > > > > > > nor does it display anything on the UART.  I don't have a debugger
> > > > > > > > > readily available, but I have seen others with AM33x boards which
> > > > > > > > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > > > > > > > anyone has any suggestions on what  might be missing.
> > > > > > > > >
> > > > > > > > On an AM335x board I had problems when moving from embedded to separate
> > > > > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > > > > > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > > > > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > > > > > > > help me quite a lot.
> > > > > > >
> > > > > > > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > > > > > > I 'think' there is something wrong with fetching data from the device
> > > > > > > tree.
> > > > > > >
> > > > > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
> > > > > > >
> > > > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> > > > > > > Trying to boot from MMC1
> > > > > > > uclass_find_device_by_seq: 0 0
> > > > > > >    - not found
> > > > > > > uclass_find_device_by_seq: 1 0
> > > > > > >    - not found
> > > > > > > spl: could not find mmc device 0. error: -19
> > > > > > > SPL: failed to boot from all boot devices
> > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > >
> > > > > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > > > > >
> > > > > > > I am not sure what these values are support to be, but I was able to
> > > > > > > do a dump of my spl device tree:
> > > > > > >
> > > > > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > > > > >
> > > > > > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > > > > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > > > > > to get my device tree based SPL to initialize both serial and MMC.
> > > > > > With Falcon mode enabled, it immediately stops booting and/or showing
> > > > > > anything.  There seems to be some correlation, because disabling it
> > > > > > again make it work.
> > > > > >
> > > > > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > > > > debugging enabled, I can see that it is not able to locate the MMC
> > > > > > device.  I am going to assume that if it cannot find the MMC device,
> > > > > > it probably cannot find the serial device which may explain why
> > > > > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > > > > >
> > > > > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> > > > > > with Falcon working?  I'd really like to keep that enabled by default.
> > > > >
> > > > > Note that I disabled Falcon for the space savings to keep MLO small
> > > > > enough, not that I noticed it failing to work.  Given that with my
> > > > > patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> > > > > and doesn't work is booting the u-boot.img I just built if there's not
> > > > > some overlap there.  Perhaps the addresses being used for
> > > > > BSS/malloc/whatever are stomping on the image and that's wrecking
> > > > > things?
> > > > >
> > > >
> > > > Is there an easy way to debug memory utilization?  We're not quite
> > > > getting to the point of loading u-boot.img since it cannot find the
> > > > MMC driver.
> > > >
> > > > Interestingly enough, when I rebased my quasi-working image with the
> > > > master, it died.  I can still build DM_SPL without SPL_OF_CONTROL but
> > > > now even with Falcon disabled, any attempts to build with
> > > > SPL_OF_CONTROL fail.
> > > > I even tried using OF_PLATDATA hoping it might reduce the memory footprint.
> > > >
> > > > I'm going to go back to 2019.01 and run some tests, but any pointers
> > > > on how to debug memory allocation might be helpful.
> > >
> > > When I've had to do this before I've written them out, picked values
> > > that must fit the hardware and rest of the situation and confirmed or
> > > denied my hypothesis.
> >
> > I've tried to make the memory maps for logic pd boards (including
> > AM3517-evm) use the TI defaults as much as I can.  Interestingly
> > enough, when I enable DM in SPL without SPL_OF_CONTROL breaks booting
> > the AM3517 even when I manually add the platform data, and it doesn't
> > have Falcon mode enabled, so I wonder if there is something off a bit
> > in the omap3 initialization and/or memory usage.
> >
> > When I pulled in the latest from origin/master, the part that I had
> > working with SPL_OF_CONTROL on the omap3_logic board stopped working.
> 
> Tom,
> 
> Do you know if your beagle patch still works when based on the current
> origin/master? Is so, would you be willing to push your
> omap3-u-boot.dtsi file?  I was able to get some limited functionality
> by disabling features with 2019.01, but when I use the same
> configuration, origin/master fails.  I wonder if it's related to the
> size thread regarding the SPL size when dtb is added.

OK, I'm a dummy :)  Yes, the patches I posted work _and_ I should have
figured this out at the time, the problem I had was that I didn't do the
right thing to have "u-boot binary as .img" be the one that has the DTB
rather than not.  Just now I've confirmed that what I posted before on
f94fa0e94f36 boots to U-Boot itself.  So I'm going to do what I need to
do to make Beagleboard work with DM and in a non-RFC way.

> I also submitted a question about omap3 memory mapping, and I was
> curious to know if you had any feedback.  I am trying to remap the
> omap3_logic board to squeeze as much space for SPL.

I keep meaning to get back to that, sorry.

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

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

* [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
  2019-02-12 17:05                 ` Tom Rini
@ 2019-02-12 17:19                   ` Tom Rini
  0 siblings, 0 replies; 13+ messages in thread
From: Tom Rini @ 2019-02-12 17:19 UTC (permalink / raw)
  To: u-boot

On Tue, Feb 12, 2019 at 12:05:55PM -0500, Tom Rini wrote:
> On Mon, Feb 11, 2019 at 09:40:17PM -0600, Adam Ford wrote:
> > On Tue, Jan 29, 2019 at 7:36 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Mon, Jan 28, 2019 at 2:33 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> > > > > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > > > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb@ltec.ch> wrote:
> > > > > > > > >
> > > > > > > > > Hello Adam,
> > > > > > > > >
> > > > > > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > > > > > enabled, extra options need to be added to the device tree to
> > > > > > > > > > tell it which portions of the tree are needed early in boot time
> > > > > > > > > >
> > > > > > > > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > > > > > > > nor does it display anything on the UART.  I don't have a debugger
> > > > > > > > > > readily available, but I have seen others with AM33x boards which
> > > > > > > > > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > > > > > > > > anyone has any suggestions on what  might be missing.
> > > > > > > > > >
> > > > > > > > > On an AM335x board I had problems when moving from embedded to separate
> > > > > > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > > > > > > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > > > > > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > > > > > > > > help me quite a lot.
> > > > > > > >
> > > > > > > > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > > > > > > > I 'think' there is something wrong with fetching data from the device
> > > > > > > > tree.
> > > > > > > >
> > > > > > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
> > > > > > > >
> > > > > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> > > > > > > > Trying to boot from MMC1
> > > > > > > > uclass_find_device_by_seq: 0 0
> > > > > > > >    - not found
> > > > > > > > uclass_find_device_by_seq: 1 0
> > > > > > > >    - not found
> > > > > > > > spl: could not find mmc device 0. error: -19
> > > > > > > > SPL: failed to boot from all boot devices
> > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > >
> > > > > > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > > > > > >
> > > > > > > > I am not sure what these values are support to be, but I was able to
> > > > > > > > do a dump of my spl device tree:
> > > > > > > >
> > > > > > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > > > > > >
> > > > > > > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > > > > > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > > > > > > to get my device tree based SPL to initialize both serial and MMC.
> > > > > > > With Falcon mode enabled, it immediately stops booting and/or showing
> > > > > > > anything.  There seems to be some correlation, because disabling it
> > > > > > > again make it work.
> > > > > > >
> > > > > > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > > > > > debugging enabled, I can see that it is not able to locate the MMC
> > > > > > > device.  I am going to assume that if it cannot find the MMC device,
> > > > > > > it probably cannot find the serial device which may explain why
> > > > > > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > > > > > >
> > > > > > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> > > > > > > with Falcon working?  I'd really like to keep that enabled by default.
> > > > > >
> > > > > > Note that I disabled Falcon for the space savings to keep MLO small
> > > > > > enough, not that I noticed it failing to work.  Given that with my
> > > > > > patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> > > > > > and doesn't work is booting the u-boot.img I just built if there's not
> > > > > > some overlap there.  Perhaps the addresses being used for
> > > > > > BSS/malloc/whatever are stomping on the image and that's wrecking
> > > > > > things?
> > > > > >
> > > > >
> > > > > Is there an easy way to debug memory utilization?  We're not quite
> > > > > getting to the point of loading u-boot.img since it cannot find the
> > > > > MMC driver.
> > > > >
> > > > > Interestingly enough, when I rebased my quasi-working image with the
> > > > > master, it died.  I can still build DM_SPL without SPL_OF_CONTROL but
> > > > > now even with Falcon disabled, any attempts to build with
> > > > > SPL_OF_CONTROL fail.
> > > > > I even tried using OF_PLATDATA hoping it might reduce the memory footprint.
> > > > >
> > > > > I'm going to go back to 2019.01 and run some tests, but any pointers
> > > > > on how to debug memory allocation might be helpful.
> > > >
> > > > When I've had to do this before I've written them out, picked values
> > > > that must fit the hardware and rest of the situation and confirmed or
> > > > denied my hypothesis.
> > >
> > > I've tried to make the memory maps for logic pd boards (including
> > > AM3517-evm) use the TI defaults as much as I can.  Interestingly
> > > enough, when I enable DM in SPL without SPL_OF_CONTROL breaks booting
> > > the AM3517 even when I manually add the platform data, and it doesn't
> > > have Falcon mode enabled, so I wonder if there is something off a bit
> > > in the omap3 initialization and/or memory usage.
> > >
> > > When I pulled in the latest from origin/master, the part that I had
> > > working with SPL_OF_CONTROL on the omap3_logic board stopped working.
> > 
> > Tom,
> > 
> > Do you know if your beagle patch still works when based on the current
> > origin/master? Is so, would you be willing to push your
> > omap3-u-boot.dtsi file?  I was able to get some limited functionality
> > by disabling features with 2019.01, but when I use the same
> > configuration, origin/master fails.  I wonder if it's related to the
> > size thread regarding the SPL size when dtb is added.
> 
> OK, I'm a dummy :)  Yes, the patches I posted work _and_ I should have
> figured this out at the time, the problem I had was that I didn't do the
> right thing to have "u-boot binary as .img" be the one that has the DTB
> rather than not.  Just now I've confirmed that what I posted before on
> f94fa0e94f36 boots to U-Boot itself.  So I'm going to do what I need to
> do to make Beagleboard work with DM and in a non-RFC way.

OK, no, that very last part is wrong, I messed up my mix-things-together
testing.  mix-and-match works, just all of this doesn't work, even when
I'm sure to have u-boot-dtb.img as what's loaded.  So, more debugging
needed.  But I get console and again, if I give it the old U-Boot file,
it works, so I feel like I'm breaking something there.

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

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

end of thread, other threads:[~2019-02-12 17:19 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-23 21:13 [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL Adam Ford
2019-01-23 21:21 ` Tom Rini
2019-01-24 15:56   ` Adam Ford
2019-01-24 13:19 ` Felix Brack
2019-01-25 21:39   ` Adam Ford
2019-01-28 15:08     ` Adam Ford
2019-01-28 15:14       ` Tom Rini
2019-01-28 20:23         ` Adam Ford
2019-01-28 20:33           ` Tom Rini
2019-01-29 13:36             ` Adam Ford
2019-02-12  3:40               ` Adam Ford
2019-02-12 17:05                 ` Tom Rini
2019-02-12 17:19                   ` Tom Rini

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