[U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address

[Tom Rini <trini@konsulko.com>]

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!

-- 
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>