07 Jan, 2012
1 commit
-
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: (21 commits)
m68k/mac: Make CONFIG_HEARTBEAT unavailable on Mac
m68k/serial: Remove references to obsolete serial config options
m68k/net: Remove obsolete IRQ_FLG_* users
m68k: Don't comment out syscalls used by glibc
m68k/atari: Move declaration of atari_SCC_reset_done to header file
m68k/serial: Remove references to obsolete CONFIG_SERIAL167
m68k/hp300: Export hp300_ledstate
m68k: Initconst section fixes
m68k/mac: cleanup macro case
mac_scsi: fix mac_scsi on some powerbooks
m68k/mac: fix powerbook 150 adb_type
m68k/mac: fix baboon irq disable and shutdown
m68k/mac: oss irq fixes
m68k/mac: fix nubus slot irq disable and shutdown
m68k/mac: enable via_alt_mapping on performa 580
m68k/mac: cleanup forward declarations
m68k/mac: cleanup mac_irq_pending
m68k/mac: cleanup mac_clear_irq
m68k/mac: early console
m68k/mvme16x: Add support for EARLY_PRINTK
...Fix up trivial conflict in arch/m68k/Kconfig.debug due to new
EARLY_PRINTK config option addition clashing with movement of the
BOOTPARAM options.
30 Dec, 2011
11 commits
-
The ColdFire CPUs have their own startup and interrupt code (in the
platform/coldfire directory), and do not use the general m68k startup and
interrupt code. In fact the use of the arch/m68k/kernel/head.o is not about
CONFIG_MMU or not, it is really about the machine type we are compiling for.Modify the selection and use of head.o to be based on the machine type.
Only select the local ints.o and vectors.o code if we are using the classic
68k CPU types (that use the conventional Morotola MMU or SUN3 MMU).Signed-off-by: Greg Ungerer
Acked-by: Matt Waddel
Acked-by: Kurt Mahan -
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
Acked-by: Matt Waddel
Acked-by: Kurt Mahan -
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: Greg Ungerer
Acked-by: Geert Uytterhoeven
Acked-by: Matt Waddel
Acked-by: Kurt Mahan -
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
Acked-by: Geert Uytterhoeven
Acked-by: Matt Waddel
Acked-by: Kurt Mahan -
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
Acked-by: Matt Waddel
Acked-by: Kurt Mahan
Acked-by: Geert Uytterhoeven -
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
Acked-by: Geert Uytterhoeven
Acked-by: Matt Waddel
Acked-by: Kurt Mahan -
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
Acked-by: Geert Uytterhoeven
Acked-by: Matt Waddel
Acked-by: Kurt Mahan -
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
Acked-by: Geert Uytterhoeven
Acked-by: Matt Waddel
Acked-by: Kurt Mahan -
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
Acked-by: Geert Uytterhoeven
Acked-by: Matt Waddel
Acked-by: Kurt Mahan -
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
Acked-by: Matt Waddel
Acked-by: Kurt Mahan
Acked-by: Geert Uytterhoeven -
Update the show_cpuinfo() code to display info about ColdFire cores.
Signed-off-by: Greg Ungerer
Acked-by: Geert Uytterhoeven
Acked-by: Matt Waddel
Acked-by: Kurt Mahan
24 Dec, 2011
9 commits
-
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
-
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
Acked-by: Geert Uytterhoeven -
Commit 61619b12078dc8b85a3d4cbfa16f650daa341bd1 ("m68k: merge mmu and
non-mmu include/asm/entry.h files") made the trap entry code basically
the same for mmu and non-mmu builds. This means we no longer need code
to mark the stack frame as "system-call" type or other in the non-mmu
trap handling entry points. This is done in the SAVE_ALL_INT macro now.Signed-off-by: Greg Ungerer
-
The non-MMU builds of m68k allow a fixed kernel boot command line to
be configured at configure time. Allow this MMU builds as well.Signed-off-by: Greg Ungerer
-
Output a table of the kernel memory regions at boot time.
This is taken directly from the ARM architecture code that does this.
The table looks like this:Virtual kernel memory layout:
vector : 0x00000000 - 0x00000400 ( 0 KiB)
kmap : 0xd0000000 - 0xe0000000 ( 256 MiB)
vmalloc : 0xc0000000 - 0xcfffffff ( 255 MiB)
lowmem : 0x00000000 - 0x02000000 ( 32 MiB)
.init : 0x00128000 - 0x00134000 ( 48 KiB)
.text : 0x00020000 - 0x00118d54 ( 996 KiB)
.data : 0x00118d60 - 0x00126000 ( 53 KiB)
.bss : 0x00134000 - 0x001413e0 ( 53 KiB)This has been very useful while debugging the ColdFire virtual memory
support code. But in general I think it is nice to know extacly where
the kernel has layed everything out on boot.Signed-off-by: Greg Ungerer
-
The mach_gettod function pointer is only called from the time_no.c
code. So move its actual definition to there too. It is currently in
setup_no.c for no particularly good reason.Signed-off-by: Greg Ungerer
-
Currently on m68k we have a comeplete thread_info structure stored inside
of the thread_struct, and we also have it in the initial part of the kernel
stack. Mostly the code currently uses the one inside of the thread_struct,
only using the "task" pointer from the stack based one.This is wasteful and confusing, we should only have the single instance of
thread_info inside the stack page. And this is the norm for all other
architectures.This change makes m68k handle thread_info consistently on both MMU enabled
and non-MMU setups.Signed-off-by: Greg Ungerer
-
We have a duplicate name and definition for the offset of the thread.info
struct within the task struct in our asm-offsets.c code. Remove one of them,
and consolidate to use a single define, TASK_INFO.Signed-off-by: Greg Ungerer
Acked-by: Geert Uytterhoeven -
The init_task code can be the same for both mmu and non-mmu targets.
None of the alignment carried out in the the current init_task code
is necessary. The linker script takes care of aligning the init_thread
structure to a THREAD SIZE boundary, and that is all we need.So use the init_task.c code for all target types, that makes m68k
code consistent with what most other architectures do.Signed-off-by: Greg Ungerer
Acked-by: Geert Uytterhoeven
11 Dec, 2011
1 commit
-
Revive the old mac_serial_print() routine as mac_early_print(). mac_serial_print() did not function because it did not use the right offsets for its stack arguments. Fix this and make compilation conditional on CONFIG_EARLY_PRINTK instead of the obscure MAC_SERIAL_DEBUG macro.
Give mac_early_print() a new string length parameter to fit the early console API.
Send output to the framebuffer as well as serial ports.
Change the line rate to 38400 baud to match the default for the real (pmac_zilog) serial console.
Signed-off-by: Finn Thain
Signed-off-by: Geert Uytterhoeven
07 Dec, 2011
1 commit
-
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
09 Nov, 2011
11 commits
-
It was used on Apollo only, before its conversion to genirq.
Signed-off-by: Geert Uytterhoeven
-
Signed-off-by: Geert Uytterhoeven
-
Disabled on all platforms for now
Signed-off-by: Geert Uytterhoeven
[v1] Acked-by: Thomas Gleixner -
The m68k core irq code stopped honoring these flags during the irq
restructuring in 2006.Signed-off-by: Geert Uytterhoeven
-
- Rename m68k_handle_int() to generic_handle_irq(), and drop the unneeded
asmlinkage,
- Rename __m68k_handle_int() to do_IRQ().Signed-off-by: Geert Uytterhoeven
-
Signed-off-by: Geert Uytterhoeven
Acked-by: Thomas Gleixner -
It has nothing to do with the standard one in
Signed-off-by: Geert Uytterhoeven
Acked-by: Thomas Gleixner -
Signed-off-by: Geert Uytterhoeven
Acked-by: Thomas Gleixner -
Make it more similar to the genirq version:
- Add an irq fieldSigned-off-by: Geert Uytterhoeven
Acked-by: Thomas Gleixner -
Signed-off-by: Geert Uytterhoeven
Acked-by: Thomas Gleixner -
Make it more similar to the genirq version:
- Remove lock (unused as we don't do SMP anyway),
- Prepend methods with irq_,
- Make irq_startup() return unsigned int.Signed-off-by: Geert Uytterhoeven
Acked-by: Thomas Gleixner
01 Nov, 2011
1 commit
-
Signed-off-by: Paul Gortmaker
25 Oct, 2011
2 commits
-
* 'for-linus' of git://github.com/gregungerer/m68knommu:
m68k: drop unused Kconfig symbols
m68k: drop unused Kconfig symbols
m68knommu: create common externs for _ram* vars
m68knommu: remove extern declarations of memory_start/memory_end from mm/init
m68knommu: use generic section names in mm/init code
m68knommu: use generic section names in setup code
m68k: merge the mmu and non-mmu traps.c files
m68k: move hardware vector setting from traps.c to its own file
m68k: merge mmu and non-mmu include/asm/entry.h files
m68k: merge the mmu and non-mmu kernel/Makefiles
m68k: merge mmu and non-mmu arch Makefiles
m68k: reorganize Kconfig options to improve mmu/non-mmu selections
m68knommu: fix problems with SPI/GPIO on ColdFire 520x
m68k: fix memcpy to unmatched/unaligned source and dest on 68000 -
Markers have removed already twice:
1: fc5377668c3d808e1d53c4aee152c836f55c3490
2: eb878b3bc0349344dbf70c51bf01fc734d5cf2d3But a little bit is still here.
Signed-off-by: Tkhai Kirill
Signed-off-by: Geert Uytterhoeven
18 Oct, 2011
3 commits
-
Create common extern definitions of _rambase, _ramstart and _ramend
instead of them being externed when used in code.Signed-off-by: Greg Ungerer
-
We should be including and using sections.h to get at the extern
definitions of the linker sections in the m68knommu startup code.
Not defining them locally.Signed-off-by: Greg Ungerer
-
The code for handling traps in the non-mmu case is a subset of the mmu
enabled case. Merge the non-mmu traps_no.c code back to a single traps.c.
There is actually no code mmu specific here at all, and the processor
specific code (for the more complex 68020/68030/68040/68060) is already
proplerly conditionaly used.The format of console exception dump is a little different, but I don't
think will cause any one problems, it is purely for debug purposes.Signed-off-by: Greg Ungerer