- 30 Dec, 2011 34 commits
-
-
Greg Ungerer authored
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:
Greg Ungerer <gerg@uclinux.org> Acked-by:
Matt Waddel <mwaddel@yahoo.com> Acked-by:
Kurt Mahan <kmahan@xmission.com>
-
Greg Ungerer authored
The exception return stack adjustment required by ColdFire when running with the MMU enabled is not completely identical to 680x0 processors. Specifically the format type 4 stack frame doesn't need any stack adjustment on exception return. And the ColdFire always must return with a frame type of 4, not 0. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
-
Greg Ungerer authored
Use the non-MMU linker script for ColdFire builds when we are building for MMU enabled. The image layout is correct for loading on existing ColdFire dev boards. The only addition required to the current non-MMU linker script is to add support for the fixup section. Signed-off-by:
-
Greg Ungerer authored
We want to use the same timer support code for ColdFire CPU's when running with MMU enabled or not. So use the same time_no.c code even when the MMU is enabled for ColdFire. This also means we do not want CONFIG_ARCH_USES_GETTIMEOFFSET set, since that code is only in time_mm.c. Signed-off-by:
-
Greg Ungerer authored
We use the same setup code for ColdFire MMU enabled platforms as standard m68k. So add support for it to setup our 54xx ColdFire platforms. They do not support the same bootinfo parsing as other m68k platforms. Signed-off-by:
-
Greg Ungerer authored
No matter whether we are configured for non-MMU or MMU enabled if we are compiling for ColdFire CPU we always use the entry_no.S code. Signed-off-by:
-
Greg Ungerer authored
Add code to support the ColdFire V4e MMU pgalloc functions. Signed-off-by:
-
Greg Ungerer authored
Create a config symbol to enable when using a ColdFire MMU. We then use that to only compile the necessary arch mm files. Signed-off-by:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
The cache push and clear code only need to flush the branch cache on the write-through cache setup of the ColdFire V4e with MMU enabled. Signed-off-by:
-
Greg Ungerer authored
The existing ColdFire code (which is all non-mmu) for system call entry and exit uses the more modern tracehook_report_syscall_entry()/exit() into the ptrace code. Now that we are supporting ColdFire with MMU we need the same hooks for these. Signed-off-by:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
We use the ColdFire V4e MMU page size of 8KiB. Define PAGE_SHIFT appropriately. Signed-off-by:
-
Greg Ungerer authored
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:
Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by:
-
Greg Ungerer authored
The ColdFire V4e MMU is unlike any of the other m68k MMU hardware. It needs its own TLB flush support code. Signed-off-by:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
Add code to traps.c to handle MMU exceptions for the ColdFire. Most of this code is from the 2.6.25 kernel BSP code released by Freescale. Signed-off-by:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
The 54xx ColdFire CPU family has an internal MMU. Up to now though we have only supported running on them with the MMU disabled. Add code to the 54xx ColdFire init sequence to initialize the bootmem used by the usual MMU m68k code for paging init. Signed-off-by:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
Add appropriate TASK_SIZE and TASK_UNMAPPED_BASE definitions for running on ColdFire V4e cores with MMU enabled. Signed-off-by:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
Basic register level definitions to support the internal MMU of the V4e ColdFire cores. Signed-off-by:
-
Greg Ungerer authored
Update the show_cpuinfo() code to display info about ColdFire cores. Signed-off-by:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
Compiling for the m68knommu/68328 Palm/Pilot target you get: LD vmlinux arch/m68k/platform/68328/head.o: In function `L3': (.text+0x170): undefined reference to `rom_length' "rom_length" is not used any longer by any of the m68knommu code. So remove it from here too. Signed-off-by: -
Greg Ungerer authored
Compiling for the m68knommu/68328 Palm/Pilot target you get: AS arch/m68k/platform/68328/head-pilot.o arch/m68k/platform/68328/head-pilot.S:37:23: fatal error: bootlogo.rh: No such file or directory The build for this target used to do a conversion on a C coded boot logo and include this in the head assembler code. This got broken by changes to the local Makefile. Clean all this up by just including the C coded boot logo struct in the C code. With the appropriate alignment attribute there is no difference to the way it can be used. Signed-off-by:
-
- 24 Dec, 2011 6 commits
-
-
Greg Ungerer authored
The merge of m68knommu left the linker scripts a little disorganized. Some consistent naming and squashing two of scripts that just include others can simplify things a lot. So merge the two simple including scripts, and rename the nommu script to be consistent with the existing m68k linker scripts. Signed-off-by: -
Greg Ungerer authored
The code that used the anchor.h include file has long been removed from the kernel. Remove it too. Signed-off-by: -
Greg Ungerer authored
There is a race on reading the ColdFire slice timer current count and the total clock count so far. Interrupts are off, and we may have just missed getting a new timer wrap event interrupt. Check for this and adjust the cycle count and current read count accordingly. Also the slice timer counts down from the terminal count. So in read_clk() we need take the current clock count away from the terminal count. Reported-by:
-
Greg Ungerer authored
Disbale the CPU cache really early in the ColdFire startup code. We set up some variables for RAM sizing and we want to make they stick in RAM. Signed-off-by:
-
Greg Ungerer authored
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:
-
Greg Ungerer authored
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:
-
