All of lore.kernel.org
 help / color / mirror / Atom feed
From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] RFC: convert MPC8536DS to use generic board
Date: Wed, 30 Apr 2014 11:21:06 -0700	[thread overview]
Message-ID: <53613F12.1090205@freescale.com> (raw)
In-Reply-To: <1398813178.24575.111.camel@snotra.buserror.net>

On 04/29/2014 04:12 PM, Scott Wood wrote:
> On Sat, 2014-04-26 at 09:36 -0700, York Sun wrote:
>> On 04/26/2014 02:22 AM, Wolfgang Denk wrote:
>>>> +#ifdef CONFIG_PPC
>>>> +	gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
>>>> +	__asm__ __volatile__("":::"memory");
>>>> +#endif
>>>
>>> Again, this is a global change.  Why is this now needed?
>>>
>>
>> It has been this way for powerpc. Do we have an alternative?
> 
> gd is already initialized at the beginning of board_init_f().  If PPC
> needs gd before board_init_f(), then add PPC (or some other relevant
> symbol if it's not all PPC) to the #ifndef X86.  In any case, there
> should be no need to add yet another initialization of gd.
> cpu_init_early_f() already initialized and cleared it.  Also, if gd
> really is needed before board_init_f(), then we probably need to skip
> clearing gd in board_init_f().

For variant PPC part, gd is initialized in cpu_init_f or cpu_init_early_f. It
shouldn't be overwritten by "gd = &data;" in board_init_f.

gd is not cleared in board_init_f for the SoCs we care. But gd may be missed for
74xx and other old SoCs if not set in board_init_f.

> 
> As for the memory clobber, if nobody can come up with a reason for its
> existence, then just let it go away.  At the very least, don't copy the
> barrier without also copying the comment that went with it -- but I'm
> really not seeing what it's trying to order.  gd is a register, not
> memory.  Maybe some versions of GCC had a bug that the clobber worked
> around -- does it apply to any recent GCC?  In any case, for mpc85xx, gd
> was previously initalized as discussed above.
> 

We can probably remove the memory boundary. I wouldn't know if any legacy
compiler will have any issue though.

York

      reply	other threads:[~2014-04-30 18:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-26  1:10 [U-Boot] [RFC] RFC: convert MPC8536DS to use generic board York Sun
2014-04-26  9:22 ` Wolfgang Denk
2014-04-26 16:36   ` York Sun
2014-04-26 19:36     ` Wolfgang Denk
2014-04-29 23:18       ` Scott Wood
2014-04-26 20:18     ` Simon Glass
2014-04-29 23:12     ` Scott Wood
2014-04-30 18:21       ` York Sun [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=53613F12.1090205@freescale.com \
    --to=yorksun@freescale.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.