[U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address
Tom Rini
trini at konsulko.com
Mon Jan 1 13:29:25 UTC 2018
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 at 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 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<----------------------------------------------------------------
> > > 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).
--
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>
More information about the U-Boot
mailing list