This patch adds the Freescale MPC86xADS board support. The supported
devices are SMC UART and 10Mbit ethernet on SCC1.
The manual for the board says that it "is compatible with the MPC8xxFADS
for software point of view". That's why this patch extends FADS instead of
introducing a new platform.
FEC is not supported as the "combined FCC/FEC ethernet driver" driver by
Pantelis Antoniou should replace the current FEC driver.
Signed-off-by: Gennadiy Kurtsman <gkurtsman@ru.mvista.com>
Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
Acked-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I have tweaked this patch slightly to handle an empty list
of pages to relocate passed to relocate_new_kernel. And
I have added ppc_md.machine_crash_shutdown. To keep up with
the changes in the generic kexec infrastructure.
From: Albert Herranz <albert_herranz@yahoo.es>
The following patch adds support for kexec on the ppc32 platform.
Non-OpenFirmware based platforms are likely to work directly without
additional changes on the kernel side. The kexec-tools userland package
may need to be slightly updated, though.
For OpenFirmware based machines, additional work is still needed on the
kernel side before kexec support is ready. Benjamin Herrenschmidt is
kindly working on that part.
In order for a ppc platform to use the kexec kernel services it must
implement some ppc_md hooks. Otherwise, kexec will be explicitly disabled,
as suggested by benh.
There are 3+1 new ppc_md hooks that a platform supporting kexec may
implement. Two of them are mandatory for kexec to work. See
include/asm-ppc/machdep.h for details.
- machine_kexec_prepare(image)
This function is called to make any arrangements to the image before it
is loaded.
This hook _MUST_ be provided by a platform in order to activate kexec
support for that platform. Otherwise, the platform is considered to not
support kexec and the kexec_load system call will fail (that makes all
existing platforms by default non-kexec'able).
- machine_kexec_cleanup(image)
This function is called to make any cleanups on image after the loaded
image data it is freed. This hook is optional. A platform may or may
not provide this hook.
- machine_kexec(image)
This function is called to perform the _actual_ kexec. This hook
_MUST_ be provided by a platform in order to activate kexec support for
that platform.
If a platform provides machine_kexec_prepare but forgets to provide
machine_kexec, a kexec will fall back to a reboot.
A ready-to-use machine_kexec_simple() generic function is provided to,
hopefully, simplify kexec adoption for embedded platforms. A platform
may call this function from its specific machine_kexec hook, like this:
void myplatform_kexec(struct kimage *image)
{
machine_kexec_simple(image);
}
- machine_shutdown()
This function is called to perform any machine specific shutdowns, not
already done by drivers. This hook is optional. A platform may or may
not provide this hook.
An example (trimmed) platform specific module for a platform supporting
kexec through the existing machine_kexec_simple follows:
/* ... */
#ifdef CONFIG_KEXEC
int myplatform_kexec_prepare(struct kimage *image)
{
/* here, we can place additional preparations
*/
return 0; /* yes, we support kexec */
}
void myplatform_kexec(struct kimage *image)
{
machine_kexec_simple(image);
}
#endif /* CONFIG_KEXEC */
/* ... */
void __init
platform_init(unsigned long r3, unsigned long r4,
unsigned long r5,
unsigned long r6, unsigned long r7)
{
/* ... */
#ifdef CONFIG_KEXEC
ppc_md.machine_kexec_prepare =
myplatform_kexec_prepare;
ppc_md.machine_kexec =
myplatform_kexec;
#endif /* CONFIG_KEXEC */
/* ... */
}
The kexec ppc kernel support has been heavily tested on the GameCube Linux
port, and, as reported in the fastboot mailing list, it has been tested too
on a Moto 82xx ppc by Rick Richardson.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Signed-off-by: Eric Biederman <ebiederm@xmission.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.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>
For all architectures, this just means that you'll see a "Memory Model"
choice in your architecture menu. For those that implement DISCONTIGMEM,
you may eventually want to make your ARCH_DISCONTIGMEM_ENABLE a "def_bool
y" and make your users select DISCONTIGMEM right out of the new choice
menu. The only disadvantage might be if you have some specific things that
you need in your help option to explain something about DISCONTIGMEM.
Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Converted the MPC10x bridge support (used by MPC10x and 8240/1/5) to used
the standard platform device model.
Signed-off-by: Matt McClintock <msm@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>
This patch adds on-chip PCI bridge support for the PQ2 family. The
incomplete existent code is updated with interrupt handling stuff and
board-specific bits for 8272ADS and PQ2FADS; the related files were renamed
(from m8260_pci to m82xx_pci) to be of more generic fashion. This is
tested with 8266ADS and 8272ADS, should work on PQ2FADS as well.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In separating out support for hardware floating point we missed the fact
that both POWER3 and POWER4 have HW FP. Enable CONFIG_PPC_FPU for POWER3
and POWER4 fixes the issue.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Acked-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
While looking at code generated by gcc4.0 I noticed some functions still
had frame pointers, even after we stopped ppc64 from defining
CONFIG_FRAME_POINTER. It turns out kernel/Makefile hardwires
-fno-omit-frame-pointer on when compiling schedule.c.
Create CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER and define it on architectures
that dont require frame pointers in sched.c code.
(akpm: blame me for the name)
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A bunch of drivers use ISA DMA helpers or their equivalents for
platforms that have ISA with different DMA controller (a lot of ARM
boxen). Currently there is no way to put such dependency in Kconfig -
CONFIG_ISA is not it (e.g. it is not set on platforms that have no ISA
slots, but have on-board devices that pretend to be ISA ones).
New symbol added - ISA_DMA_API. Set when we have functional
enable_dma()/set_dma_mode()/etc. set of helpers. Next patches in the
series will add missing dependencies for drivers that need them.
I'm very carefully staying the hell out of the recurring flamefest on
what exactly CONFIG_ISA would mean in ideal world - added symbol has a
well-defined meaning and for now I really want to treat it as completely
independent from the mess around CONFIG_ISA.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
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!
