* Re: cpu features testing 32 vs 64 bit
From: Kumar Gala @ 2005-09-08 21:20 UTC (permalink / raw)
To: pantelis.antoniou; +Cc: linuxppc64-dev, linuxppc-dev, linuxppc-embedded
In-Reply-To: <200509090008.39692.pantelis.antoniou@gmail.com>
On Sep 8, 2005, at 4:08 PM, Pantelis Antoniou wrote:
> On Friday 09 September 2005 00:02, Becky Bruce wrote:
>
>> So,
>>
>> in include/asm-ppc64/cacheflush.h is the following:
>>
>> static inline void flush_icache_range(unsigned long start, unsigned
>> long stop)
>> {
>> if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
>> __flush_icache_range(start, stop);
>> }
>>
>> On the 32-bit side, we don't need the feature test -
>> CPU_FTR_COHERENT_CACHE is only defined in 64-bit land, and has
>> bits set
>> in the upper 32.
>>
>>
>
> Oh yes we need it. 8xx is non coherent.
I think she lost the I in ICACHE... its a power5 only feature at this
point.
- kumar
^ permalink raw reply
* [PATCH] ppc: Merge tlb.h
From: Kumar Gala @ 2005-09-08 21:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, linuxppc64-dev
Merged tlb.h between asm-ppc32 and asm-ppc64 into asm-powerpc. Also, fixed
a compiler warning in arch/ppc/mm/tlb.c since it was roughly related.
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
---
commit c5f0c343d08ad9c6862c1755e7b2239f31a2a633
tree c80721ace951bc55b14a8f2a3bf69599bca2e8e9
parent cebb2b156319990fc2fba615bbfeac81be62a86a
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 08 Sep 2005 16:09:42 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 08 Sep 2005 16:09:42 -0500
arch/ppc/mm/tlb.c | 1 +
include/asm-powerpc/tlb.h | 50 +++++++++++++++++++++++++++++++++++++++
include/asm-ppc/tlb.h | 57 ---------------------------------------------
include/asm-ppc64/tlb.h | 39 -------------------------------
4 files changed, 51 insertions(+), 96 deletions(-)
diff --git a/arch/ppc/mm/tlb.c b/arch/ppc/mm/tlb.c
--- a/arch/ppc/mm/tlb.c
+++ b/arch/ppc/mm/tlb.c
@@ -28,6 +28,7 @@
#include <linux/mm.h>
#include <linux/init.h>
#include <linux/highmem.h>
+#include <linux/pagemap.h>
#include <asm/tlbflush.h>
#include <asm/tlb.h>
diff --git a/include/asm-powerpc/tlb.h b/include/asm-powerpc/tlb.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/tlb.h
@@ -0,0 +1,50 @@
+#ifndef _ASM_POWERPC_TLB_H
+#define _ASM_POWERPC_TLB_H
+
+#include <asm/tlbflush.h>
+#include <asm/page.h>
+
+/* Nothing needed here in fact... */
+#define tlb_start_vma(tlb, vma) do { } while (0)
+#define tlb_end_vma(tlb, vma) do { } while (0)
+
+/* Avoid pulling in another include just for this */
+#define check_pgt_cache() do { } while (0)
+
+#if defined(CONFIG_PPC64)
+struct mmu_gather;
+
+extern void pte_free_finish(void);
+
+#define __tlb_remove_tlb_entry(tlb, pte, address) do { } while (0)
+static inline void tlb_flush(struct mmu_gather *tlb)
+{
+ flush_tlb_pending();
+ pte_free_finish();
+}
+#elif defined(CONFIG_PPC_STD_MMU)
+/* Classic PPC with hash-table based MMU... */
+
+struct mmu_gather;
+extern void tlb_flush(struct mmu_gather *tlb);
+extern void flush_hash_entry(struct mm_struct *mm, pte_t *ptep,
+ unsigned long address);
+#else
+/* Embedded PPC with software-loaded TLB, very simple... */
+
+#define __tlb_remove_tlb_entry(tlb, pte, address) do { } while (0)
+#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
+#endif /* CONFIG_PPC64 */
+
+/* Get the generic bits... */
+#include <asm-generic/tlb.h>
+
+#ifdef CONFIG_PPC_STD_MMU
+static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep,
+ unsigned long address)
+{
+ if (pte_val(*ptep) & _PAGE_HASHPTE)
+ flush_hash_entry(tlb->mm, ptep, address);
+}
+#endif /* CONFIG_PPC_STD_MMU */
+#endif /* _ASM_POWERPC_TLB_H */
diff --git a/include/asm-ppc/tlb.h b/include/asm-ppc/tlb.h
deleted file mode 100644
--- a/include/asm-ppc/tlb.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/*
- * TLB shootdown specifics for PPC
- *
- * Copyright (C) 2002 Paul Mackerras, IBM Corp.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-#ifndef _PPC_TLB_H
-#define _PPC_TLB_H
-
-#include <linux/config.h>
-#include <asm/pgtable.h>
-#include <asm/pgalloc.h>
-#include <asm/tlbflush.h>
-#include <asm/page.h>
-#include <asm/mmu.h>
-
-#ifdef CONFIG_PPC_STD_MMU
-/* Classic PPC with hash-table based MMU... */
-
-struct mmu_gather;
-extern void tlb_flush(struct mmu_gather *tlb);
-
-/* Get the generic bits... */
-#include <asm-generic/tlb.h>
-
-/* Nothing needed here in fact... */
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-
-extern void flush_hash_entry(struct mm_struct *mm, pte_t *ptep,
- unsigned long address);
-
-static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep,
- unsigned long address)
-{
- if (pte_val(*ptep) & _PAGE_HASHPTE)
- flush_hash_entry(tlb->mm, ptep, address);
-}
-
-#else
-/* Embedded PPC with software-loaded TLB, very simple... */
-
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-#define __tlb_remove_tlb_entry(tlb, pte, address) do { } while (0)
-#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
-
-/* Get the generic bits... */
-#include <asm-generic/tlb.h>
-
-#endif /* CONFIG_PPC_STD_MMU */
-
-#endif /* __PPC_TLB_H */
diff --git a/include/asm-ppc64/tlb.h b/include/asm-ppc64/tlb.h
deleted file mode 100644
--- a/include/asm-ppc64/tlb.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * TLB shootdown specifics for PPC64
- *
- * Copyright (C) 2002 Anton Blanchard, IBM Corp.
- * Copyright (C) 2002 Paul Mackerras, IBM Corp.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-#ifndef _PPC64_TLB_H
-#define _PPC64_TLB_H
-
-#include <asm/tlbflush.h>
-
-struct mmu_gather;
-
-extern void pte_free_finish(void);
-
-static inline void tlb_flush(struct mmu_gather *tlb)
-{
- flush_tlb_pending();
- pte_free_finish();
-}
-
-/* Avoid pulling in another include just for this */
-#define check_pgt_cache() do { } while (0)
-
-/* Get the generic bits... */
-#include <asm-generic/tlb.h>
-
-/* Nothing needed here in fact... */
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-
-#define __tlb_remove_tlb_entry(tlb, pte, address) do { } while (0)
-
-#endif /* _PPC64_TLB_H */
^ permalink raw reply
* Re: cpu features testing 32 vs 64 bit
From: Pantelis Antoniou @ 2005-09-08 21:08 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1729b6f2a199a759c4daeadd3ddcdc4a@freescale.com>
On Friday 09 September 2005 00:02, Becky Bruce wrote:
> So,
>
> in include/asm-ppc64/cacheflush.h is the following:
>
> static inline void flush_icache_range(unsigned long start, unsigned
> long stop)
> {
> if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
> __flush_icache_range(start, stop);
> }
>
> On the 32-bit side, we don't need the feature test -
> CPU_FTR_COHERENT_CACHE is only defined in 64-bit land, and has bits set
> in the upper 32.
>
Oh yes we need it. 8xx is non coherent.
> There's a couple of ways to deal with merging this:
>
> 1) The ever-so-popular #ifdef __powerpc64__around the cpu_has_feature
> test
> 2) No ifdef in the code itself, but #define CPU_FTR_WHATEVER to be 0
> when !__powerpc64__ in cputable.h so that the cpu_has_feature test will
> always fail for 32-bit.
>
> I'd like to get some opinions on this. Do folks feel like the
> performance hit of doing the compare is enough to justify going with
> method 1? Should we be using likely/unlikely with the feature test?
>
> This is just one code example - I suspect there will be others as we
> continue the merge, and the importance of performance may differ
> depending on where in the code we are.
>
> Thanks!
> -B
>
Regards
Pantelis
^ permalink raw reply
* cpu features testing 32 vs 64 bit
From: Becky Bruce @ 2005-09-08 21:02 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-embedded, linuxppc-dev
So,
in include/asm-ppc64/cacheflush.h is the following:
static inline void flush_icache_range(unsigned long start, unsigned
long stop)
{
if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
__flush_icache_range(start, stop);
}
On the 32-bit side, we don't need the feature test -
CPU_FTR_COHERENT_CACHE is only defined in 64-bit land, and has bits set
in the upper 32.
There's a couple of ways to deal with merging this:
1) The ever-so-popular #ifdef __powerpc64__around the cpu_has_feature
test
2) No ifdef in the code itself, but #define CPU_FTR_WHATEVER to be 0
when !__powerpc64__ in cputable.h so that the cpu_has_feature test will
always fail for 32-bit.
I'd like to get some opinions on this. Do folks feel like the
performance hit of doing the compare is enough to justify going with
method 1? Should we be using likely/unlikely with the feature test?
This is just one code example - I suspect there will be others as we
continue the merge, and the importance of performance may differ
depending on where in the code we are.
Thanks!
-B
^ permalink raw reply
* Re: RFC: merging of cputables between ppc32/64
From: will schmidt @ 2005-09-08 20:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, ppc64-dev
In-Reply-To: <268E83D3-853C-4752-88D1-A7354E924C07@freescale.com>
Kumar Gala wrote:
> I was hoping to get some idea on which direction we wanted to head with
> cputable between ppc32/64. The only major difference that exists
> between the two is the use of cpu_setup().
>
> On ppc32, cpu_setup is called for each processor in an SMP
> configuration. Which gives us the following signature:
>
> typedef void (*cpu_setup_t)(unsigned long offset, int cpu_nr, struct
> cpu_spec* spec);
>
> On ppc64, cpu_setup is only called for the boot cpu. It is left to the
Yeah, at the time, we figured all cpu's in a system would be the same.
with the merge of 32/64, is this still going to be the case?
> cpu save/restore functions to handle setting up the state for
> additional CPUs. Which gives is the following signature:
>
> typedef void (*cpu_setup_t)(unsigned long offset, struct cpu_spec* spec);
>
> So my question is do we just extend the ppc64 signature to match the
> ppc32 by having a dummy "int cpu_nr" that is ignored or do we do
> something else? As far as I can tell cpu_nr is only used by ppc32 as
> temp storage so that the cpu_setup functions can return properly.
If cpu_nr is just used as temp storage, then can it be removed and
replaced with a local variable?
>
> - kumar
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev
^ permalink raw reply
* Re: [PATCH] ppc: Moved ASM_CONST macro into ppc_asm.h
From: Kumar Gala @ 2005-09-08 20:32 UTC (permalink / raw)
To: Gala Kumar K.-galak; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <Pine.LNX.4.61.0509071354270.31849@nylon.am.freescale.net>
Well, this patch breaks thinks since ppc_asm.h really needs a hugh
__ASSEMBLY__ protection for most of it.
I'll send an updated patch that also moves ppc_asm.h into include/asm-
powerpc once we close on the non-volatile issue with r13 between
ppc32/64.
- kumar
On Sep 7, 2005, at 1:55 PM, Gala Kumar K.-galak wrote:
> Moved the ASM_CONST macro into ppc_asm for ppc32 and ppc64 since that
> seems like a much better place for it long term. Also, by adding the
> macro to ppc32 it will ease some future merging of code into
> arch/powerpc.
>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
> ---
> commit f56255eddd631902e3835bf7cdd8d94e69799097
> tree 82c222d64fdccbaed25e302816fd4cf6237e8d56
> parent 71c22e7cc4bf30119761b60b26c498d7b9d33e36
> author Kumar K. Gala <kumar.gala@freescale.com> Wed, 07 Sep 2005
> 13:53:35 -0500
> committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 07 Sep 2005
> 13:53:35 -0500
>
> include/asm-ppc/ppc_asm.h | 12 ++++++++++++
> include/asm-ppc64/cputable.h | 2 +-
> include/asm-ppc64/mmu.h | 1 +
> include/asm-ppc64/page.h | 8 +-------
> include/asm-ppc64/ppc_asm.h | 7 +++++++
> 5 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/include/asm-ppc/ppc_asm.h b/include/asm-ppc/ppc_asm.h
> --- a/include/asm-ppc/ppc_asm.h
> +++ b/include/asm-ppc/ppc_asm.h
> @@ -11,6 +11,9 @@
> * 2 of the License, or (at your option) any later version.
> */
>
> +#ifndef __PPC_ASM_H
> +#define __PPC_ASM_H
> +
> #include <linux/config.h>
>
> /*
> @@ -348,3 +351,12 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
> #define N_RSYM 64
> #define N_SLINE 68
> #define N_SO 100
> +
> +#ifdef __ASSEMBLY__
> + #define ASM_CONST(x) x
> +#else
> + #define __ASM_CONST(x) x##UL
> + #define ASM_CONST(x) __ASM_CONST(x)
> +#endif
> +
> +#endif /* __PPC_ASM_H */
> diff --git a/include/asm-ppc64/cputable.h b/include/asm-ppc64/
> cputable.h
> --- a/include/asm-ppc64/cputable.h
> +++ b/include/asm-ppc64/cputable.h
> @@ -16,7 +16,7 @@
> #define __ASM_PPC_CPUTABLE_H
>
> #include <linux/config.h>
> -#include <asm/page.h> /* for ASM_CONST */
> +#include <asm/ppc_asm.h> /* for ASM_CONST */
>
> /* Exposed to userland CPU features - Must match ppc32 definitions */
> #define PPC_FEATURE_32 0x80000000
> diff --git a/include/asm-ppc64/mmu.h b/include/asm-ppc64/mmu.h
> --- a/include/asm-ppc64/mmu.h
> +++ b/include/asm-ppc64/mmu.h
> @@ -14,6 +14,7 @@
> #define _PPC64_MMU_H_
>
> #include <linux/config.h>
> +#include <asm/ppc_asm.h> /* for ASM_CONST */
> #include <asm/page.h>
>
> /*
> diff --git a/include/asm-ppc64/page.h b/include/asm-ppc64/page.h
> --- a/include/asm-ppc64/page.h
> +++ b/include/asm-ppc64/page.h
> @@ -11,13 +11,7 @@
> */
>
> #include <linux/config.h>
> -
> -#ifdef __ASSEMBLY__
> - #define ASM_CONST(x) x
> -#else
> - #define __ASM_CONST(x) x##UL
> - #define ASM_CONST(x) __ASM_CONST(x)
> -#endif
> +#include <asm/ppc_asm.h> /* for ASM_CONST */
>
> /* PAGE_SHIFT determines the page size */
> #define PAGE_SHIFT 12
> diff --git a/include/asm-ppc64/ppc_asm.h b/include/asm-ppc64/ppc_asm.h
> --- a/include/asm-ppc64/ppc_asm.h
> +++ b/include/asm-ppc64/ppc_asm.h
> @@ -239,4 +239,11 @@
> #define vr30 30
> #define vr31 31
>
> +#ifdef __ASSEMBLY__
> + #define ASM_CONST(x) x
> +#else
> + #define __ASM_CONST(x) x##UL
> + #define ASM_CONST(x) __ASM_CONST(x)
> +#endif
> +
> #endif /* _PPC64_PPC_ASM_H */
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev
>
^ permalink raw reply
* Re: [PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
From: Marcelo Tosatti @ 2005-09-08 19:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
In-Reply-To: <17183.48543.616634.628331@cargo.ozlabs.ibm.com>
On Thu, Sep 08, 2005 at 02:27:11PM +1000, Paul Mackerras wrote:
> Marcelo Tosatti writes:
>
> > eieio/isync are not required. There's no need to execute redudant
> > instructions and occupy kernel space.
>
> Given how long it takes to access I/O devices, I don't believe an
> extra instruction or two is going to make a measurable difference.
> Feel free to show me measurements proving me wrong, of course... :)
I will try to measure it later on and change out_/in_ macros as
suggested.
For now are there any objections against this? Otherwise I'll merge it.
There are a few more places which need conversion, plan to change them
later on also.
Thanks everyone.
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -73,7 +73,7 @@ cpm_mask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr &= ~(1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr) & ~(1 << cpm_vec));
}
static void
@@ -81,7 +81,7 @@ cpm_unmask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr |= (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr) | (1 << cpm_vec));
}
static void
@@ -95,7 +95,7 @@ cpm_eoi(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr = (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr, (1 << cpm_vec));
}
struct hw_interrupt_type cpm_pic = {
@@ -133,7 +133,7 @@ m8xx_cpm_reset(void)
* manual recommends it.
* Bit 25, FAM can also be set to use FEC aggressive mode (860T).
*/
- imp->im_siu_conf.sc_sdcr = 1;
+ out_be32(&imp->im_siu_conf.sc_sdcr, 1),
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
@@ -178,10 +178,10 @@ cpm_interrupt_init(void)
/* Initialize the CPM interrupt controller.
*/
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr =
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr,
(CICR_SCD_SCC4 | CICR_SCC_SCC3 | CICR_SCB_SCC2 | CICR_SCA_SCC1) |
- ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr = 0;
+ ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, 0);
/* install the CPM interrupt controller routines for the CPM
* interrupt vectors
@@ -198,7 +198,7 @@ cpm_interrupt_init(void)
if (setup_irq(CPM_IRQ_OFFSET + CPMVEC_ERROR, &cpm_error_irqaction))
panic("Could not allocate CPM error IRQ!");
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr |= CICR_IEN;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr) | CICR_IEN);
}
/*
@@ -212,8 +212,8 @@ cpm_get_irq(struct pt_regs *regs)
/* Get the vector by setting the ACK bit and then reading
* the register.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr = 1;
- cpm_vec = ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr;
+ out_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr, 1);
+ cpm_vec = in_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr);
cpm_vec >>= 11;
return cpm_vec;
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -144,12 +144,12 @@ void __init m8xx_calibrate_decr(void)
int freq, fp, divisor;
/* Unlock the SCCR. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, KAPWR_KEY);
/* Force all 8xx processors to use divide by 16 processor clock. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_sccr |= 0x02000000;
-
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr,
+ in_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr)|0x02000000);
/* Processor frequency is MHz.
* The value 'fp' is the number of decrementer ticks per second.
*/
@@ -175,28 +175,24 @@ void __init m8xx_calibrate_decr(void)
* we guarantee the registers are locked, then we unlock them
* for our use.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk, KAPWR_KEY);
/* Disable the RTC one second and alarm interrupts. */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc &=
- ~(RTCSC_SIE | RTCSC_ALE);
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc, in_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc) & ~(RTCSC_SIE | RTCSC_ALE));
/* Enable the RTC */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc |=
- (RTCSC_RTF | RTCSC_RTE);
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc, in_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc) | (RTCSC_RTF | RTCSC_RTE));
/* Enabling the decrementer also enables the timebase interrupts
* (or from the other point of view, to get decrementer interrupts
* we have to enable the timebase). The decrementer interrupt
* is wired into the vector table, nothing to do here for that.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_tbscr =
- ((mk_int_int_mask(DEC_INTERRUPT) << 8) |
- (TBSCR_TBF | TBSCR_TBE));
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_tbscr, (mk_int_int_mask(DEC_INTERRUPT) << 8) | (TBSCR_TBF | TBSCR_TBE));
if (setup_irq(DEC_INTERRUPT, &tbint_irqaction))
panic("Could not allocate timer IRQ!");
@@ -216,9 +212,9 @@ void __init m8xx_calibrate_decr(void)
static int
m8xx_set_rtc_time(unsigned long time)
{
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtc = time;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = ~KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtc, time);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck, ~KAPWR_KEY);
return(0);
}
@@ -226,7 +222,7 @@ static unsigned long
m8xx_get_rtc_time(void)
{
/* Get time from the RTC. */
- return((unsigned long)(((immap_t *)IMAP_ADDR)->im_sit.sit_rtc));
+ return (unsigned long) in_be32(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtc);
}
static void
@@ -235,13 +231,13 @@ m8xx_restart(char *cmd)
__volatile__ unsigned char dummy;
local_irq_disable();
- ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr |= 0x00000080;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr, in_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr) | 0x00000080);
/* Clear the ME bit in MSR to cause checkstop on machine check
*/
mtmsr(mfmsr() & ~0x1000);
- dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
+ dummy = in_8(&((immap_t *)IMAP_ADDR)->im_clkrst.res[0]);
printk("Restart failed\n");
while(1);
}
@@ -306,8 +302,7 @@ m8xx_init_IRQ(void)
i8259_init(0);
/* The i8259 cascade interrupt must be level sensitive. */
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel &=
- ~(0x80000000 >> ISA_BRIDGE_INT);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel, in_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel & ~(0x80000000 >> ISA_BRIDGE_INT)));
if (setup_irq(ISA_BRIDGE_INT, &mbx_i8259_irqaction))
enable_irq(ISA_BRIDGE_INT);
diff --git a/arch/ppc/syslib/m8xx_wdt.c b/arch/ppc/syslib/m8xx_wdt.c
--- a/arch/ppc/syslib/m8xx_wdt.c
+++ b/arch/ppc/syslib/m8xx_wdt.c
@@ -29,8 +29,8 @@ void m8xx_wdt_reset(void)
{
volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
- imap->im_siu_conf.sc_swsr = 0x556c; /* write magic1 */
- imap->im_siu_conf.sc_swsr = 0xaa39; /* write magic2 */
+ out_be16(imap->im_siu_conf.sc_swsr, 0x556c); /* write magic1 */
+ out_be16(imap->im_siu_conf.sc_swsr, 0xaa39); /* write magic2 */
}
static irqreturn_t m8xx_wdt_interrupt(int irq, void *dev, struct pt_regs *regs)
@@ -39,7 +39,7 @@ static irqreturn_t m8xx_wdt_interrupt(in
m8xx_wdt_reset();
- imap->im_sit.sit_piscr |= PISCR_PS; /* clear irq */
+ out_be16(imap->im_sit.sit_piscr, in_be16(imap->im_sit.sit_piscr | PISCR_PS)); /* clear irq */
return IRQ_HANDLED;
}
@@ -51,7 +51,7 @@ void __init m8xx_wdt_handler_install(bd_
u32 sypcr;
u32 pitrtclk;
- sypcr = imap->im_siu_conf.sc_sypcr;
+ sypcr = in_be32(imap->im_siu_conf.sc_sypcr);
irch/ppc/syslib/ppc8xx_pic.c:32:f (!(sypcr & 0x04)) {
printk(KERN_NOTICE "m8xx_wdt: wdt disabled (SYPCR: 0x%08X)\n",
@@ -87,9 +87,9 @@ void __init m8xx_wdt_handler_install(bd_
else
pitc = pitrtclk * wdt_timeout / binfo->bi_intfreq / 2;
- imap->im_sit.sit_pitc = pitc << 16;
- imap->im_sit.sit_piscr =
- (mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE;
+ out_be32(imap->im_sit.sit_pitc, pitc << 16);
+
+ out_be16(imap->im_sit.sit_piscr, (mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE);
if (setup_irq(PIT_INTERRUPT, &m8xx_wdt_irqaction))
panic("m8xx_wdt: error setting up the watchdog irq!");
diff --git a/arch/ppc/syslib/ppc8xx_pic.c b/arch/ppc/syslib/ppc8xx_pic.c
--- a/arch/ppc/syslib/ppc8xx_pic.c
+++ b/arch/ppc/syslib/ppc8xx_pic.c
@@ -6,6 +6,7 @@
#include <linux/signal.h>
#include <linux/interrupt.h>
#include <asm/irq.h>
+#include <asm/io.h>
#include <asm/8xx_immap.h>
#include <asm/mpc8xx.h>
#include "ppc8xx_pic.h"
@@ -29,8 +30,7 @@ static void m8xx_mask_irq(unsigned int i
word = irq_nr >> 5;
ppc_cached_irq_mask[word] &= ~(1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
static void m8xx_unmask_irq(unsigned int irq_nr)
@@ -41,8 +41,7 @@ static void m8xx_unmask_irq(unsigned int
word = irq_nr >> 5;
ppc_cached_irq_mask[word] |= (1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
static void m8xx_end_irq(unsigned int irq_nr)
@@ -55,8 +54,7 @@ static void m8xx_end_irq(unsigned int ir
word = irq_nr >> 5;
ppc_cached_irq_mask[word] |= (1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
}
@@ -69,9 +67,8 @@ static void m8xx_mask_and_ack(unsigned i
word = irq_nr >> 5;
ppc_cached_irq_mask[word] &= ~(1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sipend = 1 << (31-bit);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sipend, 1 << (31-bit));
}
struct hw_interrupt_type ppc8xx_pic = {
@@ -93,7 +90,7 @@ m8xx_get_irq(struct pt_regs *regs)
/* For MPC8xx, read the SIVEC register and shift the bits down
* to get the irq number.
*/
- irq = ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sivec >> 26;
+ irq = in_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sivec) >> 26;
/*
* When we read the sivec without an interrupt to process, we will
^ permalink raw reply
* Re: r13 is non-volatile?
From: linas @ 2005-09-08 19:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc64-dev, linuxppc-dev list
In-Reply-To: <ac556638e1f4b4f9786c30ed0debc4a8@kernel.crashing.org>
On Thu, Sep 08, 2005 at 07:01:18PM +0200, Segher Boessenkool was heard to remark:
> >Was looking at merging some code between ppc32 & ppc64 and noticed
> >that in ppc32 we consider r13 to be part of the non-volatile register
> >set. Is this really correct?
>
> >r13 is suppose to be sdata pointer in ppc32
>
> sdata pointer is non-volatile by definition...
>
> >and system thread id in ppc64.
>
> The 64-bit kernel uses GPR13 as the PACA pointer, so it handles
> it specially
There's a different value in R13 depending on which cpu you're on,
so one mustn't save R13 on one CPU and attempt to restore it on
another.
Maybe, for ppc32, you can pretend that r13 "is like a paca"? So
that instead of saving/restoring r13 like this, you could set it up
at the same time/instead of setting up the paca r13?
--linas
^ permalink raw reply
* PATCH Fix __power64__ typos that should be __powerpc64__
From: jdl @ 2005-09-08 19:05 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
Fix __power64__ typo that should be __powerpc64__ instead.
include/asm-powerpc/shmbuf.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff --git a/include/asm-powerpc/shmbuf.h b/include/asm-powerpc/shmbuf.h
--- a/include/asm-powerpc/shmbuf.h
+++ b/include/asm-powerpc/shmbuf.h
@@ -21,19 +21,19 @@
struct shmid64_ds {
struct ipc64_perm shm_perm; /* operation perms */
-#ifndef __power64__
+#ifndef __powerpc64__
unsigned long __unused1;
#endif
__kernel_time_t shm_atime; /* last attach time */
-#ifndef __power64__
+#ifndef __powerpc64__
unsigned long __unused2;
#endif
__kernel_time_t shm_dtime; /* last detach time */
-#ifndef __power64__
+#ifndef __powerpc64__
unsigned long __unused3;
#endif
__kernel_time_t shm_ctime; /* last change time */
-#ifndef __power64__
+#ifndef __powerpc64__
unsigned long __unused4;
#endif
size_t shm_segsz; /* size of segment (bytes) */
^ permalink raw reply
* RFC: merging of cputables between ppc32/64
From: Kumar Gala @ 2005-09-08 18:42 UTC (permalink / raw)
To: linuxppc-dev list, ppc64-dev
I was hoping to get some idea on which direction we wanted to head
with cputable between ppc32/64. The only major difference that
exists between the two is the use of cpu_setup().
On ppc32, cpu_setup is called for each processor in an SMP
configuration. Which gives us the following signature:
typedef void (*cpu_setup_t)(unsigned long offset, int cpu_nr, struct
cpu_spec* spec);
On ppc64, cpu_setup is only called for the boot cpu. It is left to
the cpu save/restore functions to handle setting up the state for
additional CPUs. Which gives is the following signature:
typedef void (*cpu_setup_t)(unsigned long offset, struct cpu_spec*
spec);
So my question is do we just extend the ppc64 signature to match the
ppc32 by having a dummy "int cpu_nr" that is ignored or do we do
something else? As far as I can tell cpu_nr is only used by ppc32 as
temp storage so that the cpu_setup functions can return properly.
- kumar
^ permalink raw reply
* can we kill CONFIG_PPC64BRIDGE?
From: Kumar Gala @ 2005-09-08 18:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, ppc64-dev
Paul,
Can we kill CONFIG_PPC64BRIDGE for ppc32... Not sure if anyone is
using this or not?
- kumar
^ permalink raw reply
* Re: r13 is non-volatile?
From: Segher Boessenkool @ 2005-09-08 17:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc64-dev, linuxppc-dev list
In-Reply-To: <0C620F0B-92B0-4EBF-BC0C-49FD4D3D4323@freescale.com>
> Was looking at merging some code between ppc32 & ppc64 and noticed
> that in ppc32 we consider r13 to be part of the non-volatile register
> set. Is this really correct?
I believe so, yes.
> r13 is suppose to be sdata pointer in ppc32
sdata pointer is non-volatile by definition...
> and system thread id in ppc64.
The 64-bit kernel uses GPR13 as the PACA pointer, so it handles
it specially -- it treats the userland values of the register
as non-volatile, though.
> So I'm wondering should we really be considering it NV on ppc32?
Yeah. I'm sure there is some way to make the macro's identical
between 32- and 64-bit, though.
Segher
^ permalink raw reply
* r13 is non-volatile?
From: Kumar Gala @ 2005-09-08 16:28 UTC (permalink / raw)
To: linuxppc-dev list, ppc64-dev
Was looking at merging some code between ppc32 & ppc64 and noticed
that in ppc32 we consider r13 to be part of the non-volatile register
set. Is this really correct?
r13 is suppose to be sdata pointer in ppc32 and system thread id in
ppc64. So I'm wondering should we really be considering it NV on ppc32?
PPC32:
#define SAVE_NVGPRS(base) SAVE_GPR(13, base); SAVE_8GPRS(14,
base); \
SAVE_10GPRS(22, base)
#define REST_NVGPRS(base) REST_GPR(13, base); REST_8GPRS(14,
base); \
REST_10GPRS(22, base)
PPC64:
#define SAVE_NVGPRS(base) SAVE_8GPRS(14, base); SAVE_10GPRS(22,
base)
#define REST_NVGPRS(base) REST_8GPRS(14, base); REST_10GPRS(22,
base)
- kumar
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Dan Malek @ 2005-09-08 15:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, linuxppc-dev, Gala Kumar K.-galak, Tom Rini
In-Reply-To: <5B4F5836-F3E6-4511-BD4C-9388BBA715E0@freescale.com>
On Sep 8, 2005, at 10:11 AM, Kumar Gala wrote:
> Idea's on how to solve this are welcome.
Just create the appropriate defconfigs with this clock
frequency and check them in.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH 2.6.13] ppc32: Kill PVR_440* defines
From: Tom Rini @ 2005-09-08 15:14 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded
The following patch changes the usages of PVR_440* into strcmp's with
the cpu_name field, and removes the defines altogether. The Ebony
portion was briefly tested long ago. One benefit of moving from
PVR-tests to string tests in general is that not all CPUs can be
differentiated by PVR type, but we could otherwise know which one we're
on and be able to do this type of comparison.
See http://patchwork.ozlabs.org/linuxppc/patch?id=1250 for the original
thread.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Index: linux-2.6/arch/ppc/platforms/4xx/ebony.c
===================================================================
--- linux-2.6.orig/arch/ppc/platforms/4xx/ebony.c
+++ linux-2.6/arch/ppc/platforms/4xx/ebony.c
@@ -91,15 +91,10 @@ ebony_calibrate_decr(void)
* on Rev. C silicon then errata forces us to
* use the internal clock.
*/
- switch (PVR_REV(mfspr(SPRN_PVR))) {
- case PVR_REV(PVR_440GP_RB):
- freq = EBONY_440GP_RB_SYSCLK;
- break;
- case PVR_REV(PVR_440GP_RC1):
- default:
- freq = EBONY_440GP_RC_SYSCLK;
- break;
- }
+ if (strcmp(cur_cpu_spec[0]->cpu_name, "440GP Rev. B") == 0)
+ freq = EBONY_440GP_RB_SYSCLK;
+ else
+ freq = EBONY_440GP_RC_SYSCLK;
ibm44x_calibrate_decr(freq);
}
Index: linux-2.6/arch/ppc/syslib/ibm440gx_common.c
===================================================================
--- linux-2.6.orig/arch/ppc/syslib/ibm440gx_common.c
+++ linux-2.6/arch/ppc/syslib/ibm440gx_common.c
@@ -236,9 +236,10 @@ void __init ibm440gx_l2c_setup(struct ib
/* Disable L2C on rev.A, rev.B and 800MHz version of rev.C,
enable it on all other revisions
*/
- u32 pvr = mfspr(SPRN_PVR);
- if (pvr == PVR_440GX_RA || pvr == PVR_440GX_RB ||
- (pvr == PVR_440GX_RC && p->cpu > 667000000))
+ if (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. A") == 0 ||
+ strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. B") == 0
+ || (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. C")
+ == 0 && p->cpu > 667000000))
ibm440gx_l2c_disable();
else
ibm440gx_l2c_enable();
Index: linux-2.6/include/asm-ppc/reg.h
===================================================================
--- linux-2.6.orig/include/asm-ppc/reg.h
+++ linux-2.6/include/asm-ppc/reg.h
@@ -366,12 +366,6 @@
#define PVR_STB03XXX 0x40310000
#define PVR_NP405H 0x41410000
#define PVR_NP405L 0x41610000
-#define PVR_440GP_RB 0x40120440
-#define PVR_440GP_RC1 0x40120481
-#define PVR_440GP_RC2 0x40200481
-#define PVR_440GX_RA 0x51b21850
-#define PVR_440GX_RB 0x51b21851
-#define PVR_440GX_RC 0x51b21892
#define PVR_601 0x00010000
#define PVR_602 0x00050000
#define PVR_603 0x00030000
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH 2.6.13] ppc32: In the boot code, don't rely on BASE_BAUD directly
From: Tom Rini @ 2005-09-08 15:13 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded
Modifies serial_init to get base baud rate from the rs_table entry
instead of BAUD_BASE. This patch eliminates duplication between the
SERIAL_PORT_DFNS macro and BAUD_BASE. Without the patch, if a port
set the baud rate in SERIAL_PORT_DFNS, but did not update BASE_BAUD,
the BASE_BAUD value would still be used.
Signed-off-by: Grant Likely <grant.likely@gdcanada.com>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Index: linux-2.6/arch/ppc/boot/common/ns16550.c
===================================================================
--- linux-2.6.orig/arch/ppc/boot/common/ns16550.c
+++ linux-2.6/arch/ppc/boot/common/ns16550.c
@@ -23,7 +23,7 @@ static int shift;
unsigned long serial_init(int chan, void *ignored)
{
- unsigned long com_port;
+ unsigned long com_port, base_baud;
unsigned char lcr, dlm;
/* We need to find out which type io we're expecting. If it's
@@ -43,6 +43,8 @@ unsigned long serial_init(int chan, void
/* How far apart the registers are. */
shift = rs_table[chan].iomem_reg_shift;
+ /* Base baud.. */
+ base_baud = rs_table[chan].baud_base;
/* save the LCR */
lcr = inb(com_port + (UART_LCR << shift));
@@ -62,9 +64,9 @@ unsigned long serial_init(int chan, void
else {
/* Input clock. */
outb(com_port + (UART_DLL << shift),
- (BASE_BAUD / SERIAL_BAUD) & 0xFF);
+ (base_baud / SERIAL_BAUD) & 0xFF);
outb(com_port + (UART_DLM << shift),
- (BASE_BAUD / SERIAL_BAUD) >> 8);
+ (base_baud / SERIAL_BAUD) >> 8);
/* 8 data, 1 stop, no parity */
outb(com_port + (UART_LCR << shift), 0x03);
/* RTS/DTR */
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH 2.6.13] ppc32: Correct an instruction in the boot code
From: Tom Rini @ 2005-09-08 15:13 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded
In the flush and invalidate bootcode on PPC4xx we were accidentally
using the wrong instruction. Use cmplw, which reads from a register
like we want.
From: Frank van Maarseveen <frankvm@frankvm.com>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Index: linux-2.6/arch/ppc/boot/common/util.S
===================================================================
--- linux-2.6.orig/arch/ppc/boot/common/util.S
+++ linux-2.6/arch/ppc/boot/common/util.S
@@ -252,7 +252,7 @@ _GLOBAL(flush_instruction_cache)
1: dcbf r0,r3 # Flush the data cache
icbi r0,r3 # Invalidate the instruction cache
addi r3,r3,0x10 # Increment by one cache line
- cmplwi cr0,r3,r4 # Are we at the end yet?
+ cmplw cr0,r3,r4 # Are we at the end yet?
blt 1b # No, keep flushing and invalidating
#else
/* Enable, invalidate and then disable the L1 icache/dcache. */
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: How can I compile the module into kernel
From: gqbenjamin @ 2005-09-08 14:39 UTC (permalink / raw)
To: zhonglei; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 552 bytes --]
^ permalink raw reply
* [PATCH] ppc32: Fix head_4xx.S compile error
From: Kumar Gala @ 2005-09-08 14:20 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linux-kernel, linuxppc-embedded
head_4xx.S wasn't compiling due to a missing #endif
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 170118f5773bf979d0be23673b703f9dd26d63e7
tree 16e609ae6dd17af7236bbed11a875a1a653a7237
parent 4706df3d3c42af802597d82c8b1542c3d52eab23
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 08 Sep 2005 09:18:08 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 08 Sep 2005 09:18:08 -0500
arch/ppc/kernel/head_4xx.S | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S
--- a/arch/ppc/kernel/head_4xx.S
+++ b/arch/ppc/kernel/head_4xx.S
@@ -453,6 +453,7 @@ label:
#else
CRITICAL_EXCEPTION(0x1020, WDTException, UnknownException)
#endif
+#endif
/* 0x1100 - Data TLB Miss Exception
* As the name implies, translation is not in the MMU, so search the
^ permalink raw reply
* Re: MPC5200 Linux Init Problem
From: Bob Peterson @ 2005-09-08 14:18 UTC (permalink / raw)
To: Frank Beesley, linuxppc-embedded; +Cc: frank.beesley
In-Reply-To: <431F6CDC.7030908@aeroflex.com>
Hi Frank,
I recommend you first try to boot using tftp to get your kernel and nfs to get
your root filesystem. Once that boots, you can play with MTD to make sure
your flash chips have full addressability and all, and you can mount your
jffs partition manually and look at it from the client.
Also, it would be interesting to see what u-boot messages you receive at
power-on. You may also want to do a printenv command in u-boot and
post what your u-boot settings are.
Regards,
Bob Peterson
Advanced Communication Design
At 05:42 PM 9/7/2005, Frank Beesley wrote:
>I am bringing up a custom board using the MPC5200 and based on the
>Lite5200. We changed from SDR to 128MB of DDR SDRAM and the flash
>interface is now a 32MB, 32-bit wide bus using 2 Strata flash parts.
>I have u-boot-1.1.3 up and running just fine. I have three
>partitions on the flash: 0-uboot, 1-kernel image, 2-jffs file
>system. The linux kernel (DENX based 2.4.25) starts with all the
>normal messages plus some that I added for debugging. It should then
>start running /sbin/init (busybox-1.00, dynamically linked) but
>instead I get the following Oops:
>
>VFS: Mounted root (jffs filesystem)
>readonly.
>Freeing unused kernel memory: 60k
>init
>init
>filename=/sbin/init
>Oops: kernel access of bad area, sig:
>11
>NIP: C0011030 XER: 00000000 LR: C00112AC SP: C03BBEB0 REGS: c03bbe00
>TRAP: 0300d
>MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR:
>11
>DAR: 80820000, DSISR:
>20000000
>TASK = c03ba000[1] ' nit' Last syscall:
>11
>last math 00000000 last altivec
>00000000
>GPR00: 80820000 C03BBEB0 C03BA000 C01780A0 00001032 0000000B
>C0160BA4 00000000 GPR08: 0000001B 80820000 C0160968 C013D954
>00000000 00000000 00000000 00000000 GPR16: 00000000 00000000
>00000000 00000000 C0170000 C0190000 C0160000 C0160000 GPR24:
>C000E8CC 00000000 00000000 00000000 C03BA000 C016F920 00000000
>C03BBEB0 Call
>backtrace:
>00000000 C0005D04
>00000000
>Kernel panic: Attempted to kill
>init!
><0>Rebooting in 180 seconds..
>
>
>When I change busybox to statically linked I get the following
>(notice some of my debug messages from within busybox showing up now):
>VFS: Mounted root (jffs filesystem)
>readonly.
>Freeing unused kernel memory: 60k
>init
>init
>filename=/sbin/init
>init started: BusyBox v1.00 (2005.09.07-14:56+0000) multi-call
>binary
>Machine check in kernel
>mode.
>Caused by (from SRR1=41030): Transfer error ack
>signal
>Oops: machine check, sig:
>7
>NIP: C0010FD0 XER: 00000000 LR: C0010F34 SP: C03BBE40 REGS: c03bbd90
>TRAP: 0200d
>MSR: 00041030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR:
>11
>TASK = c03ba000[1] ' nit' Last syscall:
>162
>last math 00000000 last altivec
>00000000
>GPR00: 7C691B78 C03BBE40 C03BA000 C01790A0 00001032 00000000
>C0160BA4 00000000 GPR08: 00000017 4BFFFFAC C001BF1C 80620464
>100823E4 1010D01C 00000000 00000000 GPR16: 00000000 00000000
>00000000 00000000 C0170000 C0190000 C0160000 C0160000 GPR24:
>C0005A40 00000001 100D3E28 C0180000 C7E38000 C016F920 00000000
>C03BBE40 Call
>backtrace:
>C000EA78 C0010E3C C001C0EC C0005A9C 10082408 10027000
>10000960
>10000338 10051284
>00000000
>Kernel panic: Attempted to kill
>init!
><0>Rebooting in 180 seconds..
>
>
>1) Why am i getting machine check message - also see the task name
>is messed up.
>
>2) Why are dynamic linking not working, is this a problem with my
>library loader.
>
>3) Why is my init failing to load. this is the same binary and
>config files that was used on a Lite5200 and worked fine.
>
>Any clues to help debug this would be greatly appreciated. I have
>built several different kernel and busybox images with different
>debug prints to help figure this out and I am at a loss. Please CC
>me as I am not on the mailing list OR directly email me and we can
>post the solution back to the list.
>
>Thanks
>Frank
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Kumar Gala @ 2005-09-08 14:11 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: Andrew Morton, Tom Rini, Gala Kumar K.-galak, linuxppc-dev
In-Reply-To: <20050908010428.GC8882@dmt.cnet>
> Yep.
>
> Kumar, can you please change your patch to make CONFIG_8xx use 100Hz?
>
> There was a significant performance increase from doing that (vs
> 1000Hz)
> on a 48Mhz 8xx with small cache.
>
I'd be happy to, but I'm not 100% sure how to get the Kconfig system
to do that on a sub-arch case. Right now the default is 250Hz based
on the global kernel/Kconfig.hz. If we want we can effectively
replicate the Kconfig.hz functionality into arch/ppc/Kconfig which
would give us more flexibility but I'd prefer not to do that.
Idea's on how to solve this are welcome.
- kumar
^ permalink raw reply
* Re: [PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
From: Dan Malek @ 2005-09-08 13:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
In-Reply-To: <17183.48543.616634.628331@cargo.ozlabs.ibm.com>
On Sep 8, 2005, at 12:27 AM, Paul Mackerras wrote:
> Given how long it takes to access I/O devices, I don't believe an
> extra instruction or two is going to make a measurable difference.
That's kind of true. However, the access to the CPM is nearly
instruction speed, except in the case when you actually use a
real IO register (like a GPIO on a port), then it's a little slower.
-- Dan
^ permalink raw reply
* Re: Can't run 8M ramdisk at 2.4.20 linux
From: Alex Zeffertt @ 2005-09-08 8:32 UTC (permalink / raw)
To: rober; +Cc: linuxppc-embedded
In-Reply-To: <1126163212.23563.8.camel@banana>
EMAIL <rober@opnet.com.tw> wrote:
> Hi All:
>
> I build a 8M ramdisk file, it works fine at 2.4.25 linux but fail
> in 2.4.20.Why?
> I do follow command to make 8M ramdsik, all files in the ramdisk is from
> pRamdisk (download from denx ftp site).
Possibly a kernel config error. Look for CONFIG_BLK_DEV_RAM_SIZE in your .config. You need
CONFIG_BLK_DEV_RAM_SIZE=8192
Alex
^ permalink raw reply
* Re: BDI2000 with PPC405EP
From: Albert David @ 2005-09-08 7:55 UTC (permalink / raw)
To: Albert David, linuxppc-embedded
In-Reply-To: <20050908063136.GA22596@gate.ebshome.net>
Dear Eugene,
Thanks for your suggestion! This was indeed a hardware bug! I found a
problem with my cpu strapping pins! UART0_TX was never driven
externally(it was left open),
Thanks again for your reply,
with best regards,
Albert.
On 9/8/05, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Thu, Sep 08, 2005 at 11:33:53AM +0530, Albert David wrote:
> > Friends,
> > I have been trying to find a solution to fix "PPC: timeout while
> > waiting for freeze" for my custom board.
> > BDI2000 keeps resetting the system with the following message...
> >
> > TARGET: processing user reset request
> > TARGET: resetting target passed
> > TARGET: processing target startup ....
> > *** TARGET: core #0 startup failed # PPC: timeout while waiting for fre=
eze
> > TARGET: target will be restarted in 10 sec
> >
> > I tried all the possible solutions provided at
> > http://www.ultsol.com/faq-P206.htm for this perticular behaviour but
> > the problem remains same!
> >
> > I have ensured that my Board's JTAG interface is properly working by
> > boundary scanning the pins of PPC405EP using UniversalScan software
> > with Altera-ByteBlaster MV.
> >
> > for your information: twice i could succeed connecting BDI2000 with my
> > target! somehow it happen to work while i was trying to execute low
> > level JTAG commands such as 'rir' rdr' and then after exiting(JTAG
> > command shell of BDI) it worked, but there is no consistency!
> >
> > looks like my cpu core is not halting after asserting HALT line.
> > has anyone faced similar problem??
>=20
> In _all_ cases I saw this problem it was a hw bug. Ask your hw
> engineers to help you. Start with the usual suspects: power, clocks,
> strapping, etc.
>=20
> I don't think working boundary scan is an indication that hw design is
> OK.
>=20
> --
> Eugene
>=20
>
^ permalink raw reply
* Can't run 8M ramdisk at 2.4.20 linux
From: 徐小威的EMAIL @ 2005-09-08 7:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi All:
I build a 8M ramdisk file, it works fine at 2.4.25 linux but fail
in 2.4.20.Why?
I do follow command to make 8M ramdsik, all files in the ramdisk is from
pRamdisk (download from denx ftp site).
dd if=/dev/zero of=new_ramdisk bs=1024k count=8
/sbin/mke2fs -F -m0 new_ramdisk
/sbin/tune2fs -c 0 new_ramdisk
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1434k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 56k init
attempt to access beyond end of device
01:00: rw=0, want=1647259183, limit=16384
attempt to access beyond end of device
01:00: rw=0, want=1647259183, limit=16384
attempt to access beyond end of device
01:00: rw=0, want=1647259183, limit=16384
attempt to access beyond end of device
01:00: rw=0, want=1647259183, limit=16384
Kernel panic: No init found. Try passing init= option to kernel.
<0>Rebooting in 180 seconds..
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox