On Mon, Jan 1, 2018 at 7:29 AM, Tom Rini <tr...@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.techni...@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​ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot