* [PATCH] Remove obsolete #include <linux/config.h>.
From: Jon Loeliger @ 2006-06-22 18:02 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/mpc8641_hpcn.h | 1 -
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 -
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 1 -
arch/powerpc/platforms/86xx/pci.c | 1 -
include/asm-powerpc/mpc86xx.h | 1 -
5 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/mpc8641_hpcn.h b/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
index 747e549..d862a9c 100644
--- a/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
+++ b/arch/powerpc/platforms/86xx/mpc8641_hpcn.h
@@ -14,7 +14,6 @@
#ifndef __MPC8641_HPCN_H__
#define __MPC8641_HPCN_H__
-#include <linux/config.h>
#include <linux/init.h>
/* PCI-Express memory map */
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 092bca3..cf4fd04 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -12,7 +12,6 @@
* option) any later version.
*/
-#include <linux/config.h>
#include <linux/stddef.h>
#include <linux/kernel.h>
#include <linux/pci.h>
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_smp.c b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
index 944ec4b..167f040 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_smp.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
@@ -10,7 +10,6 @@
* option) any later version.
*/
-#include <linux/config.h>
#include <linux/stddef.h>
#include <linux/kernel.h>
#include <linux/init.h>
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index a03b36f..dd7e3bf 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -12,7 +12,6 @@
* option) any later version.
*/
-#include <linux/config.h>
#include <linux/types.h>
#include <linux/module.h>
#include <linux/init.h>
diff --git a/include/asm-powerpc/mpc86xx.h b/include/asm-powerpc/mpc86xx.h
index d0a6718..1ed72f6 100644
--- a/include/asm-powerpc/mpc86xx.h
+++ b/include/asm-powerpc/mpc86xx.h
@@ -15,7 +15,6 @@ #ifdef __KERNEL__
#ifndef __ASM_POWERPC_MPC86xx_H__
#define __ASM_POWERPC_MPC86xx_H__
-#include <linux/config.h>
#include <asm/mmu.h>
#ifdef CONFIG_PPC_86xx
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH] Remove redundant STD_MMU selection.
From: Jon Loeliger @ 2006-06-22 18:01 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/Kconfig | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 3d2b21a..d1ecc0f 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -29,9 +29,4 @@ config PPC_INDIRECT_PCI_BE
depends on PPC_86xx
default y
-config PPC_STD_MMU
- bool
- depends on PPC_86xx
- default y
-
endmenu
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH] Move I8259 selection under MPC8641HPCN board
From: Jon Loeliger @ 2006-06-22 18:00 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/Kconfig | 1 -
arch/powerpc/platforms/86xx/Kconfig | 1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index cdaa4b1..45043f0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -786,7 +786,6 @@ config GENERIC_ISA_DMA
config PPC_I8259
bool
- default y if MPC8641_HPCN
default n
config PPC_INDIRECT_PCI
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 3a87863..3d2b21a 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -7,6 +7,7 @@ choice
config MPC8641_HPCN
bool "Freescale MPC8641 HPCN"
+ select PPC_I8259
help
This option enables support for the MPC8641 HPCN board.
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* [PATCH] Remove redundant PPC_86XX check.
From: Jon Loeliger @ 2006-06-22 17:59 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/86xx/Makefile | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/Makefile b/arch/powerpc/platforms/86xx/Makefile
index 7be796c..476a6ee 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -2,9 +2,6 @@ #
# Makefile for the PowerPC 86xx linux kernel.
#
-
-ifeq ($(CONFIG_PPC_86xx),y)
obj-$(CONFIG_SMP) += mpc86xx_smp.o
-endif
obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
obj-$(CONFIG_PCI) += pci.o mpc86xx_pcie.o
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* Re: help to run the C code on AMCC PPC 405EP Kit
From: Olof Johansson @ 2006-06-22 17:51 UTC (permalink / raw)
To: jagadeesh kalisetty; +Cc: linuxppc-dev
In-Reply-To: <20060622171846.18376.qmail@webmail28.rediffmail.com>
Hi,
On Thu, Jun 22, 2006 at 05:18:46PM -0000, jagadeesh kalisetty wrote:
> Hi
> We are using AMCC PPC 405EP Taihu board, our aim is to run the C code on kit.
linuxppc-embedded@ozlabs.org is a better list to post your question
to. Or try contacting AMCC for documentation on how to use their kit,
since it's pretty basic stuff you're trying to get working.
Thanks,
Olof
^ permalink raw reply
* Re: Problem for "insmod: unresolved symbol printk"
From: Olof Johansson @ 2006-06-22 17:48 UTC (permalink / raw)
To: Zhou Rui; +Cc: linuxppc-dev
In-Reply-To: <20060622143156.39031.qmail@web15601.mail.cnb.yahoo.com>
On Thu, Jun 22, 2006 at 10:31:56PM +0800, Zhou Rui wrote:
> Hi, all
> I'm a newbie for linuxppc. I've tried to write a simple hello.c as a kernel module.
Hi,
http://kernelnewbies.org/ should have information on kernel module
basics, and where to find help if you still have problems.
-Olof
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Jimi Xenidis @ 2006-06-22 17:22 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060622162358.GA13300@pb15.lixom.net>
On Jun 22, 2006, at 12:23 PM, Olof Johansson wrote:
>
> Are you aware that this code runs only once per processor during
> boot (and/or during cpu hotplug)? A few extra cycles there won't kill
> anyone.
Hey, I never said it was a hot path, only that it had performance
issues.
I agree about the a "few extra cycles"
> That being said, not touching the registers makes sense, but I
> don't buy
> the performance motivation. :-)
>
>> I juts think its good practice and as Xell and newer processes come
>> along we may want to start using the PACA(?) rather then peeking at
>> the msr all the time.
>
> PACA means it's a mfspr + dependent load + test instead of mfmsr +
> mask,
> right? It'd need benchmarking on several processors to show if it's
> better or not.
>
>
> -Olof
^ permalink raw reply
* help to run the C code on AMCC PPC 405EP Kit
From: jagadeesh kalisetty @ 2006-06-22 17:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev-request
[-- Attachment #1: Type: text/plain, Size: 6869 bytes --]
Hi
We are using AMCC PPC 405EP Taihu board, our aim is to run the C code on kit. The kit already contains U-boot, linux kernel, and Ramdik images on Flash memory. We are successfully configured C-Kermit, NFS server(/opt/eldk4/ppc_4xx, /mnt/nfs-share) on host(Fedora Core 4). We are succeeded loading the files from NFS server after U-boot, but we are failed to mount the files (/mnt/nfs-share) on target after kernel booting on kit. But booth host and target are communicating after kernel booting (using ping).
We using the command to mount /mnt/nfs-share on target(Busy box 1.1.0):
target # mkdir /mnt/nfs
target # mount –t nfs 192.168.1.18:/mnt/nfs-share /mnt/nfs
error: monting 192.168.1.18:/mnt/nfs-share on /mnt/nfs : No such directory or file
Can u tell how to mount flash file system on target, using that one also we can run (bebug) the programs on kit using gdb
So we are failed to transfer any file on to the target. Is it any way to run the program on kit using host side ppc_4xx-gdb tool and target side gdbserver tool?
Is there any another way to run the code on the target or
Below is the problem we are facing while passing arguments to the kernel …….
we are expecting that there is no nfs device notice on the target, we tried different ways but we have failed to mount the root file system on linux or to mount host files on target, But we are succeeded loading the files from NFS server after U-boot
Hit any key to stop autoboot: 0
=> printenv
bootdelay=5
baudrate=9600
filesize=ebb7e5
ethaddr=50:00:00:00:25:00
eth1addr=50:00:00:00:25:01
loads_echo=1
setboot=setenv bootargs ramdisk=71800 root=/dev/ram ip=$(RT_eth0_ip)$(RT_eth0_ip2)
ethact=ppc_4xx_eth0
bootcmd=run setboot;bootm 0xfc000000 0xfc300000
kozio=bootm 0xffe00000
RT_eth0_ip=192.168.1.62
RT_eth0_ip2=:::::eth0:off
ipaddr=192.168.1.62
serverip=192.168.1.18
netmask=255.255.255.0
hostname=taihu
netdev=eth0
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 1.1.4 (Jan 19 2006 - 14:16:53)
Environment size: 722/16379 bytes
=> setenv bootargs root=/dev/nfs rw nfsroot=192.168.1.18:/opt/eldk/ppc_4xx ip=192.168.1.62:192.168.1.18::::eth0:off
=> bootm 0xfc000000
## Booting image at fc000000 ...
Image Name: Linux-2.6.13
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1121647 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.13 (root@linux_box) (gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)) #50 Tue Feb 7 09:07:24 CST 2006
AMCC PowerPC 405EP Taihu Platform
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.18:/opt/eldk/ppc_4xx ip=192.168.1.62:192.168.1.18::::eth0:off
PID hash table entries: 1024 (order: 10, 16384 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 127232k available (1916k kernel code, 452k data, 96k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 1) is a 16550A
ttyS1 at MMIO 0x0 (irq = 0) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
mal0: Initialized, 4 tx channels, 2 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
eth0: IBM emac, MAC 50:00:00:00:25:00
eth0: Found Generic MII PHY (0x14)
eth1: IBM emac, MAC 50:00:00:00:25:01
eth1: Found Generic MII PHY (0x10)
e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
taihu: bootflash mapping: 200000 at ffe00000
AMCC Taihu Boot Flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 3 MTD partitions on "AMCC Taihu Boot Flash":
0x00000000-0x001a0000 : "kozio diags"
0x001a0000-0x001c0000 : "u-boot env"
0x001c0000-0x00200000 : "u-boot"
taihu: appflash mapping: 2000000 at fc000000
AMCC Taihu Application Flash: Found 2 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
AMCC Taihu Application Flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 3 MTD partitions on "AMCC Taihu Application Flash":
0x00000000-0x00300000 : "kernel"
0x00300000-0x01d00000 : "initrd"
0x01d00000-0x02000000 : "jffs2"
Yenta: CardBus bridge found at 0000:00:07.0 [0000:0000]
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:07.0, mfunc 0x00001000, devctl 0x66
Yenta TI: socket 0000:00:07.0 probing PCI interrupt failed, trying to fix
Yenta TI: socket 0000:00:07.0 falling back to parallel PCI interrupts
Yenta TI: socket 0000:00:07.0 parallel PCI interrupts ok
eth0: Link is Up
eth0: Speed: 100, Full duplex.
Yenta: ISA IRQ mask 0x0000, PCI irq 26
Socket status: 30000087
pcmcia: parent PCI bridge I/O window: 0x0 - 0xffff
pcmcia: parent PCI bridge Memory window: 0x80000000 - 0xbfffffff
zero gadget: Gadget Zero, version: St Patrick's Day 2004
zero gadget: using pd12_udc, OUT ep1out-bulk IN ep2in-bulk
pd12_udc: registered gadget driver 'zero'
i2c /dev entries driver
IBM IIC driver v2.1
ibm-iic0: using standard (100 kHz) mode
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
eth0: Link is Up
eth0: Speed: 100, Full duplex.
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.1.62, mask=255.255.255.0, gw=255.255.255.255,
host=192.168.1.62, domain=, nis-domain=(none),
bootserver=192.168.1.18, rootserver=192.168.1.18, rootpath=
VFS: Cannot open root device "nfs" or unknown-block(0,255)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255)
<0>Rebooting in 180 seconds..
[-- Attachment #2: Type: text/html, Size: 8017 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Olof Johansson @ 2006-06-22 16:23 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <C468730C-7E39-4B17-869D-CB2BA802A709@watson.ibm.com>
On Wed, Jun 21, 2006 at 10:35:28PM -0400, Jimi Xenidis wrote:
>
> On Jun 21, 2006, at 7:58 PM, Paul Mackerras wrote:
>
> > Jimi Xenidis writes:
> >
> >> The following patch avoids accessing Hypervisor privilege HID
> >> registers when running on a Hypervisor (MSR[HV]=0).
> >
> > Why? Aren't the writes defined to be no-ops when not in hypervisor
> > mode?
>
> The write are no-ops but look at the instructions required to be
> around the write for some of them.
> I believe read may have performance issues as well.
Are you aware that this code runs only once per processor during
boot (and/or during cpu hotplug)? A few extra cycles there won't kill
anyone.
That being said, not touching the registers makes sense, but I don't buy
the performance motivation. :-)
> I juts think its good practice and as Xell and newer processes come
> along we may want to start using the PACA(?) rather then peeking at
> the msr all the time.
PACA means it's a mfspr + dependent load + test instead of mfmsr + mask,
right? It'd need benchmarking on several processors to show if it's
better or not.
-Olof
^ permalink raw reply
* Re: entry point of kernel in RAM at 0x0c--linux tree file name
From: Laurent Pinchart @ 2006-06-22 15:35 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Arun Kumar
In-Reply-To: <edd12c050606220146i57282781o2052679c8f6108ef@mail.gmail.com>
Hi Arun,
> I would like to kow what is the entry point to kernel at 0x000 after
> decompressing and passing control to 0x0c .
> My kernel crashes somewhere after uncomressing and jumping to 0x0c .
>
> If any one can help the .c /.S file that contains the source of kernel
> startup code in RAM at 0x0/0x0c .
The entry point is in arch/ppc/kernel/head.S. Symbols _start and __start are
located at 0x00000000 and 0x0000000c respectively.
Best regards,
Laurent Pinchart
^ permalink raw reply
* Problem for "insmod: unresolved symbol printk"
From: Zhou Rui @ 2006-06-22 14:31 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
Hi, all
I'm a newbie for linuxppc. I've tried to write a simple hello.c as a kernel module.
/*hello.c*/
#ifndef MODULE
#define MODULE
#endif
#ifndef __KERNEL__
#define __KERNEL__
#endif
#include <linux/module.h>
#include <linux/kernel.h>
int init_module(void)
{
printk("Hello world 1.\n");
return 0;
}
void cleanup_module(void)
{
printk("Goodbye world 1.\n");
}
I wrote the code on a machine with Slackware installed. There was a PowerPC405EP board connected to the machined with NFS used. On the PowerPC board, the kernel is linuxppc-2.4.25-rthal5 and can be logged in via telnet. On the machine, there was also a toolchain for PowerPC and there were a series of commands beginning with "powerpc-linux-" existing. I've tried to cross-compile the source file with "powerpc-linux-gcc -c hello.c" or "powerpc-linux-gcc -c -DMODVERSIONS -I/usr/src/linuxppc-2.4.25/include hello.c" for PowerPC. But when I telneted into the board and run "insmod hello.o" on the PowerPC board, there always was "insmod: unresolved symbol printk". So would anyone give me some advice about the problem? Thank you very much.
---------------------------------
雅虎免费邮箱-3.5G容量，20M附件
[-- Attachment #2: Type: text/html, Size: 1458 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Jimi Xenidis @ 2006-06-22 2:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17561.56593.481580.556093@cargo.ozlabs.ibm.com>
On Jun 21, 2006, at 7:58 PM, Paul Mackerras wrote:
> Jimi Xenidis writes:
>
>> The following patch avoids accessing Hypervisor privilege HID
>> registers when running on a Hypervisor (MSR[HV]=0).
>
> Why? Aren't the writes defined to be no-ops when not in hypervisor
> mode?
The write are no-ops but look at the instructions required to be
around the write for some of them.
I believe read may have performance issues as well.
I juts think its good practice and as Xell and newer processes come
along we may want to start using the PACA(?) rather then peeking at
the msr all the time.
-JX
^ permalink raw reply
* Re: [linux-pm] windfarm got signal
From: Nigel Cunningham @ 2006-06-22 12:33 UTC (permalink / raw)
To: linux-pm; +Cc: Rafael J. Wysocki, linuxppc-dev list, Johannes Berg
In-Reply-To: <1150976092.16258.33.camel@johannes>
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Hi.
On Thursday 22 June 2006 21:34, Johannes Berg wrote:
> On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> > Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> > checks for pending signals.
>
> Ah. The code is just in the wrong order:
> while (!kthread_should_stop()) {
> try_to_freeze();
> ...
> schedule_timeout_interruptible(...);
> if (signal_pending())
> break;
> }
>
> Would it be correct to just move the try_to_freeze() before the
> signal_pending() statement?
Hmm. Will kthread_should_stop() be set if it should really exit? If so,
perhaps you can just remove the signal_pending() check. Otherwise, you'd want
to change the signal_pending() test to something like the "if
(signal_pending() && !try_to_freeze())" to avoid any possibility of a race.
(In this case, you should be able to remove the try_to_freeze() from above).
Regards,
Nigel
--
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Benjamin Herrenschmidt @ 2006-06-22 12:09 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <6BBF4F7C-1375-41FF-8D42-43BEC67194CC@watson.ibm.com>
On Thu, 2006-06-22 at 06:58 -0400, Jimi Xenidis wrote:
> 970s consider this a no-op (I believe an expensive one) especially
> when you consider some of the synchronization issues around the mtspr
> HIDx.
> And though this is 970 specific code, Cell and future processors,
> will no longer allow writing to to these registers if !(MSR[0]=1 &&
> MSR[PR]=0)
Fair enough, let's fix it.
Ben.
^ permalink raw reply
* Re: [linux-pm] windfarm got signal
From: Johannes Berg @ 2006-06-22 11:34 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linuxppc-dev list, linux-pm
In-Reply-To: <1150974836.16258.29.camel@johannes>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
On Thu, 2006-06-22 at 13:13 +0200, Johannes Berg wrote:
> Thanks, I'll look and submit a patch. It does try_to_freeze() but also
> checks for pending signals.
Ah. The code is just in the wrong order:
while (!kthread_should_stop()) {
try_to_freeze();
...
schedule_timeout_interruptible(...);
if (signal_pending())
break;
}
Would it be correct to just move the try_to_freeze() before the
signal_pending() statement?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [linux-pm] windfarm got signal
From: Rafael J. Wysocki @ 2006-06-22 11:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Johannes Berg, linux-pm
In-Reply-To: <1150956123.3633.23.camel@localhost.localdomain>
On Thursday 22 June 2006 08:02, Benjamin Herrenschmidt wrote:
> On Wed, 2006-06-21 at 01:51 +0200, Johannes Berg wrote:
> > Hey,
> >
> > after cpu hotplug I decided to write some fake suspend routines for
> > ppc64 that always fail to see what all the drivers would say... The
> > first thing I saw was during the phase where all threads are stopped,
> > that windfarm got a signal!
> >
> > Shortly after that, the fans were revved up fully but I guess that's
> > expected if the wf control loop exits.
> >
> > So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> > expected with pm and windfarm just does the wrong thing there by taking
> > the signal as a reason to exit the control thread?
> >
> > [code in question is windfarm_core.c:wf_thread_func]
>
> I think it's the way the freezer works ... it sends a pseudo signal to
> all kernel threads who are then supposed to do something like test for
> PF_FREEZE or something like that.
Yes. More precisely, they are supposed to use try_to_freeze().
Please see Documentation/power/kernel_threads.txt.
Greetings,
Rafael
^ permalink raw reply
* Re: [linux-pm] windfarm got signal
From: Johannes Berg @ 2006-06-22 11:13 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, linuxppc-dev list
In-Reply-To: <200606221303.19860.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On Thu, 2006-06-22 at 13:03 +0200, Rafael J. Wysocki wrote:
> > I think it's the way the freezer works ... it sends a pseudo signal to
> > all kernel threads who are then supposed to do something like test for
> > PF_FREEZE or something like that.
>
> Yes. More precisely, they are supposed to use try_to_freeze().
>
> Please see Documentation/power/kernel_threads.txt.
Thanks, I'll look and submit a patch. It does try_to_freeze() but also
checks for pending signals.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Jimi Xenidis @ 2006-06-22 10:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20060621235156.GA5414@pb15.lixom.net>
On Jun 21, 2006, at 7:51 PM, Olof Johansson wrote:
> On Wed, Jun 21, 2006 at 07:15:55PM -0400, Jimi Xenidis wrote:
>>
>> The following patch avoids accessing Hypervisor privilege HID
>> registers when running on a Hypervisor (MSR[HV]=0).
>
> I'm curious, why is this causing problems now?
Every once in a while I run Xen on one of our simulators thats is
sensitive to this code that does this.
First time we hit it (a while ago) we discovered that mtsdr1 was used
(even though a no-op)
> JS20 has been running
> that code with a hypervisor since a long time back.
970s consider this a no-op (I believe an expensive one) especially
when you consider some of the synchronization issues around the mtspr
HIDx.
And though this is 970 specific code, Cell and future processors,
will no longer allow writing to to these registers if !(MSR[0]=1 &&
MSR[PR]=0)
-JX
^ permalink raw reply
* entry point of kernel in RAM at 0x0c--linux tree file name
From: Arun Kumar @ 2006-06-22 8:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
Hi ,
I would like to kow what is the entry point to kernel at 0x000 after
decompressing and passing control to 0x0c .
My kernel crashes somewhere after uncomressing and jumping to 0x0c .
If any one can help the .c /.S file that contains the source of kernel
startup code in RAM at 0x0/0x0c .
thanks,
Arun
[-- Attachment #2: Type: text/html, Size: 333 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] PAL: Support of the fixed PHY
From: Vitaly Bordug @ 2006-06-22 8:39 UTC (permalink / raw)
To: Michael Buesch; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-embedded
In-Reply-To: <200606212248.27836.mb@bu3sch.de>
На Wed, 21 Jun 2006 22:48:27 +0200
Michael Buesch <mb@bu3sch.de> записано:
> On Wednesday 21 June 2006 18:09, Vitaly Bordug wrote:
>
> > +static int fixed_mdio_update_regs(struct fixed_info *fixed)
> > +{
> > + u16 *regs = fixed->regs;
> > + u16 bmsr = 0;
> > + u16 bmcr = 0;
> > +
> > + if(!regs) {
> > + printk(KERN_ERR "%s: regs not set up",
> > __FUNCTION__);
> > + return -1;
>
> -EINVAL perhaps?
>
OK
> > +static int fixed_mdio_register_device(int number, int speed, int
> > duplex) +{
> > + struct mii_bus *new_bus;
> > + struct fixed_info *fixed;
> > + struct phy_device *phydev;
> > + int err = 0;
> > +
> > + struct device* dev = kzalloc(sizeof(struct device),
> > GFP_KERNEL); +
> > + if (NULL == dev)
> > + return -EINVAL;
>
> -ENOMEM here.
OK
[snip]
> > + /*
> > + the mdio bus has phy_id match... In order not to do it
> > + artificially, we are binding the driver here by hand;
> > + it will be the same
> > + for all the fixed phys anyway.
> > + */
> > + down_write(&phydev->dev.bus->subsys.rwsem);
> > +
> > + phydev->dev.driver = &fixed_mdio_driver.driver;
> > +
> > + err = phydev->dev.driver->probe(&phydev->dev);
> > + if(err < 0) {
> > + printk(KERN_ERR "Phy %s: problems with fixed
> > driver\n",
> > + phydev->dev.bus_id);
> > + up_write(&phydev->dev.bus->subsys.rwsem);
> > + goto bus_register_fail;
>
> Probably need some additional error unwinding code.
> Of doesn't device_register() have to be reverted?
> What about phy_device_create()?
>
Definitely. Moreover, as I noticed now, phy_driver_register also has to
be error-handled and such. Will fix/update and resubmit.
Thanks for the feedback.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Linux on Virtex4
From: Filippo Capurso @ 2006-06-22 7:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0606210055m71277d1fl66dacfa7cd7ed203@mail.gmail.com>
Hi Grant,
Thank you for your kind answer.
> Yes, I had seen your message; but I'm not an expert on the 4xx mmu. I
> haven't seen that behaviour on my board.
>
> Double check your memory ranges. Have you given the kernel real RAM?
I'll investigate further on that...
Anyway, is your porting to the ML403 intended to work on Xilinx
reference design? I haven't exactly this design on my Virtex-4 because
I've remapped the flash memory to the end of the CPU address space in
order to execute automatically U-Boot after the configuration process...
also, obviously, I haven't any BRAM on this design (it was mapped at the
end of the address space).
The only thing that I've done to recompile the kernel for my project is
replacing the xparameters_ml403.h file with the EDK generated one. Is
this correct? Other things to do? My aim just now is to get a working
kernel with serial port support only.
Thank you.
Filippo Capurso
--
DAVE Srl - Electronics System House
via Forniz 2/1
33080 Porcia (PN) - Italy
Telephone: +39.0434.921215
Telefax: +39.0434.1994030
Freefax: +39.02.700520062
web: www.dave-tech.it
e-mail: filippo.capurso@dave-tech.it
how to reach us: http://mail.map24.com/dave
^ permalink raw reply
* Re: windfarm got signal
From: Benjamin Herrenschmidt @ 2006-06-22 6:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, linux-pm
In-Reply-To: <1150847482.16662.13.camel@johannes>
On Wed, 2006-06-21 at 01:51 +0200, Johannes Berg wrote:
> Hey,
>
> after cpu hotplug I decided to write some fake suspend routines for
> ppc64 that always fail to see what all the drivers would say... The
> first thing I saw was during the phase where all threads are stopped,
> that windfarm got a signal!
>
> Shortly after that, the fans were revved up fully but I guess that's
> expected if the wf control loop exits.
>
> So now I'm trying to see *why* it got a signal there. Any ideas? Is that
> expected with pm and windfarm just does the wrong thing there by taking
> the signal as a reason to exit the control thread?
>
> [code in question is windfarm_core.c:wf_thread_func]
I think it's the way the freezer works ... it sends a pseudo signal to
all kernel threads who are then supposed to do something like test for
PF_FREEZE or something like that.
Ben.
^ permalink raw reply
* Re: Linux ppc port problem
From: robinpv @ 2006-06-22 1:10 UTC (permalink / raw)
To: Zhan, Rongkai; +Cc: linuxppc-dev
In-Reply-To: <6A3254532ACD7A42805B4E1BFD18080E01039494@ism-mail01.corp.ad.wrs.com>
The linux is up, Thank you. I did do anything checked today console is
up!! strange
With Regards
Robin
Zhan, Rongkai wrote:
>You even have not a working kernel console.
>
>Best Regards,
>Mark. Zhan
>-----Original Message-----
>From: linuxppc-dev-bounces+rongkai.zhan=windriver.com@ozlabs.org [mailto:linuxppc-dev-bounces+rongkai.zhan=windriver.com@ozlabs.org] On Behalf Of robinpv
>Sent: Wednesday, June 21, 2006 5:45 PM
>To: linuxppc-dev@ozlabs.org
>Subject: Linux ppc port problem
>
>Hi ,
> I am trying to the port linux to the mpc5200 based board( Lite5200.)
> I am using linux version 2.6.16.1. I am getting the below message
>after that, linux seems to he in hanged state
> I debugged and found that the control is reaching the schedule() in
>rest_init() which is the last function called in start_kernel().
> I have set the command line arguements to "console=ttyPSC0,115200
>root=/dev/ram0 rw ramdisk_size=16384"
> Can you suggest, how to proceed or what could be the problem.
>
>With regards
>Robin
>
>
>## Booting image at ff000000 ...
> Image Name: Linux-2.6.16.1
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1301999 Bytes = 1.2 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>## Loading RAMDisk Image at ff200000 ...
> Image Name: ramdisk
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 2788700 Bytes = 2.7 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Loading Ramdisk to 03d05000, end 03fadd5c ... OK
>id mach(): done
>MMU:enter
>MMU:hw init
>MMU:mapin
>MMU:setio
>MMU:exit
>setup_arch: enter
>setup_arch: bootmem
>arch: exit
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Paul Mackerras @ 2006-06-21 23:58 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <E1FtBvP-00026H-TC@kmac.watson.ibm.com>
Jimi Xenidis writes:
> The following patch avoids accessing Hypervisor privilege HID
> registers when running on a Hypervisor (MSR[HV]=0).
Why? Aren't the writes defined to be no-ops when not in hypervisor
mode?
Paul.
^ permalink raw reply
* Re: [PATCH] Don't access HID registers if running on a Hypervisor.
From: Olof Johansson @ 2006-06-21 23:51 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <E1FtBvP-00026H-TC@kmac.watson.ibm.com>
On Wed, Jun 21, 2006 at 07:15:55PM -0400, Jimi Xenidis wrote:
>
> The following patch avoids accessing Hypervisor privilege HID
> registers when running on a Hypervisor (MSR[HV]=0).
I'm curious, why is this causing problems now? JS20 has been running
that code with a hypervisor since a long time back.
-Olof
^ 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