[U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com --- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 629d60b961..d95ccdf035 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -127,6 +127,7 @@ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \ + "fdt_high=0xffffffff\0" \ "bootenv=uEnv.txt\0" \ "optargs=\0" \ "mmcdev=0\0" \
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 629d60b961..d95ccdf035 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -127,6 +127,7 @@ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
- "fdt_high=0xffffffff\0" \ "bootenv=uEnv.txt\0" \ "optargs=\0" \ "mmcdev=0\0" \
What's the problem this solves, and how much memory is on the system in question? bootm_size should be ensuring we never relocate it outside of the first 256MB of memory. Thanks!
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 629d60b961..d95ccdf035 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -127,6 +127,7 @@ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
- "fdt_high=0xffffffff\0" \ "bootenv=uEnv.txt\0" \ "optargs=\0" \ "mmcdev=0\0" \
What's the problem this solves, and how much memory is on the system in question? bootm_size should be ensuring we never relocate it outside of the first 256MB of memory. Thanks!
The logic within "common/image-fdt.c" lead me down this path. The addition of this fairly common environment variable allowed my OMAP34XX board to boot the kernel without an appended devicetree. When I use the variable to trigger 'disable_relocation', as the code indicates, the kernel boot behavior is what I expect. I spent a few hours following the code path to a single line edition that works.
Without 'fdt_high' ==================
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ... * fdt: cmdline image address = 0x88000000 ## Checking for 'FDT'/'FDT Image' at 88000000 * fdt: raw FDT blob ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 8ffed000, end 8ffff56f ... OK
Starting kernel ...
[HANG]
Make note of the "of_flat_tree" and "Loading Device Tree" lines.
With 'fdt_high=0xffffffff' ==========================
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:24:25) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:24:25 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ... * fdt: cmdline image address = 0x88000000 ## Checking for 'FDT'/'FDT Image' at 88000000 * fdt: raw FDT blob ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 Using Device Tree in place at 88000000, end 8801256f
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods@ethiopia) (gcc version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-269-ge832b9b2 - Linux 4.14.y)) #17 PREEMPT Wed Dec 27 22:59:37 CST 2017 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI OMAP35XX EVM (TMDSEVM3530) [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x8e800000 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp) [ 0.000000] random: fast init done [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64706 [ 0.000000] Kernel command line: console=ttyO0,115200n8 mtdparts=omap2-nand.0:512k(spl),1792k(u-boot),128k(dtb),128k(u-boot-env),6m(kernel),-(rootfs) root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 218956K/261120K available (9216K kernel code, 742K rwdata, 3004K rodata, 1024K init, 7808K bss, 25780K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0000000 - 0xff800000 ( 760 MB) [ 0.000000] lowmem : 0xc0000000 - 0xcff00000 ( 255 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (10208 kB) [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 743 kB) [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (7809 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] ftrace: allocating 29168 entries in 86 pages [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU event tracing is enabled. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] Tasks RCU enabled.
[...]
[NORMAL BOOT]
The "of_flat_tree" and "Using Device Tree" lines have the same location in this case.
Currently in U-Boot =================== $ grep -RI -e "fdt_high=" include/configs/
include/configs/ls1012a_common.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/dh_imx6.h: "fdt_high=0xffffffff\0" \ include/configs/db-88f6820-gp.h: "fdt_high=0x10000000\0" \ include/configs/mx6qarm2.h: "fdt_high=0xffffffff\0" \ include/configs/ls2080a_common.h: "fdt_high=0xa0000000\0" \ include/configs/tegra-common-post.h: "fdt_high=" FDT_HIGH "\0" \ include/configs/ls1012ardb.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/el6x_common.h: "fdt_high=0xffffffff\0" \ include/configs/turris_omnia.h: "fdt_high=0x10000000\0" \ include/configs/ls1088ardb.h: "fdt_high=0xa0000000\0" \ include/configs/nitrogen6x.h: "fdt_high=0xffffffff\0" \ include/configs/s32v234evb.h: "fdt_high=0xffffffff\0" \ include/configs/gw_ventana.h: "fdt_high=0xffffffff\0" \ include/configs/zynq-common.h: "fdt_high=0x20000000\0" \ include/configs/omap3_cairo.h: "fdt_high=0x87000000\0" \ include/configs/mx53ppd.h: "fdt_high=0xffffffff\0" \ include/configs/rk322x_common.h: "fdt_high=0x7fffffff\0" \ include/configs/ls1021atwr.h: "fdt_high=0xffffffff\0" \ include/configs/ls1021atwr.h: "fdt_high=0xffffffff\0" \ include/configs/mx7dsabresd.h: "fdt_high=0xffffffff\0" \ include/configs/mx6slevk.h: "fdt_high=0xffffffff\0" \ include/configs/am335x_shc.h: "fdt_high=0xffffffff\0" \ include/configs/colibri_imx7.h: "fdt_high=0xffffffff\0" \ include/configs/ls1088a_common.h: "fdt_high=0xa0000000\0" \ include/configs/mx6sxsabreauto.h: "fdt_high=0xffffffff\0" \ include/configs/apalis_imx6.h: "fdt_high=0xffffffff\0" \ include/configs/advantech_dms-ba16.h: "fdt_high=0xffffffff\0" \ include/configs/pfla02.h: "fdt_high=0xffffffff\0" \ include/configs/bav335x.h:"fdt_high=0xffffffff\0" \ include/configs/pico-imx6ul.h: "fdt_high=0xffffffff\0" \ include/configs/rpi.h: "fdt_high=ffffffff\0" \ include/configs/xilinx_zynqmp.h: "fdt_high=10000000\0" \ include/configs/udoo.h: "fdt_high=0xffffffff\0" \ include/configs/thunderx_88xx.h: "fdt_high=0x9fffffff\0" include/configs/wandboard.h: "fdt_high=0xffffffff\0" \ include/configs/ls1043a_common.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/mx6cuboxi.h: "fdt_high=0xffffffff\0" \ include/configs/omap3_beagle.h: "fdt_high=0xffffffff\0" \ include/configs/ls1088aqds.h: "fdt_high=0xa0000000\0" \ include/configs/ls1088aqds.h: "fdt_high=0xa0000000\0" \ include/configs/ls1088aqds.h: "fdt_high=0xa0000000\0" \ include/configs/ls1088aqds.h: "fdt_high=0xa0000000\0" \ include/configs/rcar-gen3-common.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/mx6sxsabresd.h: "fdt_high=0xffffffff\0" \ include/configs/mx6sabre_common.h: "fdt_high=0xffffffff\0" \ include/configs/theadorable.h: "fdt_high=0x10000000\0" \ include/configs/novena.h: "fdt_high=0xffffffff\0" \ include/configs/ls1012afrdm.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/mx6ul_14x14_evk.h: "fdt_high=0xffffffff\0" \ include/configs/controlcenterdc.h: "fdt_high=0x10000000\0" \ include/configs/ls2080ardb.h: "fdt_high=0xa0000000\0" \ include/configs/colibri_imx6.h: "fdt_high=0xffffffff\0" \ include/configs/db-88f6820-amc.h: "fdt_high=0x10000000\0" \ include/configs/rk3288_common.h: "fdt_high=0x0fffffff\0" \ include/configs/tqma6.h: "fdt_high=0xffffffff\0" \ include/configs/udoo_neo.h: "fdt_high=0xffffffff\0" \ include/configs/syzygy_hub.h: "fdt_high=0x20000000\0" \ include/configs/mccmon6.h: "fdt_high=0xffffffff\0" \ include/configs/mx6ullevk.h: "fdt_high=0xffffffff\0" \ include/configs/hikey.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/aristainetos-common.h: "fdt_high=0xffffffff\0" \ include/configs/ls2080aqds.h: "fdt_high=0xa0000000\0" \ include/configs/ls2080aqds.h: "fdt_high=0xa0000000\0" \ include/configs/ls2080aqds.h: "fdt_high=0xa0000000\0" \ include/configs/topic_miami.h: "fdt_high=0x20000000\0" \ include/configs/ge_bx50v3.h: "fdt_high=0xffffffff\0" \ include/configs/opos6uldev.h: "fdt_high=0xffffffff\0" \ include/configs/cl-som-imx7.h: "fdt_high=0xffffffff\0" \ include/configs/ls1021aqds.h: "fdt_high=0xffffffff\0" \ include/configs/ls1021aqds.h: "fdt_high=0xffffffff\0" \ include/configs/liteboard.h: "fdt_high=0xffffffff\0" \ include/configs/display5.h: "fdt_high=0xffffffff\0" \ include/configs/ls1046a_common.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/rk3188_common.h: "fdt_high=0x6fffffff\0" \ include/configs/pico-imx7d.h: "fdt_high=0xffffffff\0" \ include/configs/warp.h: "fdt_high=0xffffffff\0" \ include/configs/dragonboard410c.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/vexpress_aemv8a.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/vexpress_aemv8a.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/vexpress_aemv8a.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/rk3036_common.h: "fdt_high=0x7fffffff\0" \ include/configs/ls1021aiot.h:"fdt_high=0xffffffff\0" include/configs/warp7.h: "fdt_high=0xffffffff\0" \ include/configs/mx53ard.h: "fdt_high=0xffffffff\0" \ include/configs/xpress.h: "fdt_high=0xffffffff\0" \ include/configs/qemu-arm.h: "fdt_high=0xffffffff\0" \ include/configs/stih410-b2260.h: "fdt_high=0xffffffffffffffff\0" \ include/configs/mx6sllevk.h: "fdt_high=0xffffffff\0" \ include/configs/clearfog.h: "fdt_high=0x10000000\0" \ include/configs/mx7ulp_evk.h: "fdt_high=0xffffffff\0" \ include/configs/imx6-engicam.h: "fdt_high=0xffffffff\0" \ include/configs/pcm052.h: "fdt_high=0xffffffff\0" \ include/configs/titanium.h: "fdt_high=0xffffffff\0" \ include/configs/mx25pdk.h: "fdt_high=0xffffffff\0" \
If there is some other usable code path, I will gladly add/implement it.
Derald
On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 629d60b961..d95ccdf035 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -127,6 +127,7 @@ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
- "fdt_high=0xffffffff\0" \ "bootenv=uEnv.txt\0" \ "optargs=\0" \ "mmcdev=0\0" \
What's the problem this solves, and how much memory is on the system in question? bootm_size should be ensuring we never relocate it outside of the first 256MB of memory. Thanks!
The logic within "common/image-fdt.c" lead me down this path. The addition of this fairly common environment variable allowed my OMAP34XX board to boot the kernel without an appended devicetree. When I use the variable to trigger 'disable_relocation', as the code indicates, the kernel boot behavior is what I expect. I spent a few hours following the code path to a single line edition that works.
Without 'fdt_high'
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 8ffed000, end 8ffff56f ... OK
Starting kernel ...
[HANG]
Make note of the "of_flat_tree" and "Loading Device Tree" lines.
Ah, hmmm. Can you please try setting bootm_size, as an experiment, to 0x0a000000 ? I wonder if, since you have 256MB of memory we're not putting the DTB into where U-Boot is and we stomp on it a bit, causing Linux to boot, see an invalid DTB and not have a console available to tell us. Thanks!
On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 629d60b961..d95ccdf035 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -127,6 +127,7 @@ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
- "fdt_high=0xffffffff\0" \ "bootenv=uEnv.txt\0" \ "optargs=\0" \ "mmcdev=0\0" \
What's the problem this solves, and how much memory is on the system in question? bootm_size should be ensuring we never relocate it outside of the first 256MB of memory. Thanks!
The logic within "common/image-fdt.c" lead me down this path. The addition of this fairly common environment variable allowed my OMAP34XX board to boot the kernel without an appended devicetree. When I use the variable to trigger 'disable_relocation', as the code indicates, the kernel boot behavior is what I expect. I spent a few hours following the code path to a single line edition that works.
Without 'fdt_high'
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 8ffed000, end 8ffff56f ... OK
Starting kernel ...
[HANG]
Make note of the "of_flat_tree" and "Loading Device Tree" lines.
Ah, hmmm. Can you please try setting bootm_size, as an experiment, to 0x0a000000 ? I wonder if, since you have 256MB of memory we're not putting the DTB into where U-Boot is and we stomp on it a bit, causing Linux to boot, see an invalid DTB and not have a console available to tell us. Thanks!
That seemed to do it.
---8<----------------------------------------------------------------
OMAP3_EVM # echo $bootm_size 0x0a000000 OMAP3_EVM # reset resetting ... O U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ... * fdt: cmdline image address = 0x88000000 ## Checking for 'FDT'/'FDT Image' at 88000000 * fdt: raw FDT blob ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 89fed000, end 89fff56f ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods@ethiopia) (gcc version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-269-ge832b9b2 - Linux 4.14.y)) #17 PREEMPT Wed Dec 27 22:59:37 CST 2017 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI OMAP35XX EVM (TMDSEVM3530) [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x8e800000 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp) [ 0.000000] random: fast init done [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64706 [ 0.000000] Kernel command line: console=ttyO0,115200n8 mtdparts=omap2-nand.0:512k(spl),1792k(u-boot),128k(dtb),128k(u-boot-env),6m(kernel),-(rootfs) root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 218956K/261120K available (9216K kernel code, 742K rwdata, 3004K rodata, 1024K init, 7808K bss, 25780K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0000000 - 0xff800000 ( 760 MB) [ 0.000000] lowmem : 0xc0000000 - 0xcff00000 ( 255 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (10208 kB) [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 743 kB) [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (7809 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] ftrace: allocating 29168 entries in 86 pages [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU event tracing is enabled. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] Tasks RCU enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[...] ---8<----------------------------------------------------------------
This is the patch that I used.
---8<---------------------------------------------------------------- diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 91e139853c..23d2ef840e 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -48,7 +48,7 @@ "ramdisk_addr_r=0x88080000\0" \ "scriptaddr=0x80000000\0" \ "pxefile_addr_r=0x80100000\0" \ - "bootm_size=0x10000000\0" \ + "bootm_size=0x0a000000\0" \ "boot_fdt=try\0"
#define DEFAULT_FIT_TI_ARGS \ ---8<----------------------------------------------------------------
This, I believe, would be of help for many OMAP34XX boards which have the same memory layout as the OMAP3 EVM. Do you think submitting a patch for the above would be of value? Or should it really be determined at the individual board level?
Derald
On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 629d60b961..d95ccdf035 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -127,6 +127,7 @@ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
- "fdt_high=0xffffffff\0" \ "bootenv=uEnv.txt\0" \ "optargs=\0" \ "mmcdev=0\0" \
What's the problem this solves, and how much memory is on the system in question? bootm_size should be ensuring we never relocate it outside of the first 256MB of memory. Thanks!
The logic within "common/image-fdt.c" lead me down this path. The addition of this fairly common environment variable allowed my OMAP34XX board to boot the kernel without an appended devicetree. When I use the variable to trigger 'disable_relocation', as the code indicates, the kernel boot behavior is what I expect. I spent a few hours following the code path to a single line edition that works.
Without 'fdt_high'
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 8ffed000, end 8ffff56f ... OK
Starting kernel ...
[HANG]
Make note of the "of_flat_tree" and "Loading Device Tree" lines.
Ah, hmmm. Can you please try setting bootm_size, as an experiment, to 0x0a000000 ? I wonder if, since you have 256MB of memory we're not putting the DTB into where U-Boot is and we stomp on it a bit, causing Linux to boot, see an invalid DTB and not have a console available to tell us. Thanks!
That seemed to do it.
Ah, good!
---8<----------------------------------------------------------------
OMAP3_EVM # echo $bootm_size 0x0a000000 OMAP3_EVM # reset resetting ... O U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 89fed000, end 89fff56f ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods@ethiopia) (gcc version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-269-ge832b9b2 - Linux 4.14.y)) #17 PREEMPT Wed Dec 27 22:59:37 CST 2017 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI OMAP35XX EVM (TMDSEVM3530) [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x8e800000 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp) [ 0.000000] random: fast init done [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64706 [ 0.000000] Kernel command line: console=ttyO0,115200n8 mtdparts=omap2-nand.0:512k(spl),1792k(u-boot),128k(dtb),128k(u-boot-env),6m(kernel),-(rootfs) root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 218956K/261120K available (9216K kernel code, 742K rwdata, 3004K rodata, 1024K init, 7808K bss, 25780K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0000000 - 0xff800000 ( 760 MB) [ 0.000000] lowmem : 0xc0000000 - 0xcff00000 ( 255 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (10208 kB) [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 743 kB) [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (7809 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] ftrace: allocating 29168 entries in 86 pages [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU event tracing is enabled. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] Tasks RCU enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[...] ---8<----------------------------------------------------------------
This is the patch that I used.
---8<---------------------------------------------------------------- diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 91e139853c..23d2ef840e 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -48,7 +48,7 @@ "ramdisk_addr_r=0x88080000\0" \ "scriptaddr=0x80000000\0" \ "pxefile_addr_r=0x80100000\0" \
"bootm_size=0x10000000\0" \
"bootm_size=0x0a000000\0" \ "boot_fdt=try\0"#define DEFAULT_FIT_TI_ARGS \ ---8<----------------------------------------------------------------
This, I believe, would be of help for many OMAP34XX boards which have the same memory layout as the OMAP3 EVM. Do you think submitting a patch for the above would be of value? Or should it really be determined at the individual board level?
I'm not quite sure about the best way forward here. Can you do a 'bdinfo' on your EVM and see how much memory U-Boot is taking up while running? Thanks!
On Thu, Dec 28, 2017 at 02:24:08PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 629d60b961..d95ccdf035 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -127,6 +127,7 @@ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
- "fdt_high=0xffffffff\0" \ "bootenv=uEnv.txt\0" \ "optargs=\0" \ "mmcdev=0\0" \
What's the problem this solves, and how much memory is on the system in question? bootm_size should be ensuring we never relocate it outside of the first 256MB of memory. Thanks!
The logic within "common/image-fdt.c" lead me down this path. The addition of this fairly common environment variable allowed my OMAP34XX board to boot the kernel without an appended devicetree. When I use the variable to trigger 'disable_relocation', as the code indicates, the kernel boot behavior is what I expect. I spent a few hours following the code path to a single line edition that works.
Without 'fdt_high'
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 8ffed000, end 8ffff56f ... OK
Starting kernel ...
[HANG]
Make note of the "of_flat_tree" and "Loading Device Tree" lines.
Ah, hmmm. Can you please try setting bootm_size, as an experiment, to 0x0a000000 ? I wonder if, since you have 256MB of memory we're not putting the DTB into where U-Boot is and we stomp on it a bit, causing Linux to boot, see an invalid DTB and not have a console available to tell us. Thanks!
That seemed to do it.
Ah, good!
---8<----------------------------------------------------------------
OMAP3_EVM # echo $bootm_size 0x0a000000 OMAP3_EVM # reset resetting ... O U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 89fed000, end 89fff56f ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods@ethiopia) (gcc version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-269-ge832b9b2 - Linux 4.14.y)) #17 PREEMPT Wed Dec 27 22:59:37 CST 2017 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI OMAP35XX EVM (TMDSEVM3530) [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x8e800000 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp) [ 0.000000] random: fast init done [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64706 [ 0.000000] Kernel command line: console=ttyO0,115200n8 mtdparts=omap2-nand.0:512k(spl),1792k(u-boot),128k(dtb),128k(u-boot-env),6m(kernel),-(rootfs) root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 218956K/261120K available (9216K kernel code, 742K rwdata, 3004K rodata, 1024K init, 7808K bss, 25780K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0000000 - 0xff800000 ( 760 MB) [ 0.000000] lowmem : 0xc0000000 - 0xcff00000 ( 255 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (10208 kB) [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 743 kB) [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (7809 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] ftrace: allocating 29168 entries in 86 pages [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU event tracing is enabled. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] Tasks RCU enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[...] ---8<----------------------------------------------------------------
This is the patch that I used.
---8<---------------------------------------------------------------- diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 91e139853c..23d2ef840e 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -48,7 +48,7 @@ "ramdisk_addr_r=0x88080000\0" \ "scriptaddr=0x80000000\0" \ "pxefile_addr_r=0x80100000\0" \
"bootm_size=0x10000000\0" \
"bootm_size=0x0a000000\0" \ "boot_fdt=try\0"#define DEFAULT_FIT_TI_ARGS \ ---8<----------------------------------------------------------------
This, I believe, would be of help for many OMAP34XX boards which have the same memory layout as the OMAP3 EVM. Do you think submitting a patch for the above would be of value? Or should it really be determined at the individual board level?
I'm not quite sure about the best way forward here. Can you do a 'bdinfo' on your EVM and see how much memory U-Boot is taking up while running? Thanks!
---8<----------------------------------------------------------------
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 OMAP3_EVM # bdinfo arch_number = 0x000005FF boot_params = 0x80000100 DRAM bank = 0x00000000 -> start = 0x80000000 -> size = 0x08000000 DRAM bank = 0x00000001 -> start = 0x88000000 -> size = 0x08000000 eth0name = smc911x-0 ethaddr = 00:50:c2:7e:92:98 current eth = smc911x-0 ip_addr = <NULL> baudrate = 115200 bps TLB addr = 0x8FFF0000 relocaddr = 0x8FF32000 reloc off = 0x0FE32000 irq_sp = 0x8DF01AC0 sp start = 0x8DF01AB0 Early malloc usage: 16c / 2000 fdt_blob = 8df01ad0 ---8<----------------------------------------------------------------
Derald
On Thu, Dec 28, 2017 at 02:24:08PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 629d60b961..d95ccdf035 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -127,6 +127,7 @@ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
- "fdt_high=0xffffffff\0" \ "bootenv=uEnv.txt\0" \ "optargs=\0" \ "mmcdev=0\0" \
What's the problem this solves, and how much memory is on the system in question? bootm_size should be ensuring we never relocate it outside of the first 256MB of memory. Thanks!
The logic within "common/image-fdt.c" lead me down this path. The addition of this fairly common environment variable allowed my OMAP34XX board to boot the kernel without an appended devicetree. When I use the variable to trigger 'disable_relocation', as the code indicates, the kernel boot behavior is what I expect. I spent a few hours following the code path to a single line edition that works.
Without 'fdt_high'
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 8ffed000, end 8ffff56f ... OK
Starting kernel ...
[HANG]
Make note of the "of_flat_tree" and "Loading Device Tree" lines.
Ah, hmmm. Can you please try setting bootm_size, as an experiment, to 0x0a000000 ? I wonder if, since you have 256MB of memory we're not putting the DTB into where U-Boot is and we stomp on it a bit, causing Linux to boot, see an invalid DTB and not have a console available to tell us. Thanks!
That seemed to do it.
Ah, good!
---8<----------------------------------------------------------------
OMAP3_EVM # echo $bootm_size 0x0a000000 OMAP3_EVM # reset resetting ... O U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 89fed000, end 89fff56f ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods@ethiopia) (gcc version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-269-ge832b9b2 - Linux 4.14.y)) #17 PREEMPT Wed Dec 27 22:59:37 CST 2017 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI OMAP35XX EVM (TMDSEVM3530) [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x8e800000 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp) [ 0.000000] random: fast init done [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64706 [ 0.000000] Kernel command line: console=ttyO0,115200n8 mtdparts=omap2-nand.0:512k(spl),1792k(u-boot),128k(dtb),128k(u-boot-env),6m(kernel),-(rootfs) root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 218956K/261120K available (9216K kernel code, 742K rwdata, 3004K rodata, 1024K init, 7808K bss, 25780K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0000000 - 0xff800000 ( 760 MB) [ 0.000000] lowmem : 0xc0000000 - 0xcff00000 ( 255 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (10208 kB) [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 743 kB) [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (7809 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] ftrace: allocating 29168 entries in 86 pages [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU event tracing is enabled. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] Tasks RCU enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[...] ---8<----------------------------------------------------------------
This is the patch that I used.
---8<---------------------------------------------------------------- diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 91e139853c..23d2ef840e 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -48,7 +48,7 @@ "ramdisk_addr_r=0x88080000\0" \ "scriptaddr=0x80000000\0" \ "pxefile_addr_r=0x80100000\0" \
"bootm_size=0x10000000\0" \
"bootm_size=0x0a000000\0" \ "boot_fdt=try\0"#define DEFAULT_FIT_TI_ARGS \ ---8<----------------------------------------------------------------
This, I believe, would be of help for many OMAP34XX boards which have the same memory layout as the OMAP3 EVM. Do you think submitting a patch for the above would be of value? Or should it really be determined at the individual board level?
I'm not quite sure about the best way forward here. Can you do a 'bdinfo' on your EVM and see how much memory U-Boot is taking up while running? Thanks!
Is there a reason disabling FDT relocation is not a valid path? It would at least keep things localized to a given board. I also like knowing that 'fdtaddr' is the same throughout the startup process. I just want to know if there is some rule that is being broken with 'fdt_high=0xffffffff'. It appears to exist by design.
Derald
On Thu, Dec 28, 2017 at 05:17:13PM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 02:24:08PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
> This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV. > > Signed-off-by: Derald D. Woods woods.technical@gmail.com > --- > include/configs/omap3_evm.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h > index 629d60b961..d95ccdf035 100644 > --- a/include/configs/omap3_evm.h > +++ b/include/configs/omap3_evm.h > @@ -127,6 +127,7 @@ > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ > "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ > "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \ > + "fdt_high=0xffffffff\0" \ > "bootenv=uEnv.txt\0" \ > "optargs=\0" \ > "mmcdev=0\0" \
What's the problem this solves, and how much memory is on the system in question? bootm_size should be ensuring we never relocate it outside of the first 256MB of memory. Thanks!
The logic within "common/image-fdt.c" lead me down this path. The addition of this fairly common environment variable allowed my OMAP34XX board to boot the kernel without an appended devicetree. When I use the variable to trigger 'disable_relocation', as the code indicates, the kernel boot behavior is what I expect. I spent a few hours following the code path to a single line edition that works.
Without 'fdt_high'
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 8ffed000, end 8ffff56f ... OK
Starting kernel ...
[HANG]
Make note of the "of_flat_tree" and "Loading Device Tree" lines.
Ah, hmmm. Can you please try setting bootm_size, as an experiment, to 0x0a000000 ? I wonder if, since you have 256MB of memory we're not putting the DTB into where U-Boot is and we stomp on it a bit, causing Linux to boot, see an invalid DTB and not have a console available to tell us. Thanks!
That seemed to do it.
Ah, good!
---8<----------------------------------------------------------------
OMAP3_EVM # echo $bootm_size 0x0a000000 OMAP3_EVM # reset resetting ... O U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42) Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 89fed000, end 89fff56f ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods@ethiopia) (gcc version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-269-ge832b9b2 - Linux 4.14.y)) #17 PREEMPT Wed Dec 27 22:59:37 CST 2017 [ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI OMAP35XX EVM (TMDSEVM3530) [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x8e800000 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp) [ 0.000000] random: fast init done [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64706 [ 0.000000] Kernel command line: console=ttyO0,115200n8 mtdparts=omap2-nand.0:512k(spl),1792k(u-boot),128k(dtb),128k(u-boot-env),6m(kernel),-(rootfs) root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 218956K/261120K available (9216K kernel code, 742K rwdata, 3004K rodata, 1024K init, 7808K bss, 25780K reserved, 16384K cma-reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0000000 - 0xff800000 ( 760 MB) [ 0.000000] lowmem : 0xc0000000 - 0xcff00000 ( 255 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (10208 kB) [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 743 kB) [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (7809 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] ftrace: allocating 29168 entries in 86 pages [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU event tracing is enabled. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] Tasks RCU enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[...] ---8<----------------------------------------------------------------
This is the patch that I used.
---8<---------------------------------------------------------------- diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 91e139853c..23d2ef840e 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -48,7 +48,7 @@ "ramdisk_addr_r=0x88080000\0" \ "scriptaddr=0x80000000\0" \ "pxefile_addr_r=0x80100000\0" \
"bootm_size=0x10000000\0" \
"bootm_size=0x0a000000\0" \ "boot_fdt=try\0"#define DEFAULT_FIT_TI_ARGS \ ---8<----------------------------------------------------------------
This, I believe, would be of help for many OMAP34XX boards which have the same memory layout as the OMAP3 EVM. Do you think submitting a patch for the above would be of value? Or should it really be determined at the individual board level?
I'm not quite sure about the best way forward here. Can you do a 'bdinfo' on your EVM and see how much memory U-Boot is taking up while running? Thanks!
Is there a reason disabling FDT relocation is not a valid path? It would at least keep things localized to a given board. I also like knowing that 'fdtaddr' is the same throughout the startup process. I just want to know if there is some rule that is being broken with 'fdt_high=0xffffffff'. It appears to exist by design.
The downside to stopping relocation of the fdt (and of the ramdisk via initrd_high=0xffffffff) is that you introduce the chance (more or less, based on where you load everything else) that the device tree gets stomped on by the kernel, esp on ARM (not aarch64 where this has been addressed) because we don't know the size of the kernel BSS. For this release, OK, lets go and do what you've got now, stopping fdt relocation. What I would like to see is some logic added to the boot code to see what the top of bootm_size runs into where U-Boot itself is, and then rounding bootm_size down (and warning the user).
On Mon, Jan 1, 2018 at 7:29 AM, Tom Rini trini@konsulko.com wrote:
On Thu, Dec 28, 2017 at 05:17:13PM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 02:24:08PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote: > On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods
wrote:
> > > This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.
> > > > Signed-off-by: Derald D. Woods woods.technical@gmail.com > > --- > > include/configs/omap3_evm.h | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/include/configs/omap3_evm.h
b/include/configs/omap3_evm.h
> > index 629d60b961..d95ccdf035 100644 > > --- a/include/configs/omap3_evm.h > > +++ b/include/configs/omap3_evm.h > > @@ -127,6 +127,7 @@ > > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ > > "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \ > > "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \ > > + "fdt_high=0xffffffff\0" \ > > "bootenv=uEnv.txt\0" \ > > "optargs=\0" \ > > "mmcdev=0\0" \ > > What's the problem this solves, and how much memory is on the
system in
> question? bootm_size should be ensuring we never relocate it
outside of
> the first 256MB of memory. Thanks! >
The logic within "common/image-fdt.c" lead me down this path. The addition of this fairly common environment variable allowed my OMAP34XX board to boot the kernel without an appended devicetree. When I use the variable to trigger 'disable_relocation', as the
code
indicates, the kernel boot behavior is what I expect. I spent a
few
hours following the code path to a single line edition that
works.
Without 'fdt_high'
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 -
11:16:52)
Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 -
11:16:52 -0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 8ffed000, end 8ffff56f ... OK
Starting kernel ...
[HANG]
Make note of the "of_flat_tree" and "Loading Device Tree" lines.
Ah, hmmm. Can you please try setting bootm_size, as an
experiment, to
0x0a000000 ? I wonder if, since you have 256MB of memory we're not putting the DTB into where U-Boot is and we stomp on it a bit,
causing
Linux to boot, see an invalid DTB and not have a console available
to
tell us. Thanks!
That seemed to do it.
Ah, good!
---8<-------------------------------------------------------
OMAP3_EVM # echo $bootm_size 0x0a000000 OMAP3_EVM # reset resetting ... O U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 -
13:03:42)
Trying to boot from MMC1 reading u-boot.img reading u-boot.img
U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42
-0600)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz Model: TI OMAP35XX EVM (TMDSEVM3530) OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 Read back SMSC id 0x92200000 OMAP die ID: 265a002400000000040365fa1801b01f Net: smc911x-0 starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device ** Unable to read file uEnv.txt ** reading zImage 4637344 bytes read in 407 ms (10.9 MiB/s) reading omap3-evm.dtb 62832 bytes read in 10 ms (6 MiB/s) Booting zImage from mmc ...
- fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
- fdt: raw FDT blob
## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 of_flat_tree at 0x88000000 size 0x0000f570 ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570]) Loading Device Tree to 89fed000, end 89fff56f ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08
(ddwoods@ethiopia) (gcc version 7.2.0 (crosstool-NG crosstool-ng-1.23.0-269-ge832b9b2 - Linux 4.14.y)) #17 PREEMPT Wed Dec 27 22:59:37 CST 2017
[ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT
nonaliasing instruction cache
[ 0.000000] OF: fdt: Machine model: TI OMAP35XX EVM (TMDSEVM3530) [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x8e800000 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp) [ 0.000000] random: fast init done [ 0.000000] Built 1 zonelists, mobility grouping on. Total
pages: 64706
[ 0.000000] Kernel command line: console=ttyO0,115200n8
mtdparts=omap2-nand.0:512k(spl),1792k(u-boot),128k(dtb), 128k(u-boot-env),6m(kernel),-(rootfs) root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5,
131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4,
65536 bytes)
[ 0.000000] Memory: 218956K/261120K available (9216K kernel code,
742K rwdata, 3004K rodata, 1024K init, 7808K bss, 25780K reserved, 16384K cma-reserved, 0K highmem)
[ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xd0000000 - 0xff800000 ( 760 MB) [ 0.000000] lowmem : 0xc0000000 - 0xcff00000 ( 255 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (10208 kB) [ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 743 kB) [ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) (7809 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1,
Nodes=1
[ 0.000000] ftrace: allocating 29168 entries in 86 pages [ 0.000000] Running RCU self tests [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU event tracing is enabled. [ 0.000000] RCU lockdep checking is enabled. [ 0.000000] Tasks RCU enabled. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[...] ---8<-------------------------------------------------------
This is the patch that I used.
---8<-------------------------------------------------------
diff --git a/include/configs/ti_armv7_common.h
b/include/configs/ti_armv7_common.h
index 91e139853c..23d2ef840e 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -48,7 +48,7 @@ "ramdisk_addr_r=0x88080000\0" \ "scriptaddr=0x80000000\0" \ "pxefile_addr_r=0x80100000\0" \
"bootm_size=0x10000000\0" \
"bootm_size=0x0a000000\0" \ "boot_fdt=try\0"#define DEFAULT_FIT_TI_ARGS \ ---8<-------------------------------------------------------
This, I believe, would be of help for many OMAP34XX boards which have the same memory layout as the OMAP3 EVM. Do you think submitting a
patch
for the above would be of value? Or should it really be determined at the individual board level?
I'm not quite sure about the best way forward here. Can you do a 'bdinfo' on your EVM and see how much memory U-Boot is taking up while running? Thanks!
Is there a reason disabling FDT relocation is not a valid path? It would at least keep things localized to a given board. I also like knowing that 'fdtaddr' is the same throughout the startup process. I just want to know if there is some rule that is being broken with 'fdt_high=0xffffffff'. It appears to exist by design.
The downside to stopping relocation of the fdt (and of the ramdisk via initrd_high=0xffffffff) is that you introduce the chance (more or less, based on where you load everything else) that the device tree gets stomped on by the kernel, esp on ARM (not aarch64 where this has been addressed) because we don't know the size of the kernel BSS. For this release, OK, lets go and do what you've got now, stopping fdt relocation. What I would like to see is some logic added to the boot code to see what the top of bootm_size runs into where U-Boot itself is, and then rounding bootm_size down (and warning the user).
Thanks for the clear explanation of the issue with respect to ARM.
Derald
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
Signed-off-by: Derald D. Woods woods.technical@gmail.com
Applied to u-boot/master, thanks!
participants (3)
-
Derald D. Woods -
Derald Woods
-
Tom Rini