* Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Segher Boessenkool @ 2010-06-29 16:58 UTC (permalink / raw)
To: Steve Deiters; +Cc: linuxppc-dev
In-Reply-To: <181804936ABC2349BE503168465576460F272CA4@exchserver.basler.com>
> These processors will corrupt data if accessing the local bus with
> unaligned
> addresses. This version fixes the typical case of copying from
> Flash on
> the
> local bus by keeping the source address always aligned.
On many platforms accessing ROM as RAM simply doesn't work(*). You
shouldn't
map ROM as if it is RAM, and shouldn't use the same access functions
on it.
Segher
(*) Example: any existing 970 system will checkstop as soon as you
try to
do any cacheable access to some ROM. Another example of course is
unaligned
accesses on pretty much any system, no matter whether it's called a
bug or
a feature on that system :-P
^ permalink raw reply
* [RFC Patch 1/1] Implement hardware breakpoint interfaces for PowerPC BookE processors
From: K.Prasad @ 2010-06-29 16:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20100628135631.332818538@linux.vnet.ibm.com>
Introduce support for generic hw-breakpoint interfaces for PowerPC
BookIII E processors.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 2
arch/powerpc/include/asm/cputable.h | 4
arch/powerpc/include/asm/hw_breakpoint_booke.h | 46 ++
arch/powerpc/kernel/Makefile | 4
arch/powerpc/kernel/hw_breakpoint_booke.c | 429 +++++++++++++++++++++++++
arch/powerpc/kernel/process.c | 3
arch/powerpc/kernel/ptrace.c | 51 ++
arch/powerpc/kernel/traps.c | 9
include/linux/perf_event.h | 4
kernel/trace/trace_ksym.c | 4
10 files changed, 554 insertions(+), 2 deletions(-)
Index: linux-2.6.bookE/arch/powerpc/include/asm/hw_breakpoint_booke.h
===================================================================
--- /dev/null
+++ linux-2.6.bookE/arch/powerpc/include/asm/hw_breakpoint_booke.h
@@ -0,0 +1,46 @@
+#ifndef _I386_HW_BREAKPOINT_H
+#define _I386_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define __ARCH_HW_BREAKPOINT_H
+
+struct arch_hw_breakpoint {
+ unsigned int len;
+ unsigned long address;
+ unsigned long type;
+};
+
+#include <linux/kdebug.h>
+#include <linux/percpu.h>
+#include <linux/list.h>
+
+/* Breakpoint length beyond which we should use 'range' breakpoints */
+#define DAC_LEN 8
+#define HW_BREAKPOINT_ALIGN 0x3
+
+static inline int hw_breakpoint_slots(int type)
+{
+ return HBP_NUM;
+}
+
+struct perf_event;
+struct perf_sample_data;
+struct pmu;
+
+extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+extern void hw_breakpoint_handler(struct pt_regs *regs,
+ unsigned long debug_status);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+
+extern struct pmu perf_ops_bp;
+
+#endif /* __KERNEL__ */
+#endif /* _I386_HW_BREAKPOINT_H */
+
Index: linux-2.6.bookE/arch/powerpc/kernel/hw_breakpoint_booke.c
===================================================================
--- /dev/null
+++ linux-2.6.bookE/arch/powerpc/kernel/hw_breakpoint_booke.c
@@ -0,0 +1,429 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers for PowerPC BookIII E. Derived from
+ * "arch/powerpc/kernel/hw_breakpoint.c"
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2010 IBM Corporation
+ * Author: K.Prasad <prasad@linux.vnet.ibm.com>
+ *
+ */
+
+#include <linux/perf_event.h>
+#include <linux/hw_breakpoint.h>
+#include <linux/notifier.h>
+#include <linux/percpu.h>
+#include <linux/kprobes.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+
+#include <asm/hw_breakpoint_booke.h>
+#include <asm/reg_booke.h>
+#include <asm/uaccess.h>
+#include <asm/sstep.h>
+#include <asm/reg.h>
+
+/*
+ * Stores the breakpoints currently in use on each debug register for each CPU
+ * register for each cpus
+ */
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg[HBP_NUM]);
+
+int hw_breakpoint_weight(struct perf_event *bp)
+{
+ return (bp->attr.bp_len > DAC_LEN) ? 2 : 1;
+}
+
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint. Eventually we enable it in the debug control register.
+ *
+ * Atomic: we hold the counter->ctx->lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ int i;
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ unsigned long dbcr0 = mfspr(SPRN_DBCR0);
+
+ for (i = 0; i < HBP_NUM; i++) {
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg[i]);
+
+ if (*slot)
+ continue;
+ *slot = bp;
+ mtspr(SPRN_DAC1, info->address);
+ /* Clean the 'type' fields from DBCR0 to erase old values */
+ dbcr0 &= ~(DBCR0_DAC1W | DBCR0_DAC1R | DBCR0_DAC2W | DBCR0_DAC2R);
+
+ mtspr(SPRN_DBCR0, dbcr0 |
+ (info->type > i) | DBCR0_IDM);
+ /*
+ * Use DAC2 register in 'range' mode if the length of the
+ * breakpoint request is 'large'
+ */
+ if (unlikely(info->len > DAC_LEN)) {
+ /* Check if there's a free debug register */
+ if (i > (HBP_NUM - hw_breakpoint_weight(bp))) {
+ *slot = NULL;
+ mtspr(SPRN_DBCR0, dbcr0);
+ return -EBUSY;
+ }
+ slot++;
+ i++;
+ /*
+ * In 'range' mode use two debug registers, but copy
+ * same breakpoint structure in both slots
+ */
+ *slot = bp;
+ mtspr(SPRN_DAC2, info->address + info->len);
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) |
+ (info->type >> i) | DBCR0_IDM);
+ /* We support only 'inclusive' range for now */
+ mtspr(SPRN_DBCR2, DBCR2_DAC12M);
+ }
+ break;
+ }
+
+ return 0;
+}
+
+/*
+ * Uninstall the breakpoint contained in the given counter.
+ *
+ * First we search the debug address register it uses and then we disable
+ * it.
+ *
+ * Atomic: we hold the counter->ctx->lock and we only handle variables
+ * and registers local to this cpu.
+ */
+void arch_uninstall_hw_breakpoint(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ int i;
+ unsigned long dbcr0 = mfspr(SPRN_DBCR0);
+
+ for (i = 0; i < HBP_NUM; i++) {
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg[i]);
+
+ if (*slot != bp)
+ continue;
+ *slot = NULL;
+ dbcr0 &= ~((DBCR0_DAC1W | DBCR0_DAC1R) >> i);
+ mtspr(SPRN_DBCR0, dbcr0);
+ if (info->len > DAC_LEN) {
+ slot++;
+ i++;
+ *slot = NULL;
+ dbcr0 &= ~((DBCR0_DAC1W | DBCR0_DAC1R) >> i);
+ mtspr(SPRN_DBCR0, dbcr0);
+ }
+ break;
+ }
+
+ if (WARN_ONCE(i == HBP_NUM, "Can't find any breakpoint slot"))
+ return;
+}
+
+/*
+ * Perform cleanup of arch-specific counters during unregistration
+ * of the perf-event
+ */
+void arch_unregister_hw_breakpoint(struct perf_event *bp)
+{
+ /*
+ * If the breakpoint is unregistered between a hw_breakpoint_handler()
+ * and the single_step_dabr_instruction(), then cleanup the breakpoint
+ * restoration variables to prevent dangling pointers.
+ */
+ if (bp->ctx->task)
+ bp->ctx->task->thread.last_hit_ubp = NULL;
+}
+
+/*
+ * Check for virtual address in kernel space.
+ */
+int arch_check_bp_in_kernelspace(struct perf_event *bp)
+{
+ unsigned long va;
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
+ va = info->address;
+ return (va >= TASK_SIZE) && ((va + info->len - 1) >= TASK_SIZE);
+}
+
+/*
+ * Validate the arch-specific HW Breakpoint register settings
+ */
+int arch_validate_hwbkpt_settings(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
+ switch (bp->attr.bp_type) {
+ case HW_BREAKPOINT_R:
+ info->type = DBCR0_DAC1R;
+ break;
+ case HW_BREAKPOINT_W:
+ info->type = DBCR0_DAC1W;
+ break;
+ case HW_BREAKPOINT_W | HW_BREAKPOINT_R:
+ info->type = (DBCR0_DAC1W | DBCR0_DAC1R);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* Verify if breakpoint length is less than 2^32 bytes */
+ if (bp->attr.bp_len == (unsigned int)bp->attr.bp_len)
+ info->len = bp->attr.bp_len;
+ else
+ return -EINVAL;
+ info->address = bp->attr.bp_addr;
+ return 0;
+}
+
+/*
+ * Release the user breakpoints used by ptrace
+ */
+void flush_ptrace_hw_breakpoint(struct task_struct *tsk)
+{
+ struct thread_struct *t = &tsk->thread;
+
+ unregister_hw_breakpoint(t->ptrace_bps[0]);
+ t->ptrace_bps[0] = NULL;
+}
+
+
+/*
+ * Invoke this function to populate DAC register with values corresponding
+ * to the registered breakpoints. The list of breakpoints is learnt from the
+ * per-CPU 'bp_per_reg' structure.
+ */
+static void restore_breakpoint_dac(struct perf_event *bp)
+{
+ unsigned int i;
+ unsigned long dbcr0 = mfspr(SPRN_DBCR0);
+ struct arch_hw_breakpoint *bp_info = counter_arch_bp(bp);
+
+ /*
+ * Loop through the slots to identify the appropriate DAC register
+ * and restore the breakpoint values
+ */
+ for (i = 0; i < HBP_NUM; i++) {
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg[i]);
+
+ if (*slot != bp)
+ continue;
+
+ /* Restore the breakpoint */
+ dbcr0 |= DBCR0_IDM | (bp_info->type >> i);
+ i++;
+ if (unlikely((bp_info->len > DAC_LEN) && (i != HBP_NUM)))
+ dbcr0 |= (bp_info->type >> i);
+ mtspr(SPRN_DBCR0, dbcr0);
+ break;
+ }
+}
+
+/*
+ * Restores the breakpoint on the debug registers.
+ * Invoke this function if it is known that the execution context is about to
+ * change to cause loss of MSR_SE settings.
+ */
+void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs)
+{
+ struct perf_event *bp = NULL;
+
+ if (likely(!tsk->thread.last_hit_ubp))
+ return;
+
+ restore_breakpoint_dac(bp);
+ tsk->thread.last_hit_ubp = NULL;
+}
+
+static void ptrace_deliver_signal(int regnum)
+{
+ siginfo_t sig_info;
+
+ sig_info.si_signo = SIGTRAP;
+ sig_info.si_errno = TRAP_HWBKPT;
+
+ switch(regnum) {
+ /* DAC1 */
+ case 0:
+ /* si_code values are as seen in handle_debug() function */
+ sig_info.si_code = 5;
+ sig_info.si_addr = (void __user *)mfspr(SPRN_DAC1);
+ break;
+ /* DAC2 */
+ case 1:
+ sig_info.si_code = 6;
+ sig_info.si_addr = (void __user *)mfspr(SPRN_DAC2);
+ break;
+ }
+ force_sig_info(SIGTRAP, &sig_info, current);
+}
+
+void __kprobes hw_breakpoint_handler(struct pt_regs *regs,
+ unsigned long debug_status)
+{
+ int i, stepped = 0;
+ struct perf_event *bp = NULL;
+ struct arch_hw_breakpoint *bp_info;
+ unsigned int instr = 0;
+ unsigned long dbcr0;
+
+ /*
+ * Disable breakpoints during exception handling. Disable both MSR_DE
+ * and DBCR0_IDM to prevent pending exceptions.
+ */
+ mtmsr(mfmsr() & ~MSR_DE);
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~DBCR0_IDM);
+ dbcr0 = mfspr(SPRN_DBCR0);
+
+ /* Handle all the breakpoints that were triggered */
+ for (i = 0; i < HBP_NUM; ++i) {
+ if ((debug_status & ((DBSR_DAC1R | DBSR_DAC1W) >> i)) == 0)
+ continue;
+ /* Clear the debug status register by writing onto it */
+ mtspr(SPRN_DBSR, (DBSR_DAC1R | DBSR_DAC1W) >> i);
+ /* Clear DBSR for DAC2 if operating in 'range' mode */
+ if (mfspr(SPRN_DBCR2) & DBCR2_DAC12M)
+ mtspr(SPRN_DBSR, (DBSR_DAC1R | DBSR_DAC1W) >> (i + 1));
+
+ /*
+ * The counter may be concurrently released but that can only
+ * occur from a call_rcu() path. We can then safely fetch
+ * the breakpoint, use its callback, touch its counter
+ * while we are in an rcu_read_lock() path.
+ */
+ rcu_read_lock();
+ bp = __get_cpu_var(bp_per_reg[i]);
+ /*
+ * bp can be NULL due to lazy debug register switching
+ * or due to concurrent perf counter removing.
+ */
+ if (!bp)
+ goto out;
+ }
+ bp_info = counter_arch_bp(bp);
+
+ /*
+ * Return early after invoking user-callback function without restoring
+ * breakpoints if it originated from ptrace which always operates in
+ * one-shot mode.
+ */
+ if (bp->overflow_handler == ptrace_triggered) {
+ perf_bp_event(bp, regs);
+ ptrace_deliver_signal(i);
+ goto out;
+ }
+
+ /* Do not emulate user-mode instructions, instead, single-step them */
+ if (user_mode(regs)) {
+ bp->ctx->task->thread.last_hit_ubp = bp;
+ /*
+ * Clear the breakpoint register and single-step the
+ * causative instruction
+ */
+ dbcr0 &= ~((DBCR0_DAC1W | DBCR0_DAC1R) >> i);
+ /*
+ * Block-step and single-stepping (IC) is not supported
+ * simultaneously for now
+ */
+ dbcr0 &= ~DBCR0_BT;
+ mtspr(SPRN_DBCR0, dbcr0 | DBCR0_IC);
+ mtmsr(mfmsr() | MSR_DE);
+ goto out;
+ }
+ /*
+ * Attempt to emulate the causative instruction. If successful, then
+ * invoke the perf-callback and restore the breakpoint.
+ */
+ if (!__get_user_inatomic(instr, (unsigned int *) regs->nip))
+ stepped = emulate_step(regs, instr);
+ /*
+ * emulate_step() could not execute it. We've failed in reliably
+ * handling the hw-breakpoint. Unregister it and throw a warning
+ * message to let the user know about it.
+ */
+ if (!stepped) {
+ WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
+ "0x%lx will be disabled.", bp_info->address);
+ perf_event_disable(bp);
+ goto out;
+ }
+ perf_bp_event(bp, regs);
+ restore_breakpoint_dac(bp);
+ mtmsr(mfmsr() | MSR_DE);
+out:
+ rcu_read_unlock();
+}
+
+/*
+ * Handle single-step exceptions following a DAC hit
+ */
+int __kprobes single_step_dac_instruction(struct pt_regs *regs)
+{
+ struct arch_hw_breakpoint *bp_info;
+ struct perf_event *bp = NULL;
+
+ /* Disable single-stepping */
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~DBCR0_IC);
+ mtmsr(mfmsr() & ~MSR_DE);
+
+ bp = current->thread.last_hit_ubp;
+ /*
+ * Check if we are single-stepping as a result of a
+ * previous HW Breakpoint exception
+ */
+ if (!bp)
+ return NOTIFY_DONE;
+ bp_info = counter_arch_bp(bp);
+ /*
+ * We shall invoke the user-defined callback function in the single
+ * stepping handler to confirm to 'trigger-after-execute' semantics
+ */
+ perf_bp_event(bp, regs);
+ restore_breakpoint_dac(bp);
+ mtmsr(mfmsr() | MSR_DE);
+
+ return NOTIFY_STOP;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_exceptions_notify(
+ struct notifier_block *unused, unsigned long val, void *data)
+{
+ int ret = NOTIFY_DONE;
+
+ if (val == DIE_SSTEP)
+ ret = single_step_dac_instruction(data);
+ return ret;
+}
+
+void hw_breakpoint_pmu_read(struct perf_event *bp)
+{
+ /* TODO */
+}
Index: linux-2.6.bookE/arch/powerpc/kernel/traps.c
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/kernel/traps.c
+++ linux-2.6.bookE/arch/powerpc/kernel/traps.c
@@ -57,6 +57,9 @@
#ifdef CONFIG_FSL_BOOKE
#include <asm/dbell.h>
#endif
+#ifdef CONFIG_BOOKE
+#include <asm/hw_breakpoint_booke.h>
+#endif
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -1193,7 +1196,11 @@ void __kprobes DebugException(struct pt_
_exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
} else
- handle_debug(regs, debug_status);
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ hw_breakpoint_handler(regs, debug_status);
+ return;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+ handle_debug(regs, debug_status);
}
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
Index: linux-2.6.bookE/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/Kconfig
+++ linux-2.6.bookE/arch/powerpc/Kconfig
@@ -141,7 +141,7 @@ config PPC
select GENERIC_ATOMIC64 if PPC32
select HAVE_PERF_EVENTS
select HAVE_REGS_AND_STACK_ACCESS_API
- select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
+ select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (PPC_BOOK3S_64 || BOOKE))
config EARLY_PRINTK
bool
Index: linux-2.6.bookE/arch/powerpc/kernel/Makefile
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/kernel/Makefile
+++ linux-2.6.bookE/arch/powerpc/kernel/Makefile
@@ -34,7 +34,11 @@ obj-y += vdso32/
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o nvram_64.o firmware.o
+ifeq ($(CONFIG_BOOKE),y)
+obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint_booke.o
+else
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+endif
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_ppc970.o cpu_setup_pa6t.o
obj64-$(CONFIG_RELOCATABLE) += reloc_64.o
obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o
Index: linux-2.6.bookE/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6.bookE/arch/powerpc/kernel/ptrace.c
@@ -964,6 +964,56 @@ int ptrace_set_debugreg(struct task_stru
/* Move contents to the DABR register */
task->thread.dabr = data;
#else /* CONFIG_PPC_ADV_DEBUG_REGS */
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ /*
+ * For compatibility with existing ptrace design which uses only one
+ * breakpoint slot, we will use only one DAC register.
+ */
+ bp = thread->ptrace_bps[0];
+ if (!data) {
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ thread->dac1 = 0;
+ }
+ return 0;
+ }
+ if (bp) {
+ attr = bp->attr;
+ attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
+ /*
+ * Check for write and read flags and set DBCR0
+ * accordingly
+ */
+ dbcr_dac(task) &= ~(DBCR_DAC1R|DBCR_DAC1W);
+ if (data & 0x1UL)
+ attr.bp_type |= HW_BREAKPOINT_R;
+ if (data & 0x2UL)
+ attr.bp_type |= HW_BREAKPOINT_R;
+ ret = modify_user_hw_breakpoint(bp, &attr);
+ if (ret)
+ return ret;
+ thread->ptrace_bps[0] = bp;
+ thread->dac1 = data;
+ return 0;
+ }
+
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
+ if (data & 0x1UL)
+ attr.bp_type |= HW_BREAKPOINT_R;
+ if (data & 0x2UL)
+ attr.bp_type |= HW_BREAKPOINT_R;
+ thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
+ ptrace_triggered, task);
+ if (IS_ERR(bp)) {
+ thread->ptrace_bps[0] = NULL;
+ return PTR_ERR(bp);
+ }
+ thread->dac1 = data;
+
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
/* As described above, it was assumed 3 bits were passed with the data
* address, but we will assume only the mode bits will be passed
* as to not cause alignment restrictions for DAC-based processors.
@@ -999,6 +1049,7 @@ int ptrace_set_debugreg(struct task_stru
if (data & 0x2UL)
dbcr_dac(task) |= DBCR_DAC1W;
task->thread.regs->msr |= MSR_DE;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
return 0;
}
Index: linux-2.6.bookE/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6.bookE/arch/powerpc/include/asm/cputable.h
@@ -517,7 +517,11 @@ static inline int cpu_has_feature(unsign
}
#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_BOOKE
+#define HBP_NUM 2
+#else
#define HBP_NUM 1
+#endif /* CONFIG_BOOKE */
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif /* !__ASSEMBLY__ */
Index: linux-2.6.bookE/include/linux/perf_event.h
===================================================================
--- linux-2.6.bookE.orig/include/linux/perf_event.h
+++ linux-2.6.bookE/include/linux/perf_event.h
@@ -470,7 +470,11 @@ struct perf_guest_info_callbacks {
};
#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_BOOKE
+#include <asm/hw_breakpoint_booke.h>
+#else
#include <asm/hw_breakpoint.h>
+#endif /* CONFIG_BOOKE */
#endif
#include <linux/list.h>
Index: linux-2.6.bookE/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6.bookE.orig/arch/powerpc/kernel/process.c
+++ linux-2.6.bookE/arch/powerpc/kernel/process.c
@@ -329,6 +329,7 @@ static void prime_debug_regs(struct thre
mtspr(SPRN_IAC3, thread->iac3);
mtspr(SPRN_IAC4, thread->iac4);
#endif
+#ifndef CONFIG_HAVE_HW_BREAKPOINT
mtspr(SPRN_DAC1, thread->dac1);
mtspr(SPRN_DAC2, thread->dac2);
#if CONFIG_PPC_ADV_DEBUG_DVCS > 0
@@ -340,7 +341,9 @@ static void prime_debug_regs(struct thre
#ifdef CONFIG_BOOKE
mtspr(SPRN_DBCR2, thread->dbcr2);
#endif
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
}
+
/*
* Unless neither the old or new thread are making use of the
* debug registers, set the debug registers from the values
Index: linux-2.6.bookE/kernel/trace/trace_ksym.c
===================================================================
--- linux-2.6.bookE.orig/kernel/trace/trace_ksym.c
+++ linux-2.6.bookE/kernel/trace/trace_ksym.c
@@ -30,7 +30,11 @@
#include "trace.h"
#include <linux/hw_breakpoint.h>
+#ifdef CONFIG_BOOKE
+#include <asm/hw_breakpoint_booke.h>
+#else /* CONFIG_BOOKE */
#include <asm/hw_breakpoint.h>
+#endif /* CONFIG_BOOKE */
#include <asm/atomic.h>
^ permalink raw reply
* Re: kernel init exception
From: Segher Boessenkool @ 2010-06-29 16:51 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimV1AFEUrRf-2iEizXH4HQFMrrAumsRVDKxNfAv@mail.gmail.com>
> why there generated a signal 4 in init process?
That's SIGILL; sounds like you compiled init with the wrong (sub-)arch
or cpu flags.
Segher
^ permalink raw reply
* [RFC Patch 0/1] hw-breakpoint interfaces for BookE - ver II
From: K.Prasad @ 2010-06-29 16:51 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
Please find a new version of the patch that implements generic
hw-breakpoint interfaces for PowerPC BookIII E.
While there are several improvements over the previous version in terms
of code placement, support for ptrace and fixes for incorrect issues, the
patch remains compile-tested (only)(against 44x/iss476-smp_defconfig config)
and is yet to be tested on hardware (for functionality).
Changelog Version II
(Version I:linuxppc-dev message-id: 20100427164029.GA8303@in.ibm.com)
-------------------------------------------------------------------------
- ptrace requests (through PTRACE_SET_DEBUGREG and PTRACE_GET_DEBUGREG) are
now supported.
- Changes in original arch/powerpc/kernel/hw_breakpoint.c have been percolated
down to hw_breakpoint_booke.c (such as introduction of thread_change_pc(),
arch_unregister_hw_breakpoint() and changes to hw_breakpoint_handler())
along with some code re-arrangement (for brevity/clarity).
The usage of CONFIG (in this patch) option doesn't largely represent a
form that it would turn into after enabling the use of DVCs, DACs by non-ptrace
breakpoint requests. They should turn correct as versions of this patch progress.
Kindly let me know your comments.
Thanks,
K.Prasad
^ permalink raw reply
* [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
From: Steve Deiters @ 2010-06-29 16:04 UTC (permalink / raw)
To: linuxppc-dev
These processors will corrupt data if accessing the local bus with
unaligned
addresses. This version fixes the typical case of copying from Flash on
the
local bus by keeping the source address always aligned.
Signed-off-by: Steve Deiters <SteveDeiters@basler.com>
---
arch/powerpc/lib/copy_32.S | 56
++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index 74a7f41..42e7df5 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -226,6 +226,60 @@ _GLOBAL(memmove)
bgt backwards_memcpy
/* fall through */
=20
+#if defined(CONFIG_PPC_MPC512x) || defined(CONFIG_PPC_MPC52xx)
+
+/*
+ * Alternate memcpy for MPC512x and MPC52xx to guarantee source
+ * address is always aligned to prevent corruption issues when
+ * copying unaligned from the local bus. This only fixes the usage
+ * when copying from the local bus (e.g. Flash) and will not fix
+ * issues copying to the local bus
+ */
+_GLOBAL(memcpy)
+ srwi. r7,r5,3
+ addi r6,r3,-4
+ addi r4,r4,-4
+ beq 2f /* if less than 8 bytes to do */
+ andi. r0,r4,3 /* get src word aligned */
+ mtctr r7
+ bne 5f
+1: lwz r7,4(r4)
+ lwzu r8,8(r4)
+ stw r7,4(r6)
+ stwu r8,8(r6)
+ bdnz 1b
+ andi. r5,r5,7
+2: cmplwi 0,r5,4
+ blt 3f
+ andi. r0,r4,3
+ bne 3f
+ lwzu r0,4(r4)
+ addi r5,r5,-4
+ stwu r0,4(r6)
+3: cmpwi 0,r5,0
+ beqlr
+ mtctr r5
+ addi r4,r4,3
+ addi r6,r6,3
+4: lbzu r0,1(r4)
+ stbu r0,1(r6)
+ bdnz 4b
+ blr
+5: subfic r0,r0,4
+ mtctr r0
+6: lbz r7,4(r4)
+ addi r4,r4,1
+ stb r7,4(r6)
+ addi r6,r6,1
+ bdnz 6b
+ subf r5,r0,r5
+ rlwinm. r7,r5,32-3,3,31
+ beq 2b
+ mtctr r7
+ b 1b
+
+#else
+
_GLOBAL(memcpy)
srwi. r7,r5,3
addi r6,r3,-4
@@ -267,6 +321,8 @@ _GLOBAL(memcpy)
mtctr r7
b 1b
=20
+#endif
+
_GLOBAL(backwards_memcpy)
rlwinm. r7,r5,32-3,3,31 /* r0 =3D r5 >> 3 */
add r6,r3,r5
--=20
1.5.4.3
^ permalink raw reply related
* RE: Using devices trees on X86
From: Stephen Neuendorffer @ 2010-06-29 15:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss,
Paul Mackerras, sparclinux, linuxppc-dev, David Miller
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: Monday, June 28, 2010 7:39 PM
> To: Stephen Neuendorffer
> Cc: grant.likely@secretlab.ca; devicetree-discuss@lists.ozlabs.org;
David Miller;
> sparclinux@vger.kernel.org; Michal Simek;
microblaze-uclinux@itee.uq.edu.au; Benjamin Herrenschmidt;
> Paul Mackerras; linuxppc-dev@lists.ozlabs.org
> Subject: Re: Using devices trees on X86
> =
> Hi Stephen,
> =
> On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> >
> > 2) config OF is currently implemented in the architecture code.
This
> > should be non-architecture dependent and selected by the arches that
> > need it.
> >
> > Comments greatly appreciated, in particular if you have
> > likely-to-be-easy-to-get-accepted suggestions for 3), or feel like
> > carefully solving 2) in
> > a way which doesn't bork the existing of-based arches.
> =
> See the following patch set. Parts 1, 2 and 3 could be applied to the
> respective architecture trees as well as Grant's tree to aleviate some
> conflict problems. Part 5 could wait until a later time if necessary.
> However, this is relatively trivial, so we could just collect ACKs and
> put it all in Grant's tree and live with any minor pain.
> =
> Having OF in more than one Kconfig file should not cause any problems
as
> long as they are all the same.
Ah, well, that simplifies things.. :) Thanks!
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* kernel init exception
From: wilbur.chan @ 2010-06-29 15:21 UTC (permalink / raw)
To: linuxppc-dev
We are porting linux 2.6.21.7 to a powerpc e500mc board , p4080.
But something is wrong when loading init file:
log:
free init memory...
init has generated signal 4 but has no handler for it
I found it print in _exception --->
if (is_init(current)) {
if (handler == SIG_DFL) {
printk(KERN_CRIT "init has generated signal %d "
"but has no handler for it\n", signr);
do_exit(signr);
}
}
why there generated a signal 4 in init process?
Thanks
^ permalink raw reply
* ftp login problem using wu-ftpd
From: Stevan Ignjatovic @ 2010-06-29 14:16 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I ported Linux-2.6.30-rc8 on my custom mpc885 board. The filesystem I am
using is jffs2 which I created from
eldk-4.2/ppc_8xx/images/ramdisk_image.gz. Linux boots fine and I can
telnet to the board but I cannot ftp:
# ftp 10.8.1.5
Connected to 10.8.1.5.
220 10.8.1.5 FTP server (Version wu-2.6.2(1) Wed Apr 2 09:10:49 MEST
2008) ready.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (10.8.1.5:root): root
Here ftp connection hangs. Do I have to create another user (beside
root) in order to make ftp connection? Earlier, when I was using 2.4
linux I didn't have problems with ftp connection as root.
/etc/ftpaccess:
class all real,guest,anonymous *
email root@localhost
loginfails 5
readme README* login
readme README* cwd=*
message /welcome.msg login
message .message cwd=*
compress yes all
tar yes all
chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
log transfers anonymous,real inbound,outbound
shutdown /etc/shutmsg
passwd-check rfc822 warn
/etc/xinetd.d/wu-ftpd:
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
disable = no
}
/etc/pam.d/ftp:
#%PAM-1.0
auth include system-auth
auth required /lib/security/pam_listfile.so item=user sense=deny
file=/etc/ftpusers onerr=succeed
auth required /lib/security/pam_shells.so
account include system-auth
session include system-auth
Thanks in advance.
^ permalink raw reply
* Re: [PATCH] sched: fix spelling of sibling
From: David Howells @ 2010-06-29 14:14 UTC (permalink / raw)
To: Michael Neuling; +Cc: Peter Zijlstra, Ingo Molnar, linux-kernel, linuxppc-dev
In-Reply-To: <15249.1277776921@neuling.org>
Michael Neuling <mikey@neuling.org> wrote:
> No logic changes, only spelling.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-29 13:13 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29EFCC.3030303@suse.de>
On 06/29/2010 04:06 PM, Alexander Graf wrote:
>
> Are we looking at the same link? Looks good to me there.
>
>
We're probably looking at the same link but looking at different
things. I'm whining about
static u64 f() {
...
}
as opposed to the more sober
static u64 f()
{
...
}
for f in [kvmppc_mmu_hash_pte, kvmppc_mmu_hash_vpte,
kvmppc_mmu_hash_vpte_long].
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-29 13:06 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29EF8A.4070508@redhat.com>
Avi Kivity wrote:
> On 06/29/2010 03:56 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>>
>>>>
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>>>> +}
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>>>> +}
>>>>>> +
>>>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>>>> +}
>>>>>>
>>>>>>
>>>>>>
>>>>> Still with the wierd coding style?
>>>>>
>>>>>
>>>> Not sure what's going on there. My editor displays it normally. Weird.
>>>>
>>>>
>>> Try hitting 'save'.
>>>
>> hexdump -C on the respective section in the exact patch file I submitted
>> above shows:
>>
>> 00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
>> hash_64(eadd|
>> 00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r>>
>> PTE_SIZE, H|
>>
>>
>> Maybe your mail client breaks it?
>>
>
> The list archives too:
>
> http://www.mail-archive.com/kvm@vger.kernel.org/msg37093.html
>
> Looks like a cache coherency bug. What processor are you using?
Are we looking at the same link? Looks good to me there.
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-29 13:05 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29ED94.6060904@suse.de>
On 06/29/2010 03:56 PM, Alexander Graf wrote:
> Avi Kivity wrote:
>
>> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>
>>>
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>>> +}
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>>> +}
>>>>> +
>>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>>> +}
>>>>>
>>>>>
>>>>>
>>>> Still with the wierd coding style?
>>>>
>>>>
>>> Not sure what's going on there. My editor displays it normally. Weird.
>>>
>>>
>> Try hitting 'save'.
>>
> hexdump -C on the respective section in the exact patch file I submitted
> above shows:
>
> 00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
> hash_64(eadd|
> 00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r>>
> PTE_SIZE, H|
>
>
> Maybe your mail client breaks it?
>
The list archives too:
http://www.mail-archive.com/kvm@vger.kernel.org/msg37093.html
Looks like a cache coherency bug. What processor are you using?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-29 12:56 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C286770.6010204@redhat.com>
Avi Kivity wrote:
> On 06/28/2010 11:55 AM, Alexander Graf wrote:
>>
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_pte(u64 eaddr) {
>>>> + return hash_64(eaddr>> PTE_SIZE, HPTEG_HASH_BITS_PTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte(u64 vpage) {
>>>> + return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
>>>> +}
>>>> +
>>>> +static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage) {
>>>> + return hash_64((vpage& 0xffffff000ULL)>> 12,
>>>> + HPTEG_HASH_BITS_VPTE_LONG);
>>>> +}
>>>>
>>>>
>>> Still with the wierd coding style?
>>>
>> Not sure what's going on there. My editor displays it normally. Weird.
>>
>
> Try hitting 'save'.
hexdump -C on the respective section in the exact patch file I submitted
above shows:
00000a80 75 72 6e 20 68 61 73 68 5f 36 34 28 65 61 64 64 |urn
hash_64(eadd|
00000a90 72 20 3e 3e 20 50 54 45 5f 53 49 5a 45 2c 20 48 |r >>
PTE_SIZE, H|
Maybe your mail client breaks it?
Alex
^ permalink raw reply
* Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Anton Vorontsov @ 2010-06-29 12:44 UTC (permalink / raw)
To: Marek Vasut
Cc: linuxppc-dev, Rupjyoti Sarmah, linux-kernel, linux-ide, sr,
jgarzik
In-Reply-To: <201006290333.50673.marek.vasut@gmail.com>
On Tue, Jun 29, 2010 at 03:33:50AM +0200, Marek Vasut wrote:
> Dne Pá 4. června 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> > This patch enables the on-chip DWC SATA controller of the AppliedMicro
> > processor 460EX.
> >
> > Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> > Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> > Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
> >
>
> --SNIP--
>
> > + dev_err(ap->dev, "%s: Command not pending cmd_issued=%d "
> > + "(tag=%d) DMA NOT started\n", __func__,
> > + hsdevp->cmd_issued[tag], tag);
>
> Just a nitpick, but don't break strings if possible.
Note that in this particular case breaking strings was OK, and
was actually done in a clever manner.
That is, I doubt that anyone grep for error messages with
regexps, so grep "Command not pending" or grep "DMA NOT started"
would work.
This makes the code more readable (literally, because you don't
have to scroll to see dev_err's arguments) without sacrificing
grep'ability.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Rupjyoti Sarmah @ 2010-06-29 12:20 UTC (permalink / raw)
To: Marek Vasut, Rupjyoti Sarmah
Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <201006290333.50673.marek.vasut@gmail.com>
Hi,
Thanks for your feedback. I submitted an updated version of this patch
later.
I tried to limit the lines within 80 characters.
Regards,
Rup
-----Original Message-----
From: Marek Vasut [mailto:marek.vasut@gmail.com]
Sent: Tuesday, June 29, 2010 7:04 AM
To: Rupjyoti Sarmah
Cc: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org;
jgarzik@pobox.com; sr@denx.de; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
Dne P=C3=A1 4. =C4=8Dervna 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> This patch enables the on-chip DWC SATA controller of the AppliedMicro
> processor 460EX.
>
> Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>
--SNIP--
> + dev_err(ap->dev, "%s: Command not pending cmd_issued=3D%d "
> + "(tag=3D%d) DMA NOT started\n", __func__,
> + hsdevp->cmd_issued[tag], tag);
Just a nitpick, but don't break strings if possible.
^ permalink raw reply
* Re: [PATCH 01/26] KVM: PPC: Introduce shared page
From: Avi Kivity @ 2010-06-29 10:55 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C29C2E1.4000706@suse.de>
On 06/29/2010 12:54 PM, Alexander Graf wrote:
>
>> Code repeats 3x. Share please.
>>
> Looking at this again, I could combine the 3 lines of init code into 3
> lines of code that do a generic function call and then error checking.
> And I could convert the one free_page line with one function call that
> would free the page. Is there a real gain behind this?
>
>
Looks marginal, yes. It will help if initialization is expanded later,
but currently it doesn't help much.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 5/5] of: remove architecture CONFIG_OF definitions
From: Michal Simek @ 2010-06-29 9:58 UTC (permalink / raw)
To: Stephen Rothwell
Cc: microblaze-uclinux, David Miller, Paul Mackerras, sparclinux,
linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629124701.f879c55c.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> now that CONFIG_OF is defined globally
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Michal Simek <monstr@monstr.eu>
> ---
> arch/microblaze/Kconfig | 3 ---
> arch/powerpc/Kconfig | 3 ---
> arch/sparc/Kconfig | 3 ---
> 3 files changed, 0 insertions(+), 9 deletions(-)
>
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 2b37820..1a8f682 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -126,9 +126,6 @@ config CMDLINE_FORCE
> Set this to have arguments from the default kernel command string
> override those passed by the boot loader.
>
> -config OF
> - bool
> -
> config PROC_DEVICETREE
> bool "Support for device tree in /proc"
> depends on PROC_FS
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 3697231..402f4c0 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -174,9 +174,6 @@ config ARCH_MAY_HAVE_PC_FDC
> config PPC_OF
> def_bool y
>
> -config OF
> - bool
> -
> config PPC_UDBG_16550
> bool
> default n
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index d02e8ac..13a9f2f 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -149,9 +149,6 @@ config GENERIC_GPIO
> config ARCH_NO_VIRT_TO_BUS
> def_bool y
>
> -config OF
> - bool
> -
> config ARCH_SUPPORTS_DEBUG_PAGEALLOC
> def_bool y if SPARC64
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 1/5] microblaze: turn CONFIG_OF into a select
From: Michal Simek @ 2010-06-29 9:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: microblaze-uclinux, David Miller, Paul Mackerras, sparclinux,
linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629124200.20ca24b7.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> so that we can make CONFIG_OF global and remove it from
> the architecture Kconfig files later.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Michal Simek <monstr@monstr.eu>
> ---
> arch/microblaze/Kconfig | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 76818f9..2b37820 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -17,6 +17,8 @@ config MICROBLAZE
> select HAVE_DMA_ATTRS
> select HAVE_DMA_API_DEBUG
> select TRACING_SUPPORT
> + select OF
> + select OF_FLATTREE
>
> config SWAP
> def_bool n
> @@ -125,8 +127,7 @@ config CMDLINE_FORCE
> override those passed by the boot loader.
>
> config OF
> - def_bool y
> - select OF_FLATTREE
> + bool
>
> config PROC_DEVICETREE
> bool "Support for device tree in /proc"
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH 01/26] KVM: PPC: Introduce shared page
From: Alexander Graf @ 2010-06-29 9:54 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <4C274028.7020105@redhat.com>
Avi Kivity wrote:
> On 06/26/2010 02:24 AM, Alexander Graf wrote:
>> For transparent variable sharing between the hypervisor and guest, I
>> introduce
>> a shared page. This shared page will contain all the registers the
>> guest can
>> read and write safely without exiting guest context.
>>
>> This patch only implements the stubs required for the basic structure
>> of the
>> shared page. The actual register moving follows.
>>
>>
>> @@ -123,8 +123,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>> if (err)
>> goto free_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_vcpu;
>> +
>> return vcpu;
>>
>> +uninit_vcpu:
>> + kvm_vcpu_uninit(vcpu);
>> free_vcpu:
>> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
>> out:
>> @@ -135,6 +141,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_44x *vcpu_44x = to_44x(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvm_vcpu_uninit(vcpu);
>> kmem_cache_free(kvm_vcpu_cache, vcpu_44x);
>> }
>> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
>> index 884d4a5..ba79b35 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -1247,6 +1247,10 @@ struct kvm_vcpu
>> *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
>> if (err)
>> goto free_shadow_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_vcpu;
>> +
>> vcpu->arch.host_retip = kvm_return_point;
>> vcpu->arch.host_msr = mfmsr();
>> #ifdef CONFIG_PPC_BOOK3S_64
>> @@ -1277,6 +1281,8 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>>
>> return vcpu;
>>
>> +uninit_vcpu:
>> + kvm_vcpu_uninit(vcpu);
>> free_shadow_vcpu:
>> kfree(vcpu_book3s->shadow_vcpu);
>> free_vcpu:
>> @@ -1289,6 +1295,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_book3s *vcpu_book3s = to_book3s(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvm_vcpu_uninit(vcpu);
>> kfree(vcpu_book3s->shadow_vcpu);
>> vfree(vcpu_book3s);
>> diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
>> index e8a00b0..71750f2 100644
>> --- a/arch/powerpc/kvm/e500.c
>> +++ b/arch/powerpc/kvm/e500.c
>> @@ -117,8 +117,14 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct
>> kvm *kvm, unsigned int id)
>> if (err)
>> goto uninit_vcpu;
>>
>> + vcpu->arch.shared = (void*)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!vcpu->arch.shared)
>> + goto uninit_tlb;
>> +
>> return vcpu;
>>
>> +uninit_tlb:
>> + kvmppc_e500_tlb_uninit(vcpu_e500);
>> uninit_vcpu:
>> kvm_vcpu_uninit(vcpu);
>> free_vcpu:
>> @@ -131,6 +137,7 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> {
>> struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>>
>> + free_page((unsigned long)vcpu->arch.shared);
>> kvmppc_e500_tlb_uninit(vcpu_e500);
>> kvm_vcpu_uninit(vcpu);
>> kmem_cache_free(kvm_vcpu_cache, vcpu_e500);
>>
>
> Code repeats 3x. Share please.
Looking at this again, I could combine the 3 lines of init code into 3
lines of code that do a generic function call and then error checking.
And I could convert the one free_page line with one function call that
would free the page. Is there a real gain behind this?
Alex
^ permalink raw reply
* [PATCH] powerpc: disable SPARSE_IRQ by default
From: Li Yang @ 2010-06-29 9:32 UTC (permalink / raw)
To: benh, linuxppc-dev
The SPARSE_IRQ considerably adds overhead to critical path of IRQ
handling. However it doesn't benefit much in space for most systems with
limited IRQ_NR. Should be disabled unless really necessary.
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 328774b..6506bf4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -400,7 +400,7 @@ config IRQ_ALL_CPUS
config SPARSE_IRQ
bool "Support sparse irq numbering"
- default y
+ default n
help
This enables support for sparse irqs. This is useful for distro
kernels that want to define a high CONFIG_NR_CPUS value but still
@@ -409,7 +409,7 @@ config SPARSE_IRQ
( Sparse IRQs can also be beneficial on NUMA boxes, as they spread
out the irq_desc[] array in a more NUMA-friendly way. )
- If you don't know what to do here, say Y.
+ If you don't know what to do here, say N.
config NUMA
bool "NUMA support"
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Re: machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-06-29 8:37 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: ppcdev
In-Reply-To: <OF0E653CF5.2ED4C3A3-ONC1257751.002C6D6E-C1257751.002C903E@transmode.se>
>> =3D> bootm 1000000
>> ## Booting image at 01000000 ...
>> =A0 =A0Image Name: =A0 Linux-2.6.33.5
>> =A0 =A0Image Type: =A0 PowerPC Linux Kernel Image (gzip compressed)
>> =A0 =A0Data Size: =A0 =A0747319 Bytes =3D 729.8 kB
>> =A0 =A0Load Address: 00400000
>> =A0 =A0Entry Point: =A0004004d4
>
> Load and Entry Point should probably be 0
But the cuImage.adder875-uboot image also has the same load address as
mine and the entry point is 0x4004d8. Also cuImage.mpc885ads has the
same load address and entry point as cuImage.adder875-uboot. So I
don't suspect them.
All right. I built a uImage for mpc885ads and the uImage's load
address and entry point are both 0. So this is because I'm using
cuImage instead of uImage.
Thanks Joake, anyway.
-Shawn.
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Joakim Tjernlund @ 2010-06-29 8:06 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTinA2ghLxBU41aFAsLM1oXQ8HMASx1eQMDVvi56n@mail.gmail.com>
> From: Shawn Jin <shawnxjin@gmail.com>
>
> I'm porting a mpc870 board to the powerpc arch. The base is the
> adder-875 board. My first try to boot the cuImage.my870 is
> experiencing a machine check. And I have no clue where to look. Any
> help?
>
> => bootm 1000000
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.33.5
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 747319 Bytes = 729.8 kB
> Load Address: 00400000
> Entry Point: 004004d4
Load and Entry Point should probably be 0
Jocke
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Alexander Graf @ 2010-06-29 8:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <1550A5F0-3A22-48ED-8251-96328E2FEAE3@kernel.crashing.org>
On 29.06.2010, at 09:52, Segher Boessenkool wrote:
>>>>> Also, it seems you construct the physical address by masking out =
bits from
>>>>> the effective address. Most implementations will trap or machine =
check if
>>>>> you address outside of physical address space, instead.
>>>>=20
>>>> Well the only case where I remember to have hit a real RMO case is =
on the PS3 - that issues a data/instruction storage interrupt when =
accessing anything > 8MB in real mode.
>>>>=20
>>>> So I'd argue this is heavily implementation specific.
>>>=20
>>> It is. So what is the behaviour you want to implement?
>>=20
>> The one below.
>=20
> I'm sorry, I lost it. "Below"?
Well, the ones a few lines below :).
>=20
>>>> Apart from that what I'm trying to cover is that on ppc64 accessing =
0xc0000000000000 in real mode gets you 0x0. Is there a better name for =
this?
>>>=20
>>> (You missed two zeroes).
>>> In hypervisor real mode, the top few bits are magic. They are used =
for e.g.
>>> enabling hypervisor offset real mode.
>>> In supervisor real mode, those bits are ignored (and all other bits =
that do
>>> not correspond to physical address lines may also be ignored).
>>=20
>> So which bits exactly are reserved? I couldn't find a reference to =
that part.
>=20
> If by "reserved" you mean "cannot be used for addressing", it's the =
top four
> bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 =
document.
> Implementations are allowed to ignore more bits than that.
>=20
> I believe in earlier versions of the architecture it was the top two =
bits,
> not four, but maybe I misremember.
Ah, nice. So that part is implementation specific too. Awesome ;).
>=20
>>> Maybe you want to call it physical_address_mask or similar?
>>=20
>> PAM - doesn't sound bad :).
>=20
> And miraculously nothing in the Power arch uses that acronym yet! But =
I
> would spell it out if I were you, acronyms are confusing.
Well, the bad thing about not using acronyms here is that I'll run out =
of the 80 character limit pretty soon. And that means line wraps and =
more confusingness when reading the code.
Alex
^ permalink raw reply
* machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-06-29 7:59 UTC (permalink / raw)
To: ppcdev
I'm porting a mpc870 board to the powerpc arch. The base is the
adder-875 board. My first try to boot the cuImage.my870 is
experiencing a machine check. And I have no clue where to look. Any
help?
=> bootm 1000000
## Booting image at 01000000 ...
Image Name: Linux-2.6.33.5
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 747319 Bytes = 729.8 kB
Load Address: 00400000
Entry Point: 004004d4
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Bus Fault @ 0x00404c40, fixup 0x00000000
Machine check in kernel mode.
Caused by (from msr): regs 07d1cb80 Unknown values in msr
NIP: 00404C40 XER: 00000000 LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 00000001
MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 00404D50 07D1CC70 00000000 00000004 007FFF0C 00000001 0040AAB8 726F6F74
GPR08: 3D2F6465 0059D958 FF0009C0 0059DDDC FF003C00 1014BAC4 07FFF000 00000001
GPR16: 007FFF0D 004004D4 00000001 007FFF00 07FF9D78 FFFFFFFF 00000000 07D5D2A0
GPR24: 007FFEC0 00800000 00000000 00000000 00000000 0059D958 004129BC 00000000
Call backtrace:
machine check
Thanks alot,
-Shawn.
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Segher Boessenkool @ 2010-06-29 7:52 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <182AF505-54A6-4F71-AF5D-7CA40D911C35@suse.de>
>>>> Also, it seems you construct the physical address by masking out
>>>> bits from
>>>> the effective address. Most implementations will trap or
>>>> machine check if
>>>> you address outside of physical address space, instead.
>>>
>>> Well the only case where I remember to have hit a real RMO case
>>> is on the PS3 - that issues a data/instruction storage interrupt
>>> when accessing anything > 8MB in real mode.
>>>
>>> So I'd argue this is heavily implementation specific.
>>
>> It is. So what is the behaviour you want to implement?
>
> The one below.
I'm sorry, I lost it. "Below"?
>>> Apart from that what I'm trying to cover is that on ppc64
>>> accessing 0xc0000000000000 in real mode gets you 0x0. Is there a
>>> better name for this?
>>
>> (You missed two zeroes).
>> In hypervisor real mode, the top few bits are magic. They are
>> used for e.g.
>> enabling hypervisor offset real mode.
>> In supervisor real mode, those bits are ignored (and all other
>> bits that do
>> not correspond to physical address lines may also be ignored).
>
> So which bits exactly are reserved? I couldn't find a reference to
> that part.
If by "reserved" you mean "cannot be used for addressing", it's the
top four
bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 document.
Implementations are allowed to ignore more bits than that.
I believe in earlier versions of the architecture it was the top two
bits,
not four, but maybe I misremember.
>> Maybe you want to call it physical_address_mask or similar?
>
> PAM - doesn't sound bad :).
And miraculously nothing in the Power arch uses that acronym yet! But I
would spell it out if I were you, acronyms are confusing.
Segher
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox