[U-Boot-Users] MPC83xx - previous patch to set MBAR

[U-Boot-Users] MPC83xx - previous patch to set MBAR

[Kim Phillips]

On Wed, 1 Aug 2007 15:20:22 -0500
"Keith Mund" <keith.mund@clearcube.com> wrote:

> There was a u-boot 1.1.3 patch for start.S posted on the Freescale LTIB

posts concerning u-boot should go to the u-boot-users list (cc'd).

> site:
> http://www.bitshrine.org/gpp/u-boot-1.1.3-mpc83xx-cpu-4.patch
> 
> The end result simply adds a line to set MBAR to match IMMRBAR.
> 
>         lis     r3, CFG_IMMRBAR at h
>         ori     r3, r3, CFG_IMMRBAR at l
>         stw     r3, IMMRBAR(r4)
> +       mtspr   MBAR, r3
> 
> Are these patches routinely added to the mainstream u-boot code? 
> 
> Is there any reason why this fix is not a good idea?
> 
does setting MBAR really fix anything?

MBAR doesn't live up to its name.  It's a general-purpose scratch
register - the hardware doesn't do anything with it.  So, wrt integrity
within u-boot itself, I see no point/value in setting it.  If some
piece of software needs temporary storage, it can set it and use it as
it wishes, independent of u-boot.

Kim

[U-Boot-Users] MPC83xx - previous patch to set MBAR

[Liu Dave-r63238]

> > The end result simply adds a line to set MBAR to match IMMRBAR.
> > 
> >         lis     r3, CFG_IMMRBAR at h
> >         ori     r3, r3, CFG_IMMRBAR at l
> >         stw     r3, IMMRBAR(r4)
> > +       mtspr   MBAR, r3
> > 
> > Are these patches routinely added to the mainstream u-boot code? 
> > 
> > Is there any reason why this fix is not a good idea?
> > 
> does setting MBAR really fix anything?
> 
> MBAR doesn't live up to its name.  It's a general-purpose scratch
> register - the hardware doesn't do anything with it.  So, wrt 

Kim is right.

MBAR setting is added by two years ago, it is not really fix anything.

I set the MBAR to be easier to use the CodeWarriror. The CodeWarrior
must set the MBAR first, then it will be able to access the IMMR.

Dave

[U-Boot-Users] MPC83xx - previous patch to set MBAR

[Alfred Manheim]

This was to the wrong group.

Thanks for the responses and the clarification. The "needed for CodeWarrior
only" part is what I suspected.

Keith Mund

-----Original Message-----
From: linuxppc-dev-bounces+alfman=austin.rr.com@ozlabs.org
[mailto:linuxppc-dev-bounces+alfman=austin.rr.com at ozlabs.org] On Behalf Of
Liu Dave-r63238
Sent: Wednesday, August 01, 2007 9:15 PM
To: Phillips Kim-R1AAHA; Keith Mund
Cc: linuxppc-dev at ozlabs.org; u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] MPC83xx - previous patch to set MBAR

> > The end result simply adds a line to set MBAR to match IMMRBAR.
> > 
> >         lis     r3, CFG_IMMRBAR at h
> >         ori     r3, r3, CFG_IMMRBAR at l
> >         stw     r3, IMMRBAR(r4)
> > +       mtspr   MBAR, r3
> > 
> > Are these patches routinely added to the mainstream u-boot code? 
> > 
> > Is there any reason why this fix is not a good idea?
> > 
> does setting MBAR really fix anything?
> 
> MBAR doesn't live up to its name.  It's a general-purpose scratch 
> register - the hardware doesn't do anything with it.  So, wrt

Kim is right.

MBAR setting is added by two years ago, it is not really fix anything.

I set the MBAR to be easier to use the CodeWarriror. The CodeWarrior must
set the MBAR first, then it will be able to access the IMMR.

Dave
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[U-Boot-Users] MPC83xx - previous patch to set MBAR

[Scott Wood]

On Thu, Aug 02, 2007 at 10:14:31AM +0800, Liu Dave-r63238 wrote:
> > MBAR doesn't live up to its name.  It's a general-purpose scratch
> > register - the hardware doesn't do anything with it.  So, wrt 

That doesn't mean there isn't value in setting it, so code can easily
find the IMMR without having to parse the device tree.

-Scott

[U-Boot-Users] MPC83xx - previous patch to set MBAR

[Kumar Gala]

On Aug 2, 2007, at 10:28 AM, Scott Wood wrote:

> On Thu, Aug 02, 2007 at 10:14:31AM +0800, Liu Dave-r63238 wrote:
>>> MBAR doesn't live up to its name.  It's a general-purpose scratch
>>> register - the hardware doesn't do anything with it.  So, wrt
>
> That doesn't mean there isn't value in setting it, so code can easily
> find the IMMR without having to parse the device tree.

It could be, but there isn't really any value in doing this since its  
in the device-tree and we have to find it for 85xx, 86xx, and pretty  
much all our parts.

- k