* [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
@ 2010-06-16 6:58 Micha Nelissen
2010-06-16 7:29 ` Aggrwal Poonam-B10812
2010-06-16 15:01 ` Kumar Gala
0 siblings, 2 replies; 12+ messages in thread
From: Micha Nelissen @ 2010-06-16 6:58 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 214 bytes --]
Hi,
Attached is a patch to fix large physical address support for the e500v2
core. When >4GB addresses are used, the MAS7 register needs to be valid
for tlbsx instruction usage.
Please review and apply.
Micha
[-- Attachment #2: en-mas7-update.diff --]
[-- Type: text/plain, Size: 1328 bytes --]
diff -u -ru linux-2.6.34/arch/powerpc/include/asm/reg.h linux-2.6.34-fix/arch/powerpc/include/asm/reg.h
--- linux-2.6.34/arch/powerpc/include/asm/reg.h 2010-05-16 23:17:36.000000000 +0200
+++ linux-2.6.34-fix/arch/powerpc/include/asm/reg.h 2010-06-16 08:43:28.000000000 +0200
@@ -272,6 +272,7 @@
#define HID0_DAPUEN (1<<8) /* Debug APU enable */
#define HID0_SGE (1<<7) /* Store Gathering Enable */
#define HID0_SIED (1<<7) /* Serial Instr. Execution [Disable] */
+#define HID0_EN_MAS7_UPDATE (1<<7) /* tlbre/tlbsx update MAS7 - e500v2 */
#define HID0_DCFA (1<<6) /* Data Cache Flush Assist */
#define HID0_LRSTK (1<<4) /* Link register stack - 745x */
#define HID0_BTIC (1<<5) /* Branch Target Instr Cache Enable */
diff -u -ru linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S
--- linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S 2010-05-16 23:17:36.000000000 +0200
+++ linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S 2010-06-16 08:45:10.000000000 +0200
@@ -328,6 +328,13 @@
oris r2,r2,HID0_DOZE@h
mtspr SPRN_HID0, r2
#endif
+#ifdef CONFIG_PTE_64BIT
+BEGIN_MMU_FTR_SECTION
+ mfspr r2,SPRN_HID0
+ ori r2,r2,HID0_EN_MAS7_UPDATE@l
+ mtspr SPRN_HID0, r2
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
+#endif
#if !defined(CONFIG_BDI_SWITCH)
/*
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 6:58 [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE] Micha Nelissen
@ 2010-06-16 7:29 ` Aggrwal Poonam-B10812
2010-06-16 9:24 ` Micha Nelissen
2010-06-16 15:01 ` Kumar Gala
1 sibling, 1 reply; 12+ messages in thread
From: Aggrwal Poonam-B10812 @ 2010-06-16 7:29 UTC (permalink / raw)
To: Micha Nelissen, linuxppc-dev
> -----Original Message-----
> From:
linuxppc-dev-bounces+poonam.aggrwal=3Dfreescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
Micha
> Nelissen
> Sent: Wednesday, June 16, 2010 12:29 PM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
>=20
> Hi,
>=20
> Attached is a patch to fix large physical address support for the
e500v2
> core. When >4GB addresses are used, the MAS7 register needs to be
valid
> for tlbsx instruction usage.
>=20
> Please review and apply.
[Aggrwal Poonam] This is already being done by u-boot, should linux set
it again?
>=20
> Micha
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 7:29 ` Aggrwal Poonam-B10812
@ 2010-06-16 9:24 ` Micha Nelissen
2010-06-16 10:49 ` Aggrwal Poonam-B10812
2010-06-16 14:23 ` Timur Tabi
0 siblings, 2 replies; 12+ messages in thread
From: Micha Nelissen @ 2010-06-16 9:24 UTC (permalink / raw)
To: Aggrwal Poonam-B10812, linuxppc-dev
Aggrwal Poonam-B10812 wrote:
>> Attached is a patch to fix large physical address support for the
>
> This is already being done by u-boot, should linux set it again?
Yikes! Took me 5 min to reformat your email.
Our version of U-boot does not but it's not latest greatest.
IMHO:
1) Linux should not be dependent on U-boot or any other bootloader, or
at least as possible
2) U-boot cannot (and does not want to) know whether Linux is going to
use large physical addresses.
Regards,
Micha
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 9:24 ` Micha Nelissen
@ 2010-06-16 10:49 ` Aggrwal Poonam-B10812
2010-06-16 11:34 ` Micha Nelissen
2010-06-16 14:23 ` Timur Tabi
1 sibling, 1 reply; 12+ messages in thread
From: Aggrwal Poonam-B10812 @ 2010-06-16 10:49 UTC (permalink / raw)
To: Micha Nelissen, linuxppc-dev
> -----Original Message-----
> From: Micha Nelissen [mailto:micha@neli.hopto.org]
> Sent: Wednesday, June 16, 2010 2:55 PM
> To: Aggrwal Poonam-B10812; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
>=20
> Aggrwal Poonam-B10812 wrote:
> >> Attached is a patch to fix large physical address support for the
> >
> > This is already being done by u-boot, should linux set it again?
>=20
> Yikes! Took me 5 min to reformat your email.
>=20
> Our version of U-boot does not but it's not latest greatest.
>=20
> IMHO:
> 1) Linux should not be dependent on U-boot or any other bootloader, or
at
> least as possible
> 2) U-boot cannot (and does not want to) know whether Linux is going to
> use large physical addresses.
>=20
Not sure of other platforms but on 85xx platforms on which I am
currently working u-boot does LAW and eLBC programming for 36bit
physical address. Hence=20
possibly u-boot has to made aware of large physical address space.
Please correct me if I am wrong.
> Regards,
>=20
> Micha
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 10:49 ` Aggrwal Poonam-B10812
@ 2010-06-16 11:34 ` Micha Nelissen
2010-06-16 11:38 ` Aggrwal Poonam-B10812
0 siblings, 1 reply; 12+ messages in thread
From: Micha Nelissen @ 2010-06-16 11:34 UTC (permalink / raw)
To: Aggrwal Poonam-B10812; +Cc: linuxppc-dev
Aggrwal Poonam-B10812 wrote:
> Not sure of other platforms but on 85xx platforms on which I am
> currently working u-boot does LAW and eLBC programming for 36bit
> physical address. Hence
> possibly u-boot has to made aware of large physical address space.
> Please correct me if I am wrong.
Yes, I can understand this for SDRAM and local flash interface. For
RapidIO we have (local) patches to pass the law address range in the
dtb. Perhaps also for PCI-express this might be done; U-boot has nothing
to with these high speed interfaces (in our case at least).
Micha
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 11:34 ` Micha Nelissen
@ 2010-06-16 11:38 ` Aggrwal Poonam-B10812
0 siblings, 0 replies; 12+ messages in thread
From: Aggrwal Poonam-B10812 @ 2010-06-16 11:38 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linuxppc-dev
> -----Original Message-----
> From: Micha Nelissen [mailto:micha@neli.hopto.org]
> Sent: Wednesday, June 16, 2010 5:04 PM
> To: Aggrwal Poonam-B10812
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
>=20
> Aggrwal Poonam-B10812 wrote:
> > Not sure of other platforms but on 85xx platforms on which I am
> > currently working u-boot does LAW and eLBC programming for 36bit
> > physical address. Hence possibly u-boot has to made aware of large
> > physical address space.
> > Please correct me if I am wrong.
>=20
> Yes, I can understand this for SDRAM and local flash interface. For
> RapidIO we have (local) patches to pass the law address range in the
dtb.
> Perhaps also for PCI-express this might be done; U-boot has nothing to
> with these high speed interfaces (in our case at least).
You are correct , for PCIe and SRIO kinds of interfaces Linux reprograms
the address windows.
Thanks
Poonam
>=20
> Micha
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 9:24 ` Micha Nelissen
2010-06-16 10:49 ` Aggrwal Poonam-B10812
@ 2010-06-16 14:23 ` Timur Tabi
2010-06-16 14:52 ` Micha Nelissen
2010-06-22 22:39 ` Scott Wood
1 sibling, 2 replies; 12+ messages in thread
From: Timur Tabi @ 2010-06-16 14:23 UTC (permalink / raw)
To: Micha Nelissen; +Cc: Aggrwal Poonam-B10812, linuxppc-dev
On Wed, Jun 16, 2010 at 4:24 AM, Micha Nelissen <micha@neli.hopto.org> wrote:
> IMHO:
> 1) Linux should not be dependent on U-boot or any other bootloader, or at
> least as possible
> 2) U-boot cannot (and does not want to) know whether Linux is going to use
> large physical addresses.
To quote The Dude: "Yeah, well, you know, that's just, like, your opinion, man."
I'm sorry, but Linux does depend on the boot loader, and U-Boot does
need to know whether Linux is going to use 36-bit addressing. That's
just the way it works. Linux patches that repeat what U-Boot already
does just so that you don't need to update your U-boot are going to be
rejected.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 14:23 ` Timur Tabi
@ 2010-06-16 14:52 ` Micha Nelissen
2010-06-22 22:39 ` Scott Wood
1 sibling, 0 replies; 12+ messages in thread
From: Micha Nelissen @ 2010-06-16 14:52 UTC (permalink / raw)
To: Timur Tabi, linuxppc-dev
Timur Tabi wrote:
> I'm sorry, but Linux does depend on the boot loader, and U-Boot does
> need to know whether Linux is going to use 36-bit addressing.
Why?
> That's
> just the way it works.
What a great design philosophy!
> Linux patches that repeat what U-Boot already
> does just so that you don't need to update your U-boot are going to be
> rejected.
Who said anything about not wanting/needing to upgrade U-boot?
Micha
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 14:23 ` Timur Tabi
2010-06-16 14:52 ` Micha Nelissen
@ 2010-06-22 22:39 ` Scott Wood
1 sibling, 0 replies; 12+ messages in thread
From: Scott Wood @ 2010-06-22 22:39 UTC (permalink / raw)
To: Timur Tabi; +Cc: Aggrwal Poonam-B10812, linuxppc-dev
On Wed, Jun 16, 2010 at 09:23:38AM -0500, Timur Tabi wrote:
> I'm sorry, but Linux does depend on the boot loader,
In some ways, but we try not to do so too gratuitously.
> and U-Boot does need to know whether Linux is going to use 36-bit
> addressing.
U-Boot knows whether it puts things over 4GiB. If Linux is going to change
the LAWs in what was previously a 32-bit physical system, it doesn't seem
unreasonable for it to set EN_MAS7_UPDATE.
> That's just the way it works. Linux patches that repeat what U-Boot
> already does just so that you don't need to update your U-boot are going
> to be rejected.
Why'd we do cuboot then? Or any other compatibility measure (e.g. working
with old device trees) or board-specific non-OS-specific init thing which
might be better off done in firmware (e.g. setting up I/O pins to match
what's on the board)?
Firmware is harder to upgrade than a kernel, sometimes it's not worth it.
Especially if new firmware won't boot old OSes, which could be the case with
EN_MAS7_UPDATE on a non-36-bit-aware OS (compatibility is the reason that
bit exists).
-Scott
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 6:58 [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE] Micha Nelissen
2010-06-16 7:29 ` Aggrwal Poonam-B10812
@ 2010-06-16 15:01 ` Kumar Gala
2010-06-16 15:12 ` Micha Nelissen
1 sibling, 1 reply; 12+ messages in thread
From: Kumar Gala @ 2010-06-16 15:01 UTC (permalink / raw)
To: Micha Nelissen; +Cc: linuxppc-dev
On Jun 16, 2010, at 1:58 AM, Micha Nelissen wrote:
> Hi,
>=20
> Attached is a patch to fix large physical address support for the =
e500v2 core. When >4GB addresses are used, the MAS7 register needs to be =
valid for tlbsx instruction usage.
>=20
> Please review and apply.
>=20
> Micha
> diff -u -ru linux-2.6.34/arch/powerpc/include/asm/reg.h =
linux-2.6.34-fix/arch/powerpc/include/asm/reg.h
> --- linux-2.6.34/arch/powerpc/include/asm/reg.h 2010-05-16 =
23:17:36.000000000 +0200
> +++ linux-2.6.34-fix/arch/powerpc/include/asm/reg.h 2010-06-16 =
08:43:28.000000000 +0200
> @@ -272,6 +272,7 @@
> #define HID0_DAPUEN (1<<8) /* Debug APU enable */
> #define HID0_SGE (1<<7) /* Store Gathering Enable */
> #define HID0_SIED (1<<7) /* Serial Instr. Execution =
[Disable] */
> +#define HID0_EN_MAS7_UPDATE (1<<7) /* tlbre/tlbsx update MAS7 - =
e500v2 */
> #define HID0_DCFA (1<<6) /* Data Cache Flush Assist */
> #define HID0_LRSTK (1<<4) /* Link register stack - 745x */
> #define HID0_BTIC (1<<5) /* Branch Target Instr Cache =
Enable */
> diff -u -ru linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S =
linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S
> --- linux-2.6.34/arch/powerpc/kernel/head_fsl_booke.S 2010-05-16 =
23:17:36.000000000 +0200
> +++ linux-2.6.34-fix/arch/powerpc/kernel/head_fsl_booke.S =
2010-06-16 08:45:10.000000000 +0200
> @@ -328,6 +328,13 @@
> oris r2,r2,HID0_DOZE@h
> mtspr SPRN_HID0, r2
> #endif
> +#ifdef CONFIG_PTE_64BIT
> +BEGIN_MMU_FTR_SECTION
> + mfspr r2,SPRN_HID0
> + ori r2,r2,HID0_EN_MAS7_UPDATE@l
> + mtspr SPRN_HID0, r2
> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
> +#endif
If you want to do this, do it in:
arch/powerpc/kernel/cpu_setup_fsl_booke.S
- k=
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 15:01 ` Kumar Gala
@ 2010-06-16 15:12 ` Micha Nelissen
2010-06-16 15:18 ` Micha Nelissen
0 siblings, 1 reply; 12+ messages in thread
From: Micha Nelissen @ 2010-06-16 15:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
Kumar Gala wrote:
>> +BEGIN_MMU_FTR_SECTION
>> + mfspr r2,SPRN_HID0
>> + ori r2,r2,HID0_EN_MAS7_UPDATE@l
>> + mtspr SPRN_HID0, r2
>> +END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
>> +#endif
>
> If you want to do this, do it in:
>
> arch/powerpc/kernel/cpu_setup_fsl_booke.S
Do you mean like attached? I had to change the order of the '_GLOBAL'
definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is
e500v2 only.
Thanks,
Micha
[-- Attachment #2: en-mas7-update-v2.diff --]
[-- Type: text/plain, Size: 1326 bytes --]
Index: linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S
===================================================================
--- linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (revision 2871)
+++ linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (working copy)
@@ -57,8 +57,14 @@
ori r3,r3,HID0_DAPUEN@l
mtspr SPRN_HID0,r3
b __setup_e200_ivors
+_GLOBAL(__setup_cpu_e500v2)
+#ifdef CONFIG_PTE_64BIT
+ /* enable mas7 register for tlbre/tlbsx */
+ mfspr r2,SPRN_HID0
+ ori r2,r2,HID0_EN_MAS7_UPDATE@l
+ mtspr SPRN_HID0,r2
+#endif
_GLOBAL(__setup_cpu_e500v1)
-_GLOBAL(__setup_cpu_e500v2)
mflr r4
bl __e500_icache_setup
bl __e500_dcache_setup
Index: linux/arch/powerpc/include/asm/reg.h
===================================================================
--- linux/arch/powerpc/include/asm/reg.h (revision 2871)
+++ linux/arch/powerpc/include/asm/reg.h (working copy)
@@ -276,6 +276,7 @@
#define HID0_DAPUEN (1<<8) /* Debug APU enable */
#define HID0_SGE (1<<7) /* Store Gathering Enable */
#define HID0_SIED (1<<7) /* Serial Instr. Execution [Disable] */
+#define HID0_EN_MAS7_UPDATE (1<<7) /* Enable MAS7 reg for tlbre/tlbsx */
#define HID0_DCFA (1<<6) /* Data Cache Flush Assist */
#define HID0_LRSTK (1<<4) /* Link register stack - 745x */
#define HID0_BTIC (1<<5) /* Branch Target Instr Cache Enable */
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]
2010-06-16 15:12 ` Micha Nelissen
@ 2010-06-16 15:18 ` Micha Nelissen
0 siblings, 0 replies; 12+ messages in thread
From: Micha Nelissen @ 2010-06-16 15:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 236 bytes --]
Micha Nelissen wrote:
> Do you mean like attached? I had to change the order of the '_GLOBAL'
> definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is
> e500v2 only.
Hmm, maybe need to use r0 or r3 instead of r2?
Micha
[-- Attachment #2: en-mas7-update-v2.diff --]
[-- Type: text/plain, Size: 1326 bytes --]
Index: linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S
===================================================================
--- linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (revision 2871)
+++ linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S (working copy)
@@ -57,8 +57,14 @@
ori r3,r3,HID0_DAPUEN@l
mtspr SPRN_HID0,r3
b __setup_e200_ivors
+_GLOBAL(__setup_cpu_e500v2)
+#ifdef CONFIG_PTE_64BIT
+ /* enable mas7 register for tlbre/tlbsx */
+ mfspr r0,SPRN_HID0
+ ori r0,r0,HID0_EN_MAS7_UPDATE@l
+ mtspr SPRN_HID0,r0
+#endif
_GLOBAL(__setup_cpu_e500v1)
-_GLOBAL(__setup_cpu_e500v2)
mflr r4
bl __e500_icache_setup
bl __e500_dcache_setup
Index: linux/arch/powerpc/include/asm/reg.h
===================================================================
--- linux/arch/powerpc/include/asm/reg.h (revision 2871)
+++ linux/arch/powerpc/include/asm/reg.h (working copy)
@@ -276,6 +276,7 @@
#define HID0_DAPUEN (1<<8) /* Debug APU enable */
#define HID0_SGE (1<<7) /* Store Gathering Enable */
#define HID0_SIED (1<<7) /* Serial Instr. Execution [Disable] */
+#define HID0_EN_MAS7_UPDATE (1<<7) /* Enable MAS7 reg for tlbre/tlbsx */
#define HID0_DCFA (1<<6) /* Data Cache Flush Assist */
#define HID0_LRSTK (1<<4) /* Link register stack - 745x */
#define HID0_BTIC (1<<5) /* Branch Target Instr Cache Enable */
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-06-22 22:40 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-16 6:58 [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE] Micha Nelissen
2010-06-16 7:29 ` Aggrwal Poonam-B10812
2010-06-16 9:24 ` Micha Nelissen
2010-06-16 10:49 ` Aggrwal Poonam-B10812
2010-06-16 11:34 ` Micha Nelissen
2010-06-16 11:38 ` Aggrwal Poonam-B10812
2010-06-16 14:23 ` Timur Tabi
2010-06-16 14:52 ` Micha Nelissen
2010-06-22 22:39 ` Scott Wood
2010-06-16 15:01 ` Kumar Gala
2010-06-16 15:12 ` Micha Nelissen
2010-06-16 15:18 ` Micha Nelissen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).