kbuild, modpost: fix non-allocatable section warnings
It turned out there were at least three sources of the non-allocatable section warning. 1) SUSE specific .comment section 2) endianness issues in elf header 3) additional debug sections I have updated kbuild-fixes.git with patches for all of the above. But as we have seen three independent sources of this warning within short time I expect there may be yet-to-be-discovered issues. The patches accumulated so far all looks trivially correct and Jean and Sean has been quick to test them. So unless something unexpected shows up I plan to push them within a day or two. I would like to see them in -next for a day or two first in the hope that if other architectures has troubles they will report this before it hits upstream. Patches will follow for reference / testing. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] kbuild, modpost: fix unexpected non-allocatable section when cross compiling
From 7d875a02864a35532543897195dfea2235815df8 Mon Sep 17 00:00:00 2001
From: Anders Kaseorg ande...@mit.edu
Date: Sun, 3 May 2009 22:02:55 +0200
Subject: [PATCH 1/3] kbuild, modpost: fix unexpected non-allocatable section
when cross compiling
The missing TO_NATIVE(sechdrs[i].sh_flags) was causing many
unexpected non-allocatable section warnings when cross-compiling
for an architecture with a different endianness.
Fix endianness of all the fields in the ELF header and
section headers, not just some of them so we are not
hit by this anohter time.
Signed-off-by: Anders Kaseorg ande...@mit.edu
Reported-by: Sean MacLennan smaclen...@pikatech.com
Tested-by: Sean MacLennan smaclen...@pikatech.com
Signed-off-by: Sam Ravnborg s...@ravnborg.org
---
scripts/mod/modpost.c | 35 +++
1 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 936b6f8..a5c17db 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -384,11 +384,19 @@ static int parse_elf(struct elf_info *info, const char
*filename)
return 0;
}
/* Fix endianness in ELF header */
- hdr-e_shoff= TO_NATIVE(hdr-e_shoff);
- hdr-e_shstrndx = TO_NATIVE(hdr-e_shstrndx);
- hdr-e_shnum= TO_NATIVE(hdr-e_shnum);
- hdr-e_machine = TO_NATIVE(hdr-e_machine);
- hdr-e_type = TO_NATIVE(hdr-e_type);
+ hdr-e_type = TO_NATIVE(hdr-e_type);
+ hdr-e_machine = TO_NATIVE(hdr-e_machine);
+ hdr-e_version = TO_NATIVE(hdr-e_version);
+ hdr-e_entry = TO_NATIVE(hdr-e_entry);
+ hdr-e_phoff = TO_NATIVE(hdr-e_phoff);
+ hdr-e_shoff = TO_NATIVE(hdr-e_shoff);
+ hdr-e_flags = TO_NATIVE(hdr-e_flags);
+ hdr-e_ehsize= TO_NATIVE(hdr-e_ehsize);
+ hdr-e_phentsize = TO_NATIVE(hdr-e_phentsize);
+ hdr-e_phnum = TO_NATIVE(hdr-e_phnum);
+ hdr-e_shentsize = TO_NATIVE(hdr-e_shentsize);
+ hdr-e_shnum = TO_NATIVE(hdr-e_shnum);
+ hdr-e_shstrndx = TO_NATIVE(hdr-e_shstrndx);
sechdrs = (void *)hdr + hdr-e_shoff;
info-sechdrs = sechdrs;
@@ -402,13 +410,16 @@ static int parse_elf(struct elf_info *info, const char
*filename)
/* Fix endianness in section headers */
for (i = 0; i hdr-e_shnum; i++) {
- sechdrs[i].sh_type = TO_NATIVE(sechdrs[i].sh_type);
- sechdrs[i].sh_offset = TO_NATIVE(sechdrs[i].sh_offset);
- sechdrs[i].sh_size = TO_NATIVE(sechdrs[i].sh_size);
- sechdrs[i].sh_link = TO_NATIVE(sechdrs[i].sh_link);
- sechdrs[i].sh_name = TO_NATIVE(sechdrs[i].sh_name);
- sechdrs[i].sh_info = TO_NATIVE(sechdrs[i].sh_info);
- sechdrs[i].sh_addr = TO_NATIVE(sechdrs[i].sh_addr);
+ sechdrs[i].sh_name = TO_NATIVE(sechdrs[i].sh_name);
+ sechdrs[i].sh_type = TO_NATIVE(sechdrs[i].sh_type);
+ sechdrs[i].sh_flags = TO_NATIVE(sechdrs[i].sh_flags);
+ sechdrs[i].sh_addr = TO_NATIVE(sechdrs[i].sh_addr);
+ sechdrs[i].sh_offset= TO_NATIVE(sechdrs[i].sh_offset);
+ sechdrs[i].sh_size = TO_NATIVE(sechdrs[i].sh_size);
+ sechdrs[i].sh_link = TO_NATIVE(sechdrs[i].sh_link);
+ sechdrs[i].sh_info = TO_NATIVE(sechdrs[i].sh_info);
+ sechdrs[i].sh_addralign = TO_NATIVE(sechdrs[i].sh_addralign);
+ sechdrs[i].sh_entsize = TO_NATIVE(sechdrs[i].sh_entsize);
}
/* Find symbol table. */
for (i = 1; i hdr-e_shnum; i++) {
--
1.6.3.rc3.40.g75b44
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] kbuild, modpost: fix unexpected non-allocatable warning with SUSE gcc
From 028ecebdd83cc4a7f8c7e96e28a5537d2ac98dae Mon Sep 17 00:00:00 2001
From: Sam Ravnborg s...@ravnborg.org
Date: Sun, 3 May 2009 22:17:37 +0200
Subject: [PATCH 2/3] kbuild, modpost: fix unexpected non-allocatable warning
with SUSE gcc
Jean reported that he saw one warning for each module like the one below:
WARNING: arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.o (.comment.SUSE.OPTs):
unexpected non-allocatable section.
The warning appeared with the improved version of the
check of the flags in the sections.
That check already ignored sections named .comment - but SUSE store
additional info in the comment section and has named it in a SUSE
specific way. Therefore modpost failed to ignore the section.
The fix is to extend the pattern so we ignore all sections
that start with the name .comment..
Signed-off-by: Sam Ravnborg s...@ravnborg.org
Reported-by: Jean Delvare kh...@linux-fr.org
Tested-by: Jean Delvare kh...@linux-fr.org
---
scripts/mod/modpost.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index a5c17db..268d457 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -727,7 +727,7 @@ int match(const char *sym, const char * const pat[])
/* sections that we do not want to do full section mismatch check on */
static const char *section_white_list[] =
- { .comment, .debug*, .stab*, .note*, .got*, .toc*, NULL };
+ { .comment*, .debug*, .stab*, .note*, .got*, .toc*, NULL };
/*
* This is used to find sections missing the SHF_ALLOC flag.
--
1.6.3.rc3.40.g75b44
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] kbuild, modpost: fix unexpected non-allocatable warning with mips
From 4391ed6aa9a38cdfb48addd7a9b24a2ff099b1a7 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg s...@ravnborg.org
Date: Mon, 4 May 2009 13:05:26 +0200
Subject: [PATCH 3/3] kbuild, modpost: fix unexpected non-allocatable warning
with mips
mips emit the following debug sections:
.mdebug* and .pdr
They were included in the check for non-allocatable section
and caused modpost to warn.
Manuel Lauss suggested to fix this by adding the relevant
sections to the list of sections we do not check.
Signed-off-by: Sam Ravnborg s...@ravnborg.org
Reported-by: Manuel Lauss m...@roarinelk.homelinux.net
---
scripts/mod/modpost.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 268d457..161b784 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -727,7 +727,17 @@ int match(const char *sym, const char * const pat[])
/* sections that we do not want to do full section mismatch check on */
static const char *section_white_list[] =
- { .comment*, .debug*, .stab*, .note*, .got*, .toc*, NULL };
+{
+ .comment*,
+ .debug*,
+ .mdebug*,/* alpha, score, mips etc. */
+ .pdr,/* alpha, score, mips etc. */
+ .stab*,
+ .note*,
+ .got*,
+ .toc*,
+ NULL
+};
/*
* This is used to find sections missing the SHF_ALLOC flag.
--
1.6.3.rc3.40.g75b44
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using archaic I2C with OF
Wolfram Sang wrote: Post this on the i2c list. Jean has made an effort to convert all drivers. He must have missed that one. What Jean did was converting all drivers who used the legacy i2c-binding to use the new binding which is a lot better suited to the driver model. The above mentioned driver already uses the new binding. The problem coming up here is another issue and also long standing and not yet solved. There are drivers which require platform_data with function pointers. You cannot encode function pointers to the device tree. One solution is to create a custom driver for your board with the needed specific function and create a platform device from there. Sometimes it works to add a bit more info to the device tree (e.g. some gpios) and parse it via an of_wrapper around the platform driver. So somehow, I need to create a platform driver, possibly inside an of_wrapper, which eventually instantiates an I2C device on a particular bus, with my specific platform data. Sorry, but I'm lost here. How do I untangle this maze of twisty little passages? -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: KGDBOC testing on linux-2.6.30-rc4
On Mon, May 4, 2009 at 9:13 AM, srikanth krishnakar
skrishna...@gmail.com wrote:
Hi all,
I need help in kgdboc testing on PowerPC target.
Have you tried contacting the maintainer ? (I noticed that Jason
wasn't cc'd), just in case it isn't simply a use case problem and
might be related to KGDB internals.
KGDB
P: Jason Wessel
M: jason.wes...@windriver.com
I've tested KGDBOC up to the 2.6.29 kernel and it worked fine
on a series of 85xx boards. I haven't had a chance on 2.6.30-rcX
yet, so something may have changed.
Linux Kernel: 2.6.30-rc4
KGDB method : KGDBOC
Arch: PowerPC
Note: Attached is the kernel config used.
Has anyone tested KGDBOC for Serial 8250, and the serial port has dependency
on OF_PLATFORM driver ?
Here are the kernel config options:
Device Drivers ---
Character devices ---
Serial drivers ---
* 8250/16550 and
compatible serial support
[*] Console on
8250/16550 and compatible serial port
(4) Number of
8250/16550 serial ports to register at runtime
[ ] Extended 8250/16550
serial driver options
*** Non-8250 serial
port support ***
* Xilinx uartlite
serial port support
[*] Support for
console on Xilinx uartlite serial port
Digi International
NEO PCI Support
* Serial port on Open
Firmware platform bus
NWP serial port
driver
Kernel hacking ---
-*- Magic SysRq key
[*] Kernel debugging
[*] KGDB: kernel debugging with remote gdb ---
--- KGDB: kernel debugging with remote
gdb
* KGDB: use kgdb over the serial console
--
In the process :
On the target side :
...
Serial: 8250/16550 driver, 4 ports, IRQ sharing
disabled
83e0.serial: ttyS0 at MMIO 0x83e01003 (irq
= 16) is a
16550A
console [ttyS0]
enabled
kgdb: Registered I/O driver kgdboc.
.
r...@10.161.2.35:~# echo g /proc/sysrq-trigger
SysRq : GDB
Entering KGDB
On host side :
[r...@srikant linux-2.6]# powerpc-linux-gnu-gdb
vmlinux-puru
GNU gdb G++ 4.3-150) 6.8.50.20081022-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and
redistribute it.
There is NO WARRANTY, to the extent permitted by
law. Type show copying
and show warranty for details.
This GDB was configured as
--host=i686-pc-linux-gnu --target=powerpc-linux-gnu.
For bug reporting instructions, please see:
(gdb) set remotebaud 9600
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Ignoring packet error, continuing...
warning: unrecognized item timeout in
qSupported response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Malformed response to offset query, timeout
I'm wondering if there is a GDB protocol mismatch and your
version of GDB is sending packets that KGDB can't handle.
I'm no where near an expert on GDB's protocol and won't know
if I'm seeing the same thing until I try 2.6.30-rc
Bruce
Can anybody comment on the steps followed in the process of testing or
something is missing with respect to of_serial.c for powerpc architecture.
Seems the target has never responded for gdb requests !!!
Regards
Srikanth
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: Need a patch tested on a windtunnel powermac
Hi Josh, On Mon, 4 May 2009 10:52:32 -0400, Josh Boyer wrote: On Thu, Apr 30, 2009 at 03:17:08PM -0400, Josh Boyer wrote: On Wed, Apr 29, 2009 at 08:24:48PM -0400, Josh Boyer wrote: On Thu, Apr 30, 2009 at 09:30:59AM +1000, Paul Mackerras wrote: Does anyone here still have a windtunnel powermac (PowerMac3,6) machine running Linux? We need someone to test Jean Delvare's patch to the therm_windtunnel driver. The patch is at: http://patchwork.ozlabs.org/patch/26095/ I don't have a windtunnel machine myself - I have a PowerMac3,5 but not a PowerMac3,6. I might have one. I'll pull the G4 I have out of it's box and check tomorrow. Amazingly enough, I do. It's running some crusty-arse gentoo install from 2005, so I need to install something newer on it. Hopefully that goes smoothly today... Ok, installed 2.6.30-rc4 plus Jean's patch and it appears to do something correctly: [jwbo...@localhost macintosh]$ sudo modprobe therm_windtunnel [jwbo...@localhost macintosh]$ dmesg snip DS1775 digital thermometer [...@49] Temp: 52.5 C Hyst: 75.0 C OS: 80.0 C ADM1030 fan controller [...@2c] Reducing overheating limit to 65.0 C (Hyst: 60.0 C) CPU-temp: 52.9 C, Case: 31.3 C, Fan: 0 (tuned -11) [jwbo...@localhost macintosh]$ uname -a Linux localhost.localdomain 2.6.30-rc4 #1 SMP Mon May 4 10:20:39 EDT 2009 ppc ppc ppc GNU/Linux Thanks for testing and reporting. This completes the testing of all macintosh thermal drivers. For completeness, as I see you built the driver as a module, could you try unloading and reloading it? Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Need a patch tested on a windtunnel powermac
On Mon, May 04, 2009 at 05:40:01PM +0200, Jean Delvare wrote: Hi Josh, Ok, installed 2.6.30-rc4 plus Jean's patch and it appears to do something correctly: [jwbo...@localhost macintosh]$ sudo modprobe therm_windtunnel [jwbo...@localhost macintosh]$ dmesg snip DS1775 digital thermometer [...@49] Temp: 52.5 C Hyst: 75.0 C OS: 80.0 C ADM1030 fan controller [...@2c] Reducing overheating limit to 65.0 C (Hyst: 60.0 C) CPU-temp: 52.9 C, Case: 31.3 C, Fan: 0 (tuned -11) [jwbo...@localhost macintosh]$ uname -a Linux localhost.localdomain 2.6.30-rc4 #1 SMP Mon May 4 10:20:39 EDT 2009 ppc ppc ppc GNU/Linux Thanks for testing and reporting. This completes the testing of all macintosh thermal drivers. For completeness, as I see you built the driver as a module, could you try unloading and reloading it? Sure: [jwbo...@localhost macintosh]$ sudo rmmod therm_windtunnel [jwbo...@localhost macintosh]$ sudo modprobe therm_windtunnel [jwbo...@localhost macintosh]$ dmesg snip DS1775 digital thermometer [...@49] Temp: 53.6 C Hyst: 60.0 C OS: 65.0 C ADM1030 fan controller [...@2c] CPU-temp: 53.6 C, Case: 31.8 C, Fan: 0 (tuned -11) Seems to work fine. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Need a patch tested on a windtunnel powermac
On Mon, 4 May 2009 11:42:08 -0400, Josh Boyer wrote: On Mon, May 04, 2009 at 05:40:01PM +0200, Jean Delvare wrote: For completeness, as I see you built the driver as a module, could you try unloading and reloading it? Sure: [jwbo...@localhost macintosh]$ sudo rmmod therm_windtunnel [jwbo...@localhost macintosh]$ sudo modprobe therm_windtunnel [jwbo...@localhost macintosh]$ dmesg snip DS1775 digital thermometer [...@49] Temp: 53.6 C Hyst: 60.0 C OS: 65.0 C ADM1030 fan controller [...@2c] CPU-temp: 53.6 C, Case: 31.8 C, Fan: 0 (tuned -11) Seems to work fine. Excellent. Thanks again! -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Need a patch tested on a windtunnel powermac
On Thu, Apr 30, 2009 at 03:17:08PM -0400, Josh Boyer wrote: On Wed, Apr 29, 2009 at 08:24:48PM -0400, Josh Boyer wrote: On Thu, Apr 30, 2009 at 09:30:59AM +1000, Paul Mackerras wrote: Does anyone here still have a windtunnel powermac (PowerMac3,6) machine running Linux? We need someone to test Jean Delvare's patch to the therm_windtunnel driver. The patch is at: http://patchwork.ozlabs.org/patch/26095/ I don't have a windtunnel machine myself - I have a PowerMac3,5 but not a PowerMac3,6. I might have one. I'll pull the G4 I have out of it's box and check tomorrow. Amazingly enough, I do. It's running some crusty-arse gentoo install from 2005, so I need to install something newer on it. Hopefully that goes smoothly today... Ok, installed 2.6.30-rc4 plus Jean's patch and it appears to do something correctly: [jwbo...@localhost macintosh]$ sudo modprobe therm_windtunnel [jwbo...@localhost macintosh]$ dmesg snip DS1775 digital thermometer [...@49] Temp: 52.5 C Hyst: 75.0 C OS: 80.0 C ADM1030 fan controller [...@2c] Reducing overheating limit to 65.0 C (Hyst: 60.0 C) CPU-temp: 52.9 C, Case: 31.3 C, Fan: 0 (tuned -11) [jwbo...@localhost macintosh]$ uname -a Linux localhost.localdomain 2.6.30-rc4 #1 SMP Mon May 4 10:20:39 EDT 2009 ppc ppc ppc GNU/Linux josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FSL Driver load issues with OF
Scott Wood wrote: On Wed, Apr 29, 2009 at 11:45:20AM +0200, Benjamin Zores wrote: Since the progressive migration of some PPC drivers to use of_platform bus (typically migrating OF parsing from fsl_soc.c to the device probe/init functions), I'm experiencing driver load issues. Actually, I'm not longer able to load of these drivers as the probe() function is never called. Make sure your board is calling of_platform_bus_probe(), and that the devices you're trying to probe are under buses described by the id list. Thx for spotting this point. When porting my custom board I indeed had a part of code that returned before of_platform_bus_probe() can be called. Thx again, it now works fine. Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: help with MPC8272ADS board
On Sun, May 03, 2009 at 10:16:29AM +0300, Landau, Bracha wrote: I'm trying to get the MPC8272ADS evaluation board up and running with the latest versions of u-boot and Denx linux (2.6.24). 2.6.24 is nowhere near the latest version of Linux. If you specifically want to use a Denx kernel, you're better off at e...@denx.de -- though I'd be surprised if that's the latest they offer, either. I use the device tree file (mpc8272ads.dts) provided. Based on another post, I updated the MPC8260ADS.h file, changing OF_CPU from c...@0mailto:c...@0 to PowerPC,8...@0, because I was getting an error. I'd rather change the device tree, instead. I tried booting both using a cuImage (cuImage.mpc8272ads) and a uImage with a device tree blob. Neither boot was successful, with no helpful information printed to the serial port. Is there any change that has to be made in order to get the board to boot? Upgrade to the latest kernel, and if it still doesn't work try enabling the early debug console (note that the default address is currently for cuImage). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] offb: use framebuffer_alloc() to allocate fb_info struct
From: Krzysztof Helt krzysztof...@wp.pl
Use the framebuffer_alloc() function to allocate the fb_info
structure so the structure is correctly initialized after allocation.
Signed-off-by: Krzysztof Helt krzysztof...@wp.pl
---
diff -urp linux-orig/drivers/video/offb.c linux-2.6.30/drivers/video/offb.c
--- linux-orig/drivers/video/offb.c 2008-08-09 05:09:05.0 +0200
+++ linux-2.6.30/drivers/video/offb.c 2009-05-04 00:14:28.0 +0200
@@ -378,7 +378,6 @@ static void __init offb_init_fb(const ch
struct fb_fix_screeninfo *fix;
struct fb_var_screeninfo *var;
struct fb_info *info;
- int size;
if (!request_mem_region(res_start, res_size, offb))
return;
@@ -393,15 +392,12 @@ static void __init offb_init_fb(const ch
return;
}
- size = sizeof(struct fb_info) + sizeof(u32) * 16;
-
- info = kmalloc(size, GFP_ATOMIC);
+ info = framebuffer_alloc(sizeof(u32) * 16, NULL);
if (info == 0) {
release_mem_region(res_start, res_size);
return;
}
- memset(info, 0, size);
fix = info-fix;
var = info-var;
--
Wygraj 3000 zl, wycieczke lub lot balonem!
Sprawdz http://link.interia.pl/f2154
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2.6.30-rc5] ehea: fix invalid pointer access
From: Hannes Hering hannes.her...@linux.vnet.ibm.com Date: Mon, 4 May 2009 18:02:30 +0200 This patch fixes an invalid pointer access in case the receive queue holds no pointer to the next skb when the queue is empty. Signed-off-by: Hannes Hering heri...@de.ibm.com Signed-off-by: Jan-Bernd Themann them...@de.ibm.com Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Patch] powerpc/cell: make ptcal more reliable
This is for QS21. The following patch allocates pages only from
the specified node, moves the ptcal area into the middle of the
allocated page to avoid potential prefetch problems and prints
the address of the ptcal area to facilitate diagnostics.
Signed-off-by: Gerhard Stenzel gerhard.sten...@de.ibm.com
Index: linux-2.6/arch/powerpc/platforms/cell/ras.c
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/ras.c
+++ linux-2.6/arch/powerpc/platforms/cell/ras.c
@@ -122,12 +122,22 @@ static int __init cbe_ptcal_enable_on_no
area-nid = nid;
area-order = order;
- area-pages = alloc_pages_node(area-nid, GFP_KERNEL, area-order);
+ area-pages = alloc_pages_node(area-nid, GFP_KERNEL | GFP_THISNODE,
area-order);
- if (!area-pages)
+ if (!area-pages) {
+ printk(KERN_INFO %s: no page on node %d\n,
+ __FUNCTION__, area-nid);
goto out_free_area;
+ }
- addr = __pa(page_address(area-pages));
+ /*
+* We move the ptcal area to the middle of the allocated
+* page, in order to avoid prefetches in memcpy and similar
+* functions stepping on it.
+*/
+ addr = __pa(page_address(area-pages)) + (PAGE_SIZE 1);
+ printk(KERN_INFO %s: enabling PTCAL on node %d address=0x%016lx
PAGE_SIZE1=0x%016lx \n,
+ __FUNCTION__, area-nid, addr, PAGE_SIZE1);
ret = -EIO;
if (rtas_call(ptcal_start_tok, 3, 1, NULL, area-nid,
===
Best regards,
Gerhard Stenzel, Linux on Cell Development, LTC
-
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen | Registergericht: Amtsgericht Stuttgart, HRB
243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Setting Kernel Allocated Memory Uncached on the PPC460
Hello Everyone,
This is my first post to this list, so hopefully I read all the
instructions correctly and am posting to the correct list.
I have a driver which maps some kernel allocated memory to user space
which works, and now I am trying to set that memory non-cacheable, on a
power PC using the Denx ELDK (linux-2.6.24) on a PPC460ex.
I have attempted several ways of doing this:
1. Calling the macro SetPageUncached() in linux/page-flags.h. This fails
because for some reason the bit PG_uncached is only defined for
processors whose BITS_PER_LONG 32.
2. Calling the macro pgprot_noncached() in asm/pgtable-ppc32.h. This
just doesn't seem to have any effect.
3. Setting flags in the struct vm_area_struct-vm_flags before calling
remap_pfn_range(). This doesn't work because the flag I expected to find
VM_NONCACHED is not defined anywhere.
4. Calling the function dma_alloc_coherent() instead of kmalloc() to
allocate the memory(). This causes some kind of bus error or exception
in the kernel - I believe because I passed in NULL for the device which
I read is a bug with the kernel.
Has anyone done this successfuly on a PPC440 or PPC460?
Any tips would be appreciated. Code snippets below...
Thanks!
//
// allocating the memory in the kernel
//
static int __init mapper_init_module(void)
{
int rc;
unsigned int i = 0;
phys_addr_t phys_addr;
MDEBUG(Initializing module...\n);
/* allocate the memory and pad with pages so that we can
* make sure to page align
*/
km.raw = kmalloc((2*PAGE_COUNT+1)*PAGE_SIZE, GFP_KERNEL);
if (!km.raw)
return -ENOMEM;
/* now need to adjust our other pointer to page align to 64 Kb
boundary*/
/* Note, that we just do the mal and set pal to it since if it is 64Kb
aligned
* then it is also page aligned
*/
km.mal = (int *)unsigned long)km.raw) + ((116) - 1))
0x);
/*km.pal = (int *)unsigned long)km.raw) + (PAGE_SIZE - 1))
PAGE_MASK);*/
km.pal = km.mal;
MDEBUG(Allocated %ld bytes of kernel space for driver at kernel
logical address %p...\n,
PAGE_COUNT*PAGE_SIZE, km.raw);
MDEBUG(page aligned = %p 64k aligned = %p\n, km.pal, km.mal);
MDEBUG(Physical address = 0x%lx...\n, __pa(km.raw));
.
.
.
.
/* lock down / reserve the pages in memory */
{
int k;
for (k=0; kPAGE_COUNT*PAGE_SIZE; k+=PAGE_SIZE)
{
struct page* pg = virt_to_page(((unsigned long)km.pal) + k);
SetPageReserved(pg);
//SetPageUncached(pg);
}
}
.
.
.
.
}
//
// mapping the kernel space to user space
//
static int mapper_mmap(struct file *fip, struct vm_area_struct *vma)
{
int rc;
/*
* make sure to allocate the proper number of pages when using
* mmap. We check it for correctness here.
*/
unsigned long len = vma-vm_end - vma-vm_start;
/* if user tries to map bigger space than we have, error */
if (PAGE_COUNT * PAGE_SIZE len)
return -EIO;
pgprot_noncached(vma-vm_page_prot);
//vma-vm_flags |= VM_NONCACHED | VM_RESERVED;
vma-vm_flags |= VM_RESERVED;
/* map the physical area into one buffer */
rc = remap_pfn_range(vma, vma-vm_start,
virt_to_phys( (void*)km.pal)PAGE_SHIFT,
len,
vma-vm_page_prot);
MDEBUG(Mapped %ld bytes at virt address 0x%lx to mapper file
descriptor...\n, len, vma-vm_start);
/* return an error to the caller if remap fails */
return (rc 0 ? rc : 0);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] sound: remove driver_data direct access of struct device
From: Greg Kroah-Hartman gre...@suse.de
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Cc: Takashi Iwai ti...@suse.de
Cc: Jaroslav Kysela pe...@perex.cz
Cc: linuxppc-dev@ozlabs.org
Cc: Johannes Berg johan...@sipsolutions.net
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood l...@slimlogic.co.uk
Cc: Philipp Zabel philipp.za...@gmail.com
Cc: Jean Delvare kh...@linux-fr.org
Cc: Timur Tabi ti...@freescale.com
CC: Ian Molton i...@mnementh.co.uk
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
sound/aoa/fabrics/layout.c |8
sound/aoa/soundbus/i2sbus/core.c |8
sound/soc/codecs/wm8400.c|4 ++--
sound/soc/codecs/wm8731.c|4 ++--
sound/soc/codecs/wm8753.c|4 ++--
5 files changed, 14 insertions(+), 14 deletions(-)
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -1037,7 +1037,7 @@ static int aoa_fabric_layout_probe(struc
}
ldev-selfptr_headphone.ptr = ldev;
ldev-selfptr_lineout.ptr = ldev;
- sdev-ofdev.dev.driver_data = ldev;
+ dev_set_drvdata(sdev-ofdev.dev, ldev);
list_add(ldev-list, layouts_list);
layouts_list_items++;
@@ -1081,7 +1081,7 @@ static int aoa_fabric_layout_probe(struc
static int aoa_fabric_layout_remove(struct soundbus_dev *sdev)
{
- struct layout_dev *ldev = sdev-ofdev.dev.driver_data;
+ struct layout_dev *ldev = dev_get_drvdata(sdev-ofdev.dev);
int i;
for (i=0; iMAX_CODECS_PER_BUS; i++) {
@@ -1114,7 +1114,7 @@ static int aoa_fabric_layout_remove(stru
#ifdef CONFIG_PM
static int aoa_fabric_layout_suspend(struct soundbus_dev *sdev, pm_message_t
state)
{
- struct layout_dev *ldev = sdev-ofdev.dev.driver_data;
+ struct layout_dev *ldev = dev_get_drvdata(sdev-ofdev.dev);
if (ldev-gpio.methods ldev-gpio.methods-all_amps_off)
ldev-gpio.methods-all_amps_off(ldev-gpio);
@@ -1124,7 +1124,7 @@ static int aoa_fabric_layout_suspend(str
static int aoa_fabric_layout_resume(struct soundbus_dev *sdev)
{
- struct layout_dev *ldev = sdev-ofdev.dev.driver_data;
+ struct layout_dev *ldev = dev_get_drvdata(sdev-ofdev.dev);
if (ldev-gpio.methods ldev-gpio.methods-all_amps_off)
ldev-gpio.methods-all_amps_restore(ldev-gpio);
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -358,14 +358,14 @@ static int i2sbus_probe(struct macio_dev
return -ENODEV;
}
- dev-ofdev.dev.driver_data = control;
+ dev_set_drvdata(dev-ofdev.dev, control);
return 0;
}
static int i2sbus_remove(struct macio_dev* dev)
{
- struct i2sbus_control *control = dev-ofdev.dev.driver_data;
+ struct i2sbus_control *control = dev_get_drvdata(dev-ofdev.dev);
struct i2sbus_dev *i2sdev, *tmp;
list_for_each_entry_safe(i2sdev, tmp, control-list, item)
@@ -377,7 +377,7 @@ static int i2sbus_remove(struct macio_de
#ifdef CONFIG_PM
static int i2sbus_suspend(struct macio_dev* dev, pm_message_t state)
{
- struct i2sbus_control *control = dev-ofdev.dev.driver_data;
+ struct i2sbus_control *control = dev_get_drvdata(dev-ofdev.dev);
struct codec_info_item *cii;
struct i2sbus_dev* i2sdev;
int err, ret = 0;
@@ -407,7 +407,7 @@ static int i2sbus_suspend(struct macio_d
static int i2sbus_resume(struct macio_dev* dev)
{
- struct i2sbus_control *control = dev-ofdev.dev.driver_data;
+ struct i2sbus_control *control = dev_get_drvdata(dev-ofdev.dev);
struct codec_info_item *cii;
struct i2sbus_dev* i2sdev;
int err, ret = 0;
--- a/sound/soc/codecs/wm8400.c
+++ b/sound/soc/codecs/wm8400.c
@@ -1473,8 +1473,8 @@ static int wm8400_codec_probe(struct pla
codec = priv-codec;
codec-private_data = priv;
- codec-control_data = dev-dev.driver_data;
- priv-wm8400 = dev-dev.driver_data;
+ codec-control_data = dev_get_drvdata(dev-dev);
+ priv-wm8400 = dev_get_drvdata(dev-dev);
ret = regulator_bulk_get(priv-wm8400-dev,
ARRAY_SIZE(power), power[0]);
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -666,14 +666,14 @@ static int __devinit wm8731_spi_probe(st
codec-hw_write = (hw_write_t)wm8731_spi_write;
codec-dev = spi-dev;
- spi-dev.driver_data = wm8731;
+ dev_set_drvdata(spi-dev, wm8731);
return wm8731_register(wm8731);
}
static int __devexit wm8731_spi_remove(struct spi_device *spi)
{
- struct wm8731_priv *wm8731 = spi-dev.driver_data;
+ struct wm8731_priv *wm8731 = dev_get_drvdata(spi-dev);
Re: [PATCH] sound: remove driver_data direct access of struct device
On Mon, May 04, 2009 at 01:19:36PM -0700, Greg Kroah-Hartman wrote: From: Greg Kroah-Hartman gre...@suse.de In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: Takashi Iwai ti...@suse.de Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sound: remove driver_data direct access of struct device
On Mon, May 04, 2009 at 09:34:10PM +0100, Mark Brown wrote: On Mon, May 04, 2009 at 01:19:36PM -0700, Greg Kroah-Hartman wrote: From: Greg Kroah-Hartman gre...@suse.de In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: Takashi Iwai ti...@suse.de Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Thanks, added it to the patch. greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 9/9] spi_mpc8xxx: s/83xx/8xxx/g
On Fri, 1 May 2009 03:48:33 +0400
Anton Vorontsov avoront...@ru.mvista.com wrote:
Since we renamed the file, we might want to rename the file
internals too.
Though we don't bother with changing platform driver name and
platform module alias. The stuff is legacy and hopefully we'll
remove it soon.
but but but
-static struct of_platform_driver of_mpc83xx_spi_driver = {
- .name = mpc83xx_spi,
- .match_table= of_mpc83xx_spi_match,
- .probe = of_mpc83xx_spi_probe,
- .remove = __devexit_p(of_mpc83xx_spi_remove),
+static struct of_platform_driver of_mpc8xxx_spi_driver = {
+ .name = mpc8xxx_spi,
+ .match_table= of_mpc8xxx_spi_match,
+ .probe = of_mpc8xxx_spi_probe,
+ .remove = __devexit_p(of_mpc8xxx_spi_remove),
};
It _did_ change the platform driver name, didn't it?
This patch series had quite a lot of conflicts with the already-pending
spi-move-common-spi_setup-functionality-into-core.patch
spi-move-more-spi_setup-functionality-into-core.patch
which I beleive I successfully fixed up.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] Some work for spi_mpc83xx driver, spi-mmc support for MPC8610HPCD
On Fri, 1 May 2009 03:47:39 +0400 Anton Vorontsov avoront...@ru.mvista.com wrote: Here are few patches that are needed to support spi-mmc slot on MPC8610HPCD PowerPC boards: [1/9] spi_mpc83xx: Handles other Freescale processors [2/9] spi_mpc83xx: Quieten down the Requested speed is too low message [3/9] spi_mpc83xx: Add small delay after asserting chip-select line [4/9] powerpc/86xx: Add MMC SPI support for MPC8610HPCD boards Some or all of these seem appropriate to 2.6.30 and perhaps even -stable? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Need a patch tested on a windtunnel powermac
On Thu, 30 Apr 2009 09:30:59 +1000 Paul Mackerras pau...@samba.org wrote: Does anyone here still have a windtunnel powermac (PowerMac3,6) machine running Linux? We need someone to test Jean Delvare's patch to the therm_windtunnel driver. The patch is at: http://patchwork.ozlabs.org/patch/26095/ I don't have a windtunnel machine myself - I have a PowerMac3,5 but not a PowerMac3,6. I have a dual-G4 MDD (/proc/cpuinfo says PowerMac3,6). On: Linux Jay 2.6.30-rc4 #1 SMP Sun May 3 16:20:08 CEST 2009 ppc 7455, altivec supported PowerMac3,6 GNU/Linux plus the patch above seems working fine as usual: temperature reports are written in the logs and fan speed changes correctly. therm_windtunnel is not compiled as module. I tested it for a few hours only. -- Giuliano. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/13] OF device tree handling of PHY drivers
On Mon, Apr 27, 2009 at 11:17:08AM -0600, Grant Likely wrote: Kumar, David has pulled my phylib changes into his -next tree. However, some of the driver changes have been compile tested only due to lack of hardware. Who can I ask to test the changes to the following files? arch/powerpc/platforms/82xx/ep8248e.c |9 +- Tested OK. drivers/net/fs_enet/fs_enet-main.c| 69 +-- drivers/net/fs_enet/mii-bitbang.c | 29 +- Tested OK on pq2fads. drivers/net/fs_enet/mii-fec.c | 26 +- Tested on ep88xc. No *new* problems. :-P -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MSR_SPE - being turned off...
I have both a MPC8548 SBC and MPC8572 system that are running different flavors of the same Linux - 2.6.23. I explicitly am turning it on very early on. Later, I have an application that is compiled with SPE instructions (e.g.: evstdd) , and there is where the problems happen. If I explicitly make sure there are NO SPE instructions in the application, nothing bad happens! I am polling the MSR - and it seems the SPE is turned OFF? What have I done wrong and/or has there been fixes in later kernels that I should be aware of that might help this issue? Tom Morrison Principal Software Engineer EMPIRIX 20 Crosby Drive - Bedford, MA 01730 p: 781.266.3567 f: 781.266.3670 email: tmorri...@empirix.com mailto:tmorri...@empirix.com www.empirix.com http://www.empirix.com/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 9/9] spi_mpc8xxx: s/83xx/8xxx/g
On Mon, May 04, 2009 at 01:53:27PM -0700, Andrew Morton wrote:
On Fri, 1 May 2009 03:48:33 +0400
Anton Vorontsov avoront...@ru.mvista.com wrote:
Since we renamed the file, we might want to rename the file
internals too.
Though we don't bother with changing platform driver name and
platform module alias. The stuff is legacy and hopefully we'll
remove it soon.
but but but
-static struct of_platform_driver of_mpc83xx_spi_driver = {
- .name = mpc83xx_spi,
- .match_table= of_mpc83xx_spi_match,
- .probe = of_mpc83xx_spi_probe,
- .remove = __devexit_p(of_mpc83xx_spi_remove),
+static struct of_platform_driver of_mpc8xxx_spi_driver = {
+ .name = mpc8xxx_spi,
+ .match_table= of_mpc8xxx_spi_match,
+ .probe = of_mpc8xxx_spi_probe,
+ .remove = __devexit_p(of_mpc8xxx_spi_remove),
};
It _did_ change the platform driver name, didn't it?
This is an OF platform driver, here it is safe to change
the name. But I didn't change the pure platform driver,
here:
| -static struct platform_driver mpc83xx_spi_driver = {
| - .probe = plat_mpc83xx_spi_probe,
| - .remove = __exit_p(plat_mpc83xx_spi_remove),
| +static struct platform_driver mpc8xxx_spi_driver = {
| + .probe = plat_mpc8xxx_spi_probe,
| + .remove = __exit_p(plat_mpc8xxx_spi_remove),
| .driver = {
| .name = mpc83xx_spi,
--^
This patch series had quite a lot of conflicts with the already-pending
spi-move-common-spi_setup-functionality-into-core.patch
spi-move-more-spi_setup-functionality-into-core.patch
which I beleive I successfully fixed up.
Thanks a lot, I'll test it soon.
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] Some work for spi_mpc83xx driver, spi-mmc support for MPC8610HPCD
On Mon, May 04, 2009 at 01:55:04PM -0700, Andrew Morton wrote: On Fri, 1 May 2009 03:47:39 +0400 Anton Vorontsov avoront...@ru.mvista.com wrote: Here are few patches that are needed to support spi-mmc slot on MPC8610HPCD PowerPC boards: [1/9] spi_mpc83xx: Handles other Freescale processors [2/9] spi_mpc83xx: Quieten down the Requested speed is too low message [3/9] spi_mpc83xx: Add small delay after asserting chip-select line [4/9] powerpc/86xx: Add MMC SPI support for MPC8610HPCD boards Some or all of these seem appropriate to 2.6.30 and perhaps even -stable? I'd say no, we don't need the fixes for MPC8323E-RDB boards (currently the only mainline user of that driver), and support for MPC8610HPCD boards is a new feature, so I think all these patches can wait for 2.6.31. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch] powerpc/cell: make ptcal more reliable
Hi Gerhard,
This is for QS21. The following patch allocates pages only from
the specified node, moves the ptcal area into the middle of the
allocated page to avoid potential prefetch problems and prints
the address of the ptcal area to facilitate diagnostics.
You're seeing prefetches that cross a page boundary?
- area-pages = alloc_pages_node(area-nid, GFP_KERNEL, area-order);
+ area-pages = alloc_pages_node(area-nid, GFP_KERNEL |
GFP_THISNODE, area-order);
Best to keep this under 80 cols.
- if (!area-pages)
+ if (!area-pages) {
+ printk(KERN_INFO %s: no page on node %d\n,
+ __FUNCTION__, area-nid);
goto out_free_area;
+ }
That could probably be a KERN_ERR, as we don't have ptcal enabled on
that node. Also, I believe __func__ is preferred over __FUNCTION__.
- addr = __pa(page_address(area-pages));
+ /*
+ * We move the ptcal area to the middle of the allocated
+ * page, in order to avoid prefetches in memcpy and similar
+ * functions stepping on it.
+ */
+ addr = __pa(page_address(area-pages)) + (PAGE_SIZE 1);
Minor nitpick, but I think (PAGE_SIZE / 2) better illustrates that
you're putting the addr in the middle of the page. But either should be
fine.
+ printk(KERN_INFO %s: enabling PTCAL on node %d address=0x%016lx
PAGE_SIZE1=0x%016lx \n,
+ __FUNCTION__, area-nid, addr, PAGE_SIZE1);
80 cols again. Can we do this as a pr_debug?
Cheers,
Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/13] OF device tree handling of PHY drivers
On Mon, May 4, 2009 at 5:14 PM, Scott Wood scottw...@freescale.com wrote: On Mon, Apr 27, 2009 at 11:17:08AM -0600, Grant Likely wrote: Kumar, David has pulled my phylib changes into his -next tree. However, some of the driver changes have been compile tested only due to lack of hardware. Who can I ask to test the changes to the following files? arch/powerpc/platforms/82xx/ep8248e.c | 9 +- Tested OK. drivers/net/fs_enet/fs_enet-main.c | 69 +-- drivers/net/fs_enet/mii-bitbang.c | 29 +- Tested OK on pq2fads. drivers/net/fs_enet/mii-fec.c | 26 +- Tested on ep88xc. No *new* problems. :-P Awesome! Thanks Scott. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a few things still for .30 for you to merge ! Cheers, Ben. The following changes since commit 091438dd5668396328a3419abcbc6591159eb8d1: Linus Torvalds (1): Linux 2.6.30-rc4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Benjamin Herrenschmidt (1): powerpc: Fix setting of oprofile cpu type Grant Likely (1): powerpc: Update MPC5xxx and Xilinx Virtex maintainer entries Michael Wolf (1): powerpc adjust oprofile_cpu_type version 3 MAINTAINERS|4 ++-- arch/powerpc/kernel/cputable.c | 15 ++- 2 files changed, 12 insertions(+), 7 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC8247 booting error
i want to mapping FIFO memory to bank 3 by configure br3 and or3 the boot info as following. in my code, i have mapped FIFO to 0xD000, then i red the value from this address. the prompts as following there is some wrong with BRx and ORx set? or something others? please give me some suggestion, thanks everyone. ## Booting image at 0040 ... Image Name: Linux-2.6.11 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:818473 Bytes = 799.3 kB Load Address: Entry Point: Verifying Checksum ... OK OK Linux version 2.6.11 (r...@localhost.localdomain) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #108 Mon May 4 22:54:23 EDT 2009 Motorola PQ2 ADS PowerPC port Built 1 zonelists Kernel command line: mem=32M console=ttyCPM0,9600 root=/dev/nfs/ rw nfsroot=192.168.0.131:/root/chengmo/fs_folder/rootfs ip=192.168.0.100:192.168.0.131:#:255.0.0.0:::off PID hash table entries: 256 (order: 8, 4096 bytes) Warning: real time clock seems stuck! Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 30632k available (1420k kernel code, 272k data, 88k init, 0k highmem) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) scheduling while atomic: swapper/0x0002/0 Call trace: [c015fe20] [c0003fe0] [c01a09b4] [c0194614] [35fc] NET: Registered protocol family 16 Sauce : fifo mapping to bank3 ! // here, indicate has enter fifo_init function, but after this... Oops: kernel access of bad area, sig: 11 [#1] PREEMPT NIP: C01A2108 LR: C01A2104 SP: C0227FC0 REGS: c0227f10 TRAP: 0300Not tainted MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: D000, DSISR: 2000 TASK = c0220ab0[1] 'swapper' THREAD: c0226000 Last syscall: 120 GPR00: C01A2104 C0227FC0 C0220AB0 0025 0467 F0A0 0022 GPR08: 001FF1A0 D000 F0A8 C0227ED0 0001 7FBD 0200 GPR16: 0080 01FFF9E8 007FFF00 01FFA4DC 01BD92B8 0001 GPR24: 0040 C01B C016 C01A 0001 C0226000 C01A86A8 Call trace: [c0003a40] [c0006504] Kernel panic - not syncing: Attempted to kill init! here, i have other questions about these information. what dose mean by NIP : C01A2108 ? i supposed C01A2108 may be a address of user space, what about NIP ? and what the expression DAR, DSISR, TASK, and GPR00-24 represent. i hope some will let me know those or recommand some book for me. thanks -- View this message in context: http://www.nabble.com/PPC8247-booting-error-tp23381214p23381214.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
