public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marcel Ziswiler <marcel@ziswiler.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: tegra: Use mem size from MC in combination with get_ram_size()
Date: Fri, 03 Oct 2014 18:36:01 +0200	[thread overview]
Message-ID: <1412354161.2531.61.camel@localhost.localdomain> (raw)
In-Reply-To: <542EC875.5080808@wwwdotorg.org>

On Fri, 2014-10-03 at 10:01 -0600, Stephen Warren wrote:
> Recall that on many systems, U-Boot executes from ROM initially and is 
> tasked with initializing the RAM. On all current Tegra ports, U-Boot 
> always executes from RAM, and the boot ROM has already fully initialized 
> RAM. That's quite a different semantic.

Understood.

> If there were any stuck address lines, the chances of U-Boot actually 
> executing the code far enough for the RAM size test to succeed vs fail 
> is pretty minimal, since U-Boot is executing from RAM.

Agreed.

> To be honest, I would rather that U-Boot explicitly *not* second guess 
> what the user puts into the BCT. That will make debugging other problems 
> much harder.
> 
> If the user puts the wrong BCT into flash, I want something to fail hard 
> so they realize there's a problem and fix it early. If U-Boot just 
> ignores what the user programmed, and silently fixes it, the user may 
> well not know about the problem, and hence leave it unfixed for longer, 
> which will only make it far more expensive to fix.

Unfortunately it does not do that, failing hard I mean. I can e.g.
happily flash various BCTs onto various boards of ours and some will
boot just fine even into Linux where certainly things start to go awry.
We did have real cases where customers actually did exactly that and
then were on lengthy support cases until we figured this out.

But if you are absolutely against calling get_ram_size() on the Tegras
which I think it at least should not hurt I can certainly re-submit with
that removed. But at the end for our customers we will have to put such
a check into place again.

      reply	other threads:[~2014-10-03 16:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <b85c662e32e00fa58aa19c2e2b96450976c6023a.1412262683.git.marcel@ziswiler.com>
2014-10-02 15:38 ` [U-Boot] [PATCH] ARM: tegra: Use mem size from MC in combination with get_ram_size() Marcel Ziswiler
2014-10-02 23:29   ` Stephen Warren
2014-10-03  0:18     ` Marcel Ziswiler
2014-10-03 16:01       ` Stephen Warren
2014-10-03 16:36         ` Marcel Ziswiler [this message]

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=1412354161.2531.61.camel@localhost.localdomain \
    --to=marcel@ziswiler.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox