public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jeroen Hofstee <jeroen@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] AM335x not working anymore
Date: Tue, 16 Sep 2014 16:11:17 +0200	[thread overview]
Message-ID: <1410876677.26050.21.camel@yellow> (raw)
In-Reply-To: <20140916135637.GG25506@bill-the-cat>

Hello Hannes, Tom,

On di, 2014-09-16 at 09:56 -0400, Tom Rini wrote:
> On Tue, Sep 16, 2014 at 02:17:01PM +0200, Hannes Petermaier wrote:
> 
> > Hi,
> > 
> > i've just pulled newest u-boot and tried it on my custom AM335x
> > board without success. It hangs after (successful) running init_s
> > function.
> > 
> > ....
> > Enable clock module - 44e0001c
> > Enable clock module - 44e000d0
> > Enable clock module - 44e00028
> > 
> > is the last debug output.
> > After some time the watchdog is doing his job and restarts again.
> > 
> > Okay ... thinking maybe something had become incompatible with my
> > customization ... so let's try the beaglebone board.
> > Same behaviour :-(
> > 
> > I debugged around and found finally this commit, which breaks the support:
> > /
> > //commit id: f0c3a6c4ad09210d5d4aeafe87685ee75e5683d6//
> > //
> > //    ARM: SPL: do not set gd again//
> > ////
> > //    Just before calling board_init_f, crt0.S has already//
> > //    reserved space for the initial gd on the stack. There//
> > //    should be no need to allocate it again.//
> > ////
> > //    cc: Albert ARIBAUD <albert.u.boot@aribaud.net>//
> > //    Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>/
> > 
> > I have reverted this commit in my branch and everything works fine.
> > Finally i have to admit, that i do not fully understand whats going
> > on there in detail.
> > 
> > What i can see, is that there live more than one instance of the
> > "gd". One is setup in arch/arm/lib/cpu/armv7/lowlevel_init.S,
> > another one is setup in arch/arm/lib/crt0.S.
> > Within the "gd-ptr" is loaded to &gdata (gdata __attribute__
> > ((section(".data")))
> > 
> > I am a bit confused all about this :-)
> 
> I just finished bisecting down to this being a problem commit as well.
> As far as I can see, the commit in question doesn't make sense.  Or
> perhaps rather, the comments in crt0.S aren't quite right in the SPL
> case where we don't place the initial gd on the stack, it's in the .data
> section.
> 

As far as I can tell there are two gdata's is the SPL case.
One on the stack and one in gdata. Can't the later not be
removed, so we end up with a single gd init in crt0.S?
Before this patch the code switches back and forth between
the two, which is at least a bit weird.

I will have a closer look at the call path, especially why
it used to work...

Regards,
Jeroen

  reply	other threads:[~2014-09-16 14:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16 12:17 [U-Boot] AM335x not working anymore Hannes Petermaier
2014-09-16 13:56 ` Tom Rini
2014-09-16 14:11   ` Jeroen Hofstee [this message]
2014-09-16 18:36     ` Jeroen Hofstee

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=1410876677.26050.21.camel@yellow \
    --to=jeroen@myspectrum.nl \
    --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