reboot on PQ2FADS board.

2006-07-19 Thread Li Yang-r58472
-Original Message- From: linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org [mailto:linuxppc-embedded-bounces+leoli=freescale.com at ozlabs.org] On Behalf Of Lei Sun Sent: Tuesday, July 18, 2006 11:41 AM To: linuxppc-embedded at ozlabs.org Subject: reboot on PQ2FADS board.

reboot on PQ2FADS board.

2006-07-19 Thread Wolfgang Denk
In message 4879B0C6C249214CBE7AB04453F84E4D050B0F at zch01exm20.fsl.freescale.net you wrote: command cause machine check and kernel ooops. The problem seems in the m8260_gorom in head.S. The restart() function in m8260_setup.c passed 2 parameters to that assembly code, r3 is the bd_info

Linux controlling Hardware-Tasks on FPGA

2006-07-19 Thread Josef Angermeier
Hello, anyone else out there using or wanting to use Linux to control the reconfiguration of a FPGA ? - Do you use dynamic partial reconfiguration too ? - If so how did you design the relevant software coarsely ? thanks in advance, Josef

reboot on PQ2FADS board.

2006-07-19 Thread Lei Sun
Hi : I tried your approach last ight, (in fact I copied part of the do_reboot() code from u-boot and put it in m8260_restart() function in the kernel). The only difference is the first line, volatile immap_t *immap = (immap_t *) IMAP_ADDR; in my case it is volatile immap_t * immap =

Linux controlling Hardware-Tasks on FPGA

2006-07-19 Thread David Hawkins
anyone else out there using or wanting to use Linux to control the reconfiguration of a FPGA ? - Do you use dynamic partial reconfiguration too ? - If so how did you design the relevant software coarsely ? Hi Josef, If you are talking 'partial reconfiguration' then I guess you are discussing

reboot on PQ2FADS board.

2006-07-19 Thread Mathieu Deschamps
Hi, On Wednesday 19 July 2006 16:12, Lei Sun wrote: Hi : I tried your approach last ight, (in fact I copied part of the do_reboot() code from u-boot and put it in m8260_restart() function in the kernel). The only difference is the first line, volatile immap_t *immap = (immap_t *)

MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006

2006-07-19 Thread Florian Boelstler
Hi Jeffrey, I have done the PCI config cycle under u-boot. This is very simple and able to find the PEX EP attached to the MPC8548. In this log, it is reading a pair of MPC8548E connected together using PEX. Please see the log below: [ ... ] thanks for sharing this piece of

MPC8260 SCC UART hardware flow control

2006-07-19 Thread Wolfgang Denk
In message 200607191718.00328.laurent.pinchart at tbox.biz you wrote: I was wondering if anyone had implemented hardware flow control support in the cpm_uart driver. If not, I would appreciate pointers regarding how to do so. You can probably take our 2.4 kernel code as a starting point.

export-objs in spi Makefile broke in latest linuxppc_2_4_devel?

2006-07-19 Thread Rowan, Chad
-eval.o -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060719/7e511dda/attachment.htm

export-objs in spi Makefile broke in latest linuxppc_2_4_devel [r eposted]?

2006-07-19 Thread Rowan, Chad
Shouldn't export-objs in drivers/spi be: export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5xxx-psc.o \ spi-iti5200.o spi-eval.o instead of: export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5200psc.o \ spi-iti5200.o spi-eval.o

export-objs in spi Makefile broke in latest linuxppc_2_4_devel [r eposted]?

2006-07-19 Thread Kumar Gala
On Jul 19, 2006, at 2:13 PM, Rowan, Chad wrote: Shouldn't export-objs in drivers/spi be: export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5xxx-psc.o \ spi-iti5200.o spi-eval.o instead of: export-objs := spi-core.o spi-algo-mpc5xxx.o

export-objs in spi Makefile broke in latest linuxppc_2_4_deve l [r eposted]?

2006-07-19 Thread Rowan, Chad
linuxppc_2_4_devel is alive and well. http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=shortlog -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 19, 2006 4:17 PM To: Rowan, Chad Cc: linuxppc-embedded at ozlabs.org Subject: Re: