On Jun 29, 2007, at 1:26 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Please pull from 'for_paulus' branch of
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
>> for_paulus
>
> Unfortunately with those commits I get this when compiling for a
> 64-bit target:
>
> {
>>> +- #address-cells : Address representation for
>> "rapidio" devices.
>>> + This field represents the number of cells needed to represent
>>> + the RapidIO address of the registers. For
>> supporting more than
>>> + 32-bits RapidIO address, this field should be <2>.
>>> +
Hi, Segher,
> DTS sector to the document of booting-without-of.txt file.
>
> >>> +- #address-cells : Address representation for
> >> "rapidio" devices.
> >>> + This field represents the number of cells needed
> to represent
> >>> + the RapidIO address of the registers. For
> >> s
>> Please pull from 'for_paulus' branch of
>>
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
>> for_paulus
>
> Unfortunately with those commits I get this when compiling for a
> 64-bit target:
>
> {standard input}: Assembler messages:
> {standard input}:668: Error: Unrecogni
>> It is not. -mcpu=powerpc64 doesn't select an ABI, and your
>> GCC presumably defaults to the 32-bit ABI. Use -m64 on the
>> GCC command line, too, you need it, and it solves this issue
>> as a side effect.
>
> No, actually the command line had -m64 on it. The situation is this:
>
> gcc -m64 -
>> No. The #address-cells is determined by the bus binding,
>> so that all RapidIO busses on the planet can be represented
>> in a similar way in the OF device tree. Take for example
>> the PCI binding, which gives you three address cells -- one
>> to distinguish between different address spaces
Segher Boessenkool writes:
> It is not. -mcpu=powerpc64 doesn't select an ABI, and your
> GCC presumably defaults to the 32-bit ABI. Use -m64 on the
> GCC command line, too, you need it, and it solves this issue
> as a side effect.
No, actually the command line had -m64 on it. The situation is
Segher Boessenkool wrote:
First, I'm looking for a help and advice why the current _set_L2CR()
implementation may not work for MPC7450 (namely 7448 with 1Mb L2 cache
installed). Is it a bug in _set_L2CR() or a hardware problem.
>>>
>>>
>>> I think that if anyone here could answer t
Hello,
allmodconfig on powerpc (iMac g3) fails due to
git-kgdb.patch. allmodconfig defaults should be changed?
CC arch/powerpc/kernel/kgdb.o
arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
in .config. Unselect one of them.
make[1]: *** [arch/powerpc/ker
Hello.
Mariusz Kozlowski wrote:
> allmodconfig on powerpc (iMac g3) fails due to
> git-kgdb.patch. allmodconfig defaults should be changed?
> CC arch/powerpc/kernel/kgdb.o
> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
> in .config. Unselect one of th
On Friday 29 June 2007, Paul Mackerras wrote:
> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
> the command line, and that means that gcc *doesn't* put "-mppc64" the
> as command line, and as barfs on the 64-bit instructions. That's
> presumably a gcc bug, but we'll have to
Add a minimal install target
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
Makefile |9 +
1 file changed, 9 insertions(+)
--- dtc.orig/Makefile
+++ dtc/Makefile
@@ -4,6 +4,10 @@ LDFLAGS = -Llibfdt
BISON = bison
+INSTALL = /usr/bin/install
+DESTDIR = /
+BINDIR = usr/bin
+
#
On Jun 29, 2007, at 8:45 AM, Arnd Bergmann wrote:
> On Friday 29 June 2007, Paul Mackerras wrote:
>> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
>> the command line, and that means that gcc *doesn't* put "-mppc64" the
>> as command line, and as barfs on the 64-bit instru
From: Christian Krafft <[EMAIL PROTECTED]>
This patch fixes the following compiler warning:
arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
`sysfs_create_group',
Signed-off-by: Christian Krafft <[EMAIL PROTECTED]>
--- linux-2.6.orig/arch/powerpc/kernel/sysfs.c
+++ linux-2.6/ar
On Friday 29 June 2007 16:50:10 Christian Krafft wrote:
> From: Christian Krafft <[EMAIL PROTECTED]>
>
> This patch fixes the following compiler warning:
> arch/powerpc/kernel/sysfs.c:385: warning: ignoring return value of
> `sysfs_create_group',
>
> Signed-off-by: Christian Krafft <[EMAIL PROTEC
On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> + remain in bug-fix only mode until it's scheduled removal. Platforms
http://www.angryflower.com/itsits.gif
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/
Add a minimal install target
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
Makefile |9 +
1 file changed, 9 insertions(+)
--- dtc.orig/Makefile
+++ dtc/Makefile
@@ -4,6 +4,10 @@ LDFLAGS = -Llibfdt
BISON = bison
+INSTALL = /usr/bin/install
+DESTDIR =
+BINDIR = /usr/bin
+
#
On Fri, Jun 29, Josh Boyer wrote:
> +DESTDIR = /
> +BINDIR = usr/bin
+DESTDIR=
+BINDIR=/usr/bin
Just like every other package out there.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Fri, 2007-06-29 at 16:34 +0200, Olaf Hering wrote:
> On Fri, Jun 29, Josh Boyer wrote:
>
> > +DESTDIR = /
> > +BINDIR = usr/bin
>
> +DESTDIR=
> +BINDIR=/usr/bin
>
> Just like every other package out there.
Urgh. I thought I had fixed that already. Will resubmit.
josh
On Fri, 2007-06-29 at 10:13 -0500, Josh Boyer wrote:
> That's it? I'm scheduling the demise of an entire architecture
> sub-tree and the only comment you can make is about a superfluous
> apostrophe? ;)
Sorry, allow me to rephrase...
http://www.angryflower.com/itsits.gif
DIE arch/ppc DIE!
--
Paul Mackerras <[EMAIL PROTECTED]> writes:
> It turns out that with Arnd's patches we now get "-mcpu=powerpc64" on
> the command line, and that means that gcc *doesn't* put "-mppc64" the
> as command line, and as barfs on the 64-bit instructions.
The assembler should be called with -a64, which ha
Josh Boyer <[EMAIL PROTECTED]> writes:
> +install: dtc ftdump
> + $(INSTALL) -d $(DESTDIR)/$(BINDIR)
> + $(INSTALL) -m 755 dtc $(DESTDIR)/$(BINDIR)
> + $(INSTALL) -m 755 ftdump $(DESTDIR)/$(BINDIR)
Don't put a slash after $(DESTDIR). You'll end up with a doulbe slash.
Andreas.
--
More platforms and higher bitrate tests (I've left the previous post in
comment):
> a) 8245/2.4.34/e100: 2.3.43-k1, @400 MHz
> b) 8245/2.6.17/e100: 2.3.43-k1 [2] @350 MHz
> c) 8347e/2.6.21.1/gianfar @400 Mhz
> d) XScale-IXP42x/2.6.18-4/ixp4xx @266 MHz (NSLU2)
e) 8245/2.6.17/e100: 3.5.10-k2-NAPI @3
On Fri, 2007-06-29 at 15:54 +0100, David Woodhouse wrote:
> On Wed, 2007-06-27 at 08:49 -0500, Josh Boyer wrote:
> > + remain in bug-fix only mode until it's scheduled removal. Platforms
>
> http://www.angryflower.com/itsits.gif
That's it? I'm scheduling the demise of an entire architectur
On Fri, 2007-06-29 at 17:24 +0200, Andreas Schwab wrote:
> Josh Boyer <[EMAIL PROTECTED]> writes:
>
> > +install: dtc ftdump
> > + $(INSTALL) -d $(DESTDIR)/$(BINDIR)
> > + $(INSTALL) -m 755 dtc $(DESTDIR)/$(BINDIR)
> > + $(INSTALL) -m 755 ftdump $(DESTDIR)/$(BINDIR)
>
> Don't put a slash af
>>> + remain in bug-fix only mode until it's scheduled removal.
>>> Platforms
>>
>> http://www.angryflower.com/itsits.gif
>
> That's it? I'm scheduling the demise of an entire architecture
> sub-tree
> and the only comment you can make is about a superfluous apostrophe? ;)
Oh there are bi
On Friday 29 June 2007, Kumar Gala wrote:
> > Would it work reliably if we switch the arguments to
> > '-mcpu=powerpc64 -m64' instead of '-m64 -mcpu=powerpc64'? That
> > might be better than taking it out entirely.
>
> Is there a reason you didn't use -mcpu=power3 and -mcpu=rs64 for
> those to C
On Jun 29, 2007, at 11:05 AM, Arnd Bergmann wrote:
> On Friday 29 June 2007, Kumar Gala wrote:
>>> Would it work reliably if we switch the arguments to
>>> '-mcpu=powerpc64 -m64' instead of '-m64 -mcpu=powerpc64'? That
>>> might be better than taking it out entirely.
>>
>> Is there a reason you d
On Fri, 29 Jun 2007 16:57:20 +0200
Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 29 June 2007 16:50:10 Christian Krafft wrote:
> > From: Christian Krafft <[EMAIL PROTECTED]>
> >
> > This patch fixes the following compiler warning:
> > arch/powerpc/kernel/sysfs.c:385: warning: ignoring ret
On Jun 29, 2007, at 11:05 AM, Arnd Bergmann wrote:
> On Friday 29 June 2007, Kumar Gala wrote:
>>> Would it work reliably if we switch the arguments to
>>> '-mcpu=powerpc64 -m64' instead of '-m64 -mcpu=powerpc64'? That
>>> might be better than taking it out entirely.
>>
>> Is there a reason you d
Benjamin Herrenschmidt wrote:
> On Fri, 2007-06-29 at 00:38 +0100, Matt Sealey wrote:
>> Benjamin Herrenschmidt wrote:
>>> On Thu, 2007-06-28 at 12:20 +0200, Marian Balakowicz wrote:
Hi,
Trying to change PCI IO window base for 52xx target I found that
we are pretty much limited
On Fri, Jun 29, 2007 at 04:14:42PM +0100, David Woodhouse wrote:
> On Fri, 2007-06-29 at 10:13 -0500, Josh Boyer wrote:
> > That's it? I'm scheduling the demise of an entire architecture
> > sub-tree and the only comment you can make is about a superfluous
> > apostrophe? ;)
>
> Sorry, allow me t
On Thu, Jun 28, 2007 at 09:01:58PM +0200, Guennadi Liakhovetski wrote:
> Sure, no problem, will repost with a description and a Signed-off-by...
> but, not giving Scott Wood credit for that patch doesn't seem right.
> Scott, is it ok with you if I repost that patch with your "Signed-off-by"
> fi
This patch makes the PHY optional for ucc_geth.c ethernet driver.
This is useful to support a direct mii to mii connection to, for example,
a onboard swicth.
Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 32bb748..8630294
Add of_register_i2c_devices(), which scans the children of the specified
I2C adapter node, and registers them with the I2C code.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: G. Liakhovetski <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/pro
On Thu, 28 Jun 2007, Paul Mackerras wrote:
> Guennadi Liakhovetski writes:
>
> > These two i2c patches:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
> >
> > also would be nice to get in, although, they
On Tue, 2007-06-26 at 09:50 +1000, Tony Breeds wrote:
> Updated to include feedback from Ben and Segher, also reposition the
> compare in the 64bit VDSO to catch all the references to tv.
> --- working.orig/arch/powerpc/kernel/vdso64/gettimeofday.S
> +++ working/arch/powerpc/kernel/vdso64/gettime
On Fri, 29 Jun 2007 14:32:09 +0200
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> allmodconfig on powerpc (iMac g3) fails due to
> git-kgdb.patch. allmodconfig defaults should be changed?
>
> CC arch/powerpc/kernel/kgdb.o
> arch/powerpc/kernel/kgdb.c:485:2: error: #error
The vdso64 portion of patch 74609f4536f2b8fd6a48381bbbe3cd37da20a527 for
fixing problems with NULL gettimeofday input mistakenly checks for a
null tz field twice, when it should be checking for null tz once, and
null tv once; by way of a r10/r11 typo.
Any application calling gettimeofday(&tv,NU
> The vdso64 portion of patch 74609f4536f2b8fd6a48381bbbe3cd37da20a527
> for
> fixing problems with NULL gettimeofday input mistakenly checks for a
> null tz field twice, when it should be checking for null tz once, and
> null tv once; by way of a r10/r11 typo.
>
> Any application calling gettimeo
> Define "legacy device"? What should that entail? You mean like mapping
> most of those registers to the first couple of kilobytes of "IO"?
Anything that hard-decodes IOs in the low ISA range yes. That includes
VGA video cards.
> If they're just left as their own on their own as PCI devices, wh
On Jun 27, 2007, at 17:51, Kumar Gala wrote:
>
What is the relationship between (in the example) the address
ranges x'f800_+1000 and x'f800_1000+ff000?
>>>
>>> uugh, not sure what that's all about.
>>
>> Reading back I see that the CCSR region is 1MB, and only the
>> first 4kB are f
I see this code in function of_platform_serial_setup():
static int __devinit of_platform_serial_setup(struct of_device *ofdev,
int type, struct uart_port *port)
{
struct resource resource;
struct device_node *np = ofdev->node;
const u
Andreas Schwab writes:
> The assembler should be called with -a64, which has the effect of
> defaulting to -mppc64.
Yes, the assembler is called with -a64, but that doesn't appear to
have the effect of defaulting to -mppc64.
[Alan: this thread is about the fact that compiling C code with "gcc
-m
44 matches
Mail list logo
