[uClinux-dev] PATCH] m68knommu: add definitions for the third interrupt controller on devices that don't have a third interrupt controller.
Extending the interrupt controller code in intc-simr.c to support the third interrupt controller on the m5441x means we need to add defines (as 0) for the third interrupt controller on devices that don't have a third interrupt controller. Signed-off-by: Steven King --- arch/m68k/include/asm/m520xsim.h |3 +++ arch/m68k/include/asm/m532xsim.h |3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/m68k/include/asm/m520xsim.h b/arch/m68k/include/asm/m520xsim.h index 17f2aab..f8cfb39 100644 --- a/arch/m68k/include/asm/m520xsim.h +++ b/arch/m68k/include/asm/m520xsim.h @@ -42,6 +42,9 @@ #define MCFINTC1_SIMR (0) #define MCFINTC1_CIMR (0) #defineMCFINTC1_ICR0 (0) +#define MCFINTC2_SIMR (0) +#define MCFINTC2_CIMR (0) +#define MCFINTC2_ICR0 (0) #define MCFINT_VECBASE 64 #define MCFINT_UART026 /* Interrupt number for UART0 */ diff --git a/arch/m68k/include/asm/m532xsim.h b/arch/m68k/include/asm/m532xsim.h index 29b66e2..8d86020 100644 --- a/arch/m68k/include/asm/m532xsim.h +++ b/arch/m68k/include/asm/m532xsim.h @@ -82,6 +82,9 @@ #defineMCFINTC1_SIMR 0xFC04C01C #defineMCFINTC1_CIMR 0xFC04C01D #defineMCFINTC1_ICR0 0xFC04C040 +#define MCFINTC2_SIMR (0) +#define MCFINTC2_CIMR (0) +#define MCFINTC2_ICR0 (0) #define MCFSIM_ICR_TIMER1 (0xFC048040+32) #define MCFSIM_ICR_TIMER2 (0xFC048040+33) ___ 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] Add support for the Coldfire m5441x.
On Thursday 07 June 2012 11:13:36 pm Greg Ungerer wrote: > I spoke too soon :-( > > With this patch in place, building for a m5208evb config gives: > >CC arch/m68k/platform/coldfire/intc-simr.o > arch/m68k/platform/coldfire/intc-simr.c: In function ‘intc_irq_mask’: > arch/m68k/platform/coldfire/intc-simr.c:71:6: error: ‘MCFINTC2_SIMR’ > undeclared (first use in this function) > arch/m68k/platform/coldfire/intc-simr.c:71:6: note: each undeclared > identifier is reported only once for each function it appears in > arch/m68k/platform/coldfire/intc-simr.c: In function ‘intc_irq_unmask’: > arch/m68k/platform/coldfire/intc-simr.c:83:6: error: ‘MCFINTC2_CIMR’ > undeclared (first use in this function) > arch/m68k/platform/coldfire/intc-simr.c: In function ‘intc_irq_startup’: > arch/m68k/platform/coldfire/intc-simr.c:118:6: error: ‘MCFINTC2_ICR0’ > undeclared (first use in this function) > arch/m68k/platform/coldfire/intc-simr.c: In function ‘init_IRQ’: > arch/m68k/platform/coldfire/intc-simr.c:185:6: error: ‘MCFINTC2_SIMR’ > undeclared (first use in this function) > arch/m68k/platform/coldfire/intc-simr.c:189:8: error: ‘MCFINTC2_ICR0’ > undeclared (first use in this function) D'oh! I'll send a supplemental patch or if you want I can respin the whole thing. ___ 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] m68knommu: allow ColdFire CPUs to use unaligned accesses
Hi Greg, On Fri, Jun 08, 2012 at 10:19:43PM +1000, Greg Ungerer wrote: > Hi Philippe, > > On 06/08/2012 08:39 PM, Philippe De Muyter wrote: >> On Fri, Jun 08, 2012 at 03:43:00PM +1000, g...@snapgear.com wrote: >>> From: Greg Ungerer >>> >>> All current ColdFire CPUs are able to support unaligned memory accesses. >>> So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire. >>> >>> It seems that the current restriction was inherrited from the early >>> non-MMU >>> support for the basic 68000 proecssors - which do not support unaligned >>> accesses. >> >> It seems that the first ColdFires needed the restriction : >> >> I read in the "MCF5200 ColdFire Family ProgrammerÆs Reference Manual" >> : >> >> The ColdFire processor default configuration supports word- and >> longword-sized operand references on 0-modulo-2 and 0-modulo-4 >> addresses, respectively. All other references are defined as >> misaligned accesses. Any attempt to access a misaligned operand >> generates an address-error exception, unless the optional hardware >> module for handling misalignment is present. This misalignment >> module converts any misaligned operand references into a series >> of aligned bus cycles to access the data. The existence of the >> misalignment module is implementation-dependent and is documented >> in the appropriate ColdFire userÆs manual. I mentionned that only to make you able to soften the commit comment :) > > I wish Freescale really did make that clear within the doco for each > part! > > The oldest (and I assume simplest) part we support is the 5206, and it > does explicitly state in the MCF5206UM that it supports unaligned > accesses (Section 6.6). It is not as clear as this in some of the > other CPU/SoC User Manuals that I looked through. > > I am pretty confident that all the parts we currently support in Linux > do unaligned accesses. I agree. And if some parts did not implement it, we'd see it quickly. Regards Philippe ___ 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] m68knommu: allow ColdFire CPUs to use unaligned accesses
Hi Philippe, On 06/08/2012 08:39 PM, Philippe De Muyter wrote: On Fri, Jun 08, 2012 at 03:43:00PM +1000, g...@snapgear.com wrote: From: Greg Ungerer All current ColdFire CPUs are able to support unaligned memory accesses. So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire. It seems that the current restriction was inherrited from the early non-MMU support for the basic 68000 proecssors - which do not support unaligned accesses. It seems that the first ColdFires needed the restriction : I read in the "MCF5200 ColdFire Family ProgrammerÆs Reference Manual" : The ColdFire processor default configuration supports word- and longword-sized operand references on 0-modulo-2 and 0-modulo-4 addresses, respectively. All other references are defined as misaligned accesses. Any attempt to access a misaligned operand generates an address-error exception, unless the optional hardware module for handling misalignment is present. This misalignment module converts any misaligned operand references into a series of aligned bus cycles to access the data. The existence of the misalignment module is implementation-dependent and is documented in the appropriate ColdFire userÆs manual. I wish Freescale really did make that clear within the doco for each part! The oldest (and I assume simplest) part we support is the 5206, and it does explicitly state in the MCF5206UM that it supports unaligned accesses (Section 6.6). It is not as clear as this in some of the other CPU/SoC User Manuals that I looked through. I am pretty confident that all the parts we currently support in Linux do unaligned accesses. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close,FAX: +61 7 3891 3630 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ 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] m68knommu: allow ColdFire CPUs to use unaligned accesses
On Fri, Jun 08, 2012 at 03:43:00PM +1000, g...@snapgear.com wrote: > From: Greg Ungerer > > All current ColdFire CPUs are able to support unaligned memory accesses. > So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire. > > It seems that the current restriction was inherrited from the early non-MMU > support for the basic 68000 proecssors - which do not support unaligned > accesses. It seems that the first ColdFires needed the restriction : I read in the "MCF5200 ColdFire Family Programmer’s Reference Manual" : The ColdFire processor default configuration supports word- and longword-sized operand references on 0-modulo-2 and 0-modulo-4 addresses, respectively. All other references are defined as misaligned accesses. Any attempt to access a misaligned operand generates an address-error exception, unless the optional hardware module for handling misalignment is present. This misalignment module converts any misaligned operand references into a series of aligned bus cycles to access the data. The existence of the misalignment module is implementation-dependent and is documented in the appropriate ColdFire user’s manual. Philippe ___ 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] m68knommu: allow ColdFire CPUs to use unaligned accesses
On Fri, Jun 8, 2012 at 7:43 AM, wrote:
> From: Greg Ungerer
>
> All current ColdFire CPUs are able to support unaligned memory accesses.
> So remove the CONFIG_CPU_HAS_NO_UNALIGNED option selection for ColdFire.
>
> It seems that the current restriction was inherrited from the early non-MMU
> support for the basic 68000 proecssors - which do not support unaligned
> accesses.
>
> Signed-off-by: Greg Ungerer
I'll add this to my tree, as it depends on the other
CPU_HAS_NO_UNALIGNED patches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
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] m68k: make syscall_trace_enter/leave exist for non-MMU classic m68k types
On Fri, Jun 8, 2012 at 7:28 AM, wrote:
> From: Greg Ungerer
>
> The assembler entry code calls directly to the syscall_trace_enter() and
> syscall_trace_leave() functions. But currently they are conditionaly
> compiled out for the non-MMU classic m68k CPU types (so 68328 for example),
> resulting in a link error:
>
> LD vmlinux
> arch/m68k/platform/68328/built-in.o: In function `do_trace':
> (.text+0x1c): undefined reference to `syscall_trace_enter'
> arch/m68k/platform/68328/built-in.o: In function `do_trace':
> (.text+0x4c): undefined reference to `syscall_trace_leave'
>
> Change the conditional check that includes these functions to be true for
> the !defined(CONFIG_MMU) case as well.
>
> Signed-off-by: Greg Ungerer
Acked-by: Geert Uytterhoeven
Hmm, should add syscall_trace support to M68KCLASSIC/MMU...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
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] m68k: fix inclusion of arch_gettimeoffset for non-MMU 68k classic CPU types
On Fri, Jun 8, 2012 at 7:25 AM, wrote:
> From: Greg Ungerer
>
> When building for non-MMU based classic 68k CPU types (like the 68328 for
> example) you get a compilation error:
>
> CC arch/m68k/kernel/time.o
> arch/m68k/kernel/time.c:91:5: error: redefinition of ‘arch_gettimeoffset’
> include/linux/time.h:145:19: note: previous definition of
> ‘arch_gettimeoffset’ was here
>
> The arch_gettimeoffset() code is included when building for these CPU types,
> but it shouldn't be. Those machine types do not have
> CONFIG_ARCH_USES_GETTIMEOFFSET set.
>
> The fix is simply to conditionally include the arch_gettimeoffset() code on
> that same config setting that specifies its use or not.
>
> Signed-off-by: Greg Ungerer
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
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
