All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Longchamp <valentin.longchamp@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [GENERIC_BOARD] env problems before relocation with ppc8360
Date: Tue, 26 Aug 2014 17:17:55 +0200	[thread overview]
Message-ID: <53FCA523.4040301@keymile.com> (raw)
In-Reply-To: <1408981371-29932-1-git-send-email-valentin.longchamp@keymile.com>

Hello,

Here is the outcome of my debug session today:

On 08/25/2014 05:42 PM, Valentin Longchamp wrote:
> Hello,
> 
> I am currently porting all the Keymile boards to CONFIG_SYS_GENERIC_BOARD.
> On u-boot 2014.10-rc1 I have all of them working quite well (at least booting
> and showing no obvious problem), except for our boards using a MPC8360
> from Freescale (kmcoge5ne and kmeter1, both using km8360.h as config) that do
> not boot at all.
> 
> I have found out that u-boot crashes as soon as a getenv function call happens
> before relocation. When I disable them, u-boot seems to work fine. I am
> currently trying to debug further, but it's not clear yet exactly what causes
> the crash.

So the problem is that for an unknown reason, the gd->flags are not correct and
getenv actually calls hsearch_h to look for the desired env variable. This fails
before relocation (due to the small stack ?).

If I replace the board_f getenv_ulong calls in board_f.c with my getenv_f_ulong
function that explicitely calls getenv_f the board boots up nicely.

Now the question is, why are my gd->flags not correct/corrupted ? Has someone
already seen something similar ? I unfortunateley cannot access gd easily with
the BDI, since it is located in the INIT_RAM which is a data cache, for which I
have no LAW configured (could work on that).

> 
> We also have quite a few MPC8321 boards (for instance tuxx1.h or suvd3.h) and
> there the problem is not present, while the environment is also in the NOR
> flash as on km8360 and their core also a e300 (so their initialization is VERY
> similar).

I have checked and there it's clearly getenv_f that gets called by getenv before
relocation. That's why no problem is seen there.

Valentin

  reply	other threads:[~2014-08-26 15:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-25 15:42 [U-Boot] [GENERIC_BOARD] env problems before relocation with ppc8360 Valentin Longchamp
2014-08-26 15:17 ` Valentin Longchamp [this message]
2014-09-28  4:27   ` Simon Glass
2014-09-30  7:03     ` Valentin Longchamp
2014-10-01 15:27       ` Simon Glass
2014-10-01 15:37         ` York Sun

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=53FCA523.4040301@keymile.com \
    --to=valentin.longchamp@keymile.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.