* time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-23 10:46 UTC (permalink / raw)
To: Linux Kernel list; +Cc: linuxppc-dev list
Hi,
On my powerbook, with NO_HZ and HIGH_RES_TIMERS, I observed recently
that powernowd would not ever switch between CPU speeds.
Doing some scripting to read /proc/stat every half second and print the
differences, I get output like this on a mostly idle system:
# for reference:
# [user, nice, system, idle, iowait, irq, softirq, steal, guest]
[4, 0, 3, 46, 0, 264, 0, 0, 0]
[5, 0, 4, 41, 0, 266, 0, 0, 0]
[4, 0, 7, 37, 0, 299, 0, 0, 0]
Now starting an empty while (1) loop, I see:
[53, 0, 1, 0, 0, 243, 0, 0, 0]
[53, 0, 2, 0, 0, 224, 0, 0, 0]
[45, 0, 7, 0, 0, 249, 0, 0, 0]
As you can see, the "irq" time is very high so that "user" (mostly my
CPU burning program) only accounts for maybe 15%. This leads to
powernowd thinking that all is fine and no switching is required. Also,
the whole stuff leads to top(1) displaying about 80-90% "hi" (hard irq?
calculated as irq - softirq?) time.
Does anybody have an idea why the irq time is so high? And no, I don't
think it can actually be true, I'm seeing maybe 500 interrupts/second
(most due to USB).
johannes
^ permalink raw reply
* Re: cant' compile busybox-1.8.1 with eldk 4.1
From: Clemens Koller @ 2007-11-23 12:05 UTC (permalink / raw)
To: fabien; +Cc: linuxppc-embedded
In-Reply-To: <f8f856500711230256j5f3c7b9fneb7351a4fdfdfe09@mail.gmail.com>
fabien schrieb:
> I try to compile busybox for my ppc custom board.
What ARCH/cpu?
> I successfuly
> compile kernel 2.6.19 with
> eldk and boot it. Now i try to get busybox working but i get some
> errors at compile time.
> It's look strange if someone can spend one minute to look at the compile log
> What step could i miss ?
> [...]
> /opt/eldk/usr/../ppc_8xx/usr/include/linux/param.h:4:23: error:
> asm/param.h: No such file or directory
> make[1]: *** [applets/applets.o] Erreur 1
> make: *** [applets] Erreur 2
It looks like your kernel headers (ARCH-specific or generic)
are broken or missing.
See i.e. Linux From Scratch to get an idea about the dependencies.
Or, see latest kernel's 'make headers_install' target and how it is used.
Google is your friend, here...
The busybox mailing list would be more suited for this question.
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* cant' compile busybox-1.8.1 with eldk 4.1
From: fabien @ 2007-11-23 10:56 UTC (permalink / raw)
To: linuxppc-embedded
I try to compile busybox for my ppc custom board. I successfuly
compile kernel 2.6.19 with
eldk and boot it. Now i try to get busybox working but i get some
errors at compile time.
It's look strange if someone can spend one minute to look at the compile log
What step could i miss ?
Thank a lot
[fabien@localhost busybox-1.8.1] cat /opt/eldk/version
ELDK version 4.1
ppc_8xx: Build 2007-01-21-uclibc
[fabien@localhost busybox-1.8.1]$ make CROSS_COMPILE=ppc_8xx-
CC applets/applets.o
In file included from /opt/eldk/usr/../ppc_8xx/usr/include/netinet/in.h:212,
from /opt/eldk/usr/../ppc_8xx/usr/include/arpa/inet.h:23,
from include/platform.h:139,
from include/libbb.h:13,
from include/busybox.h:10,
from applets/applets.c:11:
/opt/eldk/usr/../ppc_8xx/usr/include/bits/socket.h:305:24: error:
asm/socket.h: No such file or directory
In file included from /opt/eldk/usr/../ppc_8xx/usr/include/sys/ioctl.h:27,
from /opt/eldk/usr/../ppc_8xx/usr/include/sys/mount.h:26,
from include/platform.h:305,
from include/libbb.h:13,
from include/busybox.h:10,
from applets/applets.c:11:
/opt/eldk/usr/../ppc_8xx/usr/include/bits/ioctls.h:24:24: error:
asm/ioctls.h: No such file or directory
In file included from /opt/eldk/usr/../ppc_8xx/usr/include/signal.h:309,
from include/libbb.h:23,
from include/busybox.h:10,
from applets/applets.c:11:
/opt/eldk/usr/../ppc_8xx/usr/include/bits/sigcontext.h:28:29: error:
asm/sigcontext.h: No such file or directory
In file included from /opt/eldk/usr/../ppc_8xx/usr/include/ucontext.h:25,
from /opt/eldk/usr/../ppc_8xx/usr/include/signal.h:326,
from include/libbb.h:23,
from include/busybox.h:10,
from applets/applets.c:11:
/opt/eldk/usr/../ppc_8xx/usr/include/sys/ucontext.h:37: error: field
'uc_mcontext' has incomplete type
In file included from /opt/eldk/usr/../ppc_8xx/usr/include/sys/param.h:24,
from include/libbb.h:67,
from include/busybox.h:10,
from applets/applets.c:11:
/opt/eldk/usr/../ppc_8xx/usr/include/linux/param.h:4:23: error:
asm/param.h: No such file or directory
make[1]: *** [applets/applets.o] Erreur 1
make: *** [applets] Erreur 2
^ permalink raw reply
* Re: ML403 USB driver
From: Peter Korsgaard @ 2007-11-23 10:34 UTC (permalink / raw)
To: Lorenz Kolb; +Cc: linuxppc-embedded
In-Reply-To: <13858912.post@talk.nabble.com>
>>>>> "Lorenz" == Lorenz Kolb <linuxppcemb@lkmail.de> writes:
Lorenz> Hi,
Lorenz> we just tried the USB driver (from Peter Korsgaard) from
Lorenz> Grant's virtex tree.
Lorenz> Nevertheless we could not get the peripheral ports work as gadgets.
Lorenz> Has anyone tried (and probably fixed) that before?
My driver so far only has host support. I'm working on the peripheral
support (or rather, a colleage of mine is) but it's quite early days
..
Lorenz> Anyway, only one of the two peripheral ports seems to be active.
The Linux gadget stack only support a single peripheral port.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Firmware Support for USB Hub
From: Misbah khan @ 2007-11-23 8:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13877282.post@talk.nabble.com>
This is the reply that i got from the Freescale :-
--------------------------------------------------------------------------
Reply from Freescale
In reply to your Service Request SR 1-403672820:
We recommend using the MPC8272 USB controller.
We know that customers use the MPC8272/MPC8248 USB controller.
You can find also USB drivers in Linux software for the MPC8272.
For example Linux BSP for Freescale MPC8272ADS contains USB slave
driver
(http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0127260061033202A5).
Linux USB driver is available in the Arabella Linux
(http://www.arabellasw.com/products-pow2.php).
If the MPC8272 is USB host, the transaction-level interface can be used.
Note: The MPC8272 USB does not support high-speed mode. It can
operate on low-speed mode (1.5MHz) or full-speed mode (12MHz).
------------------------------------------------------------------------------------------
Can any body comment on this and help me how to start with and requirement
is this :-
I need a USB Hub to be connected to the PPC8248 board with Montavista Linux
2.6.10
on it what shall i do to achive it ....????The challenges you already know
Hoping for the the Help ...
Misbah khan wrote:
>
> Hi all,
>
> I am using a 8248 processor which has a USB controller and i need to
> connect a USB Hub to it, iam using Montavista Linux .I need to know that
> what are the support i need form Montavista or Open source to have an
> interface with Usb hub. ???
>
> Is there any driver that we need to make if so what type ???
>
> --misbah <><
>
--
View this message in context: http://www.nabble.com/Firmware-Support-for-USB-Hub-tf4850180.html#a13908701
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* register writing fails
From: Deep Deep @ 2007-11-23 6:55 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
Hi everyone,
I am writing a serial port driver for ppc board. I am facing a very strange problem. I can read the values from registers of serial port but at the time of configuration or writing the values in the register, its not allowing me to change the reset values. I am not sure about the problem cause.
Thanks,
sachin
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
[-- Attachment #2: Type: text/html, Size: 725 bytes --]
^ permalink raw reply
* Re: [PATCH] PPC: CHRP - fix possible NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-23 5:43 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Olof Johansson, PPCML, Paul Mackerras, LKML
In-Reply-To: <20071123101646.63550945.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 232 bytes --]
Here is updated version
---
From: Cyrill Gorcunov <gorcunov@gmail.com>
This patch does fix possible NULL pointer dereference
inside of strncmp() if of_get_property() failed.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
[-- Attachment #2: ppc-chrs-null-fix.diff --]
[-- Type: text/plain, Size: 1356 bytes --]
arch/powerpc/platforms/chrp/setup.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
index 5930626..da4e45e 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -115,7 +115,7 @@ void chrp_show_cpuinfo(struct seq_file *m)
seq_printf(m, "machine\t\t: CHRP %s\n", model);
/* longtrail (goldengate) stuff */
- if (!strncmp(model, "IBM,LongTrail", 13)) {
+ if (model && !strncmp(model, "IBM,LongTrail", 13)) {
/* VLSI VAS96011/12 `Golden Gate 2' */
/* Memory banks */
sdramen = (in_le32(gg2_pci_config_base + GG2_PCI_DRAM_CTRL)
@@ -203,15 +203,20 @@ static void __init sio_fixup_irq(const char *name, u8 device, u8 level,
static void __init sio_init(void)
{
struct device_node *root;
+ const char *model;
- if ((root = of_find_node_by_path("/")) &&
- !strncmp(of_get_property(root, "model", NULL),
- "IBM,LongTrail", 13)) {
+ root = of_find_node_by_path("/");
+ if (!root)
+ return;
+
+ model = of_get_property(root, "model", NULL);
+ if (model && !strncmp(model,"IBM,LongTrail", 13)) {
/* logical device 0 (KBC/Keyboard) */
sio_fixup_irq("keyboard", 0, 1, 2);
/* select logical device 1 (KBC/Mouse) */
sio_fixup_irq("mouse", 1, 12, 2);
}
+
of_node_put(root);
}
^ permalink raw reply related
* Re: [PATCH 01/10] powerpc: Set up OF properties for ppc32 kexec
From: Dale Farnsworth @ 2007-11-23 4:43 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071123091727.6e6fcd7a.sfr@canb.auug.org.au>
On Fri, Nov 23, 2007 at 09:17:27AM +1100, Stephen Rothwell wrote:
> Hi Dale,
>
> Just a nit ...
>
> On Thu, 22 Nov 2007 08:45:17 -0700 Dale Farnsworth <dale@farnsworth.org> wrote:
> > +static struct property crashk_base_prop = {
> > + .name = "linux,crashkernel-base",
> > + .length = sizeof(unsigned long),
> > + .value = &crashk_res.start, };
Heh. How did that happen? :)
I'll fix it as well as the alignment issues you mentioned.
Thanks Stephen.
-Dale
^ permalink raw reply
* Re: [PATCH] PPC: CHRP - fix possible NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-23 4:23 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Olof Johansson, PPCML, Paul Mackerras, LKML
In-Reply-To: <20071123101646.63550945.sfr@canb.auug.org.au>
On 11/23/07, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Thu, 22 Nov 2007 22:54:23 +0300 Cyrill Gorcunov <gorcunov@gmail.com>
> wrote:
> >
> > This patch does fix possible NULL pointer dereference
> > inside of strncmp() if of_get_property() failed.
>
> Thanks for this.
>
> > static void __init sio_init(void)
> > {
> > struct device_node *root;
> > + const char *model = NULL;
>
> You don't need this initialization as you always assign the variable
> before you use it.
>
> > + root = of_find_node_by_path("/");
> > + if (root) {
>
> if (!root)
> return;
>
> would save a level of indentation. Not important.
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
Oh my :) Thanks. I'll fix it and resend.
^ permalink raw reply
* Re: Initramfs problem on virtex4fx
From: David H. Lynch Jr. @ 2007-11-23 1:20 UTC (permalink / raw)
To: schardt; +Cc: Linux PPC Linux PPC
In-Reply-To: <47453B63.6010100@fz-juelich.de>
schardt wrote:
> Hi all,
>
> i try to run linux from flash with the initramfs as root filesystem.
> i wrote a simple hello_world as init to test the initramfs.
>
> the kernel boots normaly, but instead of the complete "Hello World" i
> see only "He"
> and the system hangs.
>
> Does anyone have similar problems ? And solved it ? ;)
>
> Regards
> Georg
>
The Pico Linux BSP uses initramfs. The whole Pico Linux development
environment including busybox and an initramfs cross compilers, Linux
source - pretty much everything you need is at
http://www.picocomputing.com/downloads/software.php, everything is
incorporated into a Colinux install, though you can just pull out the
necescary peices - the cross compiler, busy box, intramfs and linux
source if you are working completely under linux.
>
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> Forschungszentrum Jülich GmbH
> 52425 Jülich
>
> Sitz der Gesellschaft: Jülich
> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
> -------------------------------------------------------------------
> -------------------------------------------------------------------
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Benjamin Herrenschmidt @ 2007-11-23 0:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9e4733910711221600t378a3afate51cc798df0d8b8d@mail.gmail.com>
On Thu, 2007-11-22 at 19:00 -0500, Jon Smirl wrote:
> > It seems like AMCC does provide the necessary infos for 4xx
> processors
> > though. Jon, do you think what they provide is enough to use an open
> > source debugger ?
>
> Do you have a link to the info?
Not at hand, but easy to find from AMCC main product page, you can then
go to the various eval board download pages, and some of the d/l are
infos for JTAG debugger manufacturers.
Ben.
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Jon Smirl @ 2007-11-23 0:00 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1195774625.6970.145.camel@pasglop>
On 11/22/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-11-18 at 01:47 +0100, Wolfgang Denk wrote:
> > In message <9e4733910711141834n2bfb1742v5637c56e27e26f5a@mail.gmail.com> you wrote:
> > >
> > > > * The documentation is only available under NDA, a problem for open
> > > > source debuggers.
> > >
> > > This is what we need. I would like it specifically for the mpc5200.
> > > But we want to use it in OpenOCD so NDA won't work.
> >
> > It doesn't work. Been there a logn time ago. It's and endless
> > fingerpointing. Freescale (by then: Motorola) says they cannot
> > release any information because of their contracts with IBM, and vice
> > versa.
>
> It seems like AMCC does provide the necessary infos for 4xx processors
> though. Jon, do you think what they provide is enough to use an open
> source debugger ?
Do you have a link to the info?
>
> Ben.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Hardware debuggers for PPC74xx G4 CPUs
From: Benjamin Herrenschmidt @ 2007-11-22 23:37 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20071118004729.67824247F1@gemini.denx.de>
On Sun, 2007-11-18 at 01:47 +0100, Wolfgang Denk wrote:
> In message <9e4733910711141834n2bfb1742v5637c56e27e26f5a@mail.gmail.com> you wrote:
> >
> > > * The documentation is only available under NDA, a problem for open
> > > source debuggers.
> >
> > This is what we need. I would like it specifically for the mpc5200.
> > But we want to use it in OpenOCD so NDA won't work.
>
> It doesn't work. Been there a logn time ago. It's and endless
> fingerpointing. Freescale (by then: Motorola) says they cannot
> release any information because of their contracts with IBM, and vice
> versa.
It seems like AMCC does provide the necessary infos for 4xx processors
though. Jon, do you think what they provide is enough to use an open
source debugger ?
Ben.
^ permalink raw reply
* Re: [PATCH] PPC: CHRP - fix possible NULL pointer dereference
From: Stephen Rothwell @ 2007-11-22 23:16 UTC (permalink / raw)
To: Cyrill Gorcunov; +Cc: Olof Johansson, PPCML, Paul, Mackerras, LKML
In-Reply-To: <20071122195423.GA9877@cvg>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On Thu, 22 Nov 2007 22:54:23 +0300 Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>
> This patch does fix possible NULL pointer dereference
> inside of strncmp() if of_get_property() failed.
Thanks for this.
> static void __init sio_init(void)
> {
> struct device_node *root;
> + const char *model = NULL;
You don't need this initialization as you always assign the variable
before you use it.
> + root = of_find_node_by_path("/");
> + if (root) {
if (!root)
return;
would save a level of indentation. Not important.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 03/10] powerpc: Add kexec support for PPC_85xx platforms
From: Stephen Rothwell @ 2007-11-22 22:20 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20071122154607.GA26447@xyzzy.farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]
More nits ...
On Thu, 22 Nov 2007 08:46:07 -0700 Dale Farnsworth <dale@farnsworth.org> wrote:
>
> @@ -259,6 +260,11 @@ define_machine(mpc85xx_ads) {
> .show_cpuinfo = mpc85xx_ads_show_cpuinfo,
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> +#ifdef CONFIG_KEXEC
> + .machine_kexec_prepare = default_machine_kexec_prepare,
> + .machine_kexec = default_machine_kexec,
> + .machine_crash_shutdown = default_machine_crash_shutdown,
> +#endif
Please line these up for consistency.
> @@ -352,6 +353,11 @@ define_machine(mpc85xx_cds) {
> #else
> .restart = fsl_rstcr_restart,
> #endif
> +#ifdef CONFIG_KEXEC
> + .machine_kexec_prepare = default_machine_kexec_prepare,
> + .machine_kexec = default_machine_kexec,
> + .machine_crash_shutdown = default_machine_crash_shutdown,
> +#endif
And here
> @@ -224,6 +225,11 @@ define_machine(mpc8572_ds) {
> #endif
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> +#ifdef CONFIG_KEXEC
> + .machine_kexec_prepare = default_machine_kexec_prepare,
> + .machine_kexec = default_machine_kexec,
> + .machine_crash_shutdown = default_machine_crash_shutdown,
> +#endif
And again ...
> @@ -202,6 +203,11 @@ define_machine(mpc85xx_mds) {
> .init_IRQ = mpc85xx_mds_pic_init,
> .get_irq = mpic_get_irq,
> .restart = fsl_rstcr_restart,
> +#ifdef CONFIG_KEXEC
> + .machine_kexec_prepare = default_machine_kexec_prepare,
> + .machine_kexec = default_machine_kexec,
> + .machine_crash_shutdown = default_machine_crash_shutdown,
> +#endif
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 01/10] powerpc: Set up OF properties for ppc32 kexec
From: Stephen Rothwell @ 2007-11-22 22:17 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20071122154517.GA26340@xyzzy.farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
Hi Dale,
Just a nit ...
On Thu, 22 Nov 2007 08:45:17 -0700 Dale Farnsworth <dale@farnsworth.org> wrote:
>
> +static struct property crashk_base_prop = {
> + .name = "linux,crashkernel-base",
> + .length = sizeof(unsigned long),
> + .value = &crashk_res.start, };
^^
Should be on a new line.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* #PPC: timeout while waiting for freeze
From: Bheemappa @ 2007-11-22 6:00 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I am using BDI2000 debugger to debug our custom board which has
MPC7457 processor and Marvell's discovery-ii(MV64360) as host bridge. I
have
connectd target board to BDI using JTAG.I am getting the BDI prompt and
also its reading PVR number correctly, but when I am trying to access
any memory location i.e 0xf1000000 using below command its giving below
error.
BDI> md 0xf1000000
#PPC: timeout while waiting for freeze
Why this error is coming ? , can you give us more detailed description
for this error message , so that we can trace the source of error mssage.
Regards
Bheema
RASS Tech Pvt Ltd
Bangalore
^ permalink raw reply
* Re: oops trying to execute sh
From: Vitaly Bordug @ 2007-11-22 22:06 UTC (permalink / raw)
To: John Charles Tyner; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711211149210.3338@eon.cs.ucr.edu>
On Wed, 21 Nov 2007 11:54:01 -0800 (PST)
John Charles Tyner wrote:
> I'm trying to boot linux 2.6.22.9 on an mpc860c rev d4.
>
ppc or powerpc?
> When init trys to spawn sh, during the exec, the kernel oopses as
> seen below:
This looks like coherency problem, or kernel picks wrong entry off cputable.
I think I recall something similar when I lost a hunk applying patch for new e300 core.
... or not. The game across that ff8.. value is very confusing.
>
--
Sincerely, Vitaly
^ permalink raw reply
* [patch v2] PS3: Fix printing of os-area magic numbers
From: Geoff Levand @ 2007-11-22 22:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Geert Uytterhoeven, linuxppc-dev@ozlabs.org
In-Reply-To: <473F6A28.5000309@am.sony.com>
Fix a bug in the printing of the os-area magic numbers which assumed that
magic numbers were zero terminated strings. The magic numbers are represented
in memory as integers. If the os-area sections are not initialized correctly
they could contained random data that would be printed to the display.
CC: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
v2: handle unprintable chars.
Paul,
This fixes a very minor bug in linus' current tree. Please consider
for 2.6.24.
-Geoff
arch/powerpc/platforms/ps3/os-area.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
@@ -23,6 +23,7 @@
#include <linux/workqueue.h>
#include <linux/fs.h>
#include <linux/syscalls.h>
+#include <linux/ctype.h>
#include <asm/lmb.h>
@@ -269,8 +270,17 @@ static void __init os_area_get_property(
static void _dump_header(const struct os_area_header *h, const char *func,
int line)
{
+ u8 str[sizeof(h->magic_num) + 1];
+ u8 *s, *d;
+
+ for(s = h->magic_num, d = str; s < h->magic_num + sizeof(h->magic_num);
+ s++, d++) {
+ *d = isprint(*s) ? *s : '.';
+ }
+ d[sizeof(h->magic_num)] = 0;
+
pr_debug("%s:%d: h.magic_num: '%s'\n", func, line,
- h->magic_num);
+ str);
pr_debug("%s:%d: h.hdr_version: %u\n", func, line,
h->hdr_version);
pr_debug("%s:%d: h.db_area_offset: %u\n", func, line,
@@ -484,8 +494,17 @@ static int db_get_rtc_diff(const struct
static void _dump_db(const struct os_area_db *db, const char *func,
int line)
{
+ u8 str[sizeof(db->magic_num) + 1];
+ u8 *s, *d;
+
+ for(s = (u8*)&db->magic_num, d = str;
+ s < (u8*)&db->magic_num + sizeof(db->magic_num); s++, d++) {
+ *d = isprint(*s) ? *s : '.';
+ }
+ d[sizeof(db->magic_num)] = 0;
+
pr_debug("%s:%d: db.magic_num: '%s'\n", func, line,
- (const char*)&db->magic_num);
+ str);
pr_debug("%s:%d: db.version: %u\n", func, line,
db->version);
pr_debug("%s:%d: db.index_64: %u\n", func, line,
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Vitaly Bordug @ 2007-11-22 21:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40711221036n6438c252lde71cffdaff97ea9@mail.gmail.com>
On Thu, 22 Nov 2007 11:36:29 -0700
Grant Likely wrote:
> > +int cpm_command(u32 command, u8 opcode)
> > +{
> > + int i;
> > +
> > + if (command & 0xffffff0f)
> > + return -EINVAL;
> > +
> > + out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode <<
> > 8));
> > + for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> > + if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
> > + return 0;
> > +
> > + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> > + __FUNCTION__);
> > + return -EIO;
>
> Do these need to be protected with a spin lock?
Even that might be not enough - we may have simultaneous call of this func in non-smp case...
I was thinking of some kind of refcount, so one that is going to issue CPM command, must do say pq_cpmp_get()
and another driver won't be able to mangle with cpcr while it's not done with previous request.
Yet I am not telling it was better the way it used to be - this approach looks okay but needs some efforts to defend against
deadlocks while we are at it.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC/PATCH 2/14] powerpc: Merge pci_process_bridge_OF_ranges()
From: Vitaly Bordug @ 2007-11-22 18:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071121061709.5C616DEAA1@ozlabs.org>
On Wed, 21 Nov 2007 17:16:19 +1100
Benjamin Herrenschmidt wrote:
> This patch merges the 32 and 64 bits implementations of
> pci_process_bridge_OF_ranges(). The new function is cleaner than both
> the old ones supports 64 bits ranges on ppc32 which is necessary for
> the 4xx port.
>
> It also adds some better (hopefully) output to the kernel log which
> should help disagnose problems and makes better use of existing OF
> parsing helpers (avoiding a few bugs of both implementations along
> the way).
>
> There are still a few unfortunate ifdef's but there is no way around
> these for now at least not until some other bits of the PCI code are
> made common.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
>
> Tested on a few pSeries, PowerMac G5, and a 32 bits PowerMacs and
> a BriQ. Please let me know if it misbehaves anywhere else.
>
Tested (whole series but anyway) on FSL 83xx reference platforms,
no issues to address. Good work!
> arch/powerpc/kernel/pci-common.c | 176
> +++++++++++++++++++++++++++++++++++++++
> arch/powerpc/kernel/pci_32.c | 114 -------------------------
> arch/powerpc/kernel/pci_64.c | 93 --------------------
> include/asm-powerpc/pci-bridge.h | 1 4 files changed, 177
> insertions(+), 207 deletions(-)
>
> Index: linux-work/arch/powerpc/kernel/pci-common.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/pci-common.c
> 2007-11-13 14:15:43.000000000 +1100 +++
> linux-work/arch/powerpc/kernel/pci-common.c 2007-11-13
> 16:04:06.000000000 +1100 @@ -479,3 +479,179 @@ void
> pci_resource_to_user(const struct p *start = rsrc->start - offset;
> *end = rsrc->end - offset; }
> +
> +/**
> + * pci_process_bridge_OF_ranges - Parse PCI bridge resources from
> device tree
> + * @hose: newly allocated pci_controller to be setup
> + * @dev: device node of the host bridge
> + * @primary: set if primary bus (32 bits only, soon to be deprecated)
> + *
> + * This function will parse the "ranges" property of a PCI host
> bridge device
> + * node and setup the resource mapping of a pci controller based on
> its
> + * content.
> + *
> + * Life would be boring if it wasn't for a few issues that we have
> to deal
> + * with here:
> + *
> + * - We can only cope with one IO space range and up to 3 Memory
> space
> + * ranges. However, some machines (thanks Apple !) tend to split
> their
> + * space into lots of small contiguous ranges. So we have to
> coalesce.
> + *
> + * - We can only cope with all memory ranges having the same offset
> + * between CPU addresses and PCI addresses. Unfortunately, some
> bridges
> + * are setup for a large 1:1 mapping along with a small "window"
> which
> + * maps PCI address 0 to some arbitrary high address of the CPU
> space in
> + * order to give access to the ISA memory hole.
> + * The way out of here that I've chosen for now is to always set
> the
> + * offset based on the first resource found, then override it if
> we
> + * have a different offset and the previous was set by an ISA
> hole.
> + *
> + * - Some busses have IO space not starting at 0, which causes
> trouble with
> + * the way we do our IO resource renumbering. The code somewhat
> deals with
> + * it for 64 bits but I would expect problems on 32 bits.
> + *
> + * - Some 32 bits platforms such as 4xx can have physical space
> larger than
> + * 32 bits so we need to use 64 bits values for the parsing
> + */
> +void __devinit pci_process_bridge_OF_ranges(struct pci_controller
> *hose,
> + struct device_node *dev,
> + int primary)
> +{
> + const u32 *ranges;
> + int rlen;
> + int pna = of_n_addr_cells(dev);
> + int np = pna + 5;
> + int memno = 0, isa_hole = -1;
> + u32 pci_space;
> + unsigned long long pci_addr, cpu_addr, pci_next, cpu_next,
> size;
> + unsigned long long isa_mb = 0;
> + struct resource *res;
> +
> + printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
> + dev->full_name, primary ? "(primary)" : "");
> +
> + /* Get ranges property */
> + ranges = of_get_property(dev, "ranges", &rlen);
> + if (ranges == NULL)
> + return;
> +
> + /* Parse it */
> + while ((rlen -= np * 4) >= 0) {
> + /* Read next ranges element */
> + pci_space = ranges[0];
> + pci_addr = of_read_number(ranges + 1, 2);
> + cpu_addr = of_translate_address(dev, ranges + 3);
> + size = of_read_number(ranges + pna + 3, 2);
> + ranges += np;
> + if (cpu_addr == OF_BAD_ADDR || size == 0)
> + continue;
> +
> + /* Now consume following elements while they are
> contiguous */
> + for (;rlen >= np * sizeof(u32); ranges += np, rlen
> -= np * 4) {
> + if (ranges[0] != pci_space)
> + break;
> + pci_next = of_read_number(ranges + 1, 2);
> + cpu_next = of_translate_address(dev, ranges
> + 3);
> + if (pci_next != pci_addr + size ||
> + cpu_next != cpu_addr + size)
> + break;
> + size += of_read_number(ranges + pna + 3, 2);
> + }
> +
> + /* Act based on address space type */
> + res = NULL;
> + switch ((pci_space >> 24) & 0x3) {
> + case 1: /* PCI IO space */
> + printk(KERN_INFO
> + " IO 0x%016llx..0x%016llx ->
> 0x%016llx\n",
> + cpu_addr, cpu_addr + size - 1,
> pci_addr); +
> + /* We support only one IO range */
> + if (hose->pci_io_size) {
> + printk(KERN_WARNING
> + " \\--> Skipped (too
> many) !\n");
> + continue;
> + }
> +#ifdef CONFIG_PPC32
> + /* On 32 bits, limit I/O space to 16MB */
> + if (size > 0x01000000)
> + size = 0x01000000;
> +
> + /* 32 bits needs to map IOs here */
> + hose->io_base_virt = ioremap(cpu_addr, size);
> +
> + /* Expect trouble if pci_addr is not 0 */
> + if (primary)
> + isa_io_base =
> + (unsigned
> long)hose->io_base_virt; +#endif /* CONFIG_PPC32 */
> + /* pci_io_size and io_base_phys always
> represent IO
> + * space starting at 0 so we factor in
> pci_addr
> + */
> + hose->pci_io_size = pci_addr + size;
> + hose->io_base_phys = cpu_addr - pci_addr;
> +
> + /* Build resource */
> + res = &hose->io_resource;
> + res->flags = IORESOURCE_IO;
> + res->start = pci_addr;
> + break;
> + case 2: /* PCI Memory space */
> + printk(KERN_INFO
> + " MEM 0x%016llx..0x%016llx ->
> 0x%016llx %s\n",
> + cpu_addr, cpu_addr + size - 1,
> pci_addr,
> + (pci_space & 0x40000000) ?
> "Prefetch" : ""); +
> + /* We support only 3 memory ranges */
> + if (memno >= 3) {
> + printk(KERN_WARNING
> + " \\--> Skipped (too
> many) !\n");
> + continue;
> + }
> + /* Handles ISA memory hole space here */
> + if (pci_addr == 0) {
> + isa_mb = cpu_addr;
> + isa_hole = memno;
> + if (primary || isa_mem_base == 0)
> + isa_mem_base = cpu_addr;
> + }
> +
> + /* We get the PCI/Mem offset from the first
> range or the,
> + * current one if the offset came from an
> ISA hole.
> + * If they don't match, bugger.
> + */
> + if (memno == 0 ||
> + (isa_hole >= 0 && pci_addr != 0 &&
> + hose->pci_mem_offset == isa_mb))
> + hose->pci_mem_offset = cpu_addr -
> pci_addr;
> + else if (pci_addr != 0 &&
> + hose->pci_mem_offset != cpu_addr -
> pci_addr) {
> + printk(KERN_WARNING
> + " \\--> Skipped (offset
> mismatch) !\n");
> + continue;
> + }
> +
> + /* Build resource */
> + res = &hose->mem_resources[memno++];
> + res->flags = IORESOURCE_MEM;
> + if (pci_space & 0x40000000)
> + res->flags |= IORESOURCE_PREFETCH;
> + res->start = cpu_addr;
> + break;
> + }
> + if (res != NULL) {
> + res->name = dev->full_name;
> + res->end = res->start + size - 1;
> + res->parent = NULL;
> + res->sibling = NULL;
> + res->child = NULL;
> + }
> + }
> +
> + /* Out of paranoia, let's put the ISA hole last if any */
> + if (isa_hole >= 0 && memno > 0 && isa_hole != (memno-1)) {
> + struct resource tmp = hose->mem_resources[isa_hole];
> + hose->mem_resources[isa_hole] =
> hose->mem_resources[memno-1];
> + hose->mem_resources[memno-1] = tmp;
> + }
> +}
> Index: linux-work/arch/powerpc/kernel/pci_32.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/pci_32.c 2007-11-13
> 14:16:17.000000000 +1100 +++
> linux-work/arch/powerpc/kernel/pci_32.c 2007-11-13
> 14:16:24.000000000 +1100 @@ -842,120 +842,6 @@
> pci_device_from_OF_node(struct device_no }
> EXPORT_SYMBOL(pci_device_from_OF_node);
> -void __init
> -pci_process_bridge_OF_ranges(struct pci_controller *hose,
> - struct device_node *dev, int primary)
> -{
> - static unsigned int static_lc_ranges[256] __initdata;
> - const unsigned int *dt_ranges;
> - unsigned int *lc_ranges, *ranges, *prev, size;
> - int rlen = 0, orig_rlen;
> - int memno = 0;
> - struct resource *res;
> - int np, na = of_n_addr_cells(dev);
> - np = na + 5;
> -
> - /* First we try to merge ranges to fix a problem with some
> pmacs
> - * that can have more than 3 ranges, fortunately using
> contiguous
> - * addresses -- BenH
> - */
> - dt_ranges = of_get_property(dev, "ranges", &rlen);
> - if (!dt_ranges)
> - return;
> - /* Sanity check, though hopefully that never happens */
> - if (rlen > sizeof(static_lc_ranges)) {
> - printk(KERN_WARNING "OF ranges property too
> large !\n");
> - rlen = sizeof(static_lc_ranges);
> - }
> - lc_ranges = static_lc_ranges;
> - memcpy(lc_ranges, dt_ranges, rlen);
> - orig_rlen = rlen;
> -
> - /* Let's work on a copy of the "ranges" property instead of
> damaging
> - * the device-tree image in memory
> - */
> - ranges = lc_ranges;
> - prev = NULL;
> - while ((rlen -= np * sizeof(unsigned int)) >= 0) {
> - if (prev) {
> - if (prev[0] == ranges[0] && prev[1] ==
> ranges[1] &&
> - (prev[2] + prev[na+4]) == ranges[2]
> &&
> - (prev[na+2] + prev[na+4]) ==
> ranges[na+2]) {
> - prev[na+4] += ranges[na+4];
> - ranges[0] = 0;
> - ranges += np;
> - continue;
> - }
> - }
> - prev = ranges;
> - ranges += np;
> - }
> -
> - /*
> - * The ranges property is laid out as an array of elements,
> - * each of which comprises:
> - * cells 0 - 2: a PCI address
> - * cells 3 or 3+4: a CPU physical address
> - * (size depending on
> dev->n_addr_cells)
> - * cells 4+5 or 5+6: the size of the range
> - */
> - ranges = lc_ranges;
> - rlen = orig_rlen;
> - while (ranges && (rlen -= np * sizeof(unsigned int)) >= 0) {
> - res = NULL;
> - size = ranges[na+4];
> - switch ((ranges[0] >> 24) & 0x3) {
> - case 1: /* I/O space */
> - if (ranges[2] != 0)
> - break;
> - hose->io_base_phys = ranges[na+2];
> - /* limit I/O space to 16MB */
> - if (size > 0x01000000)
> - size = 0x01000000;
> - hose->io_base_virt = ioremap(ranges[na+2],
> size);
> - if (primary)
> - isa_io_base = (unsigned long)
> hose->io_base_virt;
> - res = &hose->io_resource;
> - res->flags = IORESOURCE_IO;
> - res->start = ranges[2];
> - DBG("PCI: IO 0x%llx -> 0x%llx\n",
> - (u64)res->start, (u64)res->start + size
> - 1);
> - break;
> - case 2: /* memory space */
> - memno = 0;
> - if (ranges[1] == 0 && ranges[2] == 0
> - && ranges[na+4] <= (16 << 20)) {
> - /* 1st 16MB, i.e. ISA memory area */
> - if (primary)
> - isa_mem_base = ranges[na+2];
> - memno = 1;
> - }
> - while (memno < 3 &&
> hose->mem_resources[memno].flags)
> - ++memno;
> - if (memno == 0)
> - hose->pci_mem_offset = ranges[na+2]
> - ranges[2];
> - if (memno < 3) {
> - res = &hose->mem_resources[memno];
> - res->flags = IORESOURCE_MEM;
> - if(ranges[0] & 0x40000000)
> - res->flags |=
> IORESOURCE_PREFETCH;
> - res->start = ranges[na+2];
> - DBG("PCI: MEM[%d] 0x%llx ->
> 0x%llx\n", memno,
> - (u64)res->start, (u64)res->start
> + size - 1);
> - }
> - break;
> - }
> - if (res != NULL) {
> - res->name = dev->full_name;
> - res->end = res->start + size - 1;
> - res->parent = NULL;
> - res->sibling = NULL;
> - res->child = NULL;
> - }
> - ranges += np;
> - }
> -}
> -
> /* We create the "pci-OF-bus-map" property now so it appears in the
> * /proc device tree
> */
> Index: linux-work/arch/powerpc/kernel/pci_64.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/pci_64.c 2007-11-13
> 14:15:43.000000000 +1100 +++
> linux-work/arch/powerpc/kernel/pci_64.c 2007-11-13
> 14:16:24.000000000 +1100 @@ -592,99 +592,6 @@ int
> pci_proc_domain(struct pci_bus *bus) } }
>
> -void __devinit pci_process_bridge_OF_ranges(struct pci_controller
> *hose,
> - struct device_node *dev,
> int prim) -{
> - const unsigned int *ranges;
> - unsigned int pci_space;
> - unsigned long size;
> - int rlen = 0;
> - int memno = 0;
> - struct resource *res;
> - int np, na = of_n_addr_cells(dev);
> - unsigned long pci_addr, cpu_phys_addr;
> -
> - np = na + 5;
> -
> - /* From "PCI Binding to 1275"
> - * The ranges property is laid out as an array of elements,
> - * each of which comprises:
> - * cells 0 - 2: a PCI address
> - * cells 3 or 3+4: a CPU physical address
> - * (size depending on
> dev->n_addr_cells)
> - * cells 4+5 or 5+6: the size of the range
> - */
> - ranges = of_get_property(dev, "ranges", &rlen);
> - if (ranges == NULL)
> - return;
> - hose->io_base_phys = 0;
> - while ((rlen -= np * sizeof(unsigned int)) >= 0) {
> - res = NULL;
> - pci_space = ranges[0];
> - pci_addr = ((unsigned long)ranges[1] << 32) |
> ranges[2];
> - cpu_phys_addr = of_translate_address(dev,
> &ranges[3]);
> - size = ((unsigned long)ranges[na+3] << 32) |
> ranges[na+4];
> - ranges += np;
> - if (size == 0)
> - continue;
> -
> - /* Now consume following elements while they are
> contiguous */
> - while (rlen >= np * sizeof(unsigned int)) {
> - unsigned long addr, phys;
> -
> - if (ranges[0] != pci_space)
> - break;
> - addr = ((unsigned long)ranges[1] << 32) |
> ranges[2];
> - phys = ranges[3];
> - if (na >= 2)
> - phys = (phys << 32) | ranges[4];
> - if (addr != pci_addr + size ||
> - phys != cpu_phys_addr + size)
> - break;
> -
> - size += ((unsigned long)ranges[na+3] << 32)
> - | ranges[na+4];
> - ranges += np;
> - rlen -= np * sizeof(unsigned int);
> - }
> -
> - switch ((pci_space >> 24) & 0x3) {
> - case 1: /* I/O space */
> - hose->io_base_phys = cpu_phys_addr -
> pci_addr;
> - /* handle from 0 to top of I/O window */
> - hose->pci_io_size = pci_addr + size;
> -
> - res = &hose->io_resource;
> - res->flags = IORESOURCE_IO;
> - res->start = pci_addr;
> - DBG("phb%d: IO 0x%lx -> 0x%lx\n",
> hose->global_number,
> - res->start, res->start + size -
> 1);
> - break;
> - case 2: /* memory space */
> - memno = 0;
> - while (memno < 3 &&
> hose->mem_resources[memno].flags)
> - ++memno;
> -
> - if (memno == 0)
> - hose->pci_mem_offset = cpu_phys_addr
> - pci_addr;
> - if (memno < 3) {
> - res = &hose->mem_resources[memno];
> - res->flags = IORESOURCE_MEM;
> - res->start = cpu_phys_addr;
> - DBG("phb%d: MEM 0x%lx -> 0x%lx\n",
> hose->global_number,
> - res->start, res->start +
> size - 1);
> - }
> - break;
> - }
> - if (res != NULL) {
> - res->name = dev->full_name;
> - res->end = res->start + size - 1;
> - res->parent = NULL;
> - res->sibling = NULL;
> - res->child = NULL;
> - }
> - }
> -}
>
> #ifdef CONFIG_HOTPLUG
>
> Index: linux-work/include/asm-powerpc/pci-bridge.h
> ===================================================================
> --- linux-work.orig/include/asm-powerpc/pci-bridge.h
> 2007-11-13 14:15:43.000000000 +1100 +++
> linux-work/include/asm-powerpc/pci-bridge.h 2007-11-13
> 14:16:24.000000000 +1100 @@ -27,6 +27,7 @@ struct pci_controller {
> void __iomem *io_base_virt;
> resource_size_t io_base_phys;
> + resource_size_t pci_io_size;
>
> /* Some machines (PReP) have a non 1:1 mapping of
> * the PCI memory space in the CPU bus space
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC/PATCH 4/14] powerpc: Fix powerpc 32 bits resource fixup for 64 bits resources
From: Vitaly Bordug @ 2007-11-22 18:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071121061713.56A0CDEAE0@ozlabs.org>
On Wed, 21 Nov 2007 17:16:21 +1100
Benjamin Herrenschmidt wrote:
> The 32bits powerpc resource fixup code uses unsigned longs to do the
> offseting of resources which overflows on platforms such as 4xx where
> resources can be 64 bits.
>
> This fixes it by using resource_size_t instead.
>
> However, the IO stuff does rely on some 32 bits arithmetic, so we hack
> by cropping the result of the fixups for IO resources with a 32 bits
> mask.
>
> This isn't the prettiest but should work for now until we change the
> 32 bits PCI code to do IO mappings like 64 bits does, within a
> reserved are of the kernel address space.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
>
Verified on Freescale 83xx and should work for other 32bit stuff.
> This needs some regression testing.
>
> arch/powerpc/kernel/pci_32.c | 44
> +++++++++++++++++++++++-------------------- 1 file changed, 24
> insertions(+), 20 deletions(-)
>
> Index: linux-work/arch/powerpc/kernel/pci_32.c
> ===================================================================
> --- linux-work.orig/arch/powerpc/kernel/pci_32.c 2007-11-16
> 15:48:27.000000000 +1100 +++
> linux-work/arch/powerpc/kernel/pci_32.c 2007-11-16
> 15:55:54.000000000 +1100 @@ -104,7 +104,7 @@
> pcibios_fixup_resources(struct pci_dev * { struct pci_controller*
> hose = (struct pci_controller *)dev->sysdata; int i;
> - unsigned long offset;
> + resource_size_t offset, mask;
>
> if (!hose) {
> printk(KERN_ERR "No hose for PCI dev %s!\n",
> pci_name(dev)); @@ -123,15 +123,17 @@ pcibios_fixup_resources(struct
> pci_dev * continue;
> }
> offset = 0;
> + mask = (resource_size_t)-1;
> if (res->flags & IORESOURCE_MEM) {
> offset = hose->pci_mem_offset;
> } else if (res->flags & IORESOURCE_IO) {
> offset = (unsigned long) hose->io_base_virt
> - isa_io_base;
> + mask = 0xffffffffu;
> }
> if (offset != 0) {
> - res->start += offset;
> - res->end += offset;
> + res->start = (res->start + offset) & mask;
> + res->end = (res->end + offset) & mask;
> DBG("Fixup res %d (%lx) of dev %s: %llx ->
> %llx\n", i, res->flags, pci_name(dev),
> (u64)res->start - offset,
> (u64)res->start); @@ -147,30 +149,32 @@
> DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PC void
> pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region
> *region, struct resource *res) {
> - unsigned long offset = 0;
> + resource_size_t offset = 0, mask = (resource_size_t)-1;
> struct pci_controller *hose = dev->sysdata;
>
> - if (hose && res->flags & IORESOURCE_IO)
> + if (hose && res->flags & IORESOURCE_IO) {
> offset = (unsigned long)hose->io_base_virt -
> isa_io_base;
> - else if (hose && res->flags & IORESOURCE_MEM)
> + mask = 0xffffffffu;
> + } else if (hose && res->flags & IORESOURCE_MEM)
> offset = hose->pci_mem_offset;
> - region->start = res->start - offset;
> - region->end = res->end - offset;
> + region->start = (res->start - offset) & mask;
> + region->end = (res->end - offset) & mask;
> }
> EXPORT_SYMBOL(pcibios_resource_to_bus);
>
> void pcibios_bus_to_resource(struct pci_dev *dev, struct resource
> *res, struct pci_bus_region *region)
> {
> - unsigned long offset = 0;
> + resource_size_t offset = 0, mask = (resource_size_t)-1;
> struct pci_controller *hose = dev->sysdata;
>
> - if (hose && res->flags & IORESOURCE_IO)
> + if (hose && res->flags & IORESOURCE_IO) {
> offset = (unsigned long)hose->io_base_virt -
> isa_io_base;
> - else if (hose && res->flags & IORESOURCE_MEM)
> + mask = 0xffffffffu;
> + } else if (hose && res->flags & IORESOURCE_MEM)
> offset = hose->pci_mem_offset;
> - res->start = region->start + offset;
> - res->end = region->end + offset;
> + res->start = (region->start + offset) & mask;
> + res->end = (region->end + offset) & mask;
> }
> EXPORT_SYMBOL(pcibios_bus_to_resource);
>
> @@ -334,9 +338,9 @@ static int __init
> pci_relocate_bridge_resource(struct pci_bus *bus, int i)
> {
> struct resource *res, *pr, *conflict;
> - unsigned long try, size;
> - int j;
> + resource_size_t try, size;
> struct pci_bus *parent = bus->parent;
> + int j;
>
> if (parent == NULL) {
> /* shouldn't ever happen */
> @@ -438,7 +442,7 @@ update_bridge_resource(struct pci_dev *d
> u8 io_base_lo, io_limit_lo;
> u16 mem_base, mem_limit;
> u16 cmd;
> - unsigned long start, end, off;
> + resource_size_t start, end, off;
> struct pci_controller *hose = dev->sysdata;
>
> if (!hose) {
> @@ -1157,8 +1161,8 @@ void pcibios_fixup_bus(struct pci_bus *b
> res->end = IO_SPACE_LIMIT;
> res->flags = IORESOURCE_IO;
> }
> - res->start += io_offset;
> - res->end += io_offset;
> + res->start = (res->start + io_offset) & 0xffffffffu;
> + res->end = (res->end + io_offset) & 0xffffffffu;
>
> for (i = 0; i < 3; ++i) {
> res = &hose->mem_resources[i];
> @@ -1183,8 +1187,8 @@ void pcibios_fixup_bus(struct pci_bus *b
> if (!res->flags || bus->self->transparent)
> continue;
> if (io_offset && (res->flags &
> IORESOURCE_IO)) {
> - res->start += io_offset;
> - res->end += io_offset;
> + res->start = (res->start +
> io_offset) & 0xffffffffu;
> + res->end = (res->end + io_offset) &
> 0xffffffffu; } else if (hose->pci_mem_offset
> && (res->flags & IORESOURCE_MEM))
> { res->start += hose->pci_mem_offset;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Sincerely, Vitaly
^ permalink raw reply
* [PATCH] PPC: CHRP - fix possible NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-22 19:54 UTC (permalink / raw)
To: PPCML; +Cc: Olof Johansson, Paul Mackerras, LKML
From: Cyrill Gorcunov <gorcunov@gmail.com>
This patch does fix possible NULL pointer dereference
inside of strncmp() if of_get_property() failed.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
arch/powerpc/platforms/chrp/setup.c | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
index 5930626..e3f276d 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -115,7 +115,7 @@ void chrp_show_cpuinfo(struct seq_file *m)
seq_printf(m, "machine\t\t: CHRP %s\n", model);
/* longtrail (goldengate) stuff */
- if (!strncmp(model, "IBM,LongTrail", 13)) {
+ if (model && !strncmp(model, "IBM,LongTrail", 13)) {
/* VLSI VAS96011/12 `Golden Gate 2' */
/* Memory banks */
sdramen = (in_le32(gg2_pci_config_base + GG2_PCI_DRAM_CTRL)
@@ -203,16 +203,19 @@ static void __init sio_fixup_irq(const char *name, u8 device, u8 level,
static void __init sio_init(void)
{
struct device_node *root;
+ const char *model = NULL;
- if ((root = of_find_node_by_path("/")) &&
- !strncmp(of_get_property(root, "model", NULL),
- "IBM,LongTrail", 13)) {
- /* logical device 0 (KBC/Keyboard) */
- sio_fixup_irq("keyboard", 0, 1, 2);
- /* select logical device 1 (KBC/Mouse) */
- sio_fixup_irq("mouse", 1, 12, 2);
- }
- of_node_put(root);
+ root = of_find_node_by_path("/");
+ if (root) {
+ model = of_get_property(root, "model", NULL);
+ if (model && !strncmp(model,"IBM,LongTrail", 13)) {
+ /* logical device 0 (KBC/Keyboard) */
+ sio_fixup_irq("keyboard", 0, 1, 2);
+ /* select logical device 1 (KBC/Mouse) */
+ sio_fixup_irq("mouse", 1, 12, 2);
+ }
+ of_node_put(root);
+ }
}
^ permalink raw reply related
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Grant Likely @ 2007-11-22 18:36 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev
In-Reply-To: <4745BB5F.6060002@scram.de>
On 11/22/07, Jochen Friedrich <jochen@scram.de> wrote:
> This patch moves the CPM command handling into commproc.c
> for CPM1 and cpm2_common.c. This is yet another preparation
> to get rid of drivers accessing the CPM via the global cpmp.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> arch/powerpc/sysdev/commproc.c | 20 ++++++++++++++++++++
> arch/powerpc/sysdev/cpm2_common.c | 17 +++++++++++++++++
> drivers/net/fs_enet/mac-fcc.c | 10 +---------
> drivers/net/fs_enet/mac-scc.c | 11 +----------
> drivers/serial/cpm_uart/cpm_uart_cpm1.c | 6 +-----
> drivers/serial/cpm_uart/cpm_uart_cpm2.c | 8 +-------
> include/asm-powerpc/cpm.h | 1 +
> 7 files changed, 42 insertions(+), 31 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
> index f6a6378..2bddbde 100644
> --- a/arch/powerpc/sysdev/commproc.c
> +++ b/arch/powerpc/sysdev/commproc.c
> @@ -240,6 +240,26 @@ void __init cpm_reset(void)
> #endif
> }
>
> +#define MAX_CR_CMD_LOOPS 10000
> +
> +int cpm_command(u32 command, u8 opcode)
> +{
> + int i;
> +
> + if (command & 0xffffff0f)
> + return -EINVAL;
> +
> + out_be16(&cpmp->cp_cpcr, command | CPM_CR_FLG | (opcode << 8));
> + for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> + if ((in_be16(&cpmp->cp_cpcr) & CPM_CR_FLG) == 0)
> + return 0;
> +
> + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
> + __FUNCTION__);
> + return -EIO;
Do these need to be protected with a spin lock?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH revised 3/4] powerpc: Add EXPORT_SYMBOL_GPL for symbols required by fs_enet and cpm_uart
From: Jochen Friedrich @ 2007-11-22 17:35 UTC (permalink / raw)
To: linuxppc-dev
fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
cpm2_common.c. Add EXPORT_SYMBOL_GPL for cpmp, cpm_setbrg and cpm2_immr,
so the drivers can be compiled as modules.
Building modules, stage 2.
MODPOST 5 modules
ERROR: "cpm2_immr" [drivers/net/fs_enet/fs_enet.ko] undefined!
ERROR: "cpmp" [drivers/net/fs_enet/fs_enet.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/commproc.c | 3 +++
arch/powerpc/sysdev/cpm2_common.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index f6a6378..ddbe138 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -51,6 +51,8 @@ static void m8xx_cpm_dpinit(void);
static uint host_buffer; /* One page of host buffer */
static uint host_end; /* end + 1 */
cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */
+EXPORT_SYMBOL_GPL(cpmp);
+
immap_t __iomem *mpc8xx_immr;
static cpic8xx_t __iomem *cpic_reg;
@@ -302,6 +304,7 @@ cpm_setbrg(uint brg, uint rate)
out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
CPM_BRG_EN | CPM_BRG_DIV16);
}
+EXPORT_SYMBOL_GPL(cpm_setbrg);
#ifndef CONFIG_PPC_CPM_NEW_BINDING
/*
diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c
index 859362f..b878a67 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -51,11 +51,13 @@ static void cpm2_dpinit(void);
#endif
cpm_cpm2_t __iomem *cpmp; /* Pointer to comm processor space */
+EXPORT_SYMBOL_GPL(cpmp);
/* We allocate this here because it is used almost exclusively for
* the communication processor devices.
*/
cpm2_map_t __iomem *cpm2_immr;
+EXPORT_SYMBOL_GPL(cpm2_immr);
#define CPM_MAP_SIZE (0x40000) /* 256k - the PQ3 reserve this amount
of space for CPM as it is larger
@@ -117,6 +119,7 @@ cpm_setbrg(uint brg, uint rate)
cpm2_unmap(bp);
}
+EXPORT_SYMBOL_GPL(cpm_setbrg);
/* This function is used to set high speed synchronous baud rate
* clocks.
--
1.5.3.4
^ permalink raw reply related
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