* [PATCH] powerpc: Fix 64 bits vDSO dwarf info for CR register
From: Benjamin Herrenschmidt @ 2007-10-17 4:23 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jakub Jelinek, linuxppc-dev list, Andrew Haley, Alan Modra,
Deepak Bhole
The current DWARF info for CR are incorrect causing the gcc unwinder to
go to lunch if taking a segfault in the vdso. This patch fixes it.
Problem identified by Andrew Haley, and fix provided by Jakub Jelinek
(thanks !).
Unfortunately, a bug in gcc cause it to not quite work either, but that
is being fixed separately with something around the lines of:
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/arch/powerpc/kernel/vdso64/sigtramp.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:32:49.000000000 +1000
+++ linux-work/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:34:18.000000000 +1000
@@ -134,13 +134,16 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
9:
/* This is where the pt_regs pointer can be found on the stack. */
-#define PTREGS 128+168+56
+#define PTREGS 128+168+56
/* Size of regs. */
-#define RSIZE 8
+#define RSIZE 8
+
+/* Size of CR reg in DWARF unwind info. */
+#define CRSIZE 4
/* This is the offset of the VMX reg pointer. */
-#define VREGS 48*RSIZE+33*8
+#define VREGS 48*RSIZE+33*8
/* Describe where general purpose regs are saved. */
#define EH_FRAME_GEN \
@@ -178,7 +181,7 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
rsave (31, 31*RSIZE); \
rsave (67, 32*RSIZE); /* ap, used as temp for nip */ \
rsave (65, 36*RSIZE); /* lr */ \
- rsave (70, 38*RSIZE) /* cr */
+ rsave (70, 38*RSIZE + (RSIZE - CRSIZE)) /* cr */
/* Describe where the FP regs are saved. */
#define EH_FRAME_FP \
^ permalink raw reply
* [PATCH] powerpc: Fix 64 bits vDSO dwarf info for CR register
From: Benjamin Herrenschmidt @ 2007-10-17 4:26 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jakub Jelinek, linuxppc-dev list, Andrew Haley, Alan Modra,
Deepak Bhole
The current DWARF info for CR are incorrect causing the gcc unwinder to
go to lunch if taking a segfault in the vdso. This patch fixes it.
Problem identified by Andrew Haley, and fix provided by Jakub Jelinek
(thanks !).
Unfortunately, a bug in gcc cause it to not quite work either, but that
is being fixed separately with something around the lines of:
linux-unwind.h:
fs->regs.reg[R_CR2].loc.offset = (long) ®s->ccr - new_cfa;
+ /* CR? regs are just 32-bit and PPC is big-endian. */
+ fs->regs.reg[R_CR2].loc.offset += sizeof (long) - 4;
(According to Jakub)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/arch/powerpc/kernel/vdso64/sigtramp.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:32:49.000000000 +1000
+++ linux-work/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:34:18.000000000 +1000
@@ -134,13 +134,16 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
9:
/* This is where the pt_regs pointer can be found on the stack. */
-#define PTREGS 128+168+56
+#define PTREGS 128+168+56
/* Size of regs. */
-#define RSIZE 8
+#define RSIZE 8
+
+/* Size of CR reg in DWARF unwind info. */
+#define CRSIZE 4
/* This is the offset of the VMX reg pointer. */
-#define VREGS 48*RSIZE+33*8
+#define VREGS 48*RSIZE+33*8
/* Describe where general purpose regs are saved. */
#define EH_FRAME_GEN \
@@ -178,7 +181,7 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
rsave (31, 31*RSIZE); \
rsave (67, 32*RSIZE); /* ap, used as temp for nip */ \
rsave (65, 36*RSIZE); /* lr */ \
- rsave (70, 38*RSIZE) /* cr */
+ rsave (70, 38*RSIZE + (RSIZE - CRSIZE)) /* cr */
/* Describe where the FP regs are saved. */
#define EH_FRAME_FP \
^ permalink raw reply
* [PATCH] Fix vmemmap warning in init_64..c
From: Tony Breeds @ 2007-10-17 4:30 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
Use the right printk format to silence the following warning.
CC arch/powerpc/mm/init_64.o
arch/powerpc/mm/init_64.c: In function 'vmemmap_populate':
arch/powerpc/mm/init_64.c:243: warning: format '%p' expects type 'void *', but argument 4 has type 'long unsigned int'
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Also a whitespace fix while I'm there.
arch/powerpc/mm/init_64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 702d884..6720b1c 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -240,7 +240,7 @@ int __meminit vmemmap_populate(struct page *start_page,
return -ENOMEM;
printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
- "physical %p.\n", start, p, __pa(p));
+ "physical %08lx.\n", start, p, __pa(p));
mapped = htab_bolt_mapping(start, start + page_size,
__pa(p), mode_rw, mmu_linear_psize,
--
1.5.3.4
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: current -git adbhid.c build error
From: Dmitry Torokhov @ 2007-10-17 4:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18197.36181.369197.363642@cargo.ozlabs.ibm.com>
On Wednesday 17 October 2007, Paul Mackerras wrote:
>
> It was a mis-merge between 555ddbb4, which made that change and *did*
> add the declaration of key, and 9a402b64, which deleted the line that
> the declaration of key was added to.
Oops, sorry.
>
> We need the patch below. Dmitry, will you push it or will I?
>
Please do. Thanks!
--
Dmitry
^ permalink raw reply
* Re: Merge dtc
From: David Gibson @ 2007-10-17 5:22 UTC (permalink / raw)
To: Grant Likely; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <fa686aa40710160617o57564cb4r260a40cd66407852@mail.gmail.com>
On Tue, Oct 16, 2007 at 07:17:01AM -0600, Grant Likely wrote:
> On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > This very large patch incorporates a copy of dtc into the kernel
> > source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> > longer an external dependency to build kernels with configurations
> > which need a dtb file.
>
> Powerpc is probably not going to be the only user of dtc. Microblaze
> will be using it too. Can it be put somewhere more common?
Well, I guess we can move it to scripts/ when microblaze starts using
it.
Also, tell me more about this microblaze, I'm certainly interested in
new users of dtc...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: New time code miscalculates cpu usage
From: Tony Breeds @ 2007-10-17 6:07 UTC (permalink / raw)
To: Olof Johansson; +Cc: paulus, linuxppc-dev
In-Reply-To: <20071016202525.GA11837@lixom.net>
On Tue, Oct 16, 2007 at 03:25:25PM -0500, Olof Johansson wrote:
> Hi,
>
> Not sure when this started happening, but I wanted to report it. I'll
> start bisecting in a day or two if noone else has gotten around to
> looking at it:
>
> $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> $ time ./a.out & sleep 2 ; killall a.out
> real 0m2.008s
> user 0m4.014s
> sys 0m0.002s
>
> Seen on POWER5 and PA6T, haven't tried anything else yet.
For what it's worth, this is my bug. I suspected it, and git bisect
confirmed it.I have an ugly work around now, but hope to have something
better out tomorrow.
Thanks Olof.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: PPC440EPx GPIO control help
From: Jeff Mock @ 2007-10-17 6:21 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <47158C69.2070903@ovro.caltech.edu>
David Hawkins wrote:
>> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21.
>> What I would want to do is to control (write and read values to) its
>> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and
>> inportb(0x378) to read. I read the PPC440EPx manual but I find it
>> difficult to understand.
>>
>> Could anyone show me any tutorial or some sample codes?
>
> I copied the code below from some test code I wrote for a TS7300
> board (uses an ARM EP9302 processor). However, since its user-space
> code it should work fine.
>
I might be a little out of date, but I think you must write your own
driver to wiggle the GPIO pins on a 440 processor. I just finished a
project using a 440GX with a 2.6.15 kernel (we froze the code about 8
months ago).
The 440 powerPC core is a 32-bit processor with 36-bit physical
addresses. The physical address for the GPIO pins is someplace above
4GB. An mmap() of /dev/mem only lets you map the lower 4GB of the
address space, as a result you can't write a user space program on the
440 to wiggle the GPIO pins. (This was true with 2.6.15, I can't speak
for later kernels).
This tossed me into writing device drivers, which turned out to be not
nearly as scary as I imagined. The Linux Device Drivers book is fabulous:
http://lwn.net/Kernel/LDD3/
Here is a driver for the 440GX that controls an LED on one of the GPIO
pins you can use as an example. The device /dev/pdev-led has a
read/write interface so you can do something like this:
# echo "1" > /dev/pdev-led # turn on LED
# echo "0" > /dev/pdev-led # turn off LED
It also has a /proc interface so you can cat /proc/pdev-led to read the
status of the LED. There are several other drivers there that probably
won't be interesting, but pdev-led.c is probably a good starting point:
http://www.mock.com/wsvn/listing.php?repname=mock.pdev&path=/trunk/sw/driver/
jeff
^ permalink raw reply
* 2.6.23-git-10 Build Failure on powerpc - asm-powerpc/dma_mapping.h
From: Kamalesh Babulal @ 2007-10-17 6:20 UTC (permalink / raw)
To: LKML, linuxppc-dev, Andy Whitcroft
Hi,
Build fails on the powerpc fails with 2.6.23-git10
CC init/main.o
In file included from include/linux/dma-mapping.h:42,
from include/linux/dmaengine.h:29,
from include/linux/skbuff.h:29,
from include/linux/netlink.h:155,
from include/linux/genetlink.h:4,
from include/net/genetlink.h:4,
from include/linux/taskstats_kern.h:12,
from init/main.c:45:
include/asm/dma-mapping.h: In function `dma_unmap_page':
include/asm/dma-mapping.h:14: error: implicit declaration of function `get_dma_ops'
include/asm/dma-mapping.h:14: warning: initialization makes pointer from integer without a cast
include/asm/dma-mapping.h:17: error: dereferencing pointer to incomplete type
include/asm/dma-mapping.h: At top level:
include/asm/dma-mapping.h:21: warning: `struct scatterlist' declared inside parameter list
include/asm/dma-mapping.h:21: warning: its scope is only this definition or declaration, which is probably not what you want
include/asm/dma-mapping.h: In function `dma_map_sg':
include/asm/dma-mapping.h:23: warning: initialization makes pointer from integer without a cast
include/asm/dma-mapping.h:26: error: dereferencing pointer to incomplete type
include/asm/dma-mapping.h: At top level:
include/asm/dma-mapping.h:31: warning: `struct scatterlist' declared inside parameter list
include/asm/dma-mapping.h: In function `dma_unmap_sg':
include/asm/dma-mapping.h:33: warning: initialization makes pointer from integer without a cast
include/asm/dma-mapping.h:36: error: dereferencing pointer to incomplete type
include/asm/dma-mapping.h: In function `dma_sync_single_for_cpu':
include/asm/dma-mapping.h:167: error: implicit declaration of function `__dma_sync'
include/asm/dma-mapping.h:167: error: implicit declaration of function `bus_to_virt'
include/asm/dma-mapping.h: At top level:
include/asm/dma-mapping.h:180: warning: `struct scatterlist' declared inside parameter list
include/asm/dma-mapping.h: In function `dma_sync_sg_for_cpu':
include/asm/dma-mapping.h:187: error: implicit declaration of function `for_each_sg'
include/asm/dma-mapping.h:188: error: parse error before "__dma_sync_page"
include/asm/dma-mapping.h: At top level:
include/asm/dma-mapping.h:193: warning: `struct scatterlist' declared inside parameter list
include/asm/dma-mapping.h: In function `dma_sync_sg_for_device':
include/asm/dma-mapping.h:201: error: parse error before "__dma_sync_page"
include/asm/dma-mapping.h: In function `dma_mapping_error':
include/asm/dma-mapping.h:207: error: `DMA_ERROR_CODE' undeclared (first use in this function)
include/asm/dma-mapping.h:207: error: (Each undeclared identifier is reported only once
include/asm/dma-mapping.h:207: error: for each function it appears in.)
In file included from include/linux/dma-mapping.h:42,
from include/linux/dmaengine.h:29,
from include/linux/skbuff.h:29,
from include/linux/netlink.h:155,
from include/linux/genetlink.h:4,
from include/net/genetlink.h:4,
from include/linux/taskstats_kern.h:12,
from init/main.c:45:
include/asm/dma-mapping.h:259:2: #endif without #if
include/asm/dma-mapping.h:260:2: #endif without #if
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: Geert Uytterhoeven @ 2007-10-17 6:38 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linux/PPC Development, Linux Kernel Development, Jens Axboe
In-Reply-To: <200710162150.37636.arnd@arndb.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1875 bytes --]
On Tue, 16 Oct 2007, Arnd Bergmann wrote:
> On Tuesday 16 October 2007, Geert Uytterhoeven wrote:
> > The recent (post 2.6.23) changes to compat_ioctl made the reporting of
> > unsupported ioctls more verbose. E.g. on the PS3 I get:
> >
> > | ioctl32(cdrom_id:608): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-11-0
> > | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
> > | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
> >
> > The first one is triggered by the detection of the CD/DVD/BD-ROM driver,
> > The others are triggered by me running hdparm.
> >
> > Was this intentional?
>
> No, it was certainly not intentional, and I can't figure out why it happens.
> The ioctl numbers from your example are HDIO_DRIVE_CMD and CDROM_GET_CAPABILITY,
> both of which should be handled through compat_blkdev_driver_ioctl by calling
> the native ioctl method of the driver, and return -ENOTTY otherwise.
>
> The one point where it is expected to have changed now is when you try
> to do these ioctls on something that is not a block device. Are you sure that
> the files you tried them on were created correctly?
/dev/ps3da is definitely a block device.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: 2.6.23-git-10 Build Failure on powerpc - asm-powerpc/dma_mapping.h
From: Olof Johansson @ 2007-10-17 6:50 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, LKML
In-Reply-To: <4715A9C1.9090106@linux.vnet.ibm.com>
Hi,
On Wed, Oct 17, 2007 at 11:50:49AM +0530, Kamalesh Babulal wrote:
> Build fails on the powerpc fails with 2.6.23-git10
This was fixed by 33ff910f0f466184ffc3514628f18403dcd86761.
-Olof
^ permalink raw reply
* [PATCH 1/2] Introduce of_get_pci_dev_node()
From: Michael Ellerman @ 2007-10-17 7:12 UTC (permalink / raw)
To: Paul Mackerras
Cc: sparclinux, Stephen Rothwell, David S. Miller, linuxppc-dev
Both powerpc and sparc have a routine, pci_device_to_OF_node(), which
returns the device_node associated with a given pci device.
The new routine, of_get_pci_dev_node(), performs exactly the same function
with the one exception that it returns a refcounted pointer to the
device_node, callers must then release the reference with of_node_put().
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
drivers/of/Makefile | 1 +
drivers/of/pci.c | 24 ++++++++++++++++++++++++
include/linux/of.h | 3 +++
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ab9be5d..f49898c 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,2 +1,3 @@
obj-y = base.o
obj-$(CONFIG_OF_DEVICE) += device.o platform.o
+obj-$(CONFIG_PCI) += pci.o
diff --git a/drivers/of/pci.c b/drivers/of/pci.c
new file mode 100644
index 0000000..2319c22
--- /dev/null
+++ b/drivers/of/pci.c
@@ -0,0 +1,24 @@
+/*
+ * Copyright 2007 Michael Ellerman, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/of.h>
+#include <linux/pci.h>
+
+/**
+ * of_get_pci_dev_node - Get a device node from a pci_dev
+ * @pdev: pci_dev to get the node from
+ *
+ * Returns a node pointer with refcount incremented, use
+ * of_node_put() on it when done.
+ */
+struct device_node *of_get_pci_dev_node(struct pci_dev *pdev)
+{
+ return of_node_get(pci_device_to_OF_node(pdev));
+}
+EXPORT_SYMBOL(of_get_pci_dev_node);
diff --git a/include/linux/of.h b/include/linux/of.h
index 6df80e9..e5bfb13 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -57,4 +57,7 @@ extern const void *of_get_property(const struct device_node *node,
extern int of_n_addr_cells(struct device_node *np);
extern int of_n_size_cells(struct device_node *np);
+struct pci_dev;
+extern struct device_node *of_get_pci_dev_node(struct pci_dev *pdev);
+
#endif /* _LINUX_OF_H */
--
1.5.1.3.g7a33b
^ permalink raw reply related
* [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Michael Ellerman @ 2007-10-17 7:12 UTC (permalink / raw)
To: Paul Mackerras
Cc: sparclinux, Stephen Rothwell, David S. Miller, linuxppc-dev
In-Reply-To: <8f76815cbbaf5fbab82c843d87bc0dafab038c80.1192605144.git.michael@ellerman.id.au>
Use of_get_pci_dev_node() in axon_msi.c. Switch to including <linux/of.h>
so we get the prototype.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/axon_msi.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index 095988f..034041c 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -14,10 +14,10 @@
#include <linux/pci.h>
#include <linux/msi.h>
#include <linux/reboot.h>
+#include <linux/of.h>
#include <asm/dcr.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
/*
@@ -119,7 +119,7 @@ static struct axon_msic *find_msi_translator(struct pci_dev *dev)
const phandle *ph;
struct axon_msic *msic = NULL;
- dn = of_node_get(pci_device_to_OF_node(dev));
+ dn = of_get_pci_dev_node(dev);
if (!dn) {
dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
return NULL;
@@ -176,7 +176,7 @@ static int setup_msi_msg_address(struct pci_dev *dev, struct msi_msg *msg)
int len;
const u32 *prop;
- dn = of_node_get(pci_device_to_OF_node(dev));
+ dn = of_get_pci_dev_node(dev);
if (!dn) {
dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
return -ENODEV;
--
1.5.1.3.g7a33b
^ permalink raw reply related
* Re: vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Geert Uytterhoeven @ 2007-10-17 8:49 UTC (permalink / raw)
To: Joseph Fannin; +Cc: linuxppc-dev, linux-fbdev-devel
In-Reply-To: <20071016191403.GA5962@nineveh.local>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2040 bytes --]
On Tue, 16 Oct 2007, Joseph Fannin wrote:
> vga16fb is an available config option on powerpc, but it won't link
> with my .config:
>
> ERROR: "vgacon_remap_base" [drivers/video/vga16fb.ko] undefined!
>
>
> I'm guessing this is because include/asm-powerpc/vga.h declares
> vgacon_remap_base:
>
> extern unsigned long vgacon_remap_base;
>
>
> ...but arch/powerpc/kernel/setup_32.c wraps the definition in an #ifdef:
>
> #ifdef CONFIG_VGA_CONSOLE
> unsigned long vgacon_remap_base;
> EXPORT_SYMBOL(vgacon_remap_base);
> #endif
>
>
> So CONFIG_VGA_CONSOLE=n and CONFIG_FB_VGA16=[y|m] won't work.
>
> I've also noticed that the only places in the tree that ever assign
> anything to config_remap_base are under arch/ppc. And
> include/asm-powerpc/vga.h also does this:
>
> #ifdef __powerpc64__
> #define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
> #else
> #define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
> #endif
>
>
> So VGACON probably doesn't work either on 32bit. I'm guessing arch/powerpc
> doesn't support PREP.
It's not only useful for PREP, but also for CHRP.
> How best could this be fixed up? Or should I just let the thing
> be? This is obviously not a new thing, and I don't have any hardware
> that supports this stuff either.
I remember this problem was present when I still had a working LongTrail (which
is CHRP), long before arch/powerpc/ was created.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH] Fix vmemmap warning in init_64..c
From: Geert Uytterhoeven @ 2007-10-17 8:55 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071017043024.GE9814@bakeyournoodle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1728 bytes --]
On Wed, 17 Oct 2007, Tony Breeds wrote:
> Use the right printk format to silence the following warning.
>
> CC arch/powerpc/mm/init_64.o
> arch/powerpc/mm/init_64.c: In function 'vmemmap_populate':
> arch/powerpc/mm/init_64.c:243: warning: format '%p' expects type 'void *', but argument 4 has type 'long unsigned int'
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
>
> Also a whitespace fix while I'm there.
>
> arch/powerpc/mm/init_64.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index 702d884..6720b1c 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -240,7 +240,7 @@ int __meminit vmemmap_populate(struct page *start_page,
> return -ENOMEM;
>
> printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
^^
> - "physical %p.\n", start, p, __pa(p));
> + "physical %08lx.\n", start, p, __pa(p));
^^
Anyone with memory outside 32-bit (`%08lx') space?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Benjamin Herrenschmidt @ 2007-10-17 9:01 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-fbdev-devel
In-Reply-To: <Pine.LNX.4.62.0710171047430.29856@pademelon.sonytel.be>
On Wed, 2007-10-17 at 10:49 +0200, Geert Uytterhoeven wrote:
> >
> > So VGACON probably doesn't work either on 32bit. I'm guessing
> arch/powerpc
> > doesn't support PREP.
>
> It's not only useful for PREP, but also for CHRP.
>
> > How best could this be fixed up? Or should I just let the thing
> > be? This is obviously not a new thing, and I don't have any
> hardware
> > that supports this stuff either.
>
> I remember this problem was present when I still had a working
> LongTrail (which
> is CHRP), long before arch/powerpc/ was created.
It's all very old stuff that needs to be dusted. If you have a setup
where legacy VGA is useable, feel free to do a bit of work on that :-)
Ben.
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Paul Mackerras @ 2007-10-17 10:27 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710161622v50484122s6ddbf6c4dc4b1e3f@mail.gmail.com>
Grant Likely writes:
> There are remaining outstanding comments; but my opinion is that they
> should be addressed in subsequent patches (performance optimization
> for mp5200b boards and making the sram management code a generic
> interface usable by other SoC support code).
>
> If you agree; please pull into your tree.
I'll pull it on the understanding that the remaining issues will in
fact be addressed in the near term.
Paul.
^ permalink raw reply
* Re: PPC440EPx GPIO control help
From: Josh Boyer @ 2007-10-17 10:49 UTC (permalink / raw)
To: Jeff Mock; +Cc: linuxppc-embedded
In-Reply-To: <4715A9D9.6090308@mock.com>
On Tue, 2007-10-16 at 23:21 -0700, Jeff Mock wrote:
> David Hawkins wrote:
> >> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21.
> >> What I would want to do is to control (write and read values to) its
> >> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and
> >> inportb(0x378) to read. I read the PPC440EPx manual but I find it
> >> difficult to understand.
> >>
> >> Could anyone show me any tutorial or some sample codes?
> >
> > I copied the code below from some test code I wrote for a TS7300
> > board (uses an ARM EP9302 processor). However, since its user-space
> > code it should work fine.
> >
>
> I might be a little out of date, but I think you must write your own
> driver to wiggle the GPIO pins on a 440 processor. I just finished a
> project using a 440GX with a 2.6.15 kernel (we froze the code about 8
> months ago).
>
> The 440 powerPC core is a 32-bit processor with 36-bit physical
> addresses. The physical address for the GPIO pins is someplace above
> 4GB. An mmap() of /dev/mem only lets you map the lower 4GB of the
> address space, as a result you can't write a user space program on the
> 440 to wiggle the GPIO pins. (This was true with 2.6.15, I can't speak
> for later kernels).
This depends on the 440 chip itself. If I recall correctly, the
440EP(x) chips don't have I/O above 4GB.
josh
^ permalink raw reply
* Re: [PATCH 01/15] [POWERPC] TQM5200 DTS
From: Marian Balakowicz @ 2007-10-17 11:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710071036u164f2cbaob8cfa4ebc0b1ed1c@mail.gmail.com>
Grant Likely wrote:
>> + memory {
>> + device_type = "memory";
>> + reg = <00000000 04000000>; // 64MB
>> + };
>> +
>> + soc5200@f0000000 {
>
> I think we're moving to the convetion of naming these nodes
> "soc@<addr>" now. (You can drop the 5200 for the node name)
Seems that this will not be painless, U-boot uses hardcoded
paths with 'soc5200', so the appropriate patch will be needed.
That may be ok for new boards but what do we do with lite5200,
where U-boot upgrade is not always an option?
m.
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: David Miller @ 2007-10-17 11:22 UTC (permalink / raw)
To: michael; +Cc: sparclinux, sfr, paulus, linuxppc-dev
In-Reply-To: <dadd2b9540369b9e2c6773b2a60021dadafa58e2.1192605144.git.michael@ellerman.id.au>
From: Michael Ellerman <michael@ellerman.id.au>
Date: Wed, 17 Oct 2007 17:12:27 +1000 (EST)
> Use of_get_pci_dev_node() in axon_msi.c. Switch to including <linux/of.h>
> so we get the prototype.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
I find it ironic that you add of_get_pci_dev_node() as a function
which gets the node and grabs a reference to it, and then the very
first usage you make of it doesn't drop the reference at all.
That reference grabbing aspect of the new interface is obviously very
useful! :-)
Kidding aside (I realize that in this case probably the driver never
unregisters and therefore the reference never needs to be released)
it's really much nicer to add facilities when you have patches in hand
that actually use them.
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: David Miller @ 2007-10-17 11:23 UTC (permalink / raw)
To: michael; +Cc: sparclinux, sfr, paulus, linuxppc-dev
In-Reply-To: <20071017.042229.95059231.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 17 Oct 2007 04:22:29 -0700 (PDT)
> From: Michael Ellerman <michael@ellerman.id.au>
> Date: Wed, 17 Oct 2007 17:12:27 +1000 (EST)
>
> > Use of_get_pci_dev_node() in axon_msi.c. Switch to including <linux/of.h>
> > so we get the prototype.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>
> I find it ironic that you add of_get_pci_dev_node() as a function
> which gets the node and grabs a reference to it, and then the very
> first usage you make of it doesn't drop the reference at all.
Ignore this poor attempt at humor, I misread your patch :)
^ permalink raw reply
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Marian Balakowicz @ 2007-10-17 11:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710072321g3494b243w341e2b09117c3695@mail.gmail.com>
Grant Likely wrote:
> Both this patch and the CM5200 support patch (#6 in your series) are
> pretty much clones of lite5200.c. I don't think this is the right
> approach. Don't duplicate code in this way. Determine the common
> bits and put them in a common place to be usable by any 5200 board
> port.
>
> It might even be better just to add a platform that matches on
> compatible='mpc5200-generic' which is usable for mpc5200 boards that
> don't need any custom setup by the kernel at platform setup time.
> (which will probably be most 5200 boards).
Agree, will try more generic approach.
>> +static void __init
>> +tqm5200_setup_cpu(void)
>> +{
>> + struct mpc52xx_gpio __iomem *gpio;
>> + u32 port_config;
>> +
>> + /* Map zones */
>> + gpio = mpc52xx_find_and_map("mpc5200-gpio");
>> + if (!gpio) {
>> + printk(KERN_ERR __FILE__ ": "
>> + "Error while mapping GPIO register for port config. "
>> + "Expect some abnormal behavior\n");
>> + goto error;
>> + }
>> +
>> + /* Set port config */
>> + port_config = in_be32(&gpio->port_config);
>> +
>> + port_config &= ~0x00800000; /* 48Mhz internal, pin is GPIO */
>> +
>> + port_config &= ~0x00007000; /* USB port : Differential mode */
>> + port_config |= 0x00001000; /* USB 1 only */
>> +
>> + port_config &= ~0x03000000; /* ATA CS is on csb_4/5 */
>> + port_config |= 0x01000000;
>
> Are you *sure* you want this? You should only be touching port_config
> if firmware fails to set it up correctly. Don't blindly copy what was
> done for the lite5200.
>
> Lite5200 touches it because firmware does *not* do the right thing at
> the moment.
Yes, that's needed, but will be moved to U-boot.
>> +void tqm5200_show_cpuinfo(struct seq_file *m)
>> +{
>> + struct device_node* np = of_find_all_nodes(NULL);
>> + const char *model = NULL;
>> +
>> + if (np)
>> + model = of_get_property(np, "model", NULL);
>> +
>> + seq_printf(m, "vendor\t\t: Freescale Semiconductor\n");
>
> Freescale? Really?
Well, not really...
Something like
seq_printf(m, "Vendor\t\t: TQ Components\n");
seq_printf(m, "Machine\t\t: %s\n", model);
and model set to 'tqc,tqm5200' would be more accurate but going for
compatible='mpc5200-generic' platform we may need to drop Vendor line
anyway.
m.
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Benjamin Herrenschmidt @ 2007-10-17 11:36 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, paulus, linuxppc-dev, sfr
In-Reply-To: <20071017.042229.95059231.davem@davemloft.net>
> I find it ironic that you add of_get_pci_dev_node() as a function
> which gets the node and grabs a reference to it, and then the very
> first usage you make of it doesn't drop the reference at all.
>
> That reference grabbing aspect of the new interface is obviously very
> useful! :-)
>
> Kidding aside (I realize that in this case probably the driver never
> unregisters and therefore the reference never needs to be released)
> it's really much nicer to add facilities when you have patches in hand
> that actually use them.
I think in this case, it's mostly a matter of consistency... pretty much
everything that returns a device_node grabs a reference... except
pci_device_to_OF_node :-)
I think Michael is trying to address that, and axon-msi happens to be
something he wrote so a good candidate for an initial conversion :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Marian Balakowicz @ 2007-10-17 11:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071008150449.GB4289@loki.buserror.net>
Scott Wood wrote:
>
>> +void tqm5200_show_cpuinfo(struct seq_file *m)
>> +{
>> + struct device_node* np = of_find_all_nodes(NULL);
>> + const char *model = NULL;
>> +
>> + if (np)
>> + model = of_get_property(np, "model", NULL);
>> +
>> + seq_printf(m, "vendor\t\t: Freescale Semiconductor\n");
>> + seq_printf(m, "machine\t\t: %s\n", model ? model : "unknown");
>> +
>> + of_node_put(np);
>> +}
>
> Get rid of this.
Agree, that may be overhead in some cases. But there would be also
cases where printing out a machine name would be informative. CM5200
is one such example, there are several variants of the hw and platform
name is too generic.
Other situation would be adding compatible='mpc5200-generic' platform
where platform name would not provide any details.
m.
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-17 12:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40710161237t54688b71g9c7cf9acdac2b744@mail.gmail.com>
Hello.
Grant Likely-2 wrote:
>
> On 10/16/07, aauer1 <aauer1@gmx.at> wrote:
>>
>> The on-chip memories are disabled. Only the BRAM is enabled. Now, we also
>> use
>> the ELDK 4.1 from Denx and the included cross compiler. The result is the
>> same... the Kernel stops at "Now booting the kernel". Now, we also have
>> an
>> USB JTAG cable. So, we can debug the memory.
>> Probably, anyone has another idea.
>
> There are two common reasons for this behaviour:
> 1. kernel crashes before the console is configured
> 2. the console is not configured correctly.
>
> In both cases; finding a way to look at __log_buf is the fastest way
> to figure out what is going on.
>
>
I was able to look at the __log_buf variable with the JTAG cable. So, I
recognized that the kernel doesn't halt after the "No booting the kernel"
message. There are many output messages in the __log_buf variable until it
stops at with a "Kernel panic" because the rootfs is not found (but this is
the minor problem).
Now, I know that the kernel boots but I don't get an output with my Xilinx
UartLite module. Are there some kernel modules which must be activated??
Btw. I have used the Linux-2.6-virtex kernel from
http://git.secretlab.ca/git/ and another Kernel (2.6.23 from kernel.org) -
both with the same result.
Thanks a lot,
Andreas
--
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13252272
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: dtc: Restore missing code for testcases
From: Jon Loeliger @ 2007-10-17 12:11 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071017012357.GE28260@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Recent commits 333542fabf8720b881e992a5abca32ef4bcb841a and
> fd1bf3a5ae46962528ef89a824261a88830758a2 added new testcases to dtc.
> However, although the testcases were added to the Makefile and
> run_tests.sh, one of the .c files for the testcase was omitted from
> the patch in each case.
>
> This patch restores the missing testcase code.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
> jdl, you should
> really run a "make check" before committing my patches...
In the past, I have. I confess, this last round I only
compiled tested things. I'm really still catching up some...
jdl
^ 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