Am Dienstag, den 30.10.2007, 13:23 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > + if( !of_address_to_resource(np, 1, &res[1])) {
>
> The spacing is still wrong.
>
> > - iounmap(bitbang->dir);
> > + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> > + iounmap(bitbang->mdio.d
From: Grant Likely <[EMAIL PROTECTED]>
mmu_mapin_ram() loops over total_lowmem to setup page tables. However, if
total_lowmem is less that 16M, the subtraction rolls over and results in
a number just under 4G (because total_lowmem is an unsigned value).
This patch rejigs the loop from countup to
From: Grant Likely <[EMAIL PROTECTED]>
When not building an arch/powerpc kernel, the mpc5200 FEC driver depends
on some symbols which are not defined (BESTCOMM & BESTCOMM_FEC).
This patch flips around the dependancy logic so that it cannot be
selected unless BESTCOMM_FEC is selected first. Kconf
From: Grant Likely <[EMAIL PROTECTED]>
Driver shouldn't complain if the register range is larger than what
it expects. This works around failures with some device trees.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/net/fec_mpc52xx.c |4 ++--
1 files changed, 2 insertions(+),
The 44x family has an interesting "feature" which is a virtually
tagged instruction cache (yuck !). So far, we haven't dealt with
it properly, which means we've been mostly lucky or people didn't
report the problems, unless people have been running custom patches
in their distro...
This is an atte
On Tue, 2007-10-30 at 23:18 -0600, Grant Likely wrote:
> On 10/30/07, Bai Shuwei <[EMAIL PROTECTED]> wrote:
> > Hi, everyone
> >As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> > 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> > And now I w
On Wed, 31 Oct 2007 14:28:46 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> ioresource was good structure for remembering "which memory is conventional
> memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> when I posted patch. (just say "System Ram" is not for memo
On Tue, 30 Oct 2007 11:19:11 -0800
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi KAME,
>
> As I mentioned while ago, ppc64 does not export information about
> "system RAM" in /proc/iomem. Looking at the code and usage
> scenerios I am not sure what its really serving. Could you
> explain what
On 10/30/07, Bai Shuwei <[EMAIL PROTECTED]> wrote:
> Hi, everyone
>As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
> 3) and the linux kernel run in the ring 0 and user program in the ring 3.
> And now I want to know wether there is a simple mechanism on the PowerPC
> ar
Hi, everyone
As we know, the program on the X86 can run on the differnt ring(0, 1, 2,
3) and the linux kernel run in the ring 0 and user program in the ring 3.
And now I want to know wether there is a simple mechanism on the PowerPC
architecture? thx all!
best regards!
Buroc
--
Add: Tianshu
On Tue, Oct 30, 2007 at 11:37:15PM -0500, Kumar Gala wrote:
>
> On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
>
> > These two patches are a respin of my previous patch to merge a copy of
> > dtc into the kernel tree, so that kernel builds no longer depend on an
> > externally installed copy o
On Oct 30, 2007, at 10:24 PM, David Gibson wrote:
> These two patches are a respin of my previous patch to merge a copy of
> dtc into the kernel tree, so that kernel builds no longer depend on an
> externally installed copy of dtc.
>
> This respin embeds a newer revision of dtc, and incorporates
This patch alters the kernel makefiles to build dtc from the sources
embedded in the previous patch. It also changes the
arch/powerpc/boot/wrapper script to use the embedded dtc, rather than
expecting a copy of dtc already installed on the system.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
This very large patch incorporates a copy of dtc into the kernel
source, in arch/powerpc/boot/dtc-src. This patch only imports the dtc
sources verbatim, another patch coming to actually link it into the
kernel Makefiles and use the embedded copy of dtc for kernel builds.
Signed-off-by: David Gibs
These two patches are a respin of my previous patch to merge a copy of
dtc into the kernel tree, so that kernel builds no longer depend on an
externally installed copy of dtc.
This respin embeds a newer revision of dtc, and incorporates Sam
Ravnborg's preferred approach to Makefile integration. A
On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
> +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c2007-10-30
> 18:00:15.0 +0300
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
You want
--
Cheers,
Stephen
On Tue, Oct 30, 2007 at 09:09:17PM -0500, Josh Boyer wrote:
> On Tue, 30 Oct 2007 20:56:51 -0500
> Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > > PowerPC
Jon Loeliger wrote:
> So, like, the other day Kumar Gala mumbled:
>> Jon,
>>
>> It seems like have libfdt as a unique git repo that is a submodule of
>> the things that need it (dtc, u-boot, etc.) might make some sense and
>> it easier for the projects that need to pull it in.
>>
>> Is this som
On Tue, 30 Oct 2007 17:09:19 +0100 Sergej Stepanov <[EMAIL PROTECTED]> wrote:
>
> static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
> struct device_node *np)
> {
> - struct resource res;
> + struct resource res[2];
Why not just reuse
On Tue, 30 Oct 2007 20:56:51 -0500
Olof Johansson <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> > On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > > PowerPC 440GRx Rainier DTS.
> > [snip]
> > > + SDRAM0: sdram {
> > > +
On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
> On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> > PowerPC 440GRx Rainier DTS.
> [snip]
> > + SDRAM0: sdram {
> > + device_type = "memory-controller";
>
> How many times do we need to sa
Will Schmidt writes:
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output for any slb entries
> that contain only zeros.
>
> sample output from p
On Tue, 30 Oct 2007 17:41:27 -0400
"Steven A. Falco" <[EMAIL PROTECTED]> wrote:
> From: "Steven A. Falco" <[EMAIL PROTECTED]>
> To: linuxppc-dev@ozlabs.org
> Subject: Re: PPC405GP Walnut irq patch
> Date: Tue, 30 Oct 2007 17:41:27 -0400
> Sender: [EMAIL PROTECTED]
> User-Agent: Thunderbird 2.0.0.5
On Tue, Oct 30, 2007 at 04:50:39PM -0500, Will Schmidt wrote:
>
> [powerpc] update xmon slb code
>
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the
On Tue, 2007-10-30 at 16:50 -0500, Will Schmidt wrote:
> [powerpc] update xmon slb code
>
> This adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the output fo
On Tue, 2007-10-30 at 13:59 -0500, Will Schmidt wrote:
> [Powerpc] fix switch_slb handling of 1T ESID values
>
> Now that we have 1TB segment size support, we need to be using the
> GET_ESID_1T macro when comparing ESID values for pc,stack, and
> unmapped_base within switch_slb().A new helper
On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
> Jon Loeliger wrote:
>> So, like, the other day Kumar Gala mumbled:
>>> Jon,
>>>
>>> It seems like have libfdt as a unique git repo that is a submodule of
>>> the things that need it (dtc, u-boot, etc.) might make some sense and i
On Tue, Oct 30, 2007 at 07:56:33AM -0700, Yoder Stuart-B08248 wrote:
[snip]
> > Yeah.. what he said.
> >
> > The *only* substantive change with the "class" proposal is the fact
> > that multiple classes can be specified. That's nice, but I don't
> > think it's worth the trouble of attempting to d
On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
> PowerPC 440GRx Rainier DTS.
[snip]
> + SDRAM0: sdram {
> + device_type = "memory-controller";
How many times do we need to say it...
Don't make up random device_type values. This does not belong
On Tue, Oct 30, 2007 at 12:06:33PM -0700, Yoder Stuart-B08248 wrote:
>
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Tuesday, October 30, 2007 11:34 AM
> > To: Yoder Stuart-B08248
> > Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> > Subject: Re: RFC: replac
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
>
> > Explicitly specifying what device class bindings / conventions the
> > node complies with is cute, but not actually all that useful in
> > practice. If it looks like a "duck" class device node, and it
> > quacks^Whas the p
On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
>
> Michael Ellerman <[EMAIL PROTECTED]> wrote on 28.10.2007 23:32:17:
> >
> >
> > How do you plan to support kdump?
> >
>
> When kexec is fully supported kdump should work out of the box
> as for any other ethernet card (if you load the
[powerpc] update xmon slb code
This adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
sample output from po
I realized that I should have done this from the root level. So here is
the corrected patch.
Signed-off-by: Steve Falco
Steven A. Falco wrote:
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentatio
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom board
- the ethernet would not work. The attached patch corrects that.
This is the first pa
Hello Stefan,
In message <[EMAIL PROTECTED]> you wrote:
>
> I already have it running on my system using a quick hack (see patch below)
> in
> include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean
> implementation, that has chances for upstream merge (in arch/powerpc later),
On Wed, 31 Oct 2007 07:16:31 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > > Fortunately, we don't support SMP on these or this solution wouldn't
> > > work.
> >
> > We should mark 44x BROKEN on SMP in Kconfig.
>
> Can we enable SMP on 44x at all currently ?
Not without editing
> > Fortunately, we don't support SMP on these or this solution wouldn't
> > work.
>
> We should mark 44x BROKEN on SMP in Kconfig.
Can we enable SMP on 44x at all currently ?
> No arch/ppc fix? I know we all want it to die as soon as possible, but
> still... :)
Yeah, I didn't do it yet, whic
On Tue, 30 Oct 2007 19:45:11 +0300
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> The following patches add PowerPC 440GRx Rainier board support.
> The board is almost identical to Sequoia, but doesn't have USB
> and FPU is not supported.
So why do we need anything other than the DTS and the defc
On Tuesday 30 October 2007, Valentine Barshak wrote:
> +static struct of_device_id rainier_of_bus[] = {
> + { .compatible = "ibm,plb4", },
> + { .compatible = "ibm,opb", },
> + { .compatible = "ibm,ebc", },
> + {},
> +};
> +
> +static int __init rainier_device_probe(void)
>
Make sure that at least cmpxchg64_local is available on all architectures to use
for unsigned long long values.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
CC: linuxppc-dev@ozlabs.org
---
include/asm-powerpc/system.h |6 ++
1 file chan
On 10/30/07, Yoder Stuart-B08248 <[EMAIL PROTECTED]> wrote:
> Another good reason for device_type-- it helps
> distinguish between two similar classes of devices.
> Both "open-pic" and "isa-pic" look very similar but
> have different encodings of their interrupt cells.
> Without a device_type it ma
Demke Torsten-atd012 <[EMAIL PROTECTED]> wrote:
>I tried to ping over a bonded VLAN tagged interface.
>(e.g -> ifenslave bond0 eth3.24)
[...]
>It seems that the skb headroom is to small. How can I solve this?
>I could insert skb_realloc_headroom() call, but where it's the best
>place then?
>What
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 30, 2007 11:34 AM
> To: Yoder Stuart-B08248
> Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>
> On Tue, Oct 30, 2007 at 09:23:14AM -070
[Powerpc] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb().A new helper function called
esids_match() contains the logic for deciding wh
Dale Farnsworth wrote:
> On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
>> This commit made an incorrect assumption:
>> --
>> Author: Lennert Buytenhek <[EMAIL PROTECTED]>
>> Date: Fri Oct 19 04:10:10 2007 +0200
>>
>> mv643xx_eth: Move ethernet register definitions into p
Josh Boyer wrote:
> On Tue, 30 Oct 2007 19:45:11 +0300
> Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
>> The following patches add PowerPC 440GRx Rainier board support.
>> The board is almost identical to Sequoia, but doesn't have USB
>> and FPU is not supported.
>
> General FYI, I'm probably g
Sergej Stepanov wrote:
> + if( !of_address_to_resource(np, 1, &res[1])) {
The spacing is still wrong.
> - iounmap(bitbang->dir);
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> + iounmap(bitbang->mdio.dir);
> + iounmap(bitbang->mdc.dir);
And here.
-Scott
__
On Tue, 30 Oct 2007 19:45:11 +0300
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> The following patches add PowerPC 440GRx Rainier board support.
> The board is almost identical to Sequoia, but doesn't have USB
> and FPU is not supported.
General FYI, I'm probably going to queue these up for .25.
Hi KAME,
As I mentioned while ago, ppc64 does not export information about
"system RAM" in /proc/iomem. Looking at the code and usage
scenerios I am not sure what its really serving. Could you
explain what its purpose & how the range can be invalid ?
At least on ppc64, all the memory ranges we g
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc: 0x10d40, mdio: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 10d40
The approach was taken from o
Alan Bennett wrote:
> Am I missing something in the PRAM areas?
> SMC1 (ttyCPM0...)
> e0008000 : 00c000e0 30300020 eefe3e7a
> e0008010 : 00c07331 11b6b05f 3044 07f4d082
> e0008020 : 00e3 746562ec d98ceffd 0dec67e3
> e0008030 : df7b2db5 5f0bf2dc 00205ce8 0001
> e000804
Well, now that I've got IRQs requestable, I'm back to battling SCC1 / SCC4
initialization,
I've verified the iop structures, and things look set-up correctly.
/* SCC1 */
{2, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{3, 29, CPM_PIN_OUTPUT | CPM
Hi,
I tried to ping over a bonded VLAN tagged interface.
(e.g -> ifenslave bond0 eth3.24)
This fails with following output:
[EMAIL PROTECTED]:/root> ping 192.168.24.101
PING 192.168.24.skb_under_panic: text:c01bbdf8 len:50 put:8
head:dd27a3a0 data:dd27a39a tail:dd27a3cc end:dd27a3e0 dev:eth3
Oop
Sergej Stepanov wrote:
> Hello Scott.
> Thank you for reply.
> Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood:
>> On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote:
>
>> You could just use of_iomap() for the second one, since we don't need
>> the physical address for bus
PowerPC 440GRx Rainier default config.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/configs/rainier_defconfig | 868 +
1 files changed, 868 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/configs/rainier_defconfig
linux-2.6/arch/pow
PowerPC 440GRx Rainier board support.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/44x/Kconfig | 16 -
arch/powerpc/platforms/44x/Makefile |3 +
arch/powerpc/platforms/44x/rainier.c | 61 +++
3 files changed, 78
Hello Scott.
Thank you for reply.
Am Dienstag, den 30.10.2007, 11:32 -0500 schrieb Scott Wood:
> On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote:
> You could just use of_iomap() for the second one, since we don't need
> the physical address for bus->id.
Nice tip.
Than it would be n
PowerPC 440GRx Rainier DTS.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/rainier.dts | 312 ++
1 files changed, 312 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts
linux-2.6/arch/powerpc/boot/dts/ra
Bootwrapper code for PowerPC 440GRx Rainier board.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile |3 +
arch/powerpc/boot/cuboot-rainier.c | 56 +
2 files changed, 58 insertions(+), 1 deletion(-)
diff -pruN li
The following patches add PowerPC 440GRx Rainier board support.
The board is almost identical to Sequoia, but doesn't have USB
and FPU is not supported.
Thanks,
Valentine.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/li
On Tue, 30 October 2007 17:13:08 +0300, Valentine Barshak wrote:
>
> I'm not saying my approach is the best, but I was hoping for a discussion.
That is good. So please take a moment to listen.
> I've reworked the patches according to the comments to the previous
> version and used my arguments
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> mpic: [EMAIL PROTECTED] {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <4 4>;
> compatible = "fsl,xyz";
> big-endian;
> }
> Explicitly specifying what device class bindings / conventions the
> node complies with is cute, but not actually all that useful in
> practice. If it looks like a "duck" class device node, and it
> quacks^Whas the properties of a "duck" class device node, it's "duck"
> class compliant.
Don't
Andreas Schwab wrote:
> Jan Dittmer <[EMAIL PROTECTED]> writes:
>
>> Your mail from 2007-10-29 4:39 pm (CET)
>>
Your compiler still needs -m32 to generate 32-bit code (or use
--with-cpu=default32 to make that the default).
>> See the 'still' ?
>
> How would the compiler know whether to
Andreas Schwab wrote:
> Jan Dittmer <[EMAIL PROTECTED]> writes:
>
>> Your mail from 2007-10-29 4:39 pm (CET)
>>
Your compiler still needs -m32 to generate 32-bit code (or use
--with-cpu=default32 to make that the default).
>> See the 'still' ?
>
> How would the compiler know whether to
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc-offset: 0x10d40, mdio-offset: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 0x10d40
The approach
So, like, the other day Kumar Gala mumbled:
> Jon,
>
> It seems like have libfdt as a unique git repo that is a submodule of
> the things that need it (dtc, u-boot, etc.) might make some sense and
> it easier for the projects that need to pull it in.
>
> Is this something you can take a look
Grant Likely wrote:
> On 10/29/07, Marian Balakowicz <[EMAIL PROTECTED]> wrote:
>> David Gibson wrote:
>>> On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
Grant Likely wrote:
> On 10/25/07, Martin Krause <[EMAIL PROTECTED]> wrote:
>>> [snip]
>> On a board with 16 MiB
Jon,
It seems like have libfdt as a unique git repo that is a submodule of
the things that need it (dtc, u-boot, etc.) might make some sense and
it easier for the projects that need to pull it in.
Is this something you can take a look at? (or have other ideas on).
- k
___
> -Original Message-
> From: David Gibson [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 29, 2007 7:52 PM
> To: Olof Johansson
> Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>
> On Mon, Oct 29, 2007 at 04:22:13PM
Hello.
Kumar Gala wrote:
>>The decrementer in Book E and 4xx processors interrupts on the
>>transition from 1 to 0, rather than on the 0 to -1 transition as on
>>64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors.
>>This fixes the problem by making set_dec subtract 1 from the count for
Thomas Gleixner wrote:
> On Mon, 29 Oct 2007, Valentine Barshak wrote:
>
>> This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
>> The code is based on the original NDFC driver by Thomas Gleixner, but
>> since it's been changed much and has initialization/clean-up completely
>>
So, like, the other day David Gibson mumbled:
> If future dtb version > 17 are defined, that are still backwards
> compatible with v16, libfdt will of course be able to read and
> understand them. However, when modifying such a tree, it can't
> guarantee that it won't clobber additional structure
So, like, the other day David Gibson mumbled:
> The mangle-layout testcase/utility had a leftover debugging printf().
> This patch removes it.
>
> Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Applied.
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@o
[added linuxppc-dev since it's PPC relevant too]
On Tuesday 30 October 2007, Josh Boyer wrote:
> On Mon, 29 Oct 2007 15:45:03 -0400
>
> [EMAIL PROTECTED] (Lennart Sorensen) wrote:
> > On Mon, Oct 29, 2007 at 03:22:27PM +0100, Stefan Roese wrote:
> > > I'm trying to implement support for a board sp
On Tue, 30 Oct 2007 16:16:54 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> The 44x family has an interesting "feature" which is a virtually
> tagged instruction cache (yuck !). So far, we haven't dealt with
> it properly, which means we've been mostly lucky or people didn't
> report th
hi,
Is it possible to run user program (statically linked) in kernel mode? for
example the user program entry is 0x1000, can we call it directly from
kernel? I've tried many times, but I got the following Error(Oops):
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: 1094 LR: 1094
On Tue, Oct 30, 2007 at 10:36:06AM +0100, Sven Luther wrote:
> On Tue, Oct 30, 2007 at 03:44:59AM -0400, Luis R. Rodriguez wrote:
> > On 10/29/07, Dale Farnsworth <[EMAIL PROTECTED]> wrote:
> > > On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> > > > This commit made an incorrec
On Tue, Oct 30, 2007 at 03:44:59AM -0400, Luis R. Rodriguez wrote:
> On 10/29/07, Dale Farnsworth <[EMAIL PROTECTED]> wrote:
> > On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> > > This commit made an incorrect assumption:
> > > --
> > > Author: Lennert Buytenhek <[EMAIL PROTEC
Jan Dittmer <[EMAIL PROTECTED]> writes:
> Your mail from 2007-10-29 4:39 pm (CET)
>
>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>> --with-cpu=default32 to make that the default).
>
> See the 'still' ?
How would the compiler know whether to generate 64bit or 32bit code??
A
Add DMA engine and SOC device support to mpc8641hpcn board
Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 32
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 16 ++
This patch adds Freescale DMA and DMA channel definition to
Documentation/powerpc/booting-without-of.txt file.
Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 59 ++
1 files chan
On Tuesday 30 October 2007, Sergej Stepanov wrote:
> -void
> +void __init
> cpm2_reset(void)
> {
> #ifdef CONFIG_PPC_85xx
>
> --
> I am not sure it is ok.
Yes, this looks good.
>
> But i have other 2 warnings (no modules).
>
> WARNING: vmlinux.o(.exit.text+0x5da): Section m
On Tuesday 30 October 2007, Tony Breeds wrote:
> Without this patch I get the following build failure
> CC arch/powerpc/platforms/celleb/setup.o
> arch/powerpc/platforms/celleb/setup.c:151: error: 'generic_calibrate_decr'
> undeclared here (not in a function)
>
> Signed-off-by: Tony Breeds
Yes, I'm working on it. Do not worry about it.
Wei.
> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 30, 2007 4:31 AM
> To: [EMAIL PROTECTED]
> Cc: Zhang Wei-r63237; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org;
> [EMAIL PRO
Michael Ellerman <[EMAIL PROTECTED]> wrote on 28.10.2007 23:32:17:
>
>
> How do you plan to support kdump?
>
When kexec is fully supported kdump should work out of the box
as for any other ethernet card (if you load the right eth driver).
There's nothing specific to kdump you have to handle in
e
87 matches
Mail list logo
