* Re: FT u-boot shim
From: Geert Uytterhoeven @ 2006-04-26 19:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20060426191957.14C4F353DAC@atlas.denx.de>
On Wed, 26 Apr 2006, Wolfgang Denk wrote:
> In message <A8793E99-83C1-4FD9-8735-D2E8F98B3003@kernel.crashing.org> you wrote:
> > How would you propose that we handle booting arch/powerpc kernels
> > from u-boot going forward? (for new board ports and existing board
> > ports).
>
> Ideally, I'd like to see a common kernel interface for all archi-
> tectures, PowerPC and ARM and MIPS and ... But last time I dared to
> suggest this I've been told what a nincompoop I am.
Let's hope Linux Darwinism will convergenge to a common kernel interface...
> I will accept what is decided by the P.T.B., but I request not to
> break backwards compatibility with existing systems.
[ dict ptb -> Physikalisch-Technische Bundesanstalt ? ]
Ah, Powers That Be!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: How do you make linux 2.6.10 U-Boot aware?
From: Steven Blakeslee @ 2006-04-26 18:57 UTC (permalink / raw)
To: Howard, Marc, linuxppc-embedded
> I'm using MontaVista linux 4.01 for the PPC440GX which is=20
> based on 2.6.10. It doesn't read the bootargs from U-Boot=20
> however. Does anyone out there have a synopsis of what needs=20
> to be modified (bd_info, etc.) to make this work with a=20
> 2.6.10 based release?
>=20
The bd_info structure needs to come from ppcboot.h and the make command
is "make uImage" That should be about it.
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-26 19:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <A8793E99-83C1-4FD9-8735-D2E8F98B3003@kernel.crashing.org>
In message <A8793E99-83C1-4FD9-8735-D2E8F98B3003@kernel.crashing.org> you wrote:
>
> I think thats part of the idea with arch/powerpc defining a standard
> mechanism for how a boot loader should pass information to the kernel
> (via a flat device tree).
Yet another standard.
> How would you propose that we handle booting arch/powerpc kernels
> from u-boot going forward? (for new board ports and existing board
> ports).
Ideally, I'd like to see a common kernel interface for all archi-
tectures, PowerPC and ARM and MIPS and ... But last time I dared to
suggest this I've been told what a nincompoop I am.
I will accept what is decided by the P.T.B., but I request not to
break backwards compatibility with existing systems.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Monday is an awful way to spend one seventh of your life.
^ permalink raw reply
* [PATCH] ppc64_softreset_patch
From: David Wilder @ 2006-04-26 18:03 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
Please pick up this patch.
This is a re-do of the ppc64-soft-reset-fix.patch. I have included
changes suggested by Olaf and Andrew and combined it with the
ppc64-kexec-tools-rm-platform-fix.patch to remove the dependency.
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: ppc64-softreset-fixes.patch --]
[-- Type: text/x-patch, Size: 12385 bytes --]
- When a system hangs, user will activate the soft-reset to initiate the kdump boot. But, soft-reset behavior is indeterminate on sending FWNMI to all CPUS. i.e, all CPUs will not get FW NMI at the same time. When the first CPU entered (calling primary CPU here onwards) kdump using crash_kexec(), sends an IPI to other CPUs. Some CPUs will respond to this IPI and execute crash_ipi_callback() before receive NMI. When they receive FW NMI, will execute die() and waiting forever since no more kdump IPI coming from the primary CPU. This issue will be fixed by invoking crash_kexec_secondary() directly from die().
Since the secondary CPUs will enter the IPI_callback function two times, CPU states have to be saved only once and the primary CPU has to start kdump boot after all CPUs are stopped. Hence, cpus_in_crash bitmap is used to determine whether pt_regs is saved. If the bit is not set, regs will be saved. Introduced cpus_in_sr bitmap and enter_on_soft_reset counter which are used to let the primary CPU know that all secondary CPUs entered via soft-reset and ready to do down.
- For the crash scenario, when a CPU hangs with interrupts disabled and the other CPUs panic or user invoked kdump boot using sysrq-c. In this case, the hung CPU can not be stopped and causes the kdump boot not successful. This case can be treated as complete system hang and asks the user to activate soft-reset if all secondary CPUs are not stopped.
Signed-off-by: David Wilder <dwilder@us.ibm.com>
Signed-off-by: Haren Myneni <haren@us.ibm.com>
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 778f22f..20ef5d2 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -23,9 +23,11 @@
#include <linux/elfcore.h>
#include <linux/init.h>
#include <linux/types.h>
+#include <linux/irq.h>
#include <asm/processor.h>
#include <asm/machdep.h>
+#include <asm/kexec.h>
#include <asm/kdump.h>
#include <asm/lmb.h>
#include <asm/firmware.h>
@@ -40,6 +42,7 @@
/* This keeps a track of which one is crashing cpu. */
int crashing_cpu = -1;
+static cpumask_t cpus_in_crash = CPU_MASK_NONE;
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
@@ -97,34 +100,66 @@ static void crash_save_this_cpu(struct p
}
#ifdef CONFIG_SMP
-static atomic_t waiting_for_crash_ipi;
+static atomic_t enter_on_soft_reset = ATOMIC_INIT(0);
void crash_ipi_callback(struct pt_regs *regs)
{
int cpu = smp_processor_id();
- if (cpu == crashing_cpu)
- return;
-
if (!cpu_online(cpu))
return;
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 1);
-
local_irq_disable();
+ if (!cpu_isset(cpu, cpus_in_crash))
+ crash_save_this_cpu(regs, cpu);
+ cpu_set(cpu, cpus_in_crash);
- crash_save_this_cpu(regs, cpu);
- atomic_dec(&waiting_for_crash_ipi);
+ /*
+ * Entered via soft-reset - could be the kdump
+ * process is invoked using soft-reset or user activated
+ * it if some CPU did not respond to an IPI.
+ * For soft-reset, the secondary CPU can enter this func
+ * twice. 1 - using IPI, and 2. soft-reset.
+ * Tell the kexec CPU that entered via soft-reset and ready
+ * to go down.
+ */
+ if (cpu_isset(cpu, cpus_in_sr)) {
+ cpu_clear(cpu, cpus_in_sr);
+ atomic_inc(&enter_on_soft_reset);
+ }
+
+ /*
+ * Starting the kdump boot.
+ * This barrier is needed to make sure that all CPUs are stopped.
+ * If not, soft-reset will be invoked to bring other CPUs.
+ */
+ while (!cpu_isset(crashing_cpu, cpus_in_crash))
+ cpu_relax();
+
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 1);
kexec_smp_wait();
/* NOTREACHED */
}
-static void crash_kexec_prepare_cpus(void)
+/*
+ * Wait until all CPUs are entered via soft-reset.
+ */
+static void crash_soft_reset_check(int cpu)
+{
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
+
+ cpu_clear(cpu, cpus_in_sr);
+ while (atomic_read(&enter_on_soft_reset) != ncpus)
+ cpu_relax();
+}
+
+
+static void crash_kexec_prepare_cpus(int cpu)
{
unsigned int msecs;
- atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
crash_send_ipi(crash_ipi_callback);
smp_wmb();
@@ -132,14 +167,13 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: Until we will have the way to stop other CPUSs reliabally,
* the crash CPU will send an IPI and wait for other CPUs to
- * respond. If not, proceed the kexec boot even though we failed to
- * capture other CPU states.
+ * respond.
* Delay of at least 10 seconds.
*/
- printk(KERN_ALERT "Sending IPI to other cpus...\n");
+ printk(KERN_EMERG "Sending IPI to other cpus...\n");
msecs = 10000;
- while ((atomic_read(&waiting_for_crash_ipi) > 0) && (--msecs > 0)) {
- barrier();
+ while ((cpus_weight(cpus_in_crash) < ncpus) && (--msecs > 0)) {
+ cpu_relax();
mdelay(1);
}
@@ -148,18 +182,71 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: In case if we do not get all CPUs, one possibility: ask the
* user to do soft reset such that we get all.
- * IPI handler is already set by the panic cpu initially. Therefore,
- * all cpus could invoke this handler from die() and the panic CPU
- * will call machine_kexec() directly from this handler to do
- * kexec boot.
- */
- if (atomic_read(&waiting_for_crash_ipi))
- printk(KERN_ALERT "done waiting: %d cpus not responding\n",
- atomic_read(&waiting_for_crash_ipi));
+ * Soft-reset will be used until better mechanism is implemented.
+ */
+ if (cpus_weight(cpus_in_crash) < ncpus) {
+ printk(KERN_EMERG "done waiting: %d cpu(s) not responding\n",
+ ncpus - cpus_weight(cpus_in_crash));
+ printk(KERN_EMERG "Activate soft-reset to stop other cpu(s)\n");
+ cpus_in_sr = CPU_MASK_NONE;
+ atomic_set(&enter_on_soft_reset, 0);
+ while (cpus_weight(cpus_in_crash) < ncpus)
+ cpu_relax();
+ }
+ /*
+ * Make sure all CPUs are entered via soft-reset if the kdump is
+ * invoked using soft-reset.
+ */
+ if (cpu_isset(cpu, cpus_in_sr))
+ crash_soft_reset_check(cpu);
/* Leave the IPI callback set */
}
+
+/*
+ * This function will be called by secondary cpus or by kexec cpu
+ * if soft-reset is activated to stop some CPUs.
+ */
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ int cpu = smp_processor_id();
+ unsigned long flags;
+ int msecs = 5;
+
+ local_irq_save(flags);
+ /* Wait 5ms if the kexec CPU is not entered yet. */
+ while (crashing_cpu < 0) {
+ if (--msecs < 0) {
+ /*
+ * Either kdump image is not loaded or
+ * kdump process is not started - Probably xmon
+ * exited using 'x'(exit and recover) or
+ * kexec_should_crash() failed for all running tasks.
+ */
+ cpu_clear(cpu, cpus_in_sr);
+ local_irq_restore(flags);
+ return;
+ }
+ mdelay(1);
+ cpu_relax();
+ }
+ if (cpu == crashing_cpu) {
+ /*
+ * Panic CPU will enter this func only via soft-reset.
+ * Wait until all secondary CPUs entered and
+ * then start kexec boot.
+ */
+ crash_soft_reset_check(cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
+ machine_kexec(kexec_crash_image);
+ /* NOTREACHED */
+ }
+ crash_ipi_callback(regs);
+}
+
#else
-static void crash_kexec_prepare_cpus(void)
+static void crash_kexec_prepare_cpus(int cpu)
{
/*
* move the secondarys to us so that we can copy
@@ -170,6 +257,10 @@ static void crash_kexec_prepare_cpus(voi
smp_release_cpus();
}
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ cpus_in_sr = CPU_MASK_NONE;
+}
#endif
void default_machine_crash_shutdown(struct pt_regs *regs)
@@ -185,15 +276,14 @@ void default_machine_crash_shutdown(stru
* The kernel is broken so disable interrupts.
*/
local_irq_disable();
-
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 0);
-
/*
* Make a note of crashing cpu. Will be used in machine_kexec
* such that another IPI will not be sent.
*/
crashing_cpu = smp_processor_id();
- crash_kexec_prepare_cpus();
crash_save_this_cpu(regs, crashing_cpu);
+ crash_kexec_prepare_cpus(crashing_cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
}
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 064a525..ad6500e 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -51,9 +51,13 @@
#include <asm/firmware.h>
#include <asm/processor.h>
#endif
+#include <asm/kexec.h>
#ifdef CONFIG_PPC64 /* XXX */
#define _IO_BASE pci_io_base
+#ifdef CONFIG_KEXEC
+cpumask_t cpus_in_sr = CPU_MASK_NONE;
+#endif
#endif
#ifdef CONFIG_DEBUGGER
@@ -96,7 +100,7 @@ static DEFINE_SPINLOCK(die_lock);
int die(const char *str, struct pt_regs *regs, long err)
{
- static int die_counter, crash_dump_start = 0;
+ static int die_counter;
if (debugger(regs))
return 1;
@@ -128,22 +132,12 @@ int die(const char *str, struct pt_regs
print_modules();
show_regs(regs);
bust_spinlocks(0);
-
- if (!crash_dump_start && kexec_should_crash(current)) {
- crash_dump_start = 1;
- spin_unlock_irq(&die_lock);
- crash_kexec(regs);
- /* NOTREACHED */
- }
spin_unlock_irq(&die_lock);
- if (crash_dump_start)
- /*
- * Only for soft-reset: Other CPUs will be responded to an IPI
- * sent by first kexec CPU.
- */
- for(;;)
- ;
+ if (kexec_should_crash(current))
+ crash_kexec(regs);
+ crash_kexec_secondary(regs);
+
if (in_interrupt())
panic("Fatal exception in interrupt");
@@ -205,6 +199,10 @@ void system_reset_exception(struct pt_re
if (ppc_md.system_reset_exception(regs))
return;
}
+
+#ifdef CONFIG_KEXEC
+ cpu_set(smp_processor_id(), cpus_in_sr);
+#endif
die("System Reset", regs, SIGABRT);
diff --git a/include/asm-powerpc/kexec.h b/include/asm-powerpc/kexec.h
index 6a2af2f..7eb2bb2 100644
--- a/include/asm-powerpc/kexec.h
+++ b/include/asm-powerpc/kexec.h
@@ -31,9 +31,8 @@
#define KEXEC_ARCH KEXEC_ARCH_PPC
#endif
-#ifdef CONFIG_KEXEC
-
#ifndef __ASSEMBLY__
+#ifdef CONFIG_KEXEC
#ifdef __powerpc64__
/*
* This function is responsible for capturing register states if coming
@@ -114,6 +113,7 @@ extern void kexec_smp_wait(void); /* get
extern void __init kexec_setup(void);
extern int crashing_cpu;
extern void crash_send_ipi(void (*crash_ipi_callback)(struct pt_regs *));
+extern cpumask_t cpus_in_sr;
#endif /* __powerpc64 __ */
struct kimage;
@@ -123,8 +123,10 @@ extern int default_machine_kexec_prepare
extern void default_machine_crash_shutdown(struct pt_regs *regs);
extern void machine_kexec_simple(struct kimage *image);
-
-#endif /* ! __ASSEMBLY__ */
+extern void crash_kexec_secondary(struct pt_regs *regs);
+#else
+static inline void crash_kexec_secondary(struct pt_regs *regs) { }
#endif /* CONFIG_KEXEC */
+#endif /* ! __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_KEXEC_H */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index cfb3410..6427949 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -106,6 +106,7 @@ extern struct page *kimage_alloc_control
extern void crash_kexec(struct pt_regs *);
int kexec_should_crash(struct task_struct *);
extern struct kimage *kexec_image;
+extern struct kimage *kexec_crash_image;
#define KEXEC_ON_CRASH 0x00000001
#define KEXEC_ARCH_MASK 0xffff0000
diff --git a/kernel/kexec.c b/kernel/kexec.c
index bf39d28..950559d 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -903,7 +903,7 @@ static int kimage_load_segment(struct ki
* that to happen you need to do that yourself.
*/
struct kimage *kexec_image = NULL;
-static struct kimage *kexec_crash_image = NULL;
+struct kimage *kexec_crash_image = NULL;
/*
* A home grown binary mutex.
* Nothing can wait so this mutex is safe to use
@@ -1042,7 +1042,6 @@ asmlinkage long compat_sys_kexec_load(un
void crash_kexec(struct pt_regs *regs)
{
- struct kimage *image;
int locked;
@@ -1056,12 +1055,11 @@ void crash_kexec(struct pt_regs *regs)
*/
locked = xchg(&kexec_lock, 1);
if (!locked) {
- image = xchg(&kexec_crash_image, NULL);
- if (image) {
+ if (kexec_crash_image) {
struct pt_regs fixed_regs;
crash_setup_regs(&fixed_regs, regs);
machine_crash_shutdown(&fixed_regs);
- machine_kexec(image);
+ machine_kexec(kexec_crash_image);
}
xchg(&kexec_lock, 0);
}
^ permalink raw reply related
* Re: How do you make linux 2.6.10 U-Boot aware?
From: Eugene Surovegin @ 2006-04-26 19:02 UTC (permalink / raw)
To: Howard, Marc; +Cc: linuxppc-embedded
In-Reply-To: <91B22F93A880FA48879475E134D6F0BE027DEF15@CA1EXCLV02.adcorp.kla-tencor.com>
On Wed, Apr 26, 2006 at 11:54:13AM -0700, Howard, Marc wrote:
> Hi,
>
> I'm using MontaVista linux 4.01 for the PPC440GX which is based on
> 2.6.10. It doesn't read the bootargs from U-Boot however. Does anyone
> out there have a synopsis of what needs to be modified (bd_info, etc.)
> to make this work with a 2.6.10 based release?
Please, take a look at Ocotea port in the latest 2.6 kernel. It
supports booting from PIBS and U-Boot.
--
^ permalink raw reply
* How do you make linux 2.6.10 U-Boot aware?
From: Howard, Marc @ 2006-04-26 18:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm using MontaVista linux 4.01 for the PPC440GX which is based on
2.6.10. It doesn't read the bootargs from U-Boot however. Does anyone
out there have a synopsis of what needs to be modified (bd_info, etc.)
to make this work with a 2.6.10 based release?
Thanks,
Marc W. Howard
^ permalink raw reply
* [PATCH] ppc64-xmon-stop-cpu.patch
From: David Wilder @ 2006-04-26 18:37 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
Please pick up this patch
- During CPU(s) hang scenarios, kdump could not stop these CPUs.
However, the user could invoke soft-reset to shoot down CPUs reliably.
But, when the debugger is enabled, these CPUs are returned to hang state
after they exited from the debugger. This patch fixes this issue by
calling crash_kexec_secondary() before returns to previous state.
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: ppc64-xmon-stop-cpu.patch --]
[-- Type: text/x-patch, Size: 1283 bytes --]
- During CPU(s) hang scenarios, kdump could not stop these CPUs. However, the user could invoke soft-reset to shoot down CPUs reliably. But, when the debugger is enabled, these CPUs are returned to hang state after they exited from the debugger. This patch fixes this issue by calling crash_kexec_secondary() before returns to previous state.
Signed-off-by: David Wilder <dwilder@us.ibm.com>
Signed-off-by: Haren Myneni <haren@us.ibm.com>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 064a525..9a509f8 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -208,6 +208,16 @@ void system_reset_exception(struct pt_re
die("System Reset", regs, SIGABRT);
+ /*
+ * Some CPUs which got released from debugger will execute this path.
+ * These CPUs entered debugger first time via soft-reset - Means,
+ * could be possible that these CPUs may not repond to an IPI later.
+ * Therefore, has to call kdump func directly.
+ * Not a problem if we exited from debugger to recover. In this case
+ * there will not be any primary kexec CPU. Hence, will be returned.
+ */
+ crash_kexec_secondary(regs);
+
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
panic("Unrecoverable System Reset");
^ permalink raw reply related
* RE: PPC Linux support for Tundra TSI148
From: Martin, Tim @ 2006-04-26 16:24 UTC (permalink / raw)
To: Gerhard Jaeger, linuxppc-embedded
Gerhard,
Thanks for the information. More questions...
What type of transfers were you doing? (e.g. A32/D64? SST320 or SST267?)
Are these transfer from userspace data, from kernelspace data, or from
the Tundra's pattern buffer?
What was your PCI bus speed & width?
Were you using inbound/outbound windows or Tundra's DMA controller?
What was the Tundra chipset configuration for the 168 MBps?
Thanks,
Tim
> -----Original Message-----
> From: linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.org] On
Behalf
> Of Gerhard Jaeger
> Sent: Wednesday, April 26, 2006 12:26 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: PPC Linux support for Tundra TSI148
>=20
> On Wednesday 26 April 2006 01:47, Martin, Tim wrote:
> > Does anyone out there have any real world measured performance of a
> > Linux PowerPC (kernel module + user space application) doing 2eSST
VME
> > transfers with the Tundra TSI148 chipset?
> >
> > Tundra has a Linux driver available for the Motorola MVME6100 , but
told
> > me they don't have any performance data available. I'm looking for
> > sustained throughput rates, not the peak burst rates (e.g. 320 MBps,
267
> > MBps).
> >
>=20
> Hi,
>=20
> I've done here some tests between two MVME6100, while updating the
6100
> BSP
> for our embedded Linux distro. Depending on the buffersize, alignment,
VME
> and
> PCI FIFO settings we have (without further optimizations) throughput
rates
> ranging
> from 100MBps up to 168MBps. I think some tuning could still be done.
>=20
> HTH
> Gerhard
>=20
> --
> Gerhard Jaeger <gjaeger@sysgo.com>
> SYSGO AG Embedded and Real-Time Software
> www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] nvram_print_partitions cosmetic fixup
From: Will Schmidt @ 2006-04-26 16:09 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org list, paulus
This is a cosmetic fixup. When printing the nvram partition table, the
first couple entries have a shorter 'index' value than the others, so
table is a bit askew. This change makes the table look pretty.
Tested on pseries and g5. Footnote: yes, this table is normally hidden
behind a DEBUG_NVRAM #define.
Signed-off-by: Will Schmidt <willschm@us.ibm.com>
diff --git a/arch/powerpc/kernel/nvram_64.c
b/arch/powerpc/kernel/nvram_64.c
index ada50aa..6960f09 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -204,7 +204,7 @@ static void nvram_print_partitions(char
printk(KERN_WARNING "indx\t\tsig\tchks\tlen\tname\n");
list_for_each(p, &nvram_part->partition) {
tmp_part = list_entry(p, struct nvram_partition, partition);
- printk(KERN_WARNING "%d \t%02x\t%02x\t%d\t%s\n",
+ printk(KERN_WARNING "%4d \t%02x\t%02x\t%d\t%s\n",
tmp_part->index, tmp_part->header.signature,
tmp_part->header.checksum, tmp_part->header.length,
tmp_part->header.name);
^ permalink raw reply related
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-26 14:37 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20060425222841.C2D0E353DAC@atlas.denx.de>
On Apr 25, 2006, at 5:28 PM, Wolfgang Denk wrote:
> In message
> <DAD4396E-7458-471C-8150-9DDCD396BA63@kernel.crashing.org> you wrote:
>>
>>> No. Remove them from the U-Boot tree. I was never happy to see
>>> this
>>> stuff there.
>>
>> Then why did you accept the patches for them? I'm confused on what
>
> Because I had neither time nor nerves to discuss with kernel
> maintainers how this could be done. Several people asked me again and
> again to accept these patches because they were vital for FDT
> support, so I gave in.
>
>> you see as the solution for how to boot an arch/powerpc kernel going
>> forward.
>
> I strongly agree with Dan and Eugene: the kernel should not depend on
> any specific version of a boot loader, and more general not even on
> any specific boot loader at all.
I think thats part of the idea with arch/powerpc defining a standard
mechanism for how a boot loader should pass information to the kernel
(via a flat device tree).
How would you propose that we handle booting arch/powerpc kernels
from u-boot going forward? (for new board ports and existing board
ports).
- kumar
^ permalink raw reply
* Re: Linux 2.6 sources for MPC852T processor
From: David Jander @ 2006-04-26 11:50 UTC (permalink / raw)
To: linuxppc-embedded, chandrasekhar_n
In-Reply-To: <20060426025008.C8A7D773@resin02.mta.everyone.net>
On Wednesday 26 April 2006 11:50, Chandrasekhar Nagaraj wrote:
> <DIV style="font-family:Arial,sans-serif;"><DIV>Hi,</DIV>
> <DIV>I have a customized board based on the MPC852T based processor.</DIV>
> <DIV>I intend to develop a BSP for this board.</DIV>
> <DIV> </DIV>
> <DIV>Does 2.6.16 from the kernel.org support this processor?</DIV>
First of all, please avoid HTML in e-mail messages. It is hard to read, and
normally banned on mailing list such as this one.
Yes, MPC852T is supported, although I might add that I have been using 2.6.14
and 2.6.15 sucessfully with our own MPC852T-based board, but 2.6.16 did not
boot and as of today I don't know why, or whether this is an issue at all
with boards other than ours.
> <DIV> </DIV>
> <DIV>In the 2.6.16 sources I found support for CONFIG_8xx. Does this mean
> that 852T processor is also supported?</DIV> <DIV> </DIV>
Yes. Look at BSP stuff for other 8xx boards to learn how to port yours. Keep
an eye on the new platform_bus stuff, that's currently being implemented for
different drivers and subsystmes for powerpc (this could be the reason, our
own BSP stuff stopped working with 2.6.16, btw).
Also a transition from /arch/ppc and /arch/ppc64 towards the
common /arch/powerpc is in progress, and therefore some things might be in a
state of flux between released versions of the kernel. As of today (kernel
2.6.16) the architecture you need to use is still /arch/ppc.
Good luck!
Greetings,
--
David Jander
^ permalink raw reply
* Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
From: Michael Ellerman @ 2006-04-26 10:37 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc64-dev, netdev
In-Reply-To: <1143421876.7795.2.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]
On Mon, 2006-03-27 at 12:11 +1100, Michael Ellerman wrote:
> On Thu, 2006-03-02 at 13:40 -0600, Santiago Leon wrote:
> > From: Michael Ellerman <michael@ellerman.id.au>
> >
> > After a kexec the veth driver will fail when trying to register with the
> > Hypervisor because the previous kernel has not unregistered.
> >
> > So if the registration fails, we unregister and then try again.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > Acked-by: Anton Blanchard <anton@samba.org>
> > Signed-off-by: Santiago Leon <santil@us.ibm.com>
> > ---
> >
> > drivers/net/ibmveth.c | 32 ++++++++++++++++++++++++++------
> > 1 files changed, 26 insertions(+), 6 deletions(-)
>
> Looks like this hit the floor. Any chance of getting it into to 2.6.17
> Jeff? AFAICT it should still apply cleanly.
/me knocks politely
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Linux 2.6 sources for MPC852T processor
From: Chandrasekhar Nagaraj @ 2006-04-26 9:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 668 bytes --]
^ permalink raw reply
* Re: PPC Linux support for Tundra TSI148
From: Gerhard Jaeger @ 2006-04-26 7:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE487104970DA7@VCAEXCH01.hq.corp.viasat.com>
On Wednesday 26 April 2006 01:47, Martin, Tim wrote:
> Does anyone out there have any real world measured performance of a
> Linux PowerPC (kernel module + user space application) doing 2eSST VME
> transfers with the Tundra TSI148 chipset?
>
> Tundra has a Linux driver available for the Motorola MVME6100 , but told
> me they don't have any performance data available. I'm looking for
> sustained throughput rates, not the peak burst rates (e.g. 320 MBps, 267
> MBps).
>
Hi,
I've done here some tests between two MVME6100, while updating the 6100 BSP
for our embedded Linux distro. Depending on the buffersize, alignment, VME and
PCI FIFO settings we have (without further optimizations) throughput rates ranging
from 100MBps up to 168MBps. I think some tuning could still be done.
HTH
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Re: maple_defconfig - CONFIG_ALTIVEC is not set
From: Segher Boessenkool @ 2006-04-26 0:15 UTC (permalink / raw)
To: Stephen Winiecki; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <OFC5EF8ADF.0CD9CACA-ON8725715B.0049AB44-8525715B.0049E2DA@us.ibm.com>
> Is there a reason why ALTIVEC is not enabled in maple_defconfig?
Is it not? You're kidding me. [checks] It's not. Ouch.
Please, Ben or Paul, can you fix this? Thanks!
Segher
p.s. I probably should check if it has some more errors /
shortcomings. But I'm too lazy. Stephen, do you see anything
else wrong?
^ permalink raw reply
* PPC Linux support for Tundra TSI148
From: Martin, Tim @ 2006-04-25 23:47 UTC (permalink / raw)
To: linuxppc-embedded
Does anyone out there have any real world measured performance of a
Linux PowerPC (kernel module + user space application) doing 2eSST VME
transfers with the Tundra TSI148 chipset?
Tundra has a Linux driver available for the Motorola MVME6100 , but told
me they don't have any performance data available. I'm looking for
sustained throughput rates, not the peak burst rates (e.g. 320 MBps, 267
MBps).
Thanks!
Tim
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-25 22:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <DAD4396E-7458-471C-8150-9DDCD396BA63@kernel.crashing.org>
In message <DAD4396E-7458-471C-8150-9DDCD396BA63@kernel.crashing.org> you wrote:
>
> > No. Remove them from the U-Boot tree. I was never happy to see this
> > stuff there.
>
> Then why did you accept the patches for them? I'm confused on what
Because I had neither time nor nerves to discuss with kernel
maintainers how this could be done. Several people asked me again and
again to accept these patches because they were vital for FDT
support, so I gave in.
> you see as the solution for how to boot an arch/powerpc kernel going
> forward.
I strongly agree with Dan and Eugene: the kernel should not depend on
any specific version of a boot loader, and more general not even on
any specific boot loader at all.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973)
``Hazards of Prophecy: The Failure of Imagination''
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 22:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <D6F58AA4-54EA-44BF-A0B7-83397B115B27@kernel.crashing.org>
In message <D6F58AA4-54EA-44BF-A0B7-83397B115B27@kernel.crashing.org> you wrote:
>
> > Some do. Some use them in products.
>
> Can you give a concrete example of this.
No, I cannot. Not in public.
> > Others (and not a small number) use them for testing application
> > code. In your definition these are probably "end users", too.
>
> Then they can use the kernel the board comes with.
No, they cannot. Running different kernel versions (including old
ones, eventually even 2.4) may be the key issue of their tests. Note
that this is something which does not require any modification to the
board - I can just TFTP the kernel image and boot it.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Weekends were made for programming. - Karl Lehenbauer
^ permalink raw reply
* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Vincent Winstead @ 2006-04-25 22:21 UTC (permalink / raw)
To: Aidan Williams; +Cc: linuxppc-embedded
In-Reply-To: <444D5907.6010506@nicta.com.au>
[-- Attachment #1: Type: text/plain, Size: 5956 bytes --]
Ok, so all that worked - it WAS necessary to choose "[*] Default all settings (lose changes)" in order for it to work though. Without this option checked I needed to add information and variables and constants and definitions that were not added into necessary files after make menuconfig and make dep were completed.
But I still have nothing working with the ML310 board. I did a "dow image.elf" at the XMD command prompt, then "con" and it showed up with a "RUNNING>" prompt, but nothing showed up on the hyperterminal window. I compiled using 115200 baud and I changed my hyperterminal to match this, but nothing shows up ...at all. Where do you think I would need to start looking to resolve this issue?
-Vincent
Aidan Williams <aidan@nicta.com.au> wrote:
After generating a new auto-config.in using the BSP,
you'll need to:
0. put new auto-config.in into kernel directory
linux-2.4.x/arch/ppc/platforms/xilinx_auto
1. change to the top uClinux-dist directory
(*NOT* the kernel directory)
2. In "Vendor/Product Selection --->"
Choose "Xilinx"
Choose "powerpc-auto"
3. In "Kernel/Library/Defaults Selection --->"
Choose linux-2.4.x as your kernel, making sure that
this is a symlink to or copy of the linuxppc-2.4
tarball from UQ.
4. In "Kernel/Library/Defaults Selection --->"
Choose "[*] Default all settings (lose changes)"
5. Save and quit..
This process will pull in default Xilinx/powerpc config
files from vendors/Xilinx/powerpc-auto/config.*
for the kernel and for other uClinux components.
It will also generate a new linux-2.4.x/.config
based on your auto-config.in and the defaults
in vendors/Xilinx/powerpc-auto/config.linux-2.4.x.
btw, I don't have an ML310 board. I have however gotten
the UQ kernel + uclinux to work on a v2pro FF1152 board
and a virtex-4 FX-12 minimodule.
another btw, the linuxppc-2.4 code has an auto-config.in
inside it which, if you follow the above steps (without
doing step 0), should compile. The supplied auto-config.in
won't match your board, but it should at least compile.
- aidan
Vincent Winstead wrote:
> guess what - I got the BSP to work! But now I have a problem with the
> make command. I put the auto-config.in where it needs to be then I did
> a make menuconfig to configure it, then I did a make dep, but when I did
> a make is when an error came up that I can't seem to figure out:
>
> In file included from
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/pagemap.h:16,
> from
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/locks.h:8,
> from
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/blk.h:5,
> from init/main.c:25:
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/highmem.h: In
> function `kmap':
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/highmem.h:68:
> error: `CONFIG_KERNEL_START' undeclared (first use in this function)
> init/main.c: In function `start_kernel':
> init/main.c:393: error: `CONFIG_KERNEL_START' undeclared (first use in
> this function)
> make[1]: *** [init/main.o] Error 1
> make[1]: Leaving directory `/home/ml310_linux/uClinux-dist/linuxppc-2.4'
> make: *** [linux] Error 1
>
> This CONFIG_KERNEL_START is the problem. It doesn't seem to be defined
> anywhere and I guess it needs to be. Is this something I need to get
> from somewhere? Or is it maybe generated along with the BSP so I would
> have to put a start number into the platform Studio configuration?
>
> -Vincent
>
>
> */Aidan Williams /* wrote:
>
>
> Vincent Winstead wrote:
> > Now, as far as step 5, am I supposed to have a symbolic link that is
> > named linux-2.4.x placed into the uClinux-dist directory? Because
> > there's already a folder named linux-2.4.x which was in there
> already
> > when I untarred everything. At the command prompt in the
> uClinux-dist
> > directory I entered the following line:
> >
> > ln -s ../linuxppc-2.4 linux-2.4.x
> >
> > and the result of this operation was to put a symbolic link into my
> > linuxppc-2.4 directory with the name of linux-2.4.x - is this
> correct?
> >
>
> First, you'll need to move the existing directory aside using
> a command like:
>
> mv linux-2.4.x linux-2.4.x-dist
>
> and then re-run the ln -s command above.
>
> > Now on to Step 6 problem.
> > How am I supposed to make use uClinux EDK Board Support Package 1.0
> > files? I'm not sure how to go about using them in the Xilinx
> Platform
> > Studio in order to generate the necessary auto-config.in file.
> >
>
> See the document below for the general approach:
>
> > Even though it is about the microblaze rather than
> > the PPC, a helpful "getting started" document is:
> >
> http://www.itee.uq.edu.au/~wu/downloads/uClinux_ready_Microblaze_design.pdf
> >
>
> Look particularly at the section "Software Platform Settings"
> on page 29, steps 67,68.
>
> If you are not overly familiar with the EDK, it would
> be best to find someone locally who can help walk you
> through the process of generating a system.
>
> - aidan
>
>
> --------------------------------------------------------------------------
> This email and any attachments may be confidential. They may contain
> legally
> privileged information or copyright material. You should not read, copy,
> use or disclose them without authorisation. If you are not an intended
> recipient, please contact us at once by return email and then delete
> both
> messages. We do not accept liability in connection with computer virus,
> data corruption, delay, interruption, unauthorised access or
> unauthorised
> amendment. This notice should not be removed.
>
>
[-- Attachment #2: Type: text/html, Size: 6947 bytes --]
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-25 21:42 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20060425213955.B9960352B18@atlas.denx.de>
On Apr 25, 2006, at 4:39 PM, Wolfgang Denk wrote:
> In message <07A76292-03D1-4648-
> AA40-11E06698FEE1@kernel.crashing.org> you wrote:
>>
>>> Since U-Boot does not need nor use this information for
>>> it's
>>> operation, but the kernel does, it should be part of the kernel.
>>
>> What about the case in which u-boot already has a .dts for a given
>> board? Should we duplicate the files between the kernel & u-boot?
>
> No. Remove them from the U-Boot tree. I was never happy to see this
> stuff there.
Then why did you accept the patches for them? I'm confused on what
you see as the solution for how to boot an arch/powerpc kernel going
forward.
- k
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-25 21:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <07A76292-03D1-4648-AA40-11E06698FEE1@kernel.crashing.org>
In message <07A76292-03D1-4648-AA40-11E06698FEE1@kernel.crashing.org> you wrote:
>
> > Since U-Boot does not need nor use this information for it's
> > operation, but the kernel does, it should be part of the kernel.
>
> What about the case in which u-boot already has a .dts for a given
> board? Should we duplicate the files between the kernel & u-boot?
No. Remove them from the U-Boot tree. I was never happy to see this
stuff there.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Don't panic.
^ permalink raw reply
* Re: FT u-boot shim
From: Eugene Surovegin @ 2006-04-25 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1448E56E-1327-40D5-BE44-0DC103AC3E8A@kernel.crashing.org>
On Tue, Apr 25, 2006 at 03:00:05PM -0500, Kumar Gala wrote:
>
> If we have a u-boot shim there are some questions that need answering:
> * where should the .dts live (hate duplicating the file both in u-
> boot and kernel source tree)
I have no strong opinion on this, maybe arch/powerpc/boot/85xx or
something. Although we may require having U-Boot tree somewhere I
don't particularly like this solution, it's better to keep kernel
self-contained, even if it requires some duplication. I personally
don't see this as an issue, because I assume this file isn't gonna
change frequently anyway.
Also, I think it's much safer to have this file in the kernel, this
way we will avoid potential problems with using different U-Boot
versions with different versions.
> * how does build system find .dts
If we go with "we-need-U-Boot-tree" solution, we can add Kconfig
option to specify path to U-Boot tree.
> * a Kconfig option to enable shim
Yes, there should be an option, for boards which can support old and
new U-Boot it should be user-selectable with old U-Boot being
a default. For boards which support only one type of U-Boot, this
option can be selected automatically.
> * assume done as a boot wrapper of sorts
Yeah, probably.
--
Eugene
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <719F1078-8AFB-48A8-9FB7-4128354F7774@kernel.crashing.org>
In message <719F1078-8AFB-48A8-9FB7-4128354F7774@kernel.crashing.org> you wrote:
>
> >> I'm not talking about all embedded PPC boards. I'm taking about the
> >> subset that exists for 85xx. Also, its moving forward as the
> >
> > What's the difference?
>
> The difference is that I'm only prescribing my views for a specific
> subset of HW.
To me it makes things not better that just a certain group of boards
is affected.
> Are we talking about other users of a board I maintain or for other
> maintaining a different board?
I'm talking about users of any board. Yes, this includes the boards
you maintain.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Crash programs fail because they are based on the theory that, with
nine women pregnant, you can get a baby a month. - Wernher von Braun
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 21:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425213622.B116F352B18@atlas.denx.de>
On Apr 25, 2006, at 4:36 PM, Wolfgang Denk wrote:
> In message <4BCCDE94-8A82-41C4-B4F9-
> F111E761F926@kernel.crashing.org> you wrote:
>>
>> I'm listening, I just dont agree. I see reference boards used by
>> developers who will end up building a custom board. I'm happy to be
>> enlightened if people are using reference boards for some other
>> purpose (beyond evaluation of the processor).
>
> Some do. Some use them in products.
Can you give a concrete example of this.
> Others (and not a small number) use them for testing application
> code. In your definition these are probably "end users", too.
Then they can use the kernel the board comes with.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4BCCDE94-8A82-41C4-B4F9-F111E761F926@kernel.crashing.org>
In message <4BCCDE94-8A82-41C4-B4F9-F111E761F926@kernel.crashing.org> you wrote:
>
> I'm listening, I just dont agree. I see reference boards used by
> developers who will end up building a custom board. I'm happy to be
> enlightened if people are using reference boards for some other
> purpose (beyond evaluation of the processor).
Some do. Some use them in products.
Others (and not a small number) use them for testing application
code. In your definition these are probably "end users", too.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You can only live once, but if you do it right, once is enough.
^ 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