* RE: Linux ppc port problem
From: Zhan, Rongkai @ 2006-06-21 16:27 UTC (permalink / raw)
To: robinpv, linuxppc-dev
You even have not a working kernel console.
Best Regards,
Mark. Zhan
-----Original Message-----
From: linuxppc-dev-bounces+rongkai.zhan=3Dwindriver.com@ozlabs.org =
[mailto:linuxppc-dev-bounces+rongkai.zhan=3Dwindriver.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=20
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=3DttyPSC0,115200 =
root=3D/dev/ram0 rw ramdisk_size=3D16384"
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 =3D 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 =3D 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: please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-06-21 21:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, torvalds
In-Reply-To: <3F041A9D-F1D9-4FF9-977F-E09D924D0741@kernel.crashing.org>
Kumar Gala writes:
> Paul, some of the 8641 patches still need some cleanup, any reason
> you included them?
Because the changes you requested were very minor, and it was
convenient to bundle up Jon's patches with the other ones I was
sending up to Linus.
Paul.
^ permalink raw reply
* Re: [PATCH 1/3] PAL: Support of the fixed PHY
From: Michael Buesch @ 2006-06-21 20:48 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-embedded
In-Reply-To: <20060621160950.4860.92979.stgit@vitb.ru.mvista.com>
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?
> +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.
> + new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
> +
> + if (NULL == new_bus) {
> + kfree(dev);
> + return -ENOMEM;
> + }
> + fixed = fixed_ptr = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
> +
> + if (NULL == fixed) {
> + kfree(dev);
> + kfree(new_bus);
> + return -ENOMEM;
> + }
> +
> + fixed->regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
> +
> + if (NULL == fixed->regs) {
> + kfree(dev);
> + kfree(new_bus);
> + kfree (fixed);
> + return -ENOMEM;
> + }
> +
> + fixed->regs_num = MII_REGS_NUM;
> + fixed->phy_status.speed = speed;
> + fixed->phy_status.duplex = duplex;
> + fixed->phy_status.link = 1;
> +
> + new_bus->name = "Fixed MII Bus",
> + new_bus->read = &fixed_mii_read,
> + new_bus->write = &fixed_mii_write,
> + new_bus->reset = &fixed_mii_reset,
> +
> + /*set up workspace*/
> + fixed_mdio_update_regs(fixed);
> + new_bus->priv = fixed;
> +
> + new_bus->dev = dev;
> + dev_set_drvdata(dev, new_bus);
> +
> + /* create phy_device and register it on the mdio bus */
> + phydev = phy_device_create(new_bus, 0, 0);
> +
> + /*
> + Put the phydev pointer into the fixed pack so that bus read/write code could be able
> + to access for instance attached netdev. Well it doesn't have to do so, only in case
> + of utilizing user-specified link-update...
> + */
> + fixed->phydev = phydev;
> +
> + if (IS_ERR(phydev)) {
> + err = PTR_ERR(-ENOMEM);
> + goto bus_register_fail;
> + }
> +
> + phydev->irq = -1;
> + phydev->dev.bus = &mdio_bus_type;
> +
> + if(number)
> + snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
> + "fixed_%d@%d:%d", number, speed, duplex);
> + else
> + snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
> + "fixed@%d:%d", speed, duplex);
> + phydev->bus = new_bus;
> +
> + err = device_register(&phydev->dev);
> + if(err) {
> + printk(KERN_ERR "Phy %s failed to register\n",
> + phydev->dev.bus_id);
> + goto bus_register_fail;
> + }
> +
> + /*
> + 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()?
> + }
> +
> + device_bind_driver(&phydev->dev);
> + up_write(&phydev->dev.bus->subsys.rwsem);
> +
> + return 0;
> +
> +bus_register_fail:
> + kfree(dev);
> + kfree (fixed);
> + kfree(new_bus);
> +
> + return err;
> +}
--
Greetings Michael.
^ permalink raw reply
* [PATCH] Don't access HID registers if running on a Hypervisor.
From: Jimi Xenidis @ 2006-06-21 23:15 UTC (permalink / raw)
To: linuxppc-dev
The following patch avoids accessing Hypervisor privilege HID
registers when running on a Hypervisor (MSR[HV]=0).
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
diff -r 87d019e8edc2 arch/powerpc/kernel/cpu_setup_power4.S
--- a/arch/powerpc/kernel/cpu_setup_power4.S Tue Jun 20 13:50:49 2006 -0400
+++ b/arch/powerpc/kernel/cpu_setup_power4.S Wed Jun 21 19:10:22 2006 -0400
@@ -149,7 +149,12 @@ _GLOBAL(__save_cpu_setup)
cmpwi r0,0x44
bne 2f
-1: /* Save HID0,1,4 and 5 */
+1: /* skip if not running in HV mode */
+ mfmsr r0
+ rldicl. r0,r0,4,63
+ beq 2f
+
+ /* Save HID0,1,4 and 5 */
mfspr r3,SPRN_HID0
std r3,CS_HID0(r5)
mfspr r3,SPRN_HID1
@@ -183,7 +188,12 @@ _GLOBAL(__restore_cpu_setup)
cmpwi r0,0x44
bnelr
-1: /* Before accessing memory, we make sure rm_ci is clear */
+1: /* skip if not running in HV mode */
+ mfmsr r0
+ rldicl. r0,r0,4,63
+ beqlr
+
+ /* Before accessing memory, we make sure rm_ci is clear */
li r0,0
mfspr r3,SPRN_HID4
rldimi r3,r0,40,23 /* clear bit 23 (rm_ci) */
^ permalink raw reply
* Re: MPC8560 CPM drivers
From: Vitaly Bordug @ 2006-06-21 23:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C9CF@CYBORG3.cyclone.com>
На Wed, 21 Jun 2006 15:57:14 -0400
"Scott Coulter" <scott.coulter@cyclone.com> записано:
>
> Hi everyone,
>
> I have a MPC8560 driver availability question that perhaps someone can
> answer.
>
> My company has built a board for a customer with an MPC8560 on it.
> The board has been designed so that the CPM can support several I/O
> interfaces using an external PMC-Sierra COMET device. Originally, the
> customer was planning to use VxWorks and port an existing pSOS driver
> that was written for the CPM on the MPC8260. They are now inquiring
> about linux driver support for the CPM. I currently have version
> 2.6.15 of the kernel running on the board.
>
> Does anyone know what exists as far as driver support for the CPM on
> the 8560? Specifically, the customer is looking to run the CPM with
> the following interfaces:
>
> TDM T1
> TDM E1
> ATM T1
> ATM E1
>
> If there is currently no support, does anyone know if there are any
> drivers in the works?
>
I'm aware of http://mpc8260sar.sourceforge.net
and http://atm8260.sourceforge.net, that utilize ATM from CPM (cpm1
and cpm2), but dunno if it is definitely the thing you are looking
for...
> Thanks in advance,
>
> Scott
>
>
>
>
> ___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
>
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
> ___________________________________________________________________
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ 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
* 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: 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: 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 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: [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
* 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] 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
* 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: [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: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: [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: 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: 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
* 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: 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
* 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
* 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: 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
* 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
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