* Linux 2.4 devel on ML403 board : problem with prompt
From: jean-francois.hasson @ 2006-04-27 6:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am trying to port linux 2.4 devel to ML403. I have used advices from this
mailing list and some websites and finally got to th epoint where
everything seems find except I cannot get the boot prompt. I have used
busybox 1.0.1 and it seems init runs well, rcS runs well and afterr that I
do not get the prompt. I have activated the askfirst line in inittab and I
am asked to hit enter to go further but all I get is, automatically,
without hitting the keyboard, is character X. I do not seem to have any
echo. I have the console node defined in /dev. Has anyone an idea as to
what I have done wrong ?
Best regards,
JF Hasson
#
This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited.
Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Au cas ou vous ne seriez pas le destinataire de ce courriel, vous etes prie d'en informer l'expediteur immediatement et de le detruire ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite.
#
^ permalink raw reply
* Re: Linux 2.6 sources for MPC852T processor
From: Dan Malek @ 2006-04-26 23:32 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604261350.05295.david.jander@protonic.nl>
On Apr 26, 2006, at 7:50 AM, David Jander wrote:
> 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.
There is a horrible bug in the 8xx TLB miss handler that is in the
2.6.16
sources. I don't know when it appeared. Enable the CPU6 Errata
workaround to see if that solves the problem and please report back
to me. I'm working on a solution.
Thanks.
-- Dan
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Stephen Williams @ 2006-04-26 23:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060426163540.H16236@cox.net>
Matt Porter wrote:
> On Wed, Apr 26, 2006 at 04:19:23PM -0700, Stephen Williams wrote:
>> ... seems completely missing in the linux-2.3.32 tree from kernel.org.
>> This used to be in the linuxppc-2.4 BK tree that no longer exists, so
>> what happened to the ppc405GPr support?!
>
> There's some stuff that never got submitted upstream to kernel.org
> during 2.4 due partially to 2.5 appearing. All upstream devel
> moved to 2.5/2.6 and no effort was made to merge stuff from the
> linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want
> to take "new stuff" into linux-2.4 at that time either.
>
> There's still rsync://source.mvista.com/linuxppc-2.4 available with
> the 405gpr/sycamore support.
Well then I guess for 405GPr support and the SystemACE drivers
I'm on my own. Is there a git tree for main line 2.4 maintenance
(against which I could maintain patches) or am I on my own there
too?
It should be easy enough to rescue the gpr support form the bk
working dir that I have (or the mvista repository as you point
out) and make up patches.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Matt Porter @ 2006-04-26 23:35 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <e2ov5s$1hn$1@sea.gmane.org>
On Wed, Apr 26, 2006 at 04:19:23PM -0700, Stephen Williams wrote:
> ... seems completely missing in the linux-2.3.32 tree from kernel.org.
> This used to be in the linuxppc-2.4 BK tree that no longer exists, so
> what happened to the ppc405GPr support?!
There's some stuff that never got submitted upstream to kernel.org
during 2.4 due partially to 2.5 appearing. All upstream devel
moved to 2.5/2.6 and no effort was made to merge stuff from the
linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want
to take "new stuff" into linux-2.4 at that time either.
There's still rsync://source.mvista.com/linuxppc-2.4 available with
the 405gpr/sycamore support.
-Matt
^ permalink raw reply
* Re: PPC 405GPr support in linux 2.4.32
From: Tolunay Orkun @ 2006-04-26 23:48 UTC (permalink / raw)
To: Stephen Williams; +Cc: linuxppc-embedded
In-Reply-To: <e2ov5s$1hn$1@sea.gmane.org>
Stephen Williams wrote:
> ... seems completely missing in the linux-2.3.32 tree from kernel.org.
> This used to be in the linuxppc-2.4 BK tree that no longer exists, so
> what happened to the ppc405GPr support?!
I guess nobody sent patches upstream and development shifted to 2.6
kernel. 405Gpr is not alone. 405EP and a number of other CPU support
that was present never got its way up kernel.org sources.
^ permalink raw reply
* Re: [Fastboot] Documentation feedback request.
From: Michael Ellerman @ 2006-04-26 23:44 UTC (permalink / raw)
To: David Wilder; +Cc: linuxppc-dev list, fastboot
In-Reply-To: <444FB2AF.3020802@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 11643 bytes --]
Hi David,
Nice work. Few comments below ...
On Wed, 2006-04-26 at 10:49 -0700, David Wilder wrote:
> Attached is a updated Documentation/kdump/kdump.txt. Please provide
> comments. I will incorporate your feedback and send up to Linus.
>
> plain text document attachment (kdump-final-20060425.txt)
> ================================================================
> Documentation for Kdump - The kexec-based Crash Dumping Solution
> ================================================================
>
> This document includes overview, setup and installation, and analysis
> information.
>
> Overview
> ========
>
> Kdump uses kexec to quickly boot to a dump-capture kernel whenever a
> dump of the system kernel's memory needs to be taken (for example, when
> the system panics). The system kernel's memory image is preserved across
> the reboot and is accessible to the dump-capture kernel.
>
> You can use common Linux commands, such as cp and scp, to copy the
> memory image to a dump file on the local disk, or across the network to
> a remote system.
>
> Kdump and kexec are currently supported on the x86, x86_64, and ppc64
> architectures.
s/ppc64/64-bit powerpc/ ?
> When the system kernel boots, it reserves a small section of memory for
> the dump-capture kernel. This ensures that ongoing Direct Memory Access
> (DMA) from the system kernel does not corrupt the dump-capture kernel.
> The kexec -p command loads the dump-capture kernel into this reserved
> memory.
Well hopefully ;)
> On x86 machines, the first 640 KB of physical memory is needed to boot,
> regardless of where the kernel loads. Therefore, kexec backs up this
> region just before rebooting into the dump-capture kernel.
>
> All of the necessary information about the system kernel's core image is
> encoded in the ELF format, and stored in a reserved area of memory
> before a crash. The physical address of the start of the ELF header is
> passed to the dump-capture kernel through the elfcorehdr= boot
> parameter.
>
> With the dump-capture kernel, you can access the memory image, or "old
> memory," in two ways:
>
> - Through a /dev/oldmem device interface. A capture utility can read the
> device file and write out the memory in raw format. This is a raw dump
> of memory. Analysis and capture tools must be intelligent enough to
> determine where to look for the right information.
>
> - Through /proc/vmcore. This exports the dump as an ELF-format file that
> you can write out using file copy commands such as cp or scp. Further,
> you can use analysis tools such as the GNU Debugger (GDB) and the Crash
> tool to debug the dump file. This method ensures that the dump pages are
> correctly ordered.
>
>
> Setup and Installation
> ======================
>
> Install kexec-tools and the Kdump patch
> ---------------------------------------
>
> 1) Login as the root user.
>
> 2) Download the kexec-tools user-space package from the following URL:
>
> http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
>
> 3) Unpack the tarball with the tar command, as follows:
>
> tar xvpzf kexec-tools-1.101.tar.gz
>
> 4) Download the latest consolidated Kdump patch from the following URL:
>
> http://lse.sourceforge.net/kdump/
>
> (This location is being used until all the user-space Kdump patches
> are integrated with the kexec-tools package.)
>
> 5) Change to the kexec-tools-1.101 directory, as follows:
>
> cd kexec-tools-1.101
>
> 6) Apply the consolidated patch to the kexec-tools-1.101 source tree
> with the patch command, as follows. (Modify the path to the downloaded
> patch as necessary.)
>
> patch -p1 < /path-to-kdump-patch/kexec-tools-1.101-kdump.patch
>
> 7) Configure the package, as follows:
>
> ./configure
>
> 8) Compile the package, as follows:
>
> make
>
> 9) Install the package, as follows:
>
> make install
>
>
> Download and build the system and dump-capture kernels
> ------------------------------------------------------
>
> Download the mainline (vanilla) kernel source code (2.6.13-rc1 or newer)
> from http://www.kernel.org. Two kernels must be built: a system kernel
> and a dump-capture kernel. Use the following steps to configure these
> kernels with the necessary kexec and Kdump features:
>
> System kernel
> -------------
>
> 1) Enable "kexec system call" in "Processor type and features."
>
> CONFIG_KEXEC=y
>
> 2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo
> filesystems." This is usually enabled by default.
>
> CONFIG_SYSFS=y
>
> Note that "sysfs file system support" might not appear in the "Pseudo
> filesystems" menu if "Configure standard kernel features (for small
> systems)" is not enabled in "General Setup." In this case, check the
> .config file itself to ensure that sysfs is turned on, as follows:
>
> grep 'CONFIG_SYSFS' .config
Is there a particular requirement for sysfs?
> 3) Enable "Compile the kernel with debug info" in "Kernel hacking."
>
> CONFIG_DEBUG_INFO=Y
>
> This causes the kernel to be built with debug symbols. The dump
> analysis tools require a vmlinux with debug symbols in order to read
> and analyze a dump file.
>
> 4) Make and install the kernel and its modules. Update the boot loader
> (such as grub, yaboot, or lilo) configuration files as necessary.
>
> 5) Boot the system kernel with the boot parameter "crashkernel=Y@X",
> where Y specifies how much memory to reserve for the dump-capture kernel
> and X specifies the beginning of this reserved memory. For example,
> "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory
> starting at physical address 0x01000000 for the dump-capture kernel.
Most of this doesn't apply to powerpc.
> On x86 and x86_64, use "crashkernel=64M@16M".
>
> On ppc64, use "crashkernel=128M@32M".
No just use "crashkernel=128M".
> The dump-capture kernel
> -----------------------
>
> 1) Under "General setup," append "-kdump" to the current string in
> "Local version."
>
> 2) On x86, enable high memory support under "Processor type and
> features":
>
> CONFIG_HIGHMEM=y
>
> 3) On x86 and x86_64, disable symmetric multi-processing support
> under "Processor type and features":
>
> CONFIG_SMP=n
>
> 4) On ppc64, disable NUMA support and enable EMBEDDED support:
>
> CONFIG_NUMA=n
> CONFIG_EMBEDDED=y
> CONFIG_EEH=N for the dump-capture kernel
Why are we disabling NUMA? AFAIK we work on more systems with NUMA than
without?
And why are we turning off EMBEDDED and EEH?
> 5) Enable "kernel crash dumps" support under "Processor type and
> features":
>
> CONFIG_CRASH_DUMP=y
>
> 6) Use a suitable value for "Physical address where the kernel is
> loaded" (under "Processor type and features"). This only appears when
> "kernel crash dumps" is enabled. By default this value is 0x1000000
> (16MB). It should be the same as X in the "crashkernel=Y@X" boot
> parameter discussed above.
>
> On x86 and x86_64, use "CONFIG_PHYSICAL_START=0x1000000".
>
> On ppc64 the value is automatically set at 32MB when
> CONFIG_CRASH_DUMP is set.
This whole step should start "On x86 ..."
> 6) Optionally enable "/proc/vmcore support" under "Filesystems" ->
> "Pseudo filesystems".
6 + 1 = 6 :D
> CONFIG_PROC_VMCORE=y
>
> 7) Make and install the kernel and its modules. DO NOT add this kernel
> to the boot loader configuration files.
>
>
> Load the Dump-capture Kernel
> ============================
>
> After booting to the system kernel, load the dump-capture kernel using
> the following command:
>
> kexec -p <dump-capture-kernel> \
> --initrd=<initrd-for-dump-capture-kernel> --args-linux \
> --append="root=<root-dev> init 1 irqpoll"
I've never tested irqpoll on powerpc, I'm not sure we want to recommend
it, has someone tested it?
> Notes on loading the dump-capture kernel:
>
> * <dump-capture-kernel> must be a vmlinux image (that is, an
> uncompressed ELF image). bzImage does not work at this time.
>
> * By default, the ELF headers are stored in ELF64 format to support
> systems with more than 4GB memory. The --elf32-core-headers option can
> be used to force the generation of ELF32 headers. This is necessary
> because GDB currently cannot open vmcore files with ELF64 headers on
> 32-bit systems. ELF32 headers can be used on non-PAE systems (that is,
> less than 4GB of memory).
>
> * The "irqpoll" boot parameter reduces driver initialization failures
> due to shared interrupts in the dump-capture kernel.
>
> * You must specify <root-dev> in the format corresponding to the root
> device name in the output of mount command.
> * "init 1" boots the dump-capture kernel into single-user mode without
> networking. If you want networking, use "init 3."
>
>
> Kernel Panic
> ============
>
> After successfully loading the dump-capture kernel as previously
> described, the system will reboot into the dump-capture kernel if a
> panic occurs. You can write a module to force the panic, or use
> "ALT-SysRq-c" to initiate a crash dump for testing purposes.
>
>
> Write Out the Dump File
> =======================
>
> After the dump-capture kernel is booted, write out the dump file with
> the following command:
>
> cp /proc/vmcore <dump-file>
>
> You can also access dumped memory as a /dev/oldmem device for a linear
> and raw view. To create the device, use the following command:
>
> mknod /dev/oldmem c 1 12
>
> Use the dd command with suitable options for count, bs, and skip to
> access specific portions of the dump.
>
> To see the entire memory, use the following command:
>
> dd if=/dev/oldmem of=oldmem.001
>
>
> Analysis
> ========
>
> Before analyzing the dump image, you should reboot into a stable kernel.
>
> You can do limited analysis using GDB on the dump file copied out of
> /proc/vmcore. Use the debug vmlinux built with -g and run the following
> command:
>
> gdb vmlinux <dump-file>
>
> Stack trace for the task on processor 0, register display, and memory
> display work fine.
>
> Note: GDB cannot analyze core files generated in ELF64 format for x86.
> On systems with a maximum of 4GB of memory, you can generate
> ELF32-format headers using the --elf32-core-headers kernel option on the
> dump kernel.
>
> You can also use the Crash utility to analyze dump files in Kdump
> format. Crash is available on Dave Anderson's site at the following URL:
>
> http://people.redhat.com/~anderson/
>
>
> To Do
> =====
>
> 1) Provide a kernel pages filtering mechanism, so core file size is not
> extreme on systems with huge memory banks.
>
> 2) Relocatable kernel can help in maintaining multiple kernels for
> crash_dump, and the same kernel as the system kernel can be used to
> capture the dump.
>
>
> Contact
> =======
>
> Vivek Goyal (vgoyal@in.ibm.com)
> Maneesh Soni (maneesh@in.ibm.com)
fastboot@lists.osdl.org
cheers
--
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
* Re: 85xx FDT updates?
From: Dan Malek @ 2006-04-26 23:27 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425213622.B116F352B18@atlas.denx.de>
On Apr 25, 2006, at 5:36 PM, Wolfgang Denk wrote:
> Others (and not a small number) use them for testing application
> code. In your definition these are probably "end users", too.
I'm surprised by how much of this I see as well. People will
buy various evaluation boards for the purposes of evaluation
(imagine that :-)). They will try different kernel versions, write
some test applications, before making a choice of what
processor and tools to purchase. Only after that point will
they likely have some debugger capability that will allow
them to update flash parts. Based on this behavior, it's not
good to assume that just because someone has an eval
board they have the ability to update the flash on it. A failed
flash update and the inability to recover is a good way to
ensure the board/processor is not chosen for a product :-)
Thanks.
-- Dan
^ permalink raw reply
* PPC 405GPr support in linux 2.4.32
From: Stephen Williams @ 2006-04-26 23:19 UTC (permalink / raw)
To: linuxppc-embedded
... seems completely missing in the linux-2.3.32 tree from kernel.org.
This used to be in the linuxppc-2.4 BK tree that no longer exists, so
what happened to the ppc405GPr support?!
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* Re: [PATCH 4/4] ppc32 CPM_UART: Fixed odd address translations
From: Marcelo Tosatti @ 2006-04-26 21:41 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20060425162646.23551.61674.stgit@vitb.ru.mvista.com>
Ouch.
I would convert the warning printk() to a BUG(), since such an address
error
indicates deep trouble anyway...
And add a "likely()" indication around the range check.
Looks great otherwise!
On Tue, 2006-04-25 at 20:26 +0400, Vitaly Bordug wrote:
> Current address translation methods can produce wrong results, because
> virt_to_bus and vice versa may not produce correct offsets on dma-allocated
> memory. The right way is, while tracking both phys and virt address of the
> window that has been allocated for boffer descriptors, and use those
> numbers to compute the offset and make translation properly.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> ---
>
> drivers/serial/cpm_uart/cpm_uart.h | 33 +++++++++++++++++++++++++++++++
> drivers/serial/cpm_uart/cpm_uart_core.c | 31 ++++++++---------------------
> drivers/serial/cpm_uart/cpm_uart_cpm1.c | 7 ++++---
> drivers/serial/cpm_uart/cpm_uart_cpm2.c | 5 ++++-
> 4 files changed, 50 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart.h b/drivers/serial/cpm_uart/cpm_uart.h
> index 17f2c7a..9db402c 100644
> --- a/drivers/serial/cpm_uart/cpm_uart.h
> +++ b/drivers/serial/cpm_uart/cpm_uart.h
> @@ -66,6 +66,7 @@ struct uart_cpm_port {
> uint dp_addr;
> void *mem_addr;
> dma_addr_t dma_addr;
> + u32 mem_size;
> /* helpers */
> int baud;
> int bits;
> @@ -92,4 +93,36 @@ void scc2_lineif(struct uart_cpm_port *p
> void scc3_lineif(struct uart_cpm_port *pinfo);
> void scc4_lineif(struct uart_cpm_port *pinfo);
>
> +/*
> + virtual to phys transtalion
> +*/
> +static inline unsigned long cpu2cpm_addr(void* addr, struct uart_cpm_port *pinfo)
> +{
> + int offset;
> + u32 val = (u32)addr;
> + /* sane check */
> + if ((val >= (u32)pinfo->mem_addr) &&
> + (val<((u32)pinfo->mem_addr + pinfo->mem_size))) {
> + offset = val - (u32)pinfo->mem_addr;
> + return pinfo->dma_addr+offset;
> + }
> + printk("%s(): address %x to translate out of range!\n", __FUNCTION__, val);
> + return 0;
> +}
> +
> +static inline void *cpm2cpu_addr(unsigned long addr, struct uart_cpm_port *pinfo)
> +{
> + int offset;
> + u32 val = addr;
> + /* sane check */
> + if ((val >= pinfo->dma_addr) &&
> + (val<(pinfo->dma_addr + pinfo->mem_size))) {
> + offset = val - (u32)pinfo->dma_addr;
> + return (void*)(pinfo->mem_addr+offset);
> + }
> + printk("%s(): address %x to translate out of range!\n", __FUNCTION__, val);
> + return 0;
> +}
> +
> +
> #endif /* CPM_UART_H */
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
> index 8f33815..3549073 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -72,19 +72,6 @@ static void cpm_uart_initbd(struct uart_
>
> /**************************************************************/
>
> -static inline unsigned long cpu2cpm_addr(void *addr)
> -{
> - if ((unsigned long)addr >= CPM_ADDR)
> - return (unsigned long)addr;
> - return virt_to_bus(addr);
> -}
> -
> -static inline void *cpm2cpu_addr(unsigned long addr)
> -{
> - if (addr >= CPM_ADDR)
> - return (void *)addr;
> - return bus_to_virt(addr);
> -}
>
> /* Place-holder for board-specific stuff */
> struct platform_device* __attribute__ ((weak)) __init
> @@ -290,7 +277,7 @@ static void cpm_uart_int_rx(struct uart_
> }
>
> /* get pointer */
> - cp = cpm2cpu_addr(bdp->cbd_bufaddr);
> + cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
>
> /* loop through the buffer */
> while (i-- > 0) {
> @@ -633,7 +620,7 @@ static int cpm_uart_tx_pump(struct uart_
> /* Pick next descriptor and fill from buffer */
> bdp = pinfo->tx_cur;
>
> - p = cpm2cpu_addr(bdp->cbd_bufaddr);
> + p = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
>
> *p++ = port->x_char;
> bdp->cbd_datlen = 1;
> @@ -660,7 +647,7 @@ static int cpm_uart_tx_pump(struct uart_
>
> while (!(bdp->cbd_sc & BD_SC_READY) && (xmit->tail != xmit->head)) {
> count = 0;
> - p = cpm2cpu_addr(bdp->cbd_bufaddr);
> + p = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
> while (count < pinfo->tx_fifosize) {
> *p++ = xmit->buf[xmit->tail];
> xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> @@ -709,12 +696,12 @@ static void cpm_uart_initbd(struct uart_
> mem_addr = pinfo->mem_addr;
> bdp = pinfo->rx_cur = pinfo->rx_bd_base;
> for (i = 0; i < (pinfo->rx_nrfifos - 1); i++, bdp++) {
> - bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
> + bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, pinfo);
> bdp->cbd_sc = BD_SC_EMPTY | BD_SC_INTRPT;
> mem_addr += pinfo->rx_fifosize;
> }
>
> - bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
> + bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, pinfo);
> bdp->cbd_sc = BD_SC_WRAP | BD_SC_EMPTY | BD_SC_INTRPT;
>
> /* Set the physical address of the host memory
> @@ -724,12 +711,12 @@ static void cpm_uart_initbd(struct uart_
> mem_addr = pinfo->mem_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos * pinfo->rx_fifosize);
> bdp = pinfo->tx_cur = pinfo->tx_bd_base;
> for (i = 0; i < (pinfo->tx_nrfifos - 1); i++, bdp++) {
> - bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
> + bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, pinfo);
> bdp->cbd_sc = BD_SC_INTRPT;
> mem_addr += pinfo->tx_fifosize;
> }
>
> - bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr);
> + bdp->cbd_bufaddr = cpu2cpm_addr(mem_addr, pinfo);
> bdp->cbd_sc = BD_SC_WRAP | BD_SC_INTRPT;
> }
>
> @@ -1099,7 +1086,7 @@ static void cpm_uart_console_write(struc
> * If the buffer address is in the CPM DPRAM, don't
> * convert it.
> */
> - cp = cpm2cpu_addr(bdp->cbd_bufaddr);
> + cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
>
> *cp = *s;
>
> @@ -1116,7 +1103,7 @@ static void cpm_uart_console_write(struc
> while ((bdp->cbd_sc & BD_SC_READY) != 0)
> ;
>
> - cp = cpm2cpu_addr(bdp->cbd_bufaddr);
> + cp = cpm2cpu_addr(bdp->cbd_bufaddr, pinfo);
>
> *cp = 13;
> bdp->cbd_datlen = 1;
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> index 31223aa..a5a3062 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> @@ -144,7 +144,7 @@ int cpm_uart_allocbuf(struct uart_cpm_po
> /* was hostalloc but changed cause it blows away the */
> /* large tlb mapping when pinning the kernel area */
> mem_addr = (u8 *) cpm_dpram_addr(cpm_dpalloc(memsz, 8));
> - dma_addr = 0;
> + dma_addr = (u32)mem_addr;
> } else
> mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
> GFP_KERNEL);
> @@ -157,8 +157,9 @@ int cpm_uart_allocbuf(struct uart_cpm_po
> }
>
> pinfo->dp_addr = dp_offset;
> - pinfo->mem_addr = mem_addr;
> - pinfo->dma_addr = dma_addr;
> + pinfo->mem_addr = mem_addr; /* virtual address*/
> + pinfo->dma_addr = dma_addr; /* physical address*/
> + pinfo->mem_size = memsz;
>
> pinfo->rx_buf = mem_addr;
> pinfo->tx_buf = pinfo->rx_buf + L1_CACHE_ALIGN(pinfo->rx_nrfifos
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> index c9c3b1d..7c6b07a 100644
> --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> @@ -209,8 +209,10 @@ int cpm_uart_allocbuf(struct uart_cpm_po
>
> memsz = L1_CACHE_ALIGN(pinfo->rx_nrfifos * pinfo->rx_fifosize) +
> L1_CACHE_ALIGN(pinfo->tx_nrfifos * pinfo->tx_fifosize);
> - if (is_con)
> + if (is_con) {
> mem_addr = alloc_bootmem(memsz);
> + dma_addr = mem_addr;
> + }
> else
> mem_addr = dma_alloc_coherent(NULL, memsz, &dma_addr,
> GFP_KERNEL);
> @@ -225,6 +227,7 @@ int cpm_uart_allocbuf(struct uart_cpm_po
> pinfo->dp_addr = dp_offset;
> pinfo->mem_addr = mem_addr;
> pinfo->dma_addr = dma_addr;
> + pinfo->mem_size = memsz;
>
> pinfo->rx_buf = mem_addr;
> pinfo->tx_buf = pinfo->rx_buf + L1_CACHE_ALIGN(pinfo->rx_nrfifos
^ permalink raw reply
* Xilinx SysACE drivers for Linux 2.4
From: Stephen Williams @ 2006-04-26 21:46 UTC (permalink / raw)
To: linuxppc-embedded
So I'm now looking at moving from my bk based linuxppc-2.4 devel
tree to the kernel.org sources, but the latter doesn't have the
Xilinx SystemACE drivers. Is there a repository for the latest
port (to kernel 2.4) of this driver, or should I just lift it
from the kernel tree I have?
Also, I'd be going from linuxppc-2.4.30-pre1 (or thereabouts) to
kernel.org 2.4.32. This is likely to be fine for my PPC405GPr, yes?
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
^ permalink raw reply
* 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
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