ppc .gitignore update
PATCH 1/1 ppc .gitignore update
arch/ppc/.gitignore shouldn't exclude arch/ppc/boot/include
---
arch/ppc/boot/.gitignore new file +1 -0
@@ -0,0 +1 @@ +!include
arch/ppc/boot/.gitignore 2007-08-01 15:18:33.000000000 +0200 line 1
Quoted 9 lines · Adrian Bunk
arch/ppc/.gitignoreshouldn't excludearch/ppc/boot/includeSigned-off-by Adrian Bunk <[email protected]>---
arch/ppc/boot/.gitignore 2007-08-01 15:18:33.000000000 +0200 renamed from dev/null 2006-09-19 00:45:31.000000000 +0200 +1
-0@@ -0,0 +1 @@ +!include
I don't think this is the best way to go about it; rather, arch/ppc/.gitignore should be made more specific like so:
arch/ppc/.gitignore +1 -1
@@ -1 +1 @@ -include +/include
Quoted 6 lines
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Signature · 4 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [email protected] (403) 399-0195
Quoted 19 lines · Grant Likely
arch/ppc/boot/.gitignore 2007-08-01 15:18:33.000000000 +0200 line 1
Quoted 9 lines · Adrian Bunk
arch/ppc/.gitignoreshouldn't excludearch/ppc/boot/includeSigned-off-by Adrian Bunk <[email protected]>---
arch/ppc/boot/.gitignore 2007-08-01 15:18:33.000000000 +0200 renamed from dev/null 2006-09-19 00:45:31.000000000 +0200 +1
-0@@ -0,0 +1 @@ +!includeI don't think this is the best way to go about it; rather,
arch/ppc/.gitignoreshould be made more specific like so:arch/ppc/.gitignore +0
-0
arch/ppc/.gitignore line 1
Quoted 2 lines
arch/ppc/.gitignore +1
-1@@ -1 +1 @@ -include +/include
Thanks, that's obviously better than my patch.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedMPC83xx - previous patch to set MBAR
In reply to Grant LikelyThere was a u-boot 1.1.3 patch for start.S posted on the Freescale LTIB 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@h
ori r3, r3, CFG_IMMRBAR@l
stw r3, IMMRBAR(r4)
+ mtspr MBAR, r3Are these patches routinely added to the mainstream u-boot code?=20
Is there any reason why this fix is not a good idea?
Re: MPC83xx - previous patch to set MBAR
Quoted 1 line · On Wed, 1 Aug 2007 15:20:22 -0500 "Keith Mund" <[email protected]> wrote:
There was a u-boot 1.1.3 patch for
start.Sposted on the Freescale LTIB
posts concerning u-boot should go to the u-boot-users list (cc'd).
Quoted 5 lines
site:
http://www.bitshrine.org/gpp/u-boot-1.1.3-mpc83xx-cpu-4.patchThe end result simply adds a line to set MBAR to match IMMRBAR.
Quoted 9 lines
lis r3, CFG_IMMRBAR at h ori r3, r3, CFG_IMMRBAR at l stw r3, IMMRBAR(r4) + mtspr MBAR, r3Are 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
RE: [U-Boot-Users] MPC83xx - previous patch to set MBAR
Quoted 7 lines
Quoted 7 lines
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
Quoted 8 lines
Quoted 4 lines
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
RE: [U-Boot-Users] MPC83xx - previous patch to set MBAR
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: [email protected] [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
Quoted 7 lines
Quoted 7 lines
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
Quoted 8 lines
Quoted 4 lines
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
Re: [U-Boot-Users] MPC83xx - previous patch to set MBAR
In reply to Liu Dave-r63238Quoted 2 lines · On Thu, Aug 02, 2007 at 10:14:31AM +0800, Liu Dave-r63238 wrote:
Quoted 2 lines
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
Re: [U-Boot-Users] MPC83xx - previous patch to set MBAR
Quoted 6 lines · Scott Wood
Quoted 2 lines · On Thu, Aug 02, 2007 at 10:14:31AM +0800, Liu Dave-r63238 wrote:
Quoted 2 lines
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