| Age | Commit message (Collapse) | Author |
|---|
|
85xx exists in arch/powerpc as well as cuImage support to boot from
a u-boot that doesn't support device trees.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
This adds a cputable function pointer for the CPU-side machine
check handling. The semantic is still the same as the old one,
the one in ppc_md. overrides the one in cputable, though
ultimately we'll want to change that so the CPU gets first.
This removes CONFIG_440A which was a problem for multiplatform
kernels and instead fixes up the IVOR at runtime from a setup_cpu
function. The "A" version of the machine check also tweaks the
regs->trap value to differenciate the 2 versions at the C level.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
|
|
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
|
|
The new dcr code does not currently compile when configured for native
DCR access on ARCH=powerpc. This patch fixes the problems.
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
|
|
On 85xx we don't build in dcr support because the core doesn't implement the
instructions. This caused problems when building an 85xx kernel. Additionally
made it so we only build __mtdcr/__mfdcr if we are CONFIG_PPC_DCR_NATIVE.
The 85xx build issue wasPointed out by Dai Haruki.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
|
|
This fixes some debug register defines on PPC 40x that were incorrect.
Signed-off-by: Josh Boyer <jdub@us.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
|
|
This patch adds workaround for PPC 440GX erratum 440_43. According to
this erratum spurious MachineChecks (caused by L1 cache parity) can
happen during DataTLB miss processing. We disable L1 cache parity
checking for 440GX rev.C and rev.F
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
|
|
The e200 core is a Book-E core (similar to e500) that has a unified L1 cache
and is not cache coherent on the bus. The e200 core also adds a separate
exception level for debug exceptions. Part of this patch helps to cleanup a
few cases that are true for all Freescale Book-E parts, not just e500.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Moved common FPU exception handling code out of head.S so it can be used by
several of the sub-architectures that might of a full PowerPC FPU.
Also, uses new CONFIG_PPC_FPU define to fix alignment exception handling
for floating point load/store instructions to only occur if we have a
hardware FPU.
Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
To add support for 36-bit physical addressing on e500 the following changes
have been made. The changes are generalized to support any physical address
size larger than 32-bits:
* Allow FSL Book-E parts to use a 64-bit PTE, it is 44-bits of pfn, 20-bits
of flags.
* Introduced new CPU feature (CPU_FTR_BIG_PHYS) to allow runtime handling of
updating hardware register (SPRN_MAS7) which holds the upper 32-bits of
physical address that will be written into the TLB. This is useful since
not all e500 cores support 36-bit physical addressing.
* Currently have a pass through implementation of fixup_bigphys_addr
* Moved _PAGE_DIRTY in the 64-bit PTE case to free room for three additional
storage attributes that may exist in future FSL Book-E cores and updated
fault handler to copy these bits into the hardware TLBs.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
