ARM: omap3: evm: Do not relocate FDT address
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
include/configs/omap3_evm.h +1 -0
@@ -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" \
Signature · 1 line
2.15.1
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
Quoted 12 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)include/configs/omap3_evm.h +0
-0
include/configs/omap3_evm.h line 133
Quoted 7 lines
include/configs/omap3_evm.h +1
-0@@ -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!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171228/3300e7d8/attachment.sig>
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
Quoted 9 lines · Tom Rini
Quoted 7 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)
Quoted 17 lines
include/configs/omap3_evm.h line 133
Quoted 12 lines
include/configs/omap3_evm.h +1
-0@@ -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_sizeshould 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 at 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
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
Quoted 81 lines · Derald D. Woods
Quoted 9 lines · Tom Rini
Quoted 7 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)Quoted 17 lines
include/configs/omap3_evm.h line 133
Quoted 12 lines
include/configs/omap3_evm.h +1
-0@@ -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_sizeshould 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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to8ffed000, end8ffff56f... OK
Quoted 6 lines
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!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171228/66245181/attachment.sig>
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
Quoted 87 lines · Tom Rini
Quoted 86 lines · Derald D. Woods
Quoted 9 lines · Tom Rini
Quoted 7 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)Quoted 17 lines
include/configs/omap3_evm.h line 133
Quoted 12 lines
include/configs/omap3_evm.h +1
-0@@ -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_sizeshould 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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to8ffed000, end8ffff56f... OKStarting kernel ...
[HANG]
Quoted 8 lines
Quoted 1 line
Make note of the "
of_flat_tree" and "Loading Device Tree" lines.Ah, hmmm. Can you please try setting
bootm_size, as an experiment, to0x0a000000? 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_size0x0a000000OMAP3_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 at 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@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<----------------------------------------------------------------
include/configs/ti_armv7_common.h +1 -1
@@ -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
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
Quoted 98 lines · Derald D. Woods
Quoted 87 lines · Tom Rini
Quoted 86 lines · Derald D. Woods
Quoted 9 lines · Tom Rini
Quoted 7 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)Quoted 17 lines
include/configs/omap3_evm.h line 133
Quoted 12 lines
include/configs/omap3_evm.h +1
-0@@ -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_sizeshould 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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to8ffed000, end8ffff56f... OKStarting kernel ...
[HANG]
Quoted 8 lines
Quoted 1 line
Make note of the "
of_flat_tree" and "Loading Device Tree" lines.Ah, hmmm. Can you please try setting
bootm_size, as an experiment, to0x0a000000? 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!
Quoted 1 line
That seemed to do it.
Ah, good!
Quoted 108 lines
---8<----------------------------------------------------------------
OMAP3_EVM# echo $bootm_size0x0a000000OMAP3_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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to89fed000, end89fff56f... OKStarting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods at 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<----------------------------------------------------------------
include/configs/ti_armv7_common.h +1
-2@@ -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<----------------------------------------------------------------
Quoted 4 lines
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!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171228/ba1d4a11/attachment.sig>
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
Quoted 211 lines · Tom Rini
Quoted 98 lines · Derald D. Woods
Quoted 87 lines · Tom Rini
Quoted 86 lines · Derald D. Woods
Quoted 9 lines · Tom Rini
Quoted 7 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)Quoted 17 lines
include/configs/omap3_evm.h line 133
Quoted 12 lines
include/configs/omap3_evm.h +1
-0@@ -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_sizeshould 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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to8ffed000, end8ffff56f... OKStarting kernel ...
[HANG]
Quoted 8 lines
Quoted 1 line
Make note of the "
of_flat_tree" and "Loading Device Tree" lines.Ah, hmmm. Can you please try setting
bootm_size, as an experiment, to0x0a000000? 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!Quoted 1 line
That seemed to do it.
Ah, good!
Quoted 108 lines
---8<----------------------------------------------------------------
OMAP3_EVM# echo $bootm_size0x0a000000OMAP3_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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to89fed000, end89fff56f... OKStarting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods at 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<----------------------------------------------------------------
include/configs/ti_armv7_common.h +1
-2@@ -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<----------------------------------------------------------------
Quoted 9 lines
Quoted 4 lines
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: 0OMAP3_EVM # bdinfoarch_number = 0x000005FFboot_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 / 2000fdt_blob = 8df01ad0 ---8<----------------------------------------------------------------
Derald
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
In reply to Tom RiniQuoted 211 lines · Tom Rini
Quoted 98 lines · Derald D. Woods
Quoted 87 lines · Tom Rini
Quoted 86 lines · Derald D. Woods
Quoted 9 lines · Tom Rini
Quoted 7 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)Quoted 17 lines
include/configs/omap3_evm.h line 133
Quoted 12 lines
include/configs/omap3_evm.h +1
-0@@ -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_sizeshould 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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to8ffed000, end8ffff56f... OKStarting kernel ...
[HANG]
Quoted 8 lines
Quoted 1 line
Make note of the "
of_flat_tree" and "Loading Device Tree" lines.Ah, hmmm. Can you please try setting
bootm_size, as an experiment, to0x0a000000? 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!Quoted 1 line
That seemed to do it.
Ah, good!
Quoted 108 lines
---8<----------------------------------------------------------------
OMAP3_EVM# echo $bootm_size0x0a000000OMAP3_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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to89fed000, end89fff56f... OKStarting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods at 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<----------------------------------------------------------------
include/configs/ti_armv7_common.h +1
-2@@ -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<----------------------------------------------------------------
Quoted 9 lines
Quoted 4 lines
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
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
Quoted 222 lines · Derald D. Woods
Quoted 211 lines · Tom Rini
Quoted 98 lines · Derald D. Woods
Quoted 87 lines · Tom Rini
Quoted 86 lines · Derald D. Woods
Quoted 9 lines · Tom Rini
Quoted 7 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)Quoted 17 lines
include/configs/omap3_evm.h line 133
Quoted 12 lines
include/configs/omap3_evm.h +1
-0@@ -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_sizeshould 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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to8ffed000, end8ffff56f... OKStarting kernel ...
[HANG]
Quoted 8 lines
Quoted 1 line
Make note of the "
of_flat_tree" and "Loading Device Tree" lines.Ah, hmmm. Can you please try setting
bootm_size, as an experiment, to0x0a000000? 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!Quoted 1 line
That seemed to do it.
Ah, good!
Quoted 108 lines
---8<----------------------------------------------------------------
OMAP3_EVM# echo $bootm_size0x0a000000OMAP3_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.imgU-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/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to89fed000, end89fff56f... OKStarting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods at 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<----------------------------------------------------------------
include/configs/ti_armv7_common.h +1
-2@@ -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<----------------------------------------------------------------Quoted 9 lines
Quoted 4 lines
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!
Quoted 5 lines
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).
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180101/54973fae/attachment.sig>
PATCH 1/1 ARM: omap3: evm: Do not relocate FDT address
Quoted 264 lines · Tom Rini
Quoted 6 lines · Derald D. Woods
Quoted 5 lines · Tom Rini
Quoted 4 lines · Derald D. Woods
Quoted 3 lines · Tom Rini
Quoted 2 lines · Derald D. Woods
Quoted 1 line · Tom Rini
On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Review
Quoted 7 lines
Signed-off-by Derald D. Woods <[email protected]>--- include/configs/omap3_evm.h | 1 + 1 file changed, 1 insertion(+)(quoted diff) +0
-0
b/include/configs/omap3_evm.hQuoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
index
629d60b961..d95ccdf035100644include/configs/omap3_evm.h +0
-0@@ -127,6 +127,7 @@"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
include/configs/omap3_evm.h line 133
Quoted 6 lines
include/configs/omap3_evm.h +1
-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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
question?
bootm_sizeshould be ensuring we never relocate itoutside of
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
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 thecode
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
indicates, the kernel boot behavior is what I expect. I spent a
few
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
hours following the code path to a single line edition that
works.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Without '
fdt_high'
==================U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 -
11:16:52)
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Trying to boot from MMC1
reading u-boot.img
reading u-boot.imgU-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 -
11:16:52 -0600)
Quoted 35 lines
Quoted 35 lines
Quoted 35 lines
Quoted 35 lines
Quoted 35 lines
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
Model: TI OMAP35XX EVM (TMDSEVM3530)
OMAP3 EVM board + LPDDR/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to8ffed000, end8ffff56f... OKQuoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
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 anexperiment, to
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Linux to boot, see an invalid DTB and not have a console available
to
Quoted 9 lines
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
tell us. Thanks!
That seemed to do it.
Ah, good!
Quoted 1 line
---8<-------------------------------------------------------
---------
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
OMAP3_EVM# echo $bootm_size0x0a000000OMAP3_EVM# reset
resetting ...
O
U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 -13:03:42)
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Trying to boot from MMC1
reading u-boot.img
reading u-boot.imgU-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42
-0600)
Quoted 35 lines
Quoted 35 lines
Quoted 35 lines
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
Model: TI OMAP35XX EVM (TMDSEVM3530)
OMAP3 EVM board + LPDDR/NANDI2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0Read 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 at0x88000000of_flat_treeat0x88000000size0x0000f570
## device tree at 88000000 ...8800f56f(len=75120 [0x12570])
Loading Device Tree to89fed000, end89fff56f... OKQuoted 4 lines
Quoted 4 lines
Quoted 4 lines
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08(ddwoods at 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
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7),cr=10c5387d
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPTnonaliasing instruction cache
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[ 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. Totalpages: 64706
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Kernel command line: console=ttyO0,115200n8mtdparts=omap2-nand.0:512k(spl),1792k(u-boot),128k(dtb), 128k(u-boot-env),6m(kernel),-(rootfs) root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5,131072 bytes)
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4,65536 bytes)
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Memory: 218956K/261120K available (9216K kernel code,742K rwdata, 3004K rodata, 1024K init, 7808K bss, 25780K reserved, 16384K cma-reserved, 0K highmem)
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
[ 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)Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
[ 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
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
[ 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<-------------------------------------------------------
---------
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
This is the patch that I used.
---8<-------------------------------------------------------
---------
Quoted 1 line
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +0
-0
b/include/configs/ti_armv7_common.hQuoted 11 lines
Quoted 11 lines
Quoted 11 lines
index
91e139853c..23d2ef840e100644include/configs/ti_armv7_common.h +1
-1@@ -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" Quoted 2 lines
Quoted 2 lines
include/configs/ti_armv7_common.h
Quoted 2 lines
include/configs/ti_armv7_common.h +0
-1#define DEFAULT_FIT_TI_ARGS \ ---8<----------------------------------------------------------------
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
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!Quoted 5 lines
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.
Quoted 11 lines
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_sizeruns into where U-Boot itself is, and then roundingbootm_sizedown (and warning the user).
Thanks for the clear explanation of the issue with respect to ARM.
Derald
Quoted 3 lines · Derald D. Woods
This commit keeps the 'fdtaddr' as provided by
DEFAULT_LINUX_BOOT_ENV.Signed-off-by Derald D. Woods <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180101/da6beff7/attachment.sig>