Re: [uClinux-dev] [PATCH 1/3] MPU support
On Monday, August 23, 2010 14:16:30 Steve Longerbeam wrote: > On 08/23/2010 10:47 AM, Steve Longerbeam wrote: > > On 08/22/2010 05:20 PM, Mike Frysinger wrote: >> the common code changes will need justification as to why they exist > >> at all. > >> we're doing MPU on Blackfin/nommu today without any of these. we > >> support > >> pretty much all the same features of a MMU system short of virtual > >> memory -- > >> 4k pages, RWX granularity, process to process protection, process to > >> kernel > >> protection (include kernel modules), kernel XIP, and userspace XIP. > >> > >> further, why did you go with CONFIG_CPU_CP15_MPU ? there is already a > >> CONFIG_MPU option that is used in common nommu code. > > > > which tree has CONFIG_MPU, and the MPU support for blackfin? There is > > no such thing in the 888 uclinux release tree. > > sorry, I see CONFIG_MPU under blackfin in the 888 release. > > I'm not familiar with the blackfin arch, but my patches of course are > specific to ARM MPU's. i dont see how the processor matters. you're running Linux without virtual memory support (CONFIG_MMU=n) and you want to do memory protection (CONFIG_MPU=y). there is no need to stick a specific cpu name in there. after all, the option is CONFIG_MPU and not CONFIG_BFIN_MPU because all the changes we made (which were few) to common code were processor independent (exactly like all changes to common code should be). we specifically left the door open for other processors to support MMU=n MPU=y without an ifdef mess. -mike signature.asc Description: This is a digitally signed message part. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 1/3] MPU support
On 08/23/2010 10:47 AM, Steve Longerbeam wrote: On 08/22/2010 05:20 PM, Mike Frysinger wrote: as it stands, this breaks all non-arm NOMMU ports. the patch will need to be broken up into arm-specific and arm-independent parts. ok, I can do that. the common code changes will need justification as to why they exist at all. we're doing MPU on Blackfin/nommu today without any of these. we support pretty much all the same features of a MMU system short of virtual memory -- 4k pages, RWX granularity, process to process protection, process to kernel protection (include kernel modules), kernel XIP, and userspace XIP. further, why did you go with CONFIG_CPU_CP15_MPU ? there is already a CONFIG_MPU option that is used in common nommu code. which tree has CONFIG_MPU, and the MPU support for blackfin? There is no such thing in the 888 uclinux release tree. sorry, I see CONFIG_MPU under blackfin in the 888 release. I'm not familiar with the blackfin arch, but my patches of course are specific to ARM MPU's. Steve ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH 1/3] MPU support
On 08/22/2010 05:20 PM, Mike Frysinger wrote: as it stands, this breaks all non-arm NOMMU ports. the patch will need to be broken up into arm-specific and arm-independent parts. ok, I can do that. the common code changes will need justification as to why they exist at all. we're doing MPU on Blackfin/nommu today without any of these. we support pretty much all the same features of a MMU system short of virtual memory -- 4k pages, RWX granularity, process to process protection, process to kernel protection (include kernel modules), kernel XIP, and userspace XIP. further, why did you go with CONFIG_CPU_CP15_MPU ? there is already a CONFIG_MPU option that is used in common nommu code. which tree has CONFIG_MPU, and the MPU support for blackfin? There is no such thing in the 888 uclinux release tree. I don't know which repo I should be developing under. I suppose it should be the git tree that people are posting patches against in the uclinux-dev list. Which tree is that? Thanks, Steve ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] m68knommu: add support for Coldfire MCF547x/MCF548x interrupt controller.
The Coldfire MCF547x/MCF548x have the same interrupt controller than
the MCF528x, e.g., but only one, not two as in the MCF528x. Modify
intc-2.c to support only one interrupt controller if MCFICM_INTC1 is
not defined.
Signed-off-by: Philippe De Muyter
---
arch/m68knommu/platform/coldfire/intc-2.c | 30 +++-
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/m68knommu/platform/coldfire/intc-2.c
b/arch/m68knommu/platform/coldfire/intc-2.c
index a0c72ec..060ff7b 100644
--- a/arch/m68knommu/platform/coldfire/intc-2.c
+++ b/arch/m68knommu/platform/coldfire/intc-2.c
@@ -1,9 +1,11 @@
/*
* intc-2.c
*
- * General interrupt controller code for the many ColdFire version 2 cores
- * that use the two region INTC interrupt controller. This includes the
- * 523x family, 5270, 5271, 5274, 5275, and the 528x families.
+ * General interrupt controller code for the many ColdFire cores that use
+ * interrupt controllers with 63 interrupt sources, organized as 56 fully-
+ * programmable + 7 fixed-level interrupt sources. This includes the 523x
+ * family, the 5270, 5271, 5274, 5275, and the 528x family which have two such
+ * controllers, and the 547x and 548x families which have only one of them.
*
* (C) Copyright 2009, Greg Ungerer
*
@@ -27,17 +29,27 @@
* We don't really care so much what they are, we don't rely on the
* tranditional priority interrupt scheme of the m68k/ColdFire.
*/
-static u8 intc_intpri = 0x36;
+static u8 intc_intpri = 066;
+
+#ifdef MCFICM_INTC1
+#define NR_VECS128
+#else
+#define NR_VECS64
+#endif
static void intc_irq_mask(unsigned int irq)
{
- if ((irq >= MCFINT_VECBASE) && (irq <= MCFINT_VECBASE + 128)) {
+ if ((irq >= MCFINT_VECBASE) && (irq <= MCFINT_VECBASE + NR_VECS)) {
unsigned long imraddr;
u32 val, imrbit;
irq -= MCFINT_VECBASE;
imraddr = MCF_IPSBAR;
+#ifdef MCFICM_INTC1
imraddr += (irq & 0x40) ? MCFICM_INTC1 : MCFICM_INTC0;
+#else
+ imraddr += MCFICM_INTC0;
+#endif
imraddr += (irq & 0x20) ? MCFINTC_IMRH : MCFINTC_IMRL;
imrbit = 0x1 << (irq & 0x1f);
@@ -48,13 +60,17 @@ static void intc_irq_mask(unsigned int irq)
static void intc_irq_unmask(unsigned int irq)
{
- if ((irq >= MCFINT_VECBASE) && (irq <= MCFINT_VECBASE + 128)) {
+ if ((irq >= MCFINT_VECBASE) && (irq <= MCFINT_VECBASE + NR_VECS)) {
unsigned long intaddr, imraddr, icraddr;
u32 val, imrbit;
irq -= MCFINT_VECBASE;
intaddr = MCF_IPSBAR;
+#ifdef MCFICM_INTC1
intaddr += (irq & 0x40) ? MCFICM_INTC1 : MCFICM_INTC0;
+#else
+ intaddr += MCFICM_INTC0;
+#endif
imraddr = intaddr + ((irq & 0x20) ? MCFINTC_IMRH :
MCFINTC_IMRL);
icraddr = intaddr + MCFINTC_ICR0 + (irq & 0x3f);
imrbit = 0x1 << (irq & 0x1f);
@@ -85,7 +101,9 @@ void __init init_IRQ(void)
/* Mask all interrupt sources */
__raw_writel(0x1, MCF_IPSBAR + MCFICM_INTC0 + MCFINTC_IMRL);
+#ifdef MCFICM_INTC1
__raw_writel(0x1, MCF_IPSBAR + MCFICM_INTC1 + MCFINTC_IMRL);
+#endif
for (irq = 0; (irq < NR_IRQS); irq++) {
irq_desc[irq].status = IRQ_DISABLED;
--
1.6.3.3
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
