* [UPDATED] Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-05 5:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
to receive the following updates:
arch/powerpc/kernel/setup-common.c | 17 +++++++++++++++++
arch/powerpc/kernel/setup.h | 2 ++
arch/powerpc/kernel/setup_32.c | 5 +++--
arch/powerpc/kernel/setup_64.c | 18 +-----------------
4 files changed, 23 insertions(+), 19 deletions(-)
Kumar Gala:
powerpc: provide ppc_md.panic() for both ppc32 & ppc64
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 684ab1d..88de557 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -524,3 +524,20 @@ int check_legacy_ioport(unsigned long ba
return ppc_md.check_legacy_ioport(base_port);
}
EXPORT_SYMBOL(check_legacy_ioport);
+
+static int ppc_panic_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ ppc_md.panic(ptr); /* May not return */
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_panic_block = {
+ .notifier_call = ppc_panic_event,
+ .priority = INT_MIN /* may not return; must be done last */
+};
+
+void __init setup_panic(void)
+{
+ atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block);
+}
diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
index 2ebba75..e67066c 100644
--- a/arch/powerpc/kernel/setup.h
+++ b/arch/powerpc/kernel/setup.h
@@ -2,5 +2,7 @@ #ifndef _POWERPC_KERNEL_SETUP_H
#define _POWERPC_KERNEL_SETUP_H
void check_for_initrd(void);
+void do_init_bootmem(void);
+void setup_panic(void);
#endif /* _POWERPC_KERNEL_SETUP_H */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 69ac257..88832b3 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -235,8 +235,6 @@ arch_initcall(ppc_init);
/* Warning, IO base is not yet inited */
void __init setup_arch(char **cmdline_p)
{
- extern void do_init_bootmem(void);
-
/* so udelay does something sensible, assume <= 1000 bogomips */
loops_per_jiffy = 500000000 / HZ;
@@ -285,6 +283,9 @@ #endif
/* reboot on panic */
panic_timeout = 180;
+ if (ppc_md.panic)
+ setup_panic();
+
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4467c49..ab6ea37 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -100,12 +100,6 @@ unsigned long SYSRQ_KEY;
#endif /* CONFIG_MAGIC_SYSRQ */
-static int ppc64_panic_event(struct notifier_block *, unsigned long, void *);
-static struct notifier_block ppc64_panic_block = {
- .notifier_call = ppc64_panic_event,
- .priority = INT_MIN /* may not return; must be done last */
-};
-
#ifdef CONFIG_SMP
static int smt_enabled_cmdline;
@@ -456,13 +450,6 @@ #endif
DBG(" <- setup_system()\n");
}
-static int ppc64_panic_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- ppc_md.panic((char *)ptr); /* May not return */
- return NOTIFY_DONE;
-}
-
#ifdef CONFIG_IRQSTACKS
static void __init irqstack_early_init(void)
{
@@ -517,8 +504,6 @@ static void __init emergency_stack_init(
*/
void __init setup_arch(char **cmdline_p)
{
- extern void do_init_bootmem(void);
-
ppc64_boot_msg(0x12, "Setup Arch");
*cmdline_p = cmd_line;
@@ -535,8 +520,7 @@ void __init setup_arch(char **cmdline_p)
panic_timeout = 180;
if (ppc_md.panic)
- atomic_notifier_chain_register(&panic_notifier_list,
- &ppc64_panic_block);
+ setup_panic();
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
^ permalink raw reply related
* Re: [PATCH 07/13] powerpc: export symbols for page size selection
From: Paul Mackerras @ 2006-05-05 5:56 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20060429233921.099214000@localhost.localdomain>
Arnd Bergmann writes:
> We need access to some symbols in powerpc memory management
> from spufs in order to create proper SLB entries.
I don't like exporting low-level implementation details like this, and
it seems a bit bogus to have an SLB miss handler in a module. Could
you move the SLB miss handler to the non-modular part?
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH 04/13] cell: remove broken __setup_cpu_be function
From: Paul Mackerras @ 2006-05-05 6:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20060429233920.295209000@localhost.localdomain>
Arnd Bergmann writes:
> From: Geoff Levand <geoffrey.levand@am.sony.com>
>
> This patch removes the incorrect Cell processor setup routine
> __setup_cpu_be. This routine improperly accesses the hypervisor
> page size configuration at SPR HID6. The correct behavior is for
> firmware, or if needed, platform setup code, to set the correct
> page size.
> - .cpu_setup = __setup_cpu_be,
> + .cpu_setup = __setup_cpu_power4,
That looks a bit dodgy. Either just remove the contents of
__setup_cpu_be (leaving only the blr), or define a __setup_cpu_null
that does nothing, or make the identify_cpu not call the cpu setup
function if the pointer is NULL.
Paul.
^ permalink raw reply
* Bad page state in process 'swapper'
From: Richard Guinto @ 2006-05-05 8:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: argie_guinto
Hi,
I'm quoting here Grant's answer:
*****************************************
On 4/11/06, Vincent Winstead <vwinstead at yahoo.com>
wrote:
>
> I'm having a real difficulty trying to get linux
onto this board. So I'm
> finally turning to the community for help. The only
people that have
> documented their approach to putting open source
linux onto the ML310 board
> have used bitkeeper to download the kernel for the
project, but bitkeeper
> isn't used any more is it? I've been going straight
to kernel.org and
> getting kernels from there and crosscompiling them
on my machine to be
> transported to the ppc core on the ML310. Is this
wrong? Is there a patch
> or some kernel source that I don't know about for
PPC? Thanks!
Are you using 2.4 or 2.6?
Support for the ML300 & ML403 is in the mainline 2.6
git tree. As
long as you've got an xparameters.h file for your FPGA
bitstream, you
should be able to port a 2.6 kernel really easily.
If you want to use 2.4, you can pull the linuxppc
rsync mirror which
has ML300 support in it.
http://www.penguinppc.org/kernel/ (Look at the very
bottom of the
page for the RSYNC mirror)
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
*****************************************************
After changing the xparameters.h, I was able to boot
with the 2.6.16.13 kernel, which I got from
kernel.org, but then I'm having a "bad page" problem
as shown in the output below:
loaded at: 00400000 006011A0
board data at: 005FF124 005FF1A0
relocated to: 004051B4 00405230
zimage at: 0040592D 00495B48
initrd at: 00496000 005FEE44
avail ram: 00602000 04000000
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.16.13 (root@rgdev) (gcc version
3.4.1) #19 Fri May 5 13:39:53 PHT 2006
Xilinx Virtex-II Pro port
Port by MontaVista Software, Inc. (source@mvista.com)
Built 1 zonelists
Kernel command line: console=ttyS0,9600
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
PID hash table entries: 512 (order: 9, 8192 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4,
65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768
bytes)
Memory: 62060k available (908k kernel code, 364k data,
64k init, 0k highmem)
Bad page state in process 'swapper'
page:c01539c0 flags:0x00000080 mapping:00000000
mapcount:0 count:1
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[C012DDF0] [C00094B4] show_stack+0x58/0x180
(unreliable)
[C012DE20] [C00452EC] bad_page+0x5c/0xa0
[C012DE40] [C0045DD0]
get_page_from_freelist+0x2cc/0x454
[C012DE90] [C0045FAC] __alloc_pages+0x54/0x278
[C012DED0] [C005869C] cache_alloc_refill+0x2e0/0x53c
[C012DF10] [C0058398] kmem_cache_alloc+0x50/0x74
[C012DF30] [C00594A8] kmem_cache_create+0x3a0/0x508
[C012DFA0] [C013846C] kmem_cache_init+0x180/0x3a0
[C012DFD0] [C012E5E4] start_kernel+0x138/0x1a4
[C012DFF0] [C000225C] start_here+0x44/0xb0
Now, I tried to debug the functions in the call trace,
and it seems that the prep_new_page function calls the
bad_page because the test for page_count(page) != 0 is
TRUE (count value is 1).
I know that the hardware or the memory is working
because I have 2.4.20 running. What could probably
cause this problem? Is there a patch for ml300
available to fix this?
Many thanks!!!
*
Richard
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: Gautam Borad @ 2006-05-05 8:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060504144605.B18B3353BE7@atlas.denx.de>
Wolfgang Denk wrote:
>In message <4459B1CF.60909@eisodus.com> you wrote:
>
>
>>We are having a frequent sig 11 problem on our custom mpc852t board
>>with linux kernel 2.6.14 and U-boot version 1.1.3
>>
>>
>That's a FAQ.
>
>
>
>>I had the same problem with 2.4 kernel and after posting the problem
>>
>>
>This confirms that the FAQ matches your problem. See
>http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly
>
>
>
Thanks for the reply. We have checked the cpu sdram settings and would
re-check the sdram initialization sequence.
However the problem faced is following:
The sig. 11 is generated at a specific instance of accessing memory
areas in
range of 0x00000024 - 0x000000C8 (i.e low address range).
AFAIK this is assigned to kernel area.
We have a ptrintk in arch/ppc/mm/fault.c which shows the frequent page
fault
and its recovery from the fault, however as soon as the DAR loads
0x00000024
or such low address we get a sig. 11.
Bad emulation malloctest/657
NIP: 30000c10 instruction: 00000000 opcode: 0 A: 0 B: 0 C: 0 code: 0 rc: 0
pte @ 0x30000c10: (0xc1d3b300)->(0xc020f000)->0x01c2b889
RPN: 01c2b PP: 2 SPS: 1 SH: 0 CI: 0 v: 1
Kernel VA for NIP c1c2bc10 pte @ 0xc1c2bc10: no pmd
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C00286C8 LR: C0186684 SP: C02CDCA0 REGS: c02cdbf0 TRAP: 0300 Not
tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: C2000000
<======== here the DAR is 0x00000000
TASK = c1d0e070[657] 'malloctest' THREAD: c02cc000
We have tested the SDRAM in both U-boot (mtest) and linux, and the tests
doesnt show anything
wrong with the SDRAM.
thanks in advance.
^ permalink raw reply
* Re: [PATCH 07/13] powerpc: export symbols for page size selection
From: Arnd Bergmann @ 2006-05-05 9:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <17498.59681.133131.336680@cargo.ozlabs.ibm.com>
On Friday 05 May 2006 07:56, Paul Mackerras wrote:
> I don't like exporting low-level implementation details like this, and
> it seems a bit bogus to have an SLB miss handler in a module. Could
> you move the SLB miss handler to the non-modular part?
Yes. The series already has the patches to move the SLB miss handler
into the built-in parts. At the moment, we also need the symbols for
the context switch code that also touches the SLB entries. We already
have a patch to move that as well, but are still discussing the details
of that.
I'll follow up with a patch to replace this one.
Arnd <><
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: Wolfgang Denk @ 2006-05-05 9:40 UTC (permalink / raw)
To: Gautam Borad; +Cc: linuxppc-embedded
In-Reply-To: <445B1019.9010103@eisodus.com>
In message <445B1019.9010103@eisodus.com> you wrote:
>
...
> We have tested the SDRAM in both U-boot (mtest) and linux, and the tests
> doesnt show anything
> wrong with the SDRAM.
No, of course not. Please read the FAQ to understand why standard RAM
tests will never detect this type of problem.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Here is an Appalachian version of management's answer to those who
are concerned with the fate of the project: "Don't worry about the
mule. Just load the wagon." - Mike Dennison's hillbilly uncle
^ permalink raw reply
* Some issues while booting the 2.6.13.4 kernel on PPC440GR with CMD649 IDE
From: vinay hegde @ 2006-05-05 11:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am porting the 2.6.13.4 kernel to PPC440GR board.
When I try to boot the kernel with CMD649 IDE support
enabled, I get kernel panic. Without CMD649, the
kernel boots just fine.
I read the PCI config space from the driver (inside
do_ide_setup_pci_device function) and verified that
DEVICE id,VENDOR id and interrupt lines are correct.
However, bar address does not seem to be correct
(actual phy and virtual set while PCI bridge config is
0xa0000000). Below is the kernel boot log for
reference:
>>>>>>>>>>>>>>>>>
..........
..........
ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
CMD649: IDE controller at PCI slot 0000:00:0c.0
CMD649: chipset revision 1
CMD649: 100% native mode on irq 25
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR=
0x360eff98
POB0: BEAR=0xc27e3194fefcfc9f BESR0=0x00000000
BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000000 LR: C0106024 SP: C1981EC0 REGS: c026af50
TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = c1134b10[1] 'swapper' THREAD: c1980000
Last syscall: 120
GPR00: FDFFEFD2 C1981EC0 C1134B10 00000000 00000060
FDFEE004 00000002 C1981EA8
GPR08: 00000000 C0270000 00000008 FDFEE004 00000000
30000000 C0277CB0 C0277CB0
GPR16: C0277CB0 00000019 00000000 C0277CB0 C0277CB0
C1130000 C1981F58 C1130000
GPR24: C0265A2A C1130000 00000000 0000FFD0 C0265A08
40000000 C0277CB0 C0277CB0
NIP [00000000] 0x0
LR [c0106024] ide_pci_setup_ports+0x61c/0x71c
Call trace:
[c010633c] do_ide_setup_pci_device+0x218/0x464
[c01065a8] ide_setup_pci_device+0x20/0x9c
[c02298d0] cmd64x_init_one+0x24/0x34
[c022a2f0] ide_scan_pcidev+0x80/0xc4
[c022a360] ide_scan_pcibus+0x2c/0xf8
[c022a24c] ide_init+0x58/0x7c
[c0001868] init+0x7c/0x2cc
[c0004b90] kernel_thread+0x48/0x64
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR=
0x360eff98
POB0: BEAR=0xc27e3194fefcfc9f BESR0=0x00000000
BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C00028DC SP: C026AE70 REGS: c026af50
TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = c1134b10[1] 'swapper' THREAD: c1980000
Last syscall: 120
GPR00: 08000000 C026AE70 C1134B10 C026AE80 00000C1B
FFFFFFFF C0270000 C01E511C
GPR08: C01E0000 C00028DC 00021002 C0003CDC C1134CD8
30000000 C0277CB0 C0277CB0
GPR16: C0277CB0 00000019 00000000 C0277CB0 C0277CB0
C1130000 C1981F58 C1130000
GPR24: C0265A2A C1130000 00000000 0000FFD0 C0265A08
40000000 C026AF50 00000007
NIP [00000000] 0x0
LR [c00028dc] ret_from_except+0x0/0x18
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
<<<<<<<<<<<<<<<<<
This is what I get when I print some PCI config space
parameters:
>>>>>>>>>>>>>
VENDOR ID: 0x1095
DEVICE ID: 0x0649
INTERRUPT LINE: 0x1C
REVISION: 0x01
BASE REG 0 is: 0x0000FFF0
BASE REG 1 is: 0x0000FFF0
BASE REG 2 is: 0x0000FFE0
BASE REG 3 is: 0x0000FFE0
<<<<<<<<<<<<
The "pci" command from u-Boot shows the following:
>>>>>>>>>>
=> pci
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class
Sub-Class
______________________________________________________00.00.00
0x1014 0x027f Bridge device 0x80
00.0c.00 0x1095 0x0649 Mass storage
controller 0x04
=>
<<<<<<<<<<
I enabled the following for CMD649 in kernel
configuration:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_IDEDMA=y
Please let me know if - anybody has seen this error
before/knows the fix for this issue.
Thanks for the help.
-Vinay.
____________________________________________________
Yahoo! India Answers: Share what you know. Learn something new. http://in.answers.yahoo.com
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Heiko J Schick @ 2006-05-05 13:05 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <adaejz9o4vh.fsf@cisco.com>
Hello Roland,
Roland Dreier wrote:
> It seems that you are deferring completion event dispatch into threads
> spread across all the CPUs. This seems like a very strange thing to
> me -- you are adding latency and possibly causing cacheline pingpong.
>
> It may help throughput in some cases to spread the work across
> multiple CPUs but it seems strange to me to do this in the low-level
> driver. My intuition would be that it would be better to do this in
> the higher levels, and leave open the possibility for protocols that
> want the lowest possible latency to be called directly from the
> interrupt handler.
We've implemented this "spread CQ callbacks across multiple CPUs"
functionality to get better throughput on a SMP system, as you have
seen.
Originaly, we had the same idea as you mentioned, that it would be better
to do this in the higher levels. The point is that we can't see so far
any simple posibility how this can done in the OpenIB stack, the TCP/IP
network layer or somewhere in the Linux kernel.
For example:
For IPoIB we get the best throughput when we do the CQ callbacks on
different CPUs and not to stay on the same CPU.
In other papers and slides (see [1]) you can see similar approaches.
I think such one implementation or functionality could require more
or less a non-trivial changes. This could be also releated to other
I/O traffic.
[1]: Speeding up Networking, Van Jacobson and Bob Felderman,
http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf
Regards,
Heiko
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: Gautam Borad @ 2006-05-05 14:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060505094007.0F169353AD3@atlas.denx.de>
Wolfgang Denk wrote:
>No, of course not. Please read the FAQ to understand why standard RAM
>tests will never detect this type of problem.
>
>Best regards,
>
>Wolfgang Denk
>
>
>
Thanks for the reply.
We are aware that its a FAQ and we rechecked the SDRAM configuration,
everything seems fine.
We disabled burst mode and tried but that didnt help. Now we want to
disable cache and check.
Is the cache disabled from u-boot or linux? Where do we have to modify
the code to disable
the cache completely. Basically we want to run the linux without using
cache.
regards,
gautam.
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Chris Dumoulin @ 2006-05-05 13:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0605041304q695a183ao68a4720e974ad4f@mail.gmail.com>
Grant Likely wrote:
> On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>
>> I'm looking into getting a BDI 2000 so I can start stepping through and
>> see what is going on.
>>
>> I looked at the ML300 and V2Pro code in the arch/ppc/platforms/4xx
>> folder, but I did not use any of that in my code. It looks like this is
>> intended to be used with the BSP that is generated by Xilinx Platform
>> Studio. I've tried generating the BSP this way, but the generated code
>> is obviously not a complete patch to port Linux to your hardware, and I
>> figure that by the time I figure out what I do/don't have to add, I
>> might as well write the whole thing by myself. Have you had success
>> integrating the automatically generated BSP from Xilinx Platform Studio?
>
>
> No; the stuff in 2.6 is not integrated w/ platform studio. (only 2.4
> is). However, you do need to extract the xparameters.h file from the
> platform studio BSP. You can generate a Linux BSP w/o actually
> telling it where your Linux tree is. Once its generated; pull out
> xparameters.h and drop it into arch/ppc/platforms/4xx/xparameters/ in
> your source tree. Note: it's important that you generate a LINUX BSP;
> not a 'standalone' bsp. If you don't, then you'll be missing a bunch
> of #defines.
>
> Let me say that once more for clarity: The only file you need from
> platform studio is the generated xparameters.h
>
> This will give you at the very least a serial port driver. Once your
> booting with that, you can focus on other device drivers.
>
> Trust me; this is the path of far less pain.
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
>
>
I generated the xparameters_ml300.h file and built my kernel configured
for the ML300 board, but I still had the same problem. I'm wondering if
there's something in the hardware that's not being setup by u-boot as
the linux kernel expects it. I'm looking through the ML300 code in
u-boot 1.1.4 to see if can spot anything that's being done in there
that's not being done in my u-boot code. Do you have any ideas about
some hardware (or other) initialization that I could be neglecting to
do in u-boot that might cause things to hang?
On a similar note, is there any guide to porting u-boot that I could
read that would enumerate all the steps I should be taking in u-boot? I
know the README in the u-boot source basically says to browse the
mailing list (which I'm doing), read the DULG (which I've done), and
read the source (which I'm also doing), but some kind of succinct guide
would be nice, if it exists.
Cheers,
Chris
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: Mark Chambers @ 2006-05-05 14:17 UTC (permalink / raw)
To: Gautam Borad, linuxppc-embedded
In-Reply-To: <445B5A98.8020004@eisodus.com>
> We are aware that its a FAQ and we rechecked the SDRAM configuration,
> everything seems fine.
> We disabled burst mode and tried but that didnt help. Now we want to
> disable cache and check.
Another thing you can try on the 852 is to change the processor frequency
via the PLPRCR register. If slowing down the clock helps, don't assume
that you have a timing problem though - these PLL circuits are notoriously
twitchy, and it could be noise (or, more properly, resonant frequencies in
your
layout)
Mark Chambers
P.S. Hopefully you have a hardware debugger - you can halt the processor
and change this register on the fly. Same with cache - no sense compiling
these changes, just do them manually.
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Roland Dreier @ 2006-05-05 14:49 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <445B4DA9.9040601@de.ibm.com>
Heiko> Originaly, we had the same idea as you mentioned, that it
Heiko> would be better to do this in the higher levels. The point
Heiko> is that we can't see so far any simple posibility how this
Heiko> can done in the OpenIB stack, the TCP/IP network layer or
Heiko> somewhere in the Linux kernel.
Heiko> For example: For IPoIB we get the best throughput when we
Heiko> do the CQ callbacks on different CPUs and not to stay on
Heiko> the same CPU.
So why not do it in IPoIB then? This approach is not optimal
globally. For example, uverbs event dispatch is just going to queue
an event and wake up the process waiting for events, and doing this on
some random CPU not related to the where the process will run is
clearly the worst possible way to dispatch the event.
Heiko> In other papers and slides (see [1]) you can see similar
Heiko> approaches.
Heiko> [1]: Speeding up Networking, Van Jacobson and Bob
Heiko> Felderman,
Heiko> http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf
I think you've misunderstood this paper. It's about maximizing CPU
locality and pushing processing directly into the consumer. In the
context of slide 9, what you've done is sort of like adding another
control loop inside the kernel, since you dispatch from interrupt
handler to driver thread to final consumer. So I would argue that
your approach is exactly the opposite of what VJ is advocating.
- R.
^ permalink raw reply
* Re: [PATCH] powermac: U4 DART improvements
From: Johannes Berg @ 2006-05-05 14:56 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060430191430.GU5518@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 171 bytes --]
> This boots happily on my quad at home,
Boots fine on my quad and seems to survive a bunch of normal tasks.
Haven't gotten to do any benchmarking yet.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Calculating virtual address from physical address
From: Chris Dumoulin @ 2006-05-05 15:08 UTC (permalink / raw)
To: linuxppc-embedded
I'm using a Virtex II Pro-based board with a PPC405. The board is
hanging somewhere very early in the kernel boot process. I believe it
may be dying at the point where the MMU is enabled. In order to
determine the exact point at which my board hangs, I'm blinking two LEDs
in the assembly code found in arch/ppc/kernel/head_4xx.S, . Currently I
am only able to successfully access the LEDs before the MMU is turned
on, but I can't be sure that I'm calculating the virtual address
properly when I try to access the LED after the MMU is turned on.
My LEDs are at address 0x4F600000 and my CONFIG_KERNEL_START is
0xC0000000. If this address were low enough, I would just add 0xC0000000
to the address to get the virtual address, but since my LED address is
so high, the sum will be well past the 32-bit maximum address value. How
is a virtual address calculated for a high address like 0x4F600000?
BTW, he is the assembly code that I'm working with (from
arch/ppc/kernel/head_4xx.S):
.text
_GLOBAL(_stext)
_GLOBAL(_start)
/* Save parameters we are passed.
*/
mr r31,r3
mr r30,r4
mr r29,r5
mr r28,r6
mr r27,r7
/* CRD: set LED state here */
lis r26,0x4F600000@h
ori r26,r26,0x4F600000@l
li r25,LED_STATE_0
stw r25,0(r26)
/* We have to turn on the MMU right away so we get cache modes
* set correctly.
*/
bl initial_mmu
/* CRD: set LED state here */
lis r26,0x4F600000@h
ori r26,r26,0x4F600000@l
li r25,LED_STATE_1
stw r25,0(r26)
/* We now have the lower 16 Meg mapped into TLB entries, and the caches
* ready to work.
*/
turn_on_mmu:
lis r0,MSR_KERNEL@h
ori r0,r0,MSR_KERNEL@l
mtspr SPRN_SRR1,r0
lis r0,start_here@h
ori r0,r0,start_here@l
mtspr SPRN_SRR0,r0
SYNC
/* CRD: set LED state here */
lis r26,0x4F600000@h
ori r26,r26,0x4F600000@l
li r25,LED_STATE_2
stw r25,0(r26)
rfi /* enables MMU */
/* CRD: set LED state here */
/* This address should be a virtual address */
lis r26,0x4F600000@h
ori r26,r26,0x4F600000@l
li r25,LED_STATE_3
stw r25,0(r26)
b . /* prevent prefetch past rfi */
Regards,
Chris Dumoulin
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Grant Likely @ 2006-05-05 15:31 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <445B5597.9010801@ics-ltd.com>
On 5/5/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I generated the xparameters_ml300.h file and built my kernel configured
> for the ML300 board, but I still had the same problem. I'm wondering if
> there's something in the hardware that's not being setup by u-boot as
> the linux kernel expects it. I'm looking through the ML300 code in
> u-boot 1.1.4 to see if can spot anything that's being done in there
> that's not being done in my u-boot code. Do you have any ideas about
> some hardware (or other) initialization that I could be neglecting to
> do in u-boot that might cause things to hang?
Probably not; The nice thing about the V2Pro is that there is pretty
much no setup that needs to be done. The bitstream takes care of
configuring SDRAM. :). For my daily work; I don't even use u-boot.=20
I'm downloading a zImage directly through my BDI 2000. (But u-boot
does work for me too)
Can you post your xparameters file? (Or email it to me directly)
Are you using a full UART or UART lite?
> On a similar note, is there any guide to porting u-boot that I could
> read that would enumerate all the steps I should be taking in u-boot? I
> know the README in the u-boot source basically says to browse the
> mailing list (which I'm doing), read the DULG (which I've done), and
> read the source (which I'm also doing), but some kind of succinct guide
> would be nice, if it exists.
Not that I know of; I had to pile throught the same stuff to learn it.
> Interactive Circuits and Systems Ltd.
> 5430 Canotek Road
> Ottawa, ON
Hey; you going to OLS this year?
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powermac: U4 DART improvements
From: Olof Johansson @ 2006-05-05 15:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, paulus
In-Reply-To: <1146840992.16487.0.camel@localhost>
On Fri, May 05, 2006 at 04:56:32PM +0200, Johannes Berg wrote:
>
> > This boots happily on my quad at home,
>
> Boots fine on my quad and seems to survive a bunch of normal tasks.
> Haven't gotten to do any benchmarking yet.
Thanks for testing. I've been running with it all week here as well. I'll
try to do some benchmarking this weekend; there are a couple of other
things that should be changed in the patch as well.
-Olof
^ permalink raw reply
* Re: Calculating virtual address from physical address
From: Sylvain Munaut @ 2006-05-05 19:27 UTC (permalink / raw)
To: Chris Dumoulin, linuxppc-embedded
In-Reply-To: <445B6A80.2090202@ics-ltd.com>
Chris Dumoulin wrote:
> I'm using a Virtex II Pro-based board with a PPC405. The board is
> hanging somewhere very early in the kernel boot process. I believe it
> may be dying at the point where the MMU is enabled. In order to
> determine the exact point at which my board hangs, I'm blinking two LEDs
> in the assembly code found in arch/ppc/kernel/head_4xx.S, . Currently I
> am only able to successfully access the LEDs before the MMU is turned
> on, but I can't be sure that I'm calculating the virtual address
> properly when I try to access the LED after the MMU is turned on.
Typical when trying to bring up board ...
Once the MMU is turned on, you leds register are most likely ... nowhere
... i.e.
if you don't create a mapping your self there is just no virtual address
that will
access your leds physical address.
What I did on some ppc work was tu use a quick BAT mapping to map some leds.
It's pretty easy to setup. Be aware though that this mapping will get
wiped out when
the kernel sets up the BAT for itself.
Sylvain
^ permalink raw reply
* [PATCH] ppc32 8xx: Fix r3 thrashing due to 8MB TLB page instantiation (!CONFIG_8xx_CPU6)
From: Marcelo Tosatti @ 2006-05-05 20:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: David Jander, linux-ppc-embedded
(please ignore last patch, its incomplete)
Instantiation of 8MB pages on the TLB cache for the kernel static
mapping thrashes r3 register on !CONFIG_8xx_CPU6 configurations.
Signed-off-by: Marcelo Tosatti <marcelo@kvack.org>
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index ec53c7d..09b3adc 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -355,9 +355,7 @@ #endif
. = 0x1200
DataStoreTLBMiss:
-#ifdef CONFIG_8xx_CPU6
stw r3, 8(r0)
-#endif
DO_8xx_CPU6(0x3f80, r3)
mtspr SPRN_M_TW, r10 /* Save a couple of working registers */
mfcr r10
@@ -417,9 +415,7 @@ #endif
lwz r11, 0(r0)
mtcr r11
lwz r11, 4(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is an instruction TLB error on the MPC8xx. This could be due
@@ -500,9 +496,7 @@ LoadLargeDTLB:
lwz r11, 4(r0)
lwz r12, 16(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is the data TLB error on the MPC8xx. This could be due to
^ permalink raw reply related
* Re: Calculating virtual address from physical address
From: Matt Porter @ 2006-05-05 20:24 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Chris Dumoulin, linuxppc-embedded
In-Reply-To: <445BA736.30208@246tNt.com>
On Fri, May 05, 2006 at 09:27:50PM +0200, Sylvain Munaut wrote:
> Chris Dumoulin wrote:
> > I'm using a Virtex II Pro-based board with a PPC405. The board is
> > hanging somewhere very early in the kernel boot process. I believe it
> > may be dying at the point where the MMU is enabled. In order to
> > determine the exact point at which my board hangs, I'm blinking two LEDs
> > in the assembly code found in arch/ppc/kernel/head_4xx.S, . Currently I
> > am only able to successfully access the LEDs before the MMU is turned
> > on, but I can't be sure that I'm calculating the virtual address
> > properly when I try to access the LED after the MMU is turned on.
>
> Typical when trying to bring up board ...
>
> Once the MMU is turned on, you leds register are most likely ... nowhere
> ... i.e.
> if you don't create a mapping your self there is just no virtual address
> that will
> access your leds physical address.
>
> What I did on some ppc work was tu use a quick BAT mapping to map some leds.
> It's pretty easy to setup. Be aware though that this mapping will get
> wiped out when
> the kernel sets up the BAT for itself.
There are no BATs on 4xx. However, the same conceptual thing can be
done by wiring a fixed TLB entry to cover those LEDs temporarily
during bringup debug. The temporary TLB entry will be wiped out by
normal tlb misses after things are running whenever the fixed entry
is clobbered by the round robin replacement.
-Matt
^ permalink raw reply
* Re: Calculating virtual address from physical address
From: Josh Boyer @ 2006-05-05 20:58 UTC (permalink / raw)
To: Matt Porter; +Cc: Sylvain Munaut, Chris Dumoulin, linuxppc-embedded
In-Reply-To: <20060505132441.B30563@cox.net>
On Fri, 2006-05-05 at 13:24 -0700, Matt Porter wrote:
>
> There are no BATs on 4xx. However, the same conceptual thing can be
> done by wiring a fixed TLB entry to cover those LEDs temporarily
> during bringup debug. The temporary TLB entry will be wiped out by
> normal tlb misses after things are running whenever the fixed entry
> is clobbered by the round robin replacement.
At which point you should be able to call ioremap to generate a virtual
address inside a device driver or board file.
josh
^ permalink raw reply
* Re: Calculating virtual address from physical address
From: David H. Lynch Jr. @ 2006-05-05 23:35 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <445B6A80.2090202@ics-ltd.com>
Chris Dumoulin wrote:
> My LEDs are at address 0x4F600000 and my CONFIG_KERNEL_START is
> 0xC0000000. If this address were low enough, I would just add 0xC0000000
> to the address to get the virtual address, but since my LED address is
> so high, the sum will be well past the 32-bit maximum address value. How
> is a virtual address calculated for a high address like 0x4F600000?
>
There are macros tophys and tovirt that convert addresses between
physical and virtual. There are use example in the head_4xx.S file you
are already in.
If you are going to use a port for debugging you need to create a
tlb entry for it.
Same file in initial_mmu the code inside the if
defined(CONFIG_SERIAL_TEXT_DEBUG) should provide an example how to do that.
Be forwarned that any entries you create now will eventually
disappear (took 2 weeks to figure that out once), but that may not
happen intil after /init starts.
Also with a little of jiggering arround the bits in MSR_KERNEL you
can enable Data address translation independently of instruction address
translation as well as disable or enable a variety of
checks. It took me three weeks to get a new Xilinx V4 board through
the rfi and to start_here in the same turn_on_mmu code you are working on.
Eventually I ended up enabling the MSR bits one at a time until I
discovered that enabling the Machine Check sent me to space.
Regardless, once I relialized I could test the code with the MSR
bits enabled one at a time isolating the problem became easier.
The two issues I addressed above which relate specifically to your
efforts with the ml300, constituted more than 80% of my effort to get a
Xilinx Virtex 4 running.
Finally, I started prior to grants platform bus changes. I have been
adapting my V4 code to fit with Grants changes (the client has what they
want so they do not care)
I have not put alot of effort into this, but I currently get
waylayed much later in new platform bus specific initialization code.
I had no problem with the older board specific initialization code.
If you are running on a real ml300 I am surprised you are having any
problems though I do not have an ml300 to check that.
But if you are running on a custom V2Pro board you have to get the
board specific initalization right and therefore could trip over the
issue I am currently having migrating from old to new.
> BTW, he is the assembly code that I'm working with (from
> arch/ppc/kernel/head_4xx.S):
>
> .text
> _GLOBAL(_stext)
> _GLOBAL(_start)
>
> /* Save parameters we are passed.
> */
> mr r31,r3
> mr r30,r4
> mr r29,r5
> mr r28,r6
> mr r27,r7
>
> /* CRD: set LED state here */
> lis r26,0x4F600000@h
> ori r26,r26,0x4F600000@l
> li r25,LED_STATE_0
> stw r25,0(r26)
>
> /* We have to turn on the MMU right away so we get cache modes
> * set correctly.
> */
> bl initial_mmu
>
> /* CRD: set LED state here */
> lis r26,0x4F600000@h
> ori r26,r26,0x4F600000@l
> li r25,LED_STATE_1
> stw r25,0(r26)
>
> /* We now have the lower 16 Meg mapped into TLB entries, and the caches
> * ready to work.
> */
> turn_on_mmu:
> lis r0,MSR_KERNEL@h
> ori r0,r0,MSR_KERNEL@l
> mtspr SPRN_SRR1,r0
> lis r0,start_here@h
> ori r0,r0,start_here@l
> mtspr SPRN_SRR0,r0
> SYNC
>
> /* CRD: set LED state here */
> lis r26,0x4F600000@h
> ori r26,r26,0x4F600000@l
> li r25,LED_STATE_2
> stw r25,0(r26)
>
> rfi /* enables MMU */
>
> /* CRD: set LED state here */
> /* This address should be a virtual address */
> lis r26,0x4F600000@h
> ori r26,r26,0x4F600000@l
> li r25,LED_STATE_3
> stw r25,0(r26)
>
> b . /* prevent prefetch past rfi */
>
> Regards,
> Chris Dumoulin
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH 04/13] cell: remove broken __setup_cpu_be function
From: Geoff Levand @ 2006-05-06 0:00 UTC (permalink / raw)
To: Paul Mackerras
Cc: Arnd Bergmann, Levand, Geoffrey, linux-kernel, linuxppc-dev,
Arnd Bergmann, cbe-oss-dev
In-Reply-To: <17498.60066.92373.6527@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Arnd Bergmann writes:
>
>> From: Geoff Levand <geoffrey.levand@am.sony.com>
>>
>> This patch removes the incorrect Cell processor setup routine
>> __setup_cpu_be. This routine improperly accesses the hypervisor
>> page size configuration at SPR HID6. The correct behavior is for
>> firmware, or if needed, platform setup code, to set the correct
>> page size.
>
>> - .cpu_setup = __setup_cpu_be,
>> + .cpu_setup = __setup_cpu_power4,
>
> That looks a bit dodgy. Either just remove the contents of
> __setup_cpu_be (leaving only the blr), or define a __setup_cpu_null
> that does nothing, or make the identify_cpu not call the cpu setup
> function if the pointer is NULL.
OK, I set it up with __setup_cpu_null. An updated patch follows.
It falls out from this that we can replace the do-nothing routines
__setup_cpu_power3 and __setup_cpu_power4 with __setup_cpu_null also.
I'll post a separate patch for consideration.
-Geoff
Replaced the Cell processor specific routine __setup_cpu_be with
a new generic routine __setup_cpu_null. __setup_cpu_be improperly
accessed the hypervisor page size configuration at SPR HID6. Correct
behavior is for firmware, or if needed, platform setup code, to set
the correct page size.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Index: cell--alp--3/arch/powerpc/kernel/cpu_setup_power4.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/cpu_setup_power4.S 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/cpu_setup_power4.S 2006-05-05 15:59:58.000000000 -0700
@@ -76,20 +76,6 @@
_GLOBAL(__setup_cpu_power4)
blr
-_GLOBAL(__setup_cpu_be)
- /* Set large page sizes LP=0: 16MB, LP=1: 64KB */
- addi r3, 0, 0
- ori r3, r3, HID6_LB
- sldi r3, r3, 32
- nor r3, r3, r3
- mfspr r4, SPRN_HID6
- and r4, r4, r3
- addi r3, 0, 0x02000
- sldi r3, r3, 32
- or r4, r4, r3
- mtspr SPRN_HID6, r4
- blr
-
_GLOBAL(__setup_cpu_ppc970)
mfspr r0,SPRN_HID0
li r11,5 /* clear DOZE and SLEEP */
Index: cell--alp--3/arch/powerpc/kernel/cputable.c
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/cputable.c 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/cputable.c 2006-05-05 16:29:06.000000000 -0700
@@ -31,9 +31,9 @@
* and ppc64
*/
#ifdef CONFIG_PPC64
+extern void __setup_cpu_null(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_power3(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_power4(unsigned long offset, struct cpu_spec* spec);
-extern void __setup_cpu_be(unsigned long offset, struct cpu_spec* spec);
#else
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
@@ -273,7 +273,7 @@
PPC_FEATURE_SMT,
.icache_bsize = 128,
.dcache_bsize = 128,
- .cpu_setup = __setup_cpu_be,
+ .cpu_setup = __setup_cpu_null,
.platform = "ppc-cell-be",
},
{ /* default match */
Index: cell--alp--3/arch/powerpc/kernel/misc_64.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/misc_64.S 2006-04-26 19:19:25.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/misc_64.S 2006-05-05 16:04:59.000000000 -0700
@@ -768,6 +768,9 @@
#endif /* CONFIG_ALTIVEC */
+_GLOBAL(__setup_cpu_null)
+ blr
+
_GLOBAL(__setup_cpu_power3)
blr
^ permalink raw reply
* [patch] powerpc: remove do-nothing cpu setup routines
From: Geoff Levand @ 2006-05-06 0:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev, Arnd Bergmann
Removes the processor specific do-nothing routines __setup_cpu_power3 and
__setup_cpu_power4 with the generic routine __setup_cpu_null.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Index: cell--alp--3/arch/powerpc/kernel/cpu_setup_power4.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/cpu_setup_power4.S 2006-05-05 15:59:58.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/cpu_setup_power4.S 2006-05-05 16:40:44.000000000 -0700
@@ -73,9 +73,6 @@
isync
blr
-_GLOBAL(__setup_cpu_power4)
- blr
-
_GLOBAL(__setup_cpu_ppc970)
mfspr r0,SPRN_HID0
li r11,5 /* clear DOZE and SLEEP */
Index: cell--alp--3/arch/powerpc/kernel/cputable.c
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/cputable.c 2006-05-05 16:29:06.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/cputable.c 2006-05-05 16:40:41.000000000 -0700
@@ -32,8 +32,6 @@
*/
#ifdef CONFIG_PPC64
extern void __setup_cpu_null(unsigned long offset, struct cpu_spec* spec);
-extern void __setup_cpu_power3(unsigned long offset, struct cpu_spec* spec);
-extern void __setup_cpu_power4(unsigned long offset, struct cpu_spec* spec);
#else
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
@@ -80,7 +78,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/power3",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "power3",
@@ -94,7 +92,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/power3",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "power3",
@@ -108,7 +106,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -122,7 +120,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -136,7 +134,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -150,7 +148,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power3,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/rs64",
.oprofile_type = PPC_OPROFILE_RS64,
.platform = "rs64",
@@ -164,7 +162,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power4,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/power4",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power4",
@@ -178,7 +176,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_power4,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/power4",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power4",
@@ -244,7 +242,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/power5",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5",
@@ -258,7 +256,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
+ .cpu_setup = __setup_cpu_null,
.oprofile_cpu_type = "ppc64/power5+",
.oprofile_type = PPC_OPROFILE_POWER4,
.platform = "power5+",
@@ -285,7 +283,7 @@
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 6,
- .cpu_setup = __setup_cpu_power4,
+ .cpu_setup = __setup_cpu_null,
.platform = "power4",
}
#endif /* CONFIG_PPC64 */
Index: cell--alp--3/arch/powerpc/kernel/misc_64.S
===================================================================
--- cell--alp--3.orig/arch/powerpc/kernel/misc_64.S 2006-05-05 16:04:59.000000000 -0700
+++ cell--alp--3/arch/powerpc/kernel/misc_64.S 2006-05-05 16:40:47.000000000 -0700
@@ -771,9 +771,6 @@
_GLOBAL(__setup_cpu_null)
blr
-_GLOBAL(__setup_cpu_power3)
- blr
-
_GLOBAL(execve)
li r0,__NR_execve
sc
^ permalink raw reply
* RE: Calculating virtual address from physical address
From: Alexander Szekely @ 2006-05-06 8:43 UTC (permalink / raw)
To: linuxppc-embedded
> How is a virtual address=20
> calculated for a high address like 0x4F600000?
Add this to the MMU initialzation code (initial_mmu):
/* map leds - 1:1 phys=3Dvirt */
lis r3,0x4F600000@h
ori r3,r3,0x4F600000@l
mr r4,r3
clrrwi r4,r4,12
ori r4,r4,(TLB_WR|TLB_I|TLB_M|TLB_G)
clrrwi r3,r3,12
ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_4K))
li r0,0 /* TLB slot 0 */
tlbwe r4,r0,TLB_DATA
tlbwe r3,r0,TLB_TAG
Then you have a one to one mapping between physical and virtual memory,=20
and you can access the LEDs at the same address after turning one the
MMU.
BTW, we had a similar problem, but the reason was not turning on the
MMU. The MMU is enabled by writing MSR_KERNEL the status register. This
also enables the machine state exception interrupt.=20
Our hardware design produced PLB bus exceptions, which was unnoticed on
standalone applications. But this bus exceptions also trigger machine
state exceptions. So instead of jumping to start_here the processor
branched to 0x200 - unfortunatly the trap table is not set up at this
point in the boot process...
Alex=20
^ 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