e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

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

> -----Original Message-----
> From:
linuxppc-dev-bounces+poonam.aggrwal=freescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-
> bounces+poonam.aggrwal=freescale.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]
> 
> 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.
[Aggrwal Poonam] This is already being done by u-boot, should linux set
it again?
> 
> Micha

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

> -----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]
> 
> 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.
> 
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.
> Regards,
> 
> Micha

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

> -----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]
> 
> 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).
You are correct , for PCIe and SRIO kinds of interfaces Linux reprograms
the address windows.
Thanks
Poonam
> 
> Micha

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 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

On Jun 16, 2010, at 1:58 AM, Micha Nelissen wrote:

> 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
> 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

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