All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] ARM: Start using fdt_high for relocation
Date: Fri, 6 Dec 2013 20:28:04 +0100	[thread overview]
Message-ID: <20131206202804.5cf6fbe4@lilith> (raw)
In-Reply-To: <20131206171813.GA420@bill-the-cat>

Hi Tom,

On Fri, 6 Dec 2013 12:18:13 -0500, Tom Rini <trini@ti.com> wrote:

> On Fri, Dec 06, 2013 at 05:59:37PM +0100, Albert ARIBAUD wrote:
> > Hi Tom,
> > 
> > On Fri, 6 Dec 2013 10:48:50 -0500, Tom Rini <trini@ti.com> wrote:
> > 
> > > Hey all,
> > > 
> > > I've been thinking.  We've had a thread on i.MX platforms about fdt
> > > being overwritten and needing to be moved to another address.  And I've
> > > also had an internal problem about fdt being overwritten.  So, how about
> > > as a rule of thumb we start setting fdt_high (in configs) to
> > > memory-start + 512MiB, as that's the lowmem limit we should always have
> > > available.  This will fix the problem of BSS overwriting the DT, which
> > > is the problem we won't catch in normal bootm/bootz usage.  Thoughts?
> > 
> > Not sure I'm getting the issue clear, and I would like to avoid (me and
> > others) having to switch back and forth between threads. Can you sketch
> > the failure scenario in a couple of lines?
> 
> Sure.  Lets take am335x_evm builds (so Beaglebone Black/White, etc).
> If you start enabling all of the tracing options in the kernel (function
> tracing, graphs, etc), you get an uncompressed kernel and BSS that will
> use up the first ~16MiB of DDR.  We default to placing the DT at about
> 15MiB into memory.  So the kernel runs, clears BSS and eats the DT.
> System now hangs, and depending on debug options set you may or may not
> see anything at all from the kernel.  U-Boot couldn't detect this
> failure because we don't know how big the kernel BSS is, only how big
> the zImage is (and where it is) and how big the fdt is and where it is.
> No overlaps, go ahead and run.

Thanks.

The only issue I have with the RFC is that the +512 MiB value will only
work with targets which have more than 512 MiB DDR, right? But since
you're suggesting this should be set in configs, you are only suggesting
+512 MiB, and any target could actually specify a lower value as long as
it's greater than or eqal to 16 MiB. Correct?

Amicalement,
-- 
Albert.

  reply	other threads:[~2013-12-06 19:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-06 15:48 [U-Boot] [RFC] ARM: Start using fdt_high for relocation Tom Rini
2013-12-06 16:59 ` Albert ARIBAUD
2013-12-06 17:18   ` Tom Rini
2013-12-06 19:28     ` Albert ARIBAUD [this message]
2013-12-06 20:31       ` Tom Rini
2013-12-06 20:44         ` Stephen Warren
2013-12-06 21:04           ` Tom Rini
2013-12-06 23:05             ` Stephen Warren
2013-12-06 20:25 ` Wolfgang Denk

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=20131206202804.5cf6fbe4@lilith \
    --to=albert.u.boot@aribaud.net \
    --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.