Hello Michael,
bisect tells me that since your commit 9422de3e953d0e60eb95f5430a9dd803eec1c6d7
"powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint registers",
compiling linux fails with :
cc1: warnings being treated as errors
arch/powerpc/kernel/ptrace.c: In function 'arch_p
On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote:
> > bisect tells me that since your commit
> > 9422de3e953d0e60eb95f5430a9dd803eec1c6d7
> > "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint
> > registers",
> > compiling linux fails with :
> >
> > cc1: warni
Hello Mikey,
On Thu, Mar 07, 2013 at 10:14:30AM +1100, Michael Neuling wrote:
> Philippe De Muyter wrote:
>
> > On Thu, Mar 07, 2013 at 09:09:48AM +1100, Michael Neuling wrote:
> > > > bisect tells me that since your commit
> > > > 9422de3e953d0e60eb95f5
On Fri, Mar 08, 2013 at 10:03:34AM +1100, Michael Neuling wrote:
> Michael Neuling wrote:
>
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 245c1b6..8564515 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -1428,6 +1428,7 @@
ct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
> Hi Philippe,
>
> On 05/10/12 01:03, Philippe De Muyter wrote:
>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>
>
files are moved to arch/drivers/dma/bestcomm, while
.h files are moved to include/linux/fsl/bestcomm. Makefiles, Kconfigs
and #include directives are updated for the new file locations.
Tested by recompiling for MPC5200 with all bestcomm users enabled.
Signed-off-by: Philippe De Muyter
---
arc
Hi Greg,
On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote:
> Hi Philippe,
>
> On 09/10/12 19:07, Philippe De Muyter wrote:
>> [CCing lkml, linux-ppc, netdev, linux-m68k]
>>
>> Hello kernel sources architects
>>
>> I have a working driver f
Dear list,
I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
specific gcc.
I then got tan infinity of "SPE used in kernel" messages. Looking at the
sources I ifdeffed out the printk call in KernelSPE, and I now have a
silent kernel, that seems to work fine.
Is there somethi
On Fri, Feb 22, 2008 at 12:33:19PM -0600, Andy Fleming wrote:
>
> On Feb 22, 2008, at 03:50, Philippe De Muyter wrote:
>
>> Dear list,
>>
>> I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
>> specific gcc.
>>
>> I then got
Hi Johanness,
On Sat, Feb 23, 2008 at 10:51:08AM +0100, Johannes Berg wrote:
>
> > My first trial used ARCH=ppc and caused this infinity of "SPE used in
> > kernel"
> > messages, but I then recompiled linux with ARCH=powerpc. With the message
> > not ifdef'ed out, this second kernel does not em
Dear ppclinux gurus,
I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
specific gcc.
After my first attempt using ARCH=ppc, leading to an infinity of messages :
"SPE used in kernel", I recompiled the whole kernel sources using
the default ARCH (ARCH=powerpc). I now have a ke
Hi Kumar,
On Tue, Feb 26, 2008 at 01:39:20AM -0600, Kumar Gala wrote:
>
> On Feb 23, 2008, at 4:25 AM, Johannes Berg wrote:
>
>>
>>> But as I said in the same mail, processes still dies unexpectedly.
>>
>> Yeah, no idea though. I guess you could try putting that into the
>> arch/ppc Makefile, but
Hi everybody,
I have a ARCH=powerpc linux-2.6.25-rc6 linux running with an i2c rtc chip,
and synchronized to a ntp server.
I noticed that my rtc chip does not get updated by the kernel, just like
it would be on all other architectures (included ppc).
Looking at the differences between ./arch/pow
CCing lkml
On Tue, May 20, 2008 at 09:10:25PM +1000, Paul Mackerras wrote:
> Philippe De Muyter writes:
>
> > I have a ARCH=powerpc linux-2.6.25-rc6 linux running with an i2c rtc chip,
> > and synchronized to a ntp server.
> >
> > I noticed that my rtc chip does
Hi all,
I have a currently almost working ARCH=ppc linux-2.6.24 configuration for a
new mpc8540 board (except for a RTC chip connected to an i2c bus).
Knowing that ARCH=ppc will be removed, I try to make the ARCH=powerpc version
work, but that's not easy.
I have copied the mpc8540ads.dts file to
Hi Scott,
On Mon, Mar 03, 2008 at 11:07:20AM -0600, Scott Wood wrote:
> On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote:
> > My root device is on a compact-flash connected to a PCI yenta chip from TI,
> > and this one is not working, altough it seems t
Hi Scott,
On Mon, Mar 03, 2008 at 03:11:08PM -0600, Scott Wood wrote:
> Philippe De Muyter wrote:
>> Is the PCI-interrupt map that part of the dts file :
>> interrupt-map = <
>> /* IDSEL 0x02 */
>>
Hi Scott,
On Mon, Mar 03, 2008 at 03:55:26PM -0600, Scott Wood wrote:
> Philippe De Muyter wrote:
>> The following seems important also :
>> /*
>> interrupts = <18 2>;
>> */
>> /* interrupts number are coded in hexa ! */
>
Hi Ben,
On Tue, Mar 04, 2008 at 08:41:33AM +1100, Benjamin Herrenschmidt wrote:
>
> > Thanks
> >
> > The following seems important also :
> >
> > /*
> > interrupts = <18 2>;
> > */
> > /* interrupts number are coded in hexa ! */
> > interrupts = <
Hi Ben,
On Tue, Mar 04, 2008 at 08:26:14AM +1100, Benjamin Herrenschmidt wrote:
>
> > > Maybe your PCI interrupt-map is wrong...
> >
> > Is the PCI-interrupt map that part of the dts file :
> >
> > interrupt-map = <
> >
> > /* IDSEL 0x02 */
> >
Hi Ben,
On Tue, Mar 04, 2008 at 07:22:19PM +1100, Benjamin Herrenschmidt wrote:
>
> On Tue, 2008-03-04 at 09:08 +0100, Philippe De Muyter wrote:
> > With ARCH=ppc, all those interrupt's info's are hardcoded in the .c
> > files.
> > But I expected I could fill
Hi Ben,
thanks for all the answers,
On Wed, Mar 05, 2008 at 04:01:04PM +1100, Benjamin Herrenschmidt wrote:
>
> > I also attach my current (not working) dts file attempt. It is actually
> > a modified mpc8540ads.dts file.
> >
> > I now thinks that the ide-cs (hda) discovery or not depends on t
Hi Ben,
On Thu, Mar 06, 2008 at 07:14:28AM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-03-05 at 17:15 +0100, Philippe De Muyter wrote:
> >
> > I asked the guy who designed the hardware, and if I understand
> > correctly :
> >
> > - the i/o and me
Hi Ben,
On Thu, Mar 06, 2008 at 10:46:51AM +1100, Benjamin Herrenschmidt wrote:
>
> > >>From your .dts, I see you've been doing some swizzling of slots using
> > > interrupts 1...4 ... do that correspond to EXTIRQ 58 ?
> >
> > No, those correspond to the EXT1-4 that are the other side of the
Hi Ben,
I now have a working linux on my mpc8540 based board, with support for
the compactflash disk and the i2c rtc.
The network tough, does not work yet. altough the the integrated ethernet
controller (FEC) seems to be recognized. Could it be a problem with the phy ?
I notice that I do not hav
Hi David,
On Tue, Mar 11, 2008 at 11:32:49AM +1100, David Gibson wrote:
> On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote:
> > Hi Ben,
> >
> > I now have a working linux on my mpc8540 based board, with support for
> > the compactflash disk and the i2
Hi all,
I have a mpc8540 board that could reboot when driven by a ARCH=ppc linux,
but that hangs now in arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart when
asked to reboot with a ARCH=powerpc linux.
I have found that if I call arch/powerpc/kernel/head_fsl_booke.S:abort from
there, my board reboo
e fsl_rstcr_restart for the mpc8540_ads board :(
Philippe
> On Tue, 2008-03-25 at 17:15 +0100, Philippe De Muyter wrote:
> > Hi all,
> >
> > I have a mpc8540 board that could reboot when driven by a ARCH=ppc linux,
> > but that hangs now in arch/powerpc/sysdev/fsl_so
Hi Haiying,
On Tue, Mar 25, 2008 at 04:48:23PM -0400, Haiying Wang wrote:
> Ok, I see the problem here. For 8540/60 which has e500 v1 core, it
> doesn't use RSTCR to assert HRESET_REQ signal to reset the whole system.
> We probably need to add abort() in fsl_rstcr_restart() for those
> silicons:
>
Hi everybody,
When connected to a 10Mbit/Half hub, my mpc8540 board quickly falls in an
endless "NETDEV WATCHDOG: eth0: transmit timed out" loop. This has not
yet happened here when connected to a 100Mbit/Full switch. Problem
seems to be twofold, because the gfar_timeout does not fix the problem
Hi everybody,
Previously, with the arch/ppc tree, mpc8540 boards could reboot.
Now with the arch/powerpc tree, they can not anymore.
Fix that.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.000
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.0 +
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
--
I have removed the ifdef as pointed by Olof
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.0 +
+++ b/arch/p
On Wed, Apr 09, 2008 at 05:51:40PM -0500, Kumar Gala wrote:
>
> On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
>> Hi everybody,
>>
>> Previously, with the arch/ppc tree, mpc8540 boards could reboot.
>> Now with the arch/powerpc tree, they can
Hi Andy,
On Tue, May 06, 2008 at 05:54:02PM -0500, Andy Fleming wrote:
>> Now back to the first an bigger problem :
>> currently, I have an "old" U-boot and I have written myself a dts file.
>>
>> Problem is : ethernet does not work, but that's not a mac-address problem,
>> but something else that
35 matches
Mail list logo
