All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address
Date: Thu, 28 Dec 2017 14:24:08 -0500	[thread overview]
Message-ID: <20171228192408.GD14739@bill-the-cat> (raw)
In-Reply-To: <20171228192105.GD11273@ethiopia.woodsts.org>

On Thu, Dec 28, 2017 at 01:21:05PM -0600, Derald D. Woods wrote:
> On Thu, Dec 28, 2017 at 01:43:43PM -0500, Tom Rini wrote:
> > On Thu, Dec 28, 2017 at 11:48:29AM -0600, Derald D. Woods wrote:
> > > On Thu, Dec 28, 2017 at 10:37:18AM -0500, Tom Rini wrote:
> > > > On Thu, Dec 28, 2017 at 01:25:43AM -0600, Derald D. Woods wrote:
> > > > 
> > > > > This commit keeps the 'fdtaddr' as provided by DEFAULT_LINUX_BOOT_ENV.
> > > > > 
> > > > > Signed-off-by: Derald D. Woods <woods.technical@gmail.com>
> > > > > ---
> > > > >  include/configs/omap3_evm.h | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> > > > > index 629d60b961..d95ccdf035 100644
> > > > > --- a/include/configs/omap3_evm.h
> > > > > +++ b/include/configs/omap3_evm.h
> > > > > @@ -127,6 +127,7 @@
> > > > >  	"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > > > >  	"mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
> > > > >  	"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
> > > > > +	"fdt_high=0xffffffff\0" \
> > > > >  	"bootenv=uEnv.txt\0" \
> > > > >  	"optargs=\0" \
> > > > >  	"mmcdev=0\0" \
> > > > 
> > > > What's the problem this solves, and how much memory is on the system in
> > > > question?  bootm_size should be ensuring we never relocate it outside of
> > > > the first 256MB of memory.  Thanks!
> > > > 
> > > 
> > > The logic within "common/image-fdt.c" lead me down this path. The
> > > addition of this fairly common environment variable allowed my
> > > OMAP34XX board to boot the kernel without an appended devicetree.
> > > When I use the variable to trigger 'disable_relocation', as the code
> > > indicates, the kernel boot behavior is what I expect. I spent a few
> > > hours following the code path to a single line edition that works.
> > > 
> > > 
> > > Without 'fdt_high'
> > > ==================
> > > 
> > > U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52)
> > > Trying to boot from MMC1
> > > reading u-boot.img
> > > reading u-boot.img
> > > 
> > > 
> > > U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 11:16:52 -0600)
> > > 
> > > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> > > Model: TI OMAP35XX EVM (TMDSEVM3530)
> > > OMAP3 EVM board + LPDDR/NAND
> > > I2C:   ready
> > > DRAM:  256 MiB
> > > NAND:  256 MiB
> > > MMC:   OMAP SD/MMC: 0
> > > Read back SMSC id 0x92200000
> > > OMAP die ID: 265a002400000000040365fa1801b01f
> > > Net:   smc911x-0
> > > starting USB...
> > > USB0:   USB EHCI 1.00
> > > scanning bus 0 for devices... 1 USB Device(s) found
> > > Hit any key to stop autoboot:  0 
> > > switch to partitions #0, OK
> > > mmc0 is current device
> > > Scanning mmc 0:1...
> > > switch to partitions #0, OK
> > > mmc0 is current device
> > > ** Unable to read file uEnv.txt **
> > > reading zImage
> > > 4637344 bytes read in 407 ms (10.9 MiB/s)
> > > reading omap3-evm.dtb
> > > 62832 bytes read in 10 ms (6 MiB/s)
> > > Booting zImage from mmc ...
> > > *  fdt: cmdline image address = 0x88000000
> > > ## Checking for 'FDT'/'FDT Image' at 88000000
> > > *  fdt: raw FDT blob
> > > ## Flattened Device Tree blob at 88000000
> > >    Booting using the fdt blob at 0x88000000
> > >    of_flat_tree at 0x88000000 size 0x0000f570
> > > ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570])
> > >    Loading Device Tree to 8ffed000, end 8ffff56f ... OK
> > > 
> > > Starting kernel ...
> > > 
> > > [HANG]
> > > 
> > > 
> > > Make note of the "of_flat_tree" and "Loading Device Tree" lines.
> > 
> > Ah, hmmm.  Can you please try setting bootm_size, as an experiment, to
> > 0x0a000000 ?  I wonder if, since you have 256MB of memory we're not
> > putting the DTB into where U-Boot is and we stomp on it a bit, causing
> > Linux to boot, see an invalid DTB and not have a console available to
> > tell us.  Thanks!
> > 
> 
> 
> That seemed to do it.

Ah, good!

> ---8<----------------------------------------------------------------
> 
> OMAP3_EVM # echo $bootm_size
> 0x0a000000
> OMAP3_EVM # reset
> resetting ...
> O
> U-Boot SPL 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42)
> Trying to boot from MMC1
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2018.01-rc2-00028-gaf9da945cd-dirty (Dec 28 2017 - 13:03:42 -0600)
> 
> OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
> Model: TI OMAP35XX EVM (TMDSEVM3530)
> OMAP3 EVM board + LPDDR/NAND
> I2C:   ready
> DRAM:  256 MiB
> NAND:  256 MiB
> MMC:   OMAP SD/MMC: 0
> Read back SMSC id 0x92200000
> OMAP die ID: 265a002400000000040365fa1801b01f
> Net:   smc911x-0
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> switch to partitions #0, OK
> mmc0 is current device
> ** Unable to read file uEnv.txt **
> reading zImage
> 4637344 bytes read in 407 ms (10.9 MiB/s)
> reading omap3-evm.dtb
> 62832 bytes read in 10 ms (6 MiB/s)
> Booting zImage from mmc ...
> *  fdt: cmdline image address = 0x88000000
> ## Checking for 'FDT'/'FDT Image' at 88000000
> *  fdt: raw FDT blob
> ## Flattened Device Tree blob at 88000000
>    Booting using the fdt blob at 0x88000000
>    of_flat_tree at 0x88000000 size 0x0000f570
> ## device tree at 88000000 ... 8800f56f (len=75120 [0x12570])
>    Loading Device Tree to 89fed000, end 89fff56f ... OK
> 
> Starting kernel ...
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.15.0-rc5-1-gdc7de7cf5f08 (ddwoods 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!

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

  reply	other threads:[~2017-12-28 19:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28  7:25 [U-Boot] [PATCH] ARM: omap3: evm: Do not relocate FDT address Derald D. Woods
2017-12-28 15:37 ` Tom Rini
2017-12-28 17:48   ` Derald D. Woods
2017-12-28 18:43     ` Tom Rini
2017-12-28 19:21       ` Derald D. Woods
2017-12-28 19:24         ` Tom Rini [this message]
2017-12-28 19:45           ` Derald D. Woods
2017-12-28 23:17           ` Derald D. Woods
2018-01-01 13:29             ` Tom Rini
2018-01-01 18:38               ` Derald Woods
2018-01-02  0:47 ` [U-Boot] " Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171228192408.GD14739@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.