If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5407 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 532x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 528x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5307 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 527x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5272 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5249 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 523x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 520x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5206 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

With a few small changes we can make the m68knommu timer init code the
same as the m68k code. By using the mach_sched_init function pointer
and reworking the current timer initializers to keep track of the common
m68k timer_interrupt() handler we end up with almost identical code for
m68knommu.

This will allow us to more easily merge the mmu and non-mmu m68k time.c
in future patches.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The read_persistent_clock() code is different on m68knommu, for really no
reason. With a few changes to support function names and some code
re-organization the code can be made the same.

This will make it easier to merge the arch/m68k/kernel/time.c for m68k and
m68knommu in a future patch.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

We had problems accessing our NOR flash trough mtd. The system always got
stuck at attaching UBI using ubiattach if booted from NFS or after mounting
squashfs as rootfs directly from NOR flash.
After some testing of the new changes introduced from v3.2-rc1 to v3.2-rc7
we had to apply the following patch to get mtd working again.

[gerg: The problem was ultimately caused by allocated kernel pages not having
the shared (SG) bit set. Without the SG bit set the MMU will look for page
matches incorporating the ASID as well. Things like module regions allocated
using vmalloc would fault when other processes run. ]
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The m68k core irq code stopped honoring these flags during the irq
restructuring in 2006.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

... some still remain weird :-/
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The V4e ColdFire CPU family also has an integrated FPU (as well as the MMU).
So add code to support this hardware along side the existing m68k FPU code.

The ColdFire FPU is of course different to all previous 68k FP units. It is
close in operation to the 68060, but not completely compatible. The biggest
issue to deal with is that the ColdFire FPU multi-move instructions are
different. It does not support multi-moving the FP control registers, and
the multi-move of the FP data registers uses a different instruction
mnemonic.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Add code to support the ColdFire V4e MMU pgalloc functions.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

The different ColdFire V4e MMU requires its own dedicated paging init
code, and a TLB miss handler for its software driven TLB.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

The ColdFire MMU has separate read and write bits, unlike the Motorola
m68k MMU which has a single read-only bit.

Define a _PAGE_READWRITE value for the Motorola MMU, which is 0, so we
can unconditionaly include that in the page table entry bits when setting
up ioremapped pages.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Add code to manage the context's of the ColdFire V4e MMU. This code is
mostly taken from the Freescale 2.6.35 kernel BSP for MMU enabled ColdFire.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Like the SUN3 hardware MMU the ColdFire MMU uses 8k pages. So we want
our ELF page size alingment to also be 8k. Modify the ELF alignment
setting.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

We use the ColdFire V4e MMU page size of 8KiB. Define PAGE_SHIFT
appropriately.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

The ColdFire CPU configurations need PAGE_OFFSET_RAW set to the base of
their RAM. It doesn't matter if they are running with the MMU enabled or
disabled, it is always set to the base of RAM.

We can keep the choices simple here and key of CONFIG_RAMBASE. If it is
defined we are on a plaftorm (ColdFire or other non-MMU systems) which
have a configurable RAM base, just use it.
Reported-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The ColdFire V4e MMU is unlike any of the other m68k MMU hardware.
It needs its own TLB flush support code.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Modify the cache setup for the ColdFire 54xx parts when running with
the MMU enabled.

We want to map the peripheral register space (MBAR region) as non
cacheable. And create an identity mapping for all of RAM for the
kernel.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Add code to deal with instruction, data and branch caches of the V4e
ColdFire cores when they are running with the MMU enabled.

This code is loosely based on Freescales changes for the caches of the
V4e ColdFire in the 2.6.25 kernel BSP. That code was originally by
Kurt Mahan <kmahan@freescale.com> (now <kmahan@xmission.com>).
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Define the page table size and attributes for the ColdFire V4e MMU.
Also setup the vmalloc and kmap regions we will use.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

The ColdFire V4e MMU is nothing like any of the other m68k MMU's.
So we need to create a set of definitions and support routines
for the kernels paging functions.

This is largely taken from Freescales BSP code for this (though it
was a 2.6.25 kernel). I have cleaned it up alot from the original.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Virtual memory m68k systems build with register a2 dedicated to being the
current proc pointer (non-MMU don't do this). Add code to the ColdFire
interrupt and exception processing to set this on entry, and at context
switch time. We use the same GET_CURRENT() macro that MMU enabled code
uses - modifying it so that the assembler is ColdFire clean.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Add code to the 54xx ColdFire CPU init to setup memory ready for the m68k
paged memory start up.

Some of the RAM variables that were specific to the non-mmu code paths
now need to be used during this setup, so when CONFIG_MMU is enabled.
Move these out of page_no.h and into page.h.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The ColdFire CPU family, and the original 68000, do not support separate
address spaces like the other 680x0 CPU types. Modify the set_fs()/get_fs()
functions and macros to use a thread_info addr_limit for address space
checking. This is pretty much what all other architectures that do not
support separate setable address spaces do.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Modify the user space access functions to support the ColdFire V4e cores
running with MMU enabled.

The ColdFire processors do not support the "moves" instruction used by
the traditional 680x0 processors for moving data into and out of another
address space. They only support the notion of a single address space,
and you use the usual "move" instruction to access that.

Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the
CPU types that support separate address spaces, and thus also support
the sfc/dfc registers and the "moves" instruction that go along with that.

The code is almost identical for user space access, so lets just use a
define to choose either the "move" or "moves" in the assembler code.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Add appropriate TASK_SIZE and TASK_UNMAPPED_BASE definitions for running
on ColdFire V4e cores with MMU enabled.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

The interrupt handling support defines and code is not so much conditional
on an MMU being present (CONFIG_MMU), as it is on which type of CPU we are
building for. So make the code conditional on the CPU types instead. The
current irq.h is mostly specific to the interrupt code for the 680x0 CPUs,
so it should only be used for them.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Basic register level definitions to support the internal MMU of the
V4e ColdFire cores.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Create machine and CPU definitions to support the ColdFire CPU family
members that have a virtual memory management unit.

The ColdFire V4e core contains an MMU, and it is quite different to
any other 68k family members.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

The code that used the anchor.h include file has long been removed from
the kernel. Remove it too.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The traditional 68000 processors and the newer reduced instruction set
ColdFire processors do not support the 32*32->64 multiply or the 64/32->32
divide instructions. This is not a difference based on the presence of
a hardware MMU or not.

Create a new config symbol to mark that a CPU type doesn't support the
longer multiply/divide instructions. Use this then as a basis for using
the fast 64bit based divide (in div64.h) and for linking in the extra
libgcc functions that may be required (mulsi3, divsi3, etc).
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

We have two implementations of the IP checksuming code for the m68k arch.
One uses the more advanced instructions available in 68020 and above
processors, the other uses the simpler instructions available on the
original 68000 processors and the modern ColdFire processors.

This simpler code is pretty much the same as the generic lib implementation
of the IP csum functions. So lets just switch over to using that. That
means we can completely remove the checksum_no.c file, and only have the
local fast code used for the more complex 68k CPU family members.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>