[U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL
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
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@68000000 { + u-boot,dm-spl; + + bandgap@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
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@68000000 {u-boot,dm-spl;bandgap@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
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
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@68000000/serial@49020000"; };
aliases { i2c0 = "/ocp@68000000/i2c@48070000"; serial0 = "/ocp@68000000/serial@4806a000"; serial1 = "/ocp@68000000/serial@4806c000"; serial2 = "/ocp@68000000/serial@49020000"; };
ocp@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@48000000 { compatible = "ti,omap3-l4-core\0simple-bus"; #address-cells = < 0x01 >; #size-cells = < 0x01 >; ranges = < 0x00 0x48000000 0x1000000 >; u-boot,dm-spl;
scm@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@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@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@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@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@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@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@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@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@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@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@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@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@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@48002524 { u-boot,dm-spl; }; }; };
regards Felix
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@68000000/serial@49020000"; };
aliases { i2c0 = "/ocp@68000000/i2c@48070000"; serial0 = "/ocp@68000000/serial@4806a000"; serial1 = "/ocp@68000000/serial@4806c000"; serial2 = "/ocp@68000000/serial@49020000"; };
ocp@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@48000000 { compatible = "ti,omap3-l4-core\0simple-bus"; #address-cells = < 0x01 >; #size-cells = < 0x01 >; ranges = < 0x00 0x48000000 0x1000000 >; u-boot,dm-spl;
scm@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@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@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@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@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@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@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@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@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@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@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@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@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@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@48002524 { u-boot,dm-spl; }; }; };
regards Felix
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?
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
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.
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
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
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.
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.
participants (3)
-
Adam Ford -
Felix Brack -
Tom Rini