* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Benjamin Herrenschmidt @ 2008-08-19 1:54 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Paul E. McKenney, linux-kernel, rostedt, linuxppc-dev,
Steven Rostedt, Eran Liberty
In-Reply-To: <20080818184158.GA1798@Krystal>
> > Oops: Exception in kernel mode, sig: 11 [#1]
> > Exsw1600
> > Modules linked in:
> > NIP: c00bbb20 LR: c00bbb20 CTR: 00000000
> > REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2)
> > MSR: 00029000 <EE,ME> CR: 24082282 XER: 20000000
> > TASK = ddcce060[1707] 'find' THREAD: dd5b0000
> > GPR00: 00000000 dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b
> > 100234ec
> > GPR08: c0800000 00019330 0000ffff dd5b1d20 24000288 100ad874 100936f8
> > 1008a1d0
> > GPR16: 10083f80 dd5b1e2c dd5b1d68 fffffff4 c0380000 dd5b1d60 dd5b1d58
> > dd802084
> > GPR24: dc3d7700 dd802018 dd5b1d68 c0380000 dd801180 dd5b1d68 00000000
> > dd5b1d00
> > NIP [c00bbb20] d_lookup+0x40/0x90
> > LR [c00bbb20] d_lookup+0x40/0x90
> > Call Trace:
> > [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable)
>
> Can you check if, at some point during the system execution (starting
> from boot), 0xdd5b1d58 is an address where a module is loaded ? (the
> module can be later unloaded, what I wonder is if this address would
> appear to have had a loaded+unloaded module).
>
> Actually, could you try to compile your kernel without "MODULE_UNLOAD" ?
I've had similar crashes (with similar backtraces in the VFS) on
machines with no modules, netbooted zImages.
Ben.
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Benjamin Herrenschmidt @ 2008-08-19 1:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: Paul E. McKenney, Mathieu Desnoyers, linux-kernel, rostedt,
linuxppc-dev, Eran Liberty
In-Reply-To: <48A9901B.1080900@redhat.com>
On Mon, 2008-08-18 at 11:07 -0400, Steven Rostedt wrote:
> Eran Liberty wrote:
> > After compiling a kernel with ftrace I started to experience all sorts
> > of crashes.
>
> Just to make sure...
>
> ftrace enables markers too, and RCU has tracing with the markers. This
> may not be the problem, but I just want to eliminate as many variables
> as possible.
> Could you disable ftrace, but keep the markers on too. Also, could you
> enable ftrace again and turn on the FTRACE_STARTUP_TEST.
I spent some time last week tracking one of those crashes and it appears
that we are getting corruption of some of the non-volatile registers.
So far, I found out that it -seems- to be coming from stack frame
corruption during a timer interrupt.
I haven't had a chance to dig further yet.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] hotplug/rpaphp: remove unused error path code
From: Stephen Rothwell @ 2008-08-19 1:45 UTC (permalink / raw)
To: Paul Mackerras
Cc: Alex Chiang, LKML, Jesse Barnes, linuxppc-dev, Linda Xie,
Andrew Morton
Commit f46753c5e354b857b20ab8e0fe7b2579831dc369 ("PCI: introduce pci_slot") removed the need for this error path. Eliminate this warning:
drivers/pci/hotplug/rpaphp_slot.c: In function 'rpaphp_register_slot':
drivers/pci/hotplug/rpaphp_slot.c:151: warning: label 'sysfs_fail' defined but not used
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/pci/hotplug/rpaphp_slot.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/hotplug/rpaphp_slot.c b/drivers/pci/hotplug/rpaphp_slot.c
index 9b714ea..5088450 100644
--- a/drivers/pci/hotplug/rpaphp_slot.c
+++ b/drivers/pci/hotplug/rpaphp_slot.c
@@ -147,9 +147,5 @@ int rpaphp_register_slot(struct slot *slot)
list_add(&slot->rpaphp_slot_list, &rpaphp_slot_head);
info("Slot [%s] registered\n", slot->name);
return 0;
-
-sysfs_fail:
- pci_hp_deregister(php_slot);
- return retval;
}
--
1.5.6.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
From: Paul Mackerras @ 2008-08-19 1:43 UTC (permalink / raw)
To: Mohan Kumar M; +Cc: linuxppc-dev
In-Reply-To: <48A9AF1D.5050700@in.ibm.com>
Mohan Kumar M writes:
> If you need, I can give the .config I use.
Yes please, send it over.
^ permalink raw reply
* Re: Corrections please ...
From: Michael Ellerman @ 2008-08-19 1:02 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev
In-Reply-To: <48A9E2C6.1030205@hypersurf.com>
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
On Mon, 2008-08-18 at 13:59 -0700, Kevin Diggs wrote:
> Could I get any needed corrections on this. Especially on the "???"
You're missing CC: lkml.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Finding cpuid in entry_64.S
From: Mitesh R. Meswani @ 2008-08-18 23:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
Hello
I am trying to find the cpuid when the functions that handle return from context switch and interrupts are called, based on the cpu the return code is executing on, I want to take some specific actions.
I have been trying to use the following code segments :
LOAD_REG_IMMEDIATE(r13, paca) /* Get base vaddr of paca array */
lhz r6,PACAHWCPUID(r13) /* Load HW procid from paca */
cmpwi 0,r6,7 /* Compare to our id */
My kernel is 2.6.16.21
and I am inserting the above code segments in the file entry_64.S in the following functions:
_switch
return from system calls, and
_ret_from_except
I can give line #s and the modified file itself.
The problem is my kernel does not boot and halts at the point where it reads the command line boot parameters. Any help would be appreciated .
Thanks,
Mitesh
[-- Attachment #2: Type: text/html, Size: 2847 bytes --]
^ permalink raw reply
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Michael Neuling @ 2008-08-18 23:33 UTC (permalink / raw)
To: Mihaela Grigore; +Cc: linuxppc-dev
In-Reply-To: <78ef7ce10808181507h5174be66nfe9707a421473c5c@mail.gmail.com>
In message <78ef7ce10808181507h5174be66nfe9707a421473c5c@mail.gmail.com> you wr
ote:
> On Tue, Aug 19, 2008 at 12:25 AM, Becky Bruce <becky.bruce@freescale.com> wro
te:
> >
> > On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote:
> >
> >> In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com>
> >> you wrote:
> >>>
> >>> The mmu is still disabled at this point.
> >>>
> >>> What is marked as readonly is the text section of the vmlinux file
> >>> generated when compiling the kernel. And since the code tries to write
> >>> to the text section, I assumed it was the reason for the segmentation
> >>> fault.
> >>
> >> Seriously, a seg fault in your emulator is a bug in the emulator!
> >
> > Mikey is likely right here. I've (unfortunately) done a lot of emulator
> > work, and every time I've hit a problem like this, the problem has been wit
h
> > the emulator or the emulation environment. Have you isolated the faulting
> > instruction, verified that it's to a reasonable address, and tried examinin
g
> > memory at the faulting address using your emulator's command interface?
> >
>
> yes, it's a store instruction. the value to be stored is a nop
> instruction and the
> address is inside the text section (it is writing over existing code that
> is intended for other cpus).
>
> >>
> >>
> >>> I'm not sure how this is dealt with on real hardware.
> >>
> >> The CPU seg faults... :-P
> >
> > But only if the page is mapped non-writeable. Even with the MMU on, Linux
> > maps itself in as writeable. It's the OS, it can do whatever it wants. So
> > it just works on real hardware, and it should just work in your emulator.
> >
>
> I forgot to mention that I'm trying to run directly the vmlinux image
> in psim emulator.
> I'm not sure it's even supposed to work this way.
Looking at the psim web page quickly, it seems to be for userspace
binaries.
So yeah, I don't think it's designed to be used like you are try to use
it.
>
> >>
> >>
> >>> Can somebody please explain how is it supposed to work ? Is it ok to
> >>> write to text section that you load on real hardware as readonly ?
> >>> (again, no mmu involved, as it is still turned off, so i'm not sure
> >>> who's guarding this section against writing)
> >>
> >> I'm not sure how this works for 32 bit CPUs, so I can't speak to the
> >> details of it.
> >>
> >> For the 64bit MMU, if you're in real mode (MMU off), nothing can stop
> >> this from being written. The kernel ignores the elf sections
> >> permissions and does it's own mapping but this can only be enforced once
> >> the MMU is on.
> >
> > The same is true on 32-bit ppc - the basic MMU architecture is very similar
> > if you have a part that has "real mode" (i.e. non-booke). There is no way
> > to restrict stores in real mode.
> >
> > -Becky
> >
> >>
> >>
> >> Mikey
> >>
> >>> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org>
> >>> wrote:
> >>>>
> >>>> In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com>
> >>>> you
> >>
> >> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
> >>>>> latest versions,
> >>>>> but i assume the code is still the same and just moved to powerpc.
> >>>>>
> >>>>> There is a piece of code in the early initialization of the 2.6 kernel
> >>>>> that identifies the cpu type and then tries to eliminate code that
> >>>>> does not apply to the current cpu. This is done by writing nop's over
> >>>>> sections of code that are not needed (do_cpu_ftr_fixups in
> >>>>> arch/ppc/kernel/misc.S)
> >>>>>
> >>>>> When I try to run the kernel in a ppc emulator, I get a segmentation
> >>>>> fault in do_cpu_ftr_fixups. From examining the section headers of the
> >>>>> vmlinux, the text section is marked as readonly. The piece of code
> >>>>> above mentioned is trying to write a nop to memory location inside the
> >>>>> text section which is readonly, so that explains the sigsegv error.
> >>>>
> >>>> Any segv in the emulator sounds like a bug in the emulator.
> >>>>
> >>>> If the page really is marked read only, then writing to it should cause
> >>>> a page fault.
> >>>>
> >>>>> Since the kernel does run on boards with ppc cpu's, can somebody
> >>>>> explain how come this is actually working ? Or if/where I am mistaking
> >>>>> with my assumptions ?
> >>>>>
> >>>>> Thank you
> >>>>>
> >>>>> P.S. please add me in cc in a reply to this message
> >>>>> _______________________________________________
> >>>>> Linuxppc-dev mailing list
> >>>>> Linuxppc-dev@ozlabs.org
> >>>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >>>>>
> >>>>
> >>>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* MV Linux uImage not working with u-boot, but zImage does
From: john h @ 2008-08-18 22:25 UTC (permalink / raw)
To: linuxppc-embedded, u-boot
I wasn't sure if this is a Linux issue or a u-boot issue.
We are using an older version of arch/ppc MontaVista Linux and having
a problem with u-boot. We can build a zImage and convert it to a
uImage and it runs from u-boot fine.
If we build a uImage from MV, the kernel crashes as shown below. We
are using u-boot version U-Boot 1.3.0-rc3.
Yet we can boot an arch/ppc Linux kernel (uImage) that's based on
2.6.26. Is there something we're not realizing that is different in
the u-boot interface?
Thanks,
John
version 2.6.10_mvl401-ml40x () (gcc version 3.4.3 (MontaVista 3.4.3
25.0.70.0501961
<4>mem_pieces_remove: [0,0) not in any region
<2>kernel BUG in free_bootmem_core at mm/bootmem.c:115!
<4>NIP: C02B4D04 LR: C02B2350 SP: C02A3F90 REGS: c02a3ee0 TRAP: 0700
Not tainted
<6>GPR00: 00000000 C02A3F90 C026C720 C02D6EAC 00000000 00000001
C0270000 C026DC48
<6>GPR08: C0270000 00000000 00000000 00000000 48002028 0000A5A5
10000C00 00000000
<6>GPR16: 007FFF00 00000000 007FFE80 00800000 00000000 00000000
0FFFA304 00000000
<6>GPR24: 00000000 0FEDA958 00000DC0 007FFF3A 007FFF00 C02D0000
00000001 C02CEC04
<4>NIP [c02b4d04] free_bootmem_core+0x1c/0xac
<4>LR [c02b2350] do_init_bootmem+0xfc/0x140<4> Call trace:
<4> [c02b1cec] setup_arch+0xd8/0x1dc
<4> [c02a44d8] start_kernel+0x28/0x1bc
<4> [c0000240] skpinv+0x1e8/0x224
<0>Kernel panic - not syncing: Attempted to kill the idle task!
<4> <0> Rebooting in 180 seconds..
^ permalink raw reply
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Michael Neuling @ 2008-08-18 22:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Mihaela Grigore
In-Reply-To: <48A9F423.2070602@freescale.com>
In message <48A9F423.2070602@freescale.com> you wrote:
> Michael Neuling wrote:
> >> It seems like no one else is interested in the subject, so i will talk
> >> directly to you.
> >>
> >> If you say that the cpu also seg faults, it means that the problem is
> >> in the code of the linux kernel... :)
> >
> > Sorry, I was only joking. The hardware does _not_ segfault. There is
> > no equivalent to segfault in real hardware.
>
> Well, there are machine checks and checkstops... :-)
Shhhh! :-)
Mikey
^ permalink raw reply
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Scott Wood @ 2008-08-18 22:13 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Mihaela Grigore
In-Reply-To: <18942.1219097397@neuling.org>
Michael Neuling wrote:
>> It seems like no one else is interested in the subject, so i will talk
>> directly to you.
>>
>> If you say that the cpu also seg faults, it means that the problem is
>> in the code of the linux kernel... :)
>
> Sorry, I was only joking. The hardware does _not_ segfault. There is
> no equivalent to segfault in real hardware.
Well, there are machine checks and checkstops... :-)
-Scott
^ permalink raw reply
* [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errrata
From: Vitaly Bordug @ 2008-08-18 22:10 UTC (permalink / raw)
Cc: Stefan Roese, linuxppc-dev@ozlabs.org, Mark Miesfeld,
linux-usb-devel@lists.sourceforge.net
A published errata for ppc440epx states, that when running Linux with both
EHCI and OHCI modules loaded, the EHCI module experiences a fatal error
when a high-speed device is connected to the USB2.0, and functions normally
if OHCI module is not loaded.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In USB
2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers is
connected at any one time. In the 440EPx, there is only one OHCI companion controller,
and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion controller. If
you load only an ohci driver, it will have control of the ports and any
deviceplugged in will operate, although high speed devices will be forced to
operate at full speed. When an ehci driver is loaded, it explicitly takes control
of the ports. If there is a device connected, and / or every time there is a
new device connected, the ehci driver determines if the device is high speed or
not. If it is high speed, the driver retains control of the port. If it
is not, the driver explicitly gives the companion controller control of the
port.
There is a software workaround that uses a trick to detect if full-speed interface
is enabled from the hi-speed driver(and vice versa), and use suspend control for ohci
to enable/disable it appropriately.
Initial version of the software workaround was posted to linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later were made available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to get
rid of (some) hardcoded defines.
Cc: Mark Miesfeld <mmiesfeld@amcc.com>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/usb/host/Kconfig | 16 +++++++++
drivers/usb/host/ehci-hub.c | 15 ++++++++
drivers/usb/host/ehci-ppc-of.c | 72 ++++++++++++++++++++++++++++++++++++++++
drivers/usb/host/ohci-ppc-of.c | 30 +++++++++++++++++
4 files changed, 132 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c74de1a..de9a415 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -71,6 +71,22 @@ config USB_EHCI_TT_NEWSCHED
If unsure, say N.
+config USB_PPC440EPX_USBH_23_ERRATA
+ bool "PPC440EPX USBH_23 ERRATA EHCI and OHCI contention"
+ depends on USB_EHCI_HCD && 440EPX
+ default y
+ ---help---
+ Allows the EHCI and OHCI drivers to be loaded together when using
+ the USB Host controller on the 440EPX processor. This is necessary
+ when both high speed or full speed devices may be connected to the
+ USB Host port.
+
+ The option is not needed if the USB Host port is only used with
+ USB 2.0 high speed devices and the OHCI driver is never loaded.
+
+ Say N when the OHCI driver for the 440EPX will never be loaded. If
+ unsure, say Y.
+
config USB_EHCI_BIG_ENDIAN_MMIO
bool
depends on USB_EHCI_HCD && (PPC_CELLEB || PPC_PS3 || 440EPX || ARCH_IXP4XX)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 740835b..f012f05 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -396,6 +396,10 @@ static inline void remove_companion_file(struct ehci_hcd *ehci)
/*-------------------------------------------------------------------------*/
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+static void set_ohci_hcfs(int);
+#endif
+
static int check_reset_complete (
struct ehci_hcd *ehci,
int index,
@@ -424,8 +428,17 @@ static int check_reset_complete (
port_status &= ~PORT_RWC_BITS;
ehci_writel(ehci, port_status, status_reg);
- } else
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ /* ensure 440EPX ohci controller state is operational */
+ set_ohci_hcfs(1);
+#endif
+ } else {
ehci_dbg (ehci, "port %d high speed\n", index + 1);
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ /* ensure 440EPx ohci controller state is suspended */
+ set_ohci_hcfs(0);
+#endif
+ }
return port_status;
}
diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
index b018dee..90810f6 100644
--- a/drivers/usb/host/ehci-ppc-of.c
+++ b/drivers/usb/host/ehci-ppc-of.c
@@ -17,6 +17,32 @@
#include <linux/of.h>
#include <linux/of_platform.h>
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+static u32 __iomem *ohci_hcctrl_reg;
+
+#define OHCI_CTRL_HCFS (3 << 6)
+#define OHCI_USB_OPER (2 << 6)
+#define OHCI_USB_SUSPEND (3 << 6)
+
+#define OHCI_HCCTRL_OFFSET 0x4
+#define OHCI_HCCTRL_LEN 0x4
+
+static void set_ohci_hcfs(int operational)
+{
+ u32 hc_control;
+
+ hc_control = (readl_be(ohci_hcctrl_reg) & ~OHCI_CTRL_HCFS);
+ if (operational)
+ hc_control |= OHCI_USB_OPER;
+ else
+ hc_control |= OHCI_USB_SUSPEND;
+
+ writel_be(hc_control, ohci_hcctrl_reg);
+ (void) readl_be(ohci_hcctrl_reg);
+}
+#endif
+
+
/* called during probe() after chip reset completes */
static int ehci_ppc_of_setup(struct usb_hcd *hcd)
{
@@ -111,12 +137,29 @@ ehci_hcd_ppc_of_probe(struct of_device *op, const struct of_device_id *match)
struct resource res;
int irq;
int rv;
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ struct device_node *np;
+#endif
if (usb_disabled())
return -ENODEV;
dev_dbg(&op->dev, "initializing PPC-OF USB Controller\n");
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ np = of_find_compatible_node(NULL, NULL, "ohci-be");
+ if (np != NULL) {
+ if (!of_address_to_resource(np, 0, &res))
+ ohci_hcctrl_reg = ioremap(res.start +
+ OHCI_HCCTRL_OFFSET, OHCI_HCCTRL_LEN);
+ else
+ pr_debug(__FILE__ ": no ohci offset in fdt\n");
+ }
+ if (!ohci_hcctrl_reg) {
+ pr_debug(__FILE__ ": ioremap for ohci hcctrl failed\n");
+ return -ENOMEM;
+ }
+#endif
rv = of_address_to_resource(dn, 0, &res);
if (rv)
return rv;
@@ -182,6 +225,10 @@ err_ioremap:
err_irq:
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
err_rmr:
+
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ iounmap(ohci_hcctrl_reg);
+#endif
usb_put_hcd(hcd);
return rv;
@@ -191,6 +238,11 @@ err_rmr:
static int ehci_hcd_ppc_of_remove(struct of_device *op)
{
struct usb_hcd *hcd = dev_get_drvdata(&op->dev);
+
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ struct device_node *np;
+ struct resource res;
+#endif
dev_set_drvdata(&op->dev, NULL);
dev_dbg(&op->dev, "stopping PPC-OF USB Controller\n");
@@ -201,6 +253,26 @@ static int ehci_hcd_ppc_of_remove(struct of_device *op)
irq_dispose_mapping(hcd->irq);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ /* use request_mem_region to test if the ohci driver is loaded. if so
+ * ensure the ohci core is operational.
+ */
+
+ np = of_find_compatible_node(NULL, NULL, "ohci-be");
+ if (np != NULL) {
+ if (!of_address_to_resource(np, 0, &res))
+ if (!request_mem_region(res.start, 0x4, hcd_name))
+ set_ohci_hcfs(1);
+ else
+ release_mem_region(res.start, 0x4);
+ else
+ pr_debug(__FILE__ ": no ohci offset in fdt\n");
+ of_node_put(np);
+ } else
+ pr_debug(__FILE__ ": ohci not found in device tree \n");
+
+ iounmap(ohci_hcctrl_reg);
+#endif
usb_put_hcd(hcd);
return 0;
diff --git a/drivers/usb/host/ohci-ppc-of.c b/drivers/usb/host/ohci-ppc-of.c
index a672527..59ba26c 100644
--- a/drivers/usb/host/ohci-ppc-of.c
+++ b/drivers/usb/host/ohci-ppc-of.c
@@ -92,6 +92,9 @@ ohci_hcd_ppc_of_probe(struct of_device *op, const struct of_device_id *match)
int rv;
int is_bigendian;
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ struct device_node *np;
+#endif
if (usb_disabled())
return -ENODEV;
@@ -148,6 +151,33 @@ ohci_hcd_ppc_of_probe(struct of_device *op, const struct of_device_id *match)
if (rv == 0)
return 0;
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ /* Work around - At this point ohci_run has executed, the
+ * controller is running, everything, the root ports, etc., is
+ * set up. If the ehci driver is loaded, put the ohci core in
+ * the suspended state. The ehci driver will bring it out of
+ * suspended state when / if a non-high speed USB device is
+ * attached to the USB Host port. If the ehci driver is not
+ * loaded, do nothing. request_mem_region is used to test if
+ * the ehci driver is loaded.
+ */
+ np = of_find_compatible_node(NULL, NULL, "ibm,usb-ehci-440epx");
+ if (np != NULL)
+ if (!of_address_to_resource(np, 0, &res))
+ if (!request_mem_region(res.start, 0x4, hcd_name)) {
+ writel_be((readl_be(&ohci->regs->control) |
+ OHCI_USB_SUSPEND), &ohci->regs->control);
+ (void) readl_be(&ohci->regs->control);
+ } else {
+ release_mem_region(res.start, 0x4);
+ }
+ else
+ pr_debug(__FILE__ ": cannot get ehci offset from fdt\n");
+ else
+ pr_debug(__FILE__ ": ehci not found in device tree \n");
+
+ spin_unlock_irq(&ohci->lock);
+#endif
iounmap(hcd->regs);
err_ioremap:
irq_dispose_mapping(irq);
^ permalink raw reply related
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Michael Neuling @ 2008-08-18 22:09 UTC (permalink / raw)
To: Mihaela Grigore; +Cc: linuxppc-dev
In-Reply-To: <78ef7ce10808181427m507434f4we84d507b090a707b@mail.gmail.com>
> It seems like no one else is interested in the subject, so i will talk
> directly to you.
>
> If you say that the cpu also seg faults, it means that the problem is
> in the code of the linux kernel... :)
Sorry, I was only joking. The hardware does _not_ segfault. There is
no equivalent to segfault in real hardware.
> I'm not sure you are completely familiar with this particular piece of
> code I'm talking about, so just to make sure... On powerpc, in the
> beggining, it jumps to the early initialization, where it checks cpu
> type and then does the cpu features fixup, which means that it
> overwrites with nop's code that is not intended for this particular
> cpu. This happens on every powerpc cpu (32 bits at least), so if the
> problem was here, somebody would have reported it at least. So it is
> supposed to work this way. But in my emulator at least, I can't get
> the code to write over code and not get a segmentation fault. The
> emulator (psim, the one that comes with gdb) keeps it from writing to
> sections that were loaded as readonly. You're saying it happens the
> same on real hw ?
I'm familiar with the code you are talking about... and it works
correctly on real hardware (the code is replaced with NOPs)
The section notes are just a hints to the loader. In the case of the
Linux kernel, it's ignored or can't be enforced by the PPC architecture.
Mikey
>
> On Mon, Aug 18, 2008 at 11:51 PM, Michael Neuling <mikey@neuling.org> wrote:
> > In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com> yo
u wrote:
> >> The mmu is still disabled at this point.
> >>
> >> What is marked as readonly is the text section of the vmlinux file
> >> generated when compiling the kernel. And since the code tries to write
> >> to the text section, I assumed it was the reason for the segmentation
> >> fault.
> >
> > Seriously, a seg fault in your emulator is a bug in the emulator!
> >
> >> I'm not sure how this is dealt with on real hardware.
> >
> > The CPU seg faults... :-P
> >
> >> Can somebody please explain how is it supposed to work ? Is it ok to
> >> write to text section that you load on real hardware as readonly ?
> >> (again, no mmu involved, as it is still turned off, so i'm not sure
> >> who's guarding this section against writing)
> >
> > I'm not sure how this works for 32 bit CPUs, so I can't speak to the
> > details of it.
> >
> > For the 64bit MMU, if you're in real mode (MMU off), nothing can stop
> > this from being written. The kernel ignores the elf sections
> > permissions and does it's own mapping but this can only be enforced once
> > the MMU is on.
> >
> > Mikey
> >
> >> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org> wrot
e:
> >> > In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com>
you
> > wrote:
> >> >> Hello,
> >> >>
> >> >> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
> >> >> latest versions,
> >> >> but i assume the code is still the same and just moved to powerpc.
> >> >>
> >> >> There is a piece of code in the early initialization of the 2.6 kernel
> >> >> that identifies the cpu type and then tries to eliminate code that
> >> >> does not apply to the current cpu. This is done by writing nop's over
> >> >> sections of code that are not needed (do_cpu_ftr_fixups in
> >> >> arch/ppc/kernel/misc.S)
> >> >>
> >> >> When I try to run the kernel in a ppc emulator, I get a segmentation
> >> >> fault in do_cpu_ftr_fixups. From examining the section headers of the
> >> >> vmlinux, the text section is marked as readonly. The piece of code
> >> >> above mentioned is trying to write a nop to memory location inside the
> >> >> text section which is readonly, so that explains the sigsegv error.
> >> >
> >> > Any segv in the emulator sounds like a bug in the emulator.
> >> >
> >> > If the page really is marked read only, then writing to it should cause
> >> > a page fault.
> >> >
> >> >> Since the kernel does run on boards with ppc cpu's, can somebody
> >> >> explain how come this is actually working ? Or if/where I am mistaking
> >> >> with my assumptions ?
> >> >>
> >> >> Thank you
> >> >>
> >> >> P.S. please add me in cc in a reply to this message
> >> >> _______________________________________________
> >> >> Linuxppc-dev mailing list
> >> >> Linuxppc-dev@ozlabs.org
> >> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >> >>
> >> >
> >>
> >
>
^ permalink raw reply
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Mihaela Grigore @ 2008-08-18 22:07 UTC (permalink / raw)
To: Becky Bruce, linuxppc-dev
In-Reply-To: <496E4BC8-B41E-4728-B399-80F6D0F15E28@freescale.com>
On Tue, Aug 19, 2008 at 12:25 AM, Becky Bruce <becky.bruce@freescale.com> wrote:
>
> On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote:
>
>> In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com>
>> you wrote:
>>>
>>> The mmu is still disabled at this point.
>>>
>>> What is marked as readonly is the text section of the vmlinux file
>>> generated when compiling the kernel. And since the code tries to write
>>> to the text section, I assumed it was the reason for the segmentation
>>> fault.
>>
>> Seriously, a seg fault in your emulator is a bug in the emulator!
>
> Mikey is likely right here. I've (unfortunately) done a lot of emulator
> work, and every time I've hit a problem like this, the problem has been with
> the emulator or the emulation environment. Have you isolated the faulting
> instruction, verified that it's to a reasonable address, and tried examining
> memory at the faulting address using your emulator's command interface?
>
yes, it's a store instruction. the value to be stored is a nop
instruction and the
address is inside the text section (it is writing over existing code that
is intended for other cpus).
>>
>>
>>> I'm not sure how this is dealt with on real hardware.
>>
>> The CPU seg faults... :-P
>
> But only if the page is mapped non-writeable. Even with the MMU on, Linux
> maps itself in as writeable. It's the OS, it can do whatever it wants. So
> it just works on real hardware, and it should just work in your emulator.
>
I forgot to mention that I'm trying to run directly the vmlinux image
in psim emulator.
I'm not sure it's even supposed to work this way.
>>
>>
>>> Can somebody please explain how is it supposed to work ? Is it ok to
>>> write to text section that you load on real hardware as readonly ?
>>> (again, no mmu involved, as it is still turned off, so i'm not sure
>>> who's guarding this section against writing)
>>
>> I'm not sure how this works for 32 bit CPUs, so I can't speak to the
>> details of it.
>>
>> For the 64bit MMU, if you're in real mode (MMU off), nothing can stop
>> this from being written. The kernel ignores the elf sections
>> permissions and does it's own mapping but this can only be enforced once
>> the MMU is on.
>
> The same is true on 32-bit ppc - the basic MMU architecture is very similar
> if you have a part that has "real mode" (i.e. non-booke). There is no way
> to restrict stores in real mode.
>
> -Becky
>
>>
>>
>> Mikey
>>
>>> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org>
>>> wrote:
>>>>
>>>> In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com>
>>>> you
>>
>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
>>>>> latest versions,
>>>>> but i assume the code is still the same and just moved to powerpc.
>>>>>
>>>>> There is a piece of code in the early initialization of the 2.6 kernel
>>>>> that identifies the cpu type and then tries to eliminate code that
>>>>> does not apply to the current cpu. This is done by writing nop's over
>>>>> sections of code that are not needed (do_cpu_ftr_fixups in
>>>>> arch/ppc/kernel/misc.S)
>>>>>
>>>>> When I try to run the kernel in a ppc emulator, I get a segmentation
>>>>> fault in do_cpu_ftr_fixups. From examining the section headers of the
>>>>> vmlinux, the text section is marked as readonly. The piece of code
>>>>> above mentioned is trying to write a nop to memory location inside the
>>>>> text section which is readonly, so that explains the sigsegv error.
>>>>
>>>> Any segv in the emulator sounds like a bug in the emulator.
>>>>
>>>> If the page really is marked read only, then writing to it should cause
>>>> a page fault.
>>>>
>>>>> Since the kernel does run on boards with ppc cpu's, can somebody
>>>>> explain how come this is actually working ? Or if/where I am mistaking
>>>>> with my assumptions ?
>>>>>
>>>>> Thank you
>>>>>
>>>>> P.S. please add me in cc in a reply to this message
>>>>> _______________________________________________
>>>>> Linuxppc-dev mailing list
>>>>> Linuxppc-dev@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>>>>
>>>>
>>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH] POWERPC: duplicate test of MACIO_FLAG_SCCB_ON
From: Benjamin Herrenschmidt @ 2008-08-18 21:42 UTC (permalink / raw)
To: roel kluin; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <48A9F8E9.8030303@gmail.com>
On Mon, 2008-08-18 at 18:34 -0400, roel kluin wrote:
> untested, is it correct?
Your patch is correct. The bug is quite harmless thankfully :-)
Ben.
> arch/powerpc/include/asm/pmac_feature.h:359:
> #define MACIO_FLAG_SCCA_ON 0x00000001
> #define MACIO_FLAG_SCCB_ON 0x00000002
> ---
> duplicate test of MACIO_FLAG_SCCB_ON
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
> index 5169ecc..e6c0040 100644
> --- a/arch/powerpc/platforms/powermac/feature.c
> +++ b/arch/powerpc/platforms/powermac/feature.c
> @@ -2677,7 +2677,7 @@ static void __init probe_one_macio(const char *name, const char *compat, int typ
> macio_chips[i].of_node = node;
> macio_chips[i].type = type;
> macio_chips[i].base = base;
> - macio_chips[i].flags = MACIO_FLAG_SCCB_ON | MACIO_FLAG_SCCB_ON;
> + macio_chips[i].flags = MACIO_FLAG_SCCA_ON | MACIO_FLAG_SCCB_ON;
> macio_chips[i].name = macio_names[type];
> revp = of_get_property(node, "revision-id", NULL);
> if (revp)
^ permalink raw reply
* [PATCH] duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
From: roel kluin @ 2008-08-19 3:39 UTC (permalink / raw)
To: johannes, linuxppc-dev, alsa-devel, linux-kernel
untested, is it correct?
---
duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/sound/aoa/codecs/snd-aoa-codec-tas.c b/sound/aoa/codecs/snd-aoa-codec-tas.c
index 7a16a33..c922505 100644
--- a/sound/aoa/codecs/snd-aoa-codec-tas.c
+++ b/sound/aoa/codecs/snd-aoa-codec-tas.c
@@ -654,15 +654,15 @@ static struct snd_kcontrol_new bass_control = {
static struct transfer_info tas_transfers[] = {
{
/* input */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
- SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000,
.transfer_in = 1,
},
{
/* output */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
- SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000,
.transfer_in = 0,
},
^ permalink raw reply related
* Re: [MPC7448] machdep_calls
From: Benjamin Herrenschmidt @ 2008-08-18 21:39 UTC (permalink / raw)
To: Sébastien Chrétien; +Cc: Linuxppc-dev
In-Reply-To: <319b0ac50808180717ka6731fdu591798ac0d8b4e82@mail.gmail.com>
On Mon, 2008-08-18 at 16:17 +0200, Sébastien Chrétien wrote:
> The mpc7448hpc2 uses a tsi108-bridge. My board uses an IP on a FPGA..
> I read the code of mpc7448_hpc2.c.
> It uses a ioremap in order to iniatilize the tsi108 registers. But I
> have already initialized MMU with my registers in HEAD_32.S. Do I need
> to use ioremap in setup_arch() ?
Why did you hack head_32.S ? You shouldn't do that... This is common
code, not platform code.
Ben.
>
>
>
> 2008/8/18, Michael Ellerman <michael@ellerman.id.au>:
> On Mon, 2008-08-18 at 13:35 +0200, Sébastien Chrétien wrote:
> > Can somebody explain me the aim of the
> function "setup_arch" in the
> > machine_call structure ?
>
>
> Is this MPC7448 anything like an mpc7448hpc2 ?
>
> If so maybe you should start by looking at the code for it in:
>
> arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
>
> Even if it's not related, that will give you some idea of what
> the
> callbacks are for.
>
> cheers
>
> --
> Michael Ellerman
> OzLabs, IBM Australia Development Lab
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
>
>
^ permalink raw reply
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Becky Bruce @ 2008-08-18 21:25 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Mihaela Grigore
In-Reply-To: <11009.1219092703@neuling.org>
On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote:
> In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com
> > you wrote:
>> The mmu is still disabled at this point.
>>
>> What is marked as readonly is the text section of the vmlinux file
>> generated when compiling the kernel. And since the code tries to
>> write
>> to the text section, I assumed it was the reason for the segmentation
>> fault.
>
> Seriously, a seg fault in your emulator is a bug in the emulator!
Mikey is likely right here. I've (unfortunately) done a lot of
emulator work, and every time I've hit a problem like this, the
problem has been with the emulator or the emulation environment. Have
you isolated the faulting instruction, verified that it's to a
reasonable address, and tried examining memory at the faulting address
using your emulator's command interface?
>
>
>> I'm not sure how this is dealt with on real hardware.
>
> The CPU seg faults... :-P
But only if the page is mapped non-writeable. Even with the MMU on,
Linux maps itself in as writeable. It's the OS, it can do whatever it
wants. So it just works on real hardware, and it should just work in
your emulator.
>
>
>> Can somebody please explain how is it supposed to work ? Is it ok to
>> write to text section that you load on real hardware as readonly ?
>> (again, no mmu involved, as it is still turned off, so i'm not sure
>> who's guarding this section against writing)
>
> I'm not sure how this works for 32 bit CPUs, so I can't speak to the
> details of it.
>
> For the 64bit MMU, if you're in real mode (MMU off), nothing can stop
> this from being written. The kernel ignores the elf sections
> permissions and does it's own mapping but this can only be enforced
> once
> the MMU is on.
The same is true on 32-bit ppc - the basic MMU architecture is very
similar if you have a part that has "real mode" (i.e. non-booke).
There is no way to restrict stores in real mode.
-Becky
>
>
> Mikey
>
>> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling
>> <mikey@neuling.org> wrote:
>>> In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com
>>> > you
> wrote:
>>>> Hello,
>>>>
>>>> First, I'm talkin about the 2.6.11 version. I know arch/ppc is
>>>> gone in
>>>> latest versions,
>>>> but i assume the code is still the same and just moved to powerpc.
>>>>
>>>> There is a piece of code in the early initialization of the 2.6
>>>> kernel
>>>> that identifies the cpu type and then tries to eliminate code that
>>>> does not apply to the current cpu. This is done by writing nop's
>>>> over
>>>> sections of code that are not needed (do_cpu_ftr_fixups in
>>>> arch/ppc/kernel/misc.S)
>>>>
>>>> When I try to run the kernel in a ppc emulator, I get a
>>>> segmentation
>>>> fault in do_cpu_ftr_fixups. From examining the section headers of
>>>> the
>>>> vmlinux, the text section is marked as readonly. The piece of code
>>>> above mentioned is trying to write a nop to memory location
>>>> inside the
>>>> text section which is readonly, so that explains the sigsegv
>>>> error.
>>>
>>> Any segv in the emulator sounds like a bug in the emulator.
>>>
>>> If the page really is marked read only, then writing to it should
>>> cause
>>> a page fault.
>>>
>>>> Since the kernel does run on boards with ppc cpu's, can somebody
>>>> explain how come this is actually working ? Or if/where I am
>>>> mistaking
>>>> with my assumptions ?
>>>>
>>>> Thank you
>>>>
>>>> P.S. please add me in cc in a reply to this message
>>>> _______________________________________________
>>>> Linuxppc-dev mailing list
>>>> Linuxppc-dev@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>>>
>>>
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc: fix memory leaks in QE library
From: Timur Tabi @ 2008-08-18 21:12 UTC (permalink / raw)
To: galak, linuxppc-dev, avorontsov, benh, tony
Fix two memory leaks in the Freescale QE library: add a missing kfree() in
ucc_fast_init() if the ioremap() fails, and update ucc_fast_free() to call
iounmap() on uf_regs.
Based on a patch from Tony Breeds <tony@bakeyournoodle.com>.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 1aecb07..25fbbfa 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -208,6 +208,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
uccf->uf_regs = ioremap(uf_info->regs, sizeof(struct ucc_fast));
if (uccf->uf_regs == NULL) {
printk(KERN_ERR "%s: Cannot map UCC registers\n", __func__);
+ kfree(uccf);
return -ENOMEM;
}
@@ -355,6 +356,9 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
if (uccf->ucc_fast_rx_virtual_fifo_base_offset)
qe_muram_free(uccf->ucc_fast_rx_virtual_fifo_base_offset);
+ if (uccf->uf_regs)
+ iounmap(uccf->uf_regs);
+
kfree(uccf);
}
EXPORT_SYMBOL(ucc_fast_free);
--
1.5.5
^ permalink raw reply related
* Re: [MPC7448] machdep_calls
From: Benjamin Herrenschmidt @ 2008-08-18 21:11 UTC (permalink / raw)
To: Sébastien Chrétien; +Cc: Linuxppc-dev
In-Reply-To: <319b0ac50808180435o4a8e5bebr79f86e17ba2fb9af@mail.gmail.com>
On Mon, 2008-08-18 at 13:35 +0200, Sébastien Chrétien wrote:
> Can somebody explain me the aim of the function "setup_arch" in the
> machine_call structure ?
This is where most of your arch code gets a chance to initialize before
most of the core is.
The generic core linux code calls the architecture setup_arch() very
early during boot, before most other initializations. The powerpc
architecture code performs various early initialisations there, on
32-bit that includes unflattening the device-tree, looking for legacy
serial ports, etc... and initializing bootmem.
It then calls ppc_md.setup_arch to give the platform a chance to perform
other platform specific early initializations before the rest of the
kernel starts initializing.
This is very early, ie, for memory allocation you can only use bootmem
for example. Interrupts haven't been initialized or switched on yet,
etc...
This is typically the place where your arch code will setup it's SMP ops
if any, will discover the fixed PCI host bridges, and initialize low
level HW components that need early initialization.
Ben.
> 2008/8/18, Sébastien Chrétien <sebastien.chretien.enseirb@gmail.com>:
> Ok I am going to copy some examples.
>
> 2008/8/18, Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> On Mon, 2008-08-18 at 10:45 +0200, Sébastien Chrétien
> wrote:
> > Hello,
> >
> > I am developping a Linux for my PPC Board. I must
> write a
> > define_machine structure (marchdep_calls). Where can
> I find some
> > Information about functions of this structure ?
>
>
> It isn't well documented unfortunately. Best is to
> look at what others
> do... and then find your way through.
>
> I agree somebody should write dome doco one day ... in
> the meantime,
> feel free to ask questions here.
>
> Cheers,
> Ben.
>
>
>
>
^ permalink raw reply
* Corrections please ...
From: Kevin Diggs @ 2008-08-18 20:59 UTC (permalink / raw)
To: linuxppc-dev
Could I get any needed corrections on this. Especially on the "???"
[kevdig@PowerMac8600B linux-2.6.26]$ diff -U3
include/linux/completion.{h.orig,h}|more
--- include/linux/completion.h.orig 2008-08-13 00:56:52.000000000 -0700
+++ include/linux/completion.h 2008-08-18 13:00:23.000000000 -0700
@@ -10,6 +10,16 @@
#include <linux/wait.h>
+/**
+ * struct completion - structure used to maintain state for a "completion"
+ * @done: counting variable used to signal completion
+ * @wait: internal wait queue head; used for locking and synchronization
+ *
+ * This is the structure used to maintain the state for a "completion". See
+ * also: complete(), wait_for_completion() (and friends _timeout,
+ * _interruptible, _interruptible_timeout, and _killable),
init_completion(),
+ * and macros DECLARE_COMPLETION() and INIT_COMPLETION().
+ */
struct completion {
unsigned int done;
wait_queue_head_t wait;
@@ -36,6 +46,13 @@
# define DECLARE_COMPLETION_ONSTACK(work) DECLARE_COMPLETION(work)
#endif
+/**
+ * init_completion: - Initialize a dynamically allocated completion
+ * @x: completion structure that is to be initialized
+ *
+ * This inline function will initialize a dynamically created completion
+ * structure.
+ */
static inline void init_completion(struct completion *x)
{
x->done = 0;
--- kernel/sched.c.orig 2008-08-13 02:22:42.000000000 -0700
+++ kernel/sched.c 2008-08-18 13:31:03.000000000 -0700
@@ -4363,6 +4363,13 @@
}
EXPORT_SYMBOL_GPL(__wake_up_sync); /* For internal use only */
+/**
+ * complete: - signals a single thread waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up a single thread waiting on this completion. If
multiple
+ * threads are waiting ???
+ */
void complete(struct completion *x)
{
unsigned long flags;
@@ -4374,6 +4381,12 @@
}
EXPORT_SYMBOL(complete);
+/**
+ * complete_all: - signals all threads waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up all threads waiting on this particular completion
event.
+ */
void complete_all(struct completion *x)
{
unsigned long flags;
@@ -4425,12 +4438,27 @@
return timeout;
}
+/**
+ * wait_for_completion: - waits for completion of a task
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is NOT
+ * interruptible and there is no timeout.
+ */
void __sched wait_for_completion(struct completion *x)
{
wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_UNINTERRUPTIBLE);
}
EXPORT_SYMBOL(wait_for_completion);
+/**
+ * wait_for_completion_timeout: - waits for completion of a task
(w/timeout)
+ * @x: holds the state of this particular completion
+ * @timeout: timeout value in jiffies
+ *
+ * This waits to be signaled for completion of a specific task. It is NOT
+ * interruptible. But there is a timeout in jiffies.
+ */
unsigned long __sched
wait_for_completion_timeout(struct completion *x, unsigned long timeout)
{
@@ -4438,6 +4466,13 @@
}
EXPORT_SYMBOL(wait_for_completion_timeout);
+/**
+ * wait_for_completion_interruptible: - waits for completion of a task
(w/intr)
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * interruptible.
+ */
int __sched wait_for_completion_interruptible(struct completion *x)
{
long t = wait_for_common(x, MAX_SCHEDULE_TIMEOUT,
TASK_INTERRUPTIBLE);
@@ -4447,6 +4482,14 @@
}
EXPORT_SYMBOL(wait_for_completion_interruptible);
+/**
+ * wait_for_completion_interruptible_timeout: - waits for completion
(w/(to,int
r))
+ * @x: holds the state of this particular completion
+ * @timeout: timeout value in jiffies
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * interruptible. And there is a timeout in jiffies.
+ */
unsigned long __sched
wait_for_completion_interruptible_timeout(struct completion *x,
unsigned long timeout)
@@ -4455,6 +4498,13 @@
}
EXPORT_SYMBOL(wait_for_completion_interruptible_timeout);
+/**
+ * wait_for_completion_killable: - waits for completion of a task
(killable)
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * killable (???).
+ */
int __sched wait_for_completion_killable(struct completion *x)
{
long t = wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_KILLABLE);
^ permalink raw reply
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Michael Neuling @ 2008-08-18 20:51 UTC (permalink / raw)
To: Mihaela Grigore; +Cc: linuxppc-dev
In-Reply-To: <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com>
In message <78ef7ce10808181257u637c5597xaa992b9e4e7a0925@mail.gmail.com> you wrote:
> The mmu is still disabled at this point.
>
> What is marked as readonly is the text section of the vmlinux file
> generated when compiling the kernel. And since the code tries to write
> to the text section, I assumed it was the reason for the segmentation
> fault.
Seriously, a seg fault in your emulator is a bug in the emulator!
> I'm not sure how this is dealt with on real hardware.
The CPU seg faults... :-P
> Can somebody please explain how is it supposed to work ? Is it ok to
> write to text section that you load on real hardware as readonly ?
> (again, no mmu involved, as it is still turned off, so i'm not sure
> who's guarding this section against writing)
I'm not sure how this works for 32 bit CPUs, so I can't speak to the
details of it.
For the 64bit MMU, if you're in real mode (MMU off), nothing can stop
this from being written. The kernel ignores the elf sections
permissions and does it's own mapping but this can only be enforced once
the MMU is on.
Mikey
> On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org> wrote:
> > In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com> you
wrote:
> >> Hello,
> >>
> >> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
> >> latest versions,
> >> but i assume the code is still the same and just moved to powerpc.
> >>
> >> There is a piece of code in the early initialization of the 2.6 kernel
> >> that identifies the cpu type and then tries to eliminate code that
> >> does not apply to the current cpu. This is done by writing nop's over
> >> sections of code that are not needed (do_cpu_ftr_fixups in
> >> arch/ppc/kernel/misc.S)
> >>
> >> When I try to run the kernel in a ppc emulator, I get a segmentation
> >> fault in do_cpu_ftr_fixups. From examining the section headers of the
> >> vmlinux, the text section is marked as readonly. The piece of code
> >> above mentioned is trying to write a nop to memory location inside the
> >> text section which is readonly, so that explains the sigsegv error.
> >
> > Any segv in the emulator sounds like a bug in the emulator.
> >
> > If the page really is marked read only, then writing to it should cause
> > a page fault.
> >
> >> Since the kernel does run on boards with ppc cpu's, can somebody
> >> explain how come this is actually working ? Or if/where I am mistaking
> >> with my assumptions ?
> >>
> >> Thank you
> >>
> >> P.S. please add me in cc in a reply to this message
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >>
> >
>
^ permalink raw reply
* Re: Clock / Timebase / Bus Frequencies Help
From: surendranath.moilla @ 2008-08-18 19:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080818155921.GA26475@loki.buserror.net>
Hi,
I have a similar problem with custom MPC8360 board.
I am able to boot Linux with the mpc836x_dts.dtb provided by freescale.
but when use dtb customised for my board i am unable to boot Linux.
It is hanging after the console handover to real console from boot console.
I am filling all the frequencies properly, can someone help me to fix this
Where to set the baud rate in dts file.
Here is the log:
=> tftp $loadaddr /nfk684/vpm_test/uImage
Using FSL UEC0 device
TFTP from server 192.168.0.2; our IP address is 192.168.0.100
Filename '/nfk684/vpm_test/uImage'.
Load address: 0x200000
Loading: #################################################################
##########
done
Bytes transferred = 1095689 (10b809 hex)
=> tftp $fdtaddr /nfk684/vpm_test/mpc8360_vpm.dtb
Using FSL UEC0 device
TFTP from server 192.168.0.2; our IP address is 192.168.0.100
Filename '/nfk684/vpm_test/mpc8360_vpm.dtb'.
Load address: 0x400000
Loading: #
done
Bytes transferred = 12288 (3000 hex)
=> bootm $loadaddr - $fdtaddr
## Booting image at 00200000 ...
Image Name: Linux-2.6.22
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1095625 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x400000
Probing machine type
Using MPC8360 VPM machine description
Linux version 2.6.22 (nfk684@ilec4411) (gcc version 4.0.0 (DENX ELDK 4.1
4.0.0))
#17 Fri Aug 15 16:13:41 CDT 2008
setup_arch: bootmem
mpc8360_vpm_setup_arch()
Bad clock source for time stamp 1
Bad clock source for time stamp 2
arch: exit
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists. Total pages: 65024
Kernel command line: root=/dev/ram rw console=ttyS1,115200
IPIC (128 IRQ sources) at fdefc700
QEIC (64 IRQ sources) at fdefb080
PID hash table entries: 1024 (order: 10, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257280k/262144k available (2152k kernel code, 4624k reserved, 96k
data,
80k bss, 128k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Generic PHY: Registered new driver
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
console handover: boot [udbg0] -> real [ttyS1]
Regards
Surendra
> On Mon, Aug 18, 2008 at 07:52:12AM -0400, richw@netcomuk.co.uk wrote:
>> We've got an 8347 based board very similar to the A&M asp8347. Core
>> clock
>> is 400MHz. Bus clock is 266666666Hz.
>> According to the data sheet for the 8347, the decrementer clock runs at
>> a
>> quarter of the rate of the bus clock. I have two questions:
>> In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to
>> dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my
>> system clock runs approximately 4 times too fast.
>> Can anyone point me in the direction of an explanation for the div by 16
>> rather than 4?
>
> It's a bug, which I pointed out here:
> http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html
>
>> If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is
>> passed
>> in, then the clock runs more accurately. However, its still not correct.
>> This gives a decrementer frequency of 66666666Hz, but if I hard code the
>> value to 66000000Hz, the clock runs accurately.
>> Can anyone shed any light on why the value passed in by the boot loader
>> (redboot) seems to be inaccurate.
>
> Redboot probably has the wrong crystal frequency hardcoded.
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Mihaela Grigore @ 2008-08-18 19:57 UTC (permalink / raw)
To: Michael Neuling, linuxppc-dev
In-Reply-To: <1586.1219087193@neuling.org>
The mmu is still disabled at this point.
What is marked as readonly is the text section of the vmlinux file
generated when compiling the kernel. And since the code tries to write
to the text section, I assumed it was the reason for the segmentation
fault.
I'm not sure how this is dealt with on real hardware.
Can somebody please explain how is it supposed to work ? Is it ok to
write to text section that you load on real hardware as readonly ?
(again, no mmu involved, as it is still turned off, so i'm not sure
who's guarding this section against writing)
On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling <mikey@neuling.org> wrote:
> In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com> you wrote:
>> Hello,
>>
>> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
>> latest versions,
>> but i assume the code is still the same and just moved to powerpc.
>>
>> There is a piece of code in the early initialization of the 2.6 kernel
>> that identifies the cpu type and then tries to eliminate code that
>> does not apply to the current cpu. This is done by writing nop's over
>> sections of code that are not needed (do_cpu_ftr_fixups in
>> arch/ppc/kernel/misc.S)
>>
>> When I try to run the kernel in a ppc emulator, I get a segmentation
>> fault in do_cpu_ftr_fixups. From examining the section headers of the
>> vmlinux, the text section is marked as readonly. The piece of code
>> above mentioned is trying to write a nop to memory location inside the
>> text section which is readonly, so that explains the sigsegv error.
>
> Any segv in the emulator sounds like a bug in the emulator.
>
> If the page really is marked read only, then writing to it should cause
> a page fault.
>
>> Since the kernel does run on boards with ppc cpu's, can somebody
>> explain how come this is actually working ? Or if/where I am mistaking
>> with my assumptions ?
>>
>> Thank you
>>
>> P.S. please add me in cc in a reply to this message
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-18 19:28 UTC (permalink / raw)
To: Scott Wood
Cc: Eran Liberty, Mathieu Desnoyers, linux-kernel, linuxppc-dev,
Steven Rostedt, Paul E. McKenney
In-Reply-To: <48A9C5C0.5010705@freescale.com>
On Mon, 18 Aug 2008, Scott Wood wrote:
> Steven Rostedt wrote:
> > What syntax to do that with?
> >
> > lwz %1,0(%U2)
> > stu %3, 0(%X2)
> >
> > I'm new to those. (and the above does not compile)
>
> lwz%U2%X2 %1, %2
> stw%U2%X2 %3, %2
Thanks, that's new to me.
>
> > > Why stwu with an offset of zero,
> >
> > How else to do it? stwu %3, (%2) does not compile for me.
>
> stw %3, 0(%2)
>
> The "u" tells it to write the effective address back to %2 -- but with an
> offset of zero, the effective address is unchanged.
Ah! Right!
/me should open up his PowerPC ref books again :-p
-- Steve
^ permalink raw reply
* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Michael Neuling @ 2008-08-18 19:19 UTC (permalink / raw)
To: Mihaela Grigore; +Cc: linuxppc-dev
In-Reply-To: <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com>
In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com> you wrote:
> Hello,
>
> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
> latest versions,
> but i assume the code is still the same and just moved to powerpc.
>
> There is a piece of code in the early initialization of the 2.6 kernel
> that identifies the cpu type and then tries to eliminate code that
> does not apply to the current cpu. This is done by writing nop's over
> sections of code that are not needed (do_cpu_ftr_fixups in
> arch/ppc/kernel/misc.S)
>
> When I try to run the kernel in a ppc emulator, I get a segmentation
> fault in do_cpu_ftr_fixups. From examining the section headers of the
> vmlinux, the text section is marked as readonly. The piece of code
> above mentioned is trying to write a nop to memory location inside the
> text section which is readonly, so that explains the sigsegv error.
Any segv in the emulator sounds like a bug in the emulator.
If the page really is marked read only, then writing to it should cause
a page fault.
> Since the kernel does run on boards with ppc cpu's, can somebody
> explain how come this is actually working ? Or if/where I am mistaking
> with my assumptions ?
>
> Thank you
>
> P.S. please add me in cc in a reply to this message
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ 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