* Re: (Very) Simple question(s) compared to group topics
From: Mark Chambers @ 2004-12-04 15:08 UTC (permalink / raw)
To: Bora Þahin, linuxppc-embedded
In-Reply-To: <8316506505.20041204160411@ttnet.net.tr>
If you go by MIPS, it takes very approximately 1000MIPS to decode DVD
quality MPEG2.
I don't think floating point helps with MPEG2, not sure about MPEG4. You
also have to
think about memory bandwidth with an application like video. All settop box
designs that
I'm aware of have some kind of MPEG decode coprocessor, either a separate
chip or built
into the main processor (like ATI Xilleon).
Mark Chambers
wvcomputronics.com
----- Original Message -----
From: "Bora Þahin" <bora.sahin@ttnet.net.tr>
To: <linuxppc-embedded@ozlabs.org>
Sent: Saturday, December 04, 2004 9:04 AM
Subject: (Very) Simple question(s) compared to group topics
> Hi,
>
> I was subscribed to list a few days ago. I dont know this group is
eligible for my very simple or
> basic questions compared to list topics. In one side asm codes is
discussed like one jump command
> why not reach to symbol and the other side interrupt handling routines
is discussed like whether
> or not critical interrupt handling is used in 405 EP. Subsequently, my
simple question is to stay
> very basic. However if i get an answer(s) or redirections to correct
places, I can be very
> grateful.
>
> A bit summary about me...
>
> So far, let say until the last one week or a bit over, I havent done any
work out of x86 including
> any RISC cpu. I know inner workings of x86(asm) like segmentation,
paging, booting etc. not to be
> very detailed. Before, I have dealt with mem. mag. especially in the
means of mm initialization,
> booting, ...etc on the x86 imp. of the Linux kernel.
>
> The subject...
>
> PPC and 4xx series of it is absolutely new to me. We think to decode
"mpeg 4/level 5" coded films
> on the 4xx series of ppc if it is possible. I examined a bit these cpus.
4xx series go to 700/800
> MHZ clock freq but most of them dont contain floating point unit.(Only
one of them has fpu if my
> memory dont serve me. I cant say it is connected. If i understand the
doc correctly, you can
> connect a fpu to the system) This is just a point. I know clock freq is
not alone on the cpu
> performance. I would like to hear experianced users testimonals or
thought about decoding of mpeg
> performance of these cpus...
>
> --
> Bora Sahin
> borasahin.port5.com
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* (Very) Simple question(s) compared to group topics
From: Bora Þahin @ 2004-12-04 14:04 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <065ACD8E84315E4394C835E398C8D5EBBBED0A@COSSMGMBX02.email.corp.tld>
Hi,
I was subscribed to list a few days ago. I dont know this group is eligible for my very simple or
basic questions compared to list topics. In one side asm codes is discussed like one jump command
why not reach to symbol and the other side interrupt handling routines is discussed like whether
or not critical interrupt handling is used in 405 EP. Subsequently, my simple question is to stay
very basic. However if i get an answer(s) or redirections to correct places, I can be very
grateful.
A bit summary about me...
So far, let say until the last one week or a bit over, I havent done any work out of x86 including
any RISC cpu. I know inner workings of x86(asm) like segmentation, paging, booting etc. not to be
very detailed. Before, I have dealt with mem. mag. especially in the means of mm initialization,
booting, ...etc on the x86 imp. of the Linux kernel.
The subject...
PPC and 4xx series of it is absolutely new to me. We think to decode "mpeg 4/level 5" coded films
on the 4xx series of ppc if it is possible. I examined a bit these cpus. 4xx series go to 700/800
MHZ clock freq but most of them dont contain floating point unit.(Only one of them has fpu if my
memory dont serve me. I cant say it is connected. If i understand the doc correctly, you can
connect a fpu to the system) This is just a point. I know clock freq is not alone on the cpu
performance. I would like to hear experianced users testimonals or thought about decoding of mpeg
performance of these cpus...
--
Bora Sahin
borasahin.port5.com
^ permalink raw reply
* looking for help, attempting to debug high latency in 2.4 kernel
From: Chris Friesen @ 2004-12-03 21:58 UTC (permalink / raw)
To: Linux kernel, linuxppc-dev
Hi guys,
I'm running 2.4.22 on ppc32. Embedded system, just 74xx cpu, dual tulip network
links and fiberchannel card. Card has 1.5GB of memory, rootfs is tmpfs, system
has some NFS mounts.
We're seeing userspace delayed for almost a second every so often. No idea
what's causing it.
We've got scheduler instrumentation showing a usespace task starting to run,
then a bunch of tasks being put on the runqueue, and finally we wake up and
start running normally again almost a full second later. The timing is not
exactly the same in each case, but it's usually close to a second of delay.
I'm looking for some tips on how to go about tracking this down.
Where are my delays likely to be coming from? Long-running code paths? Long
periods with interrupts off? I dunno where to start.
Would porting lockmeter be a good idea? Is there anyone who's already done this
for ppc?
I appreciate any help.
Thanks,
Chris
^ permalink raw reply
* Re: PPC debug setcontext syscall implementation
From: Corey Minyard @ 2004-12-03 22:07 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20041202231621.GF14005@smtp.west.cox.net>
Tom Rini wrote:
>On Thu, Dec 02, 2004 at 04:58:45PM -0600, Corey Minyard wrote:
>
>
>
>>I'll test gdb on classic and an ebony that I have. I assume that gdb
>>has a built-in test suite?
>>
>>
>
>The GDB sources, yes. You do need to build GDB first, have dejagnu
>installed and then run a 'make check'. Ping me off-list if you want
>some help getting it all done.
>
>
>
It checks out on 440gp and 7xx. There were no differences in failures
on the 7xx. There was one difference on the 440gp, but that appeared to
be a thread race condition and not related to this.
Thanks,
-Corey
^ permalink raw reply
* RE: 440GX MMU problem
From: VanBaren, Gerald (AGRE) @ 2004-12-03 21:56 UTC (permalink / raw)
To: Barbier, Renaud (GE Infrastructure), Matt Porter; +Cc: linuxppc-embedded
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=0D
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=0D
> Barbier, Renaud (GE Infrastructure)
> Sent: Friday, December 03, 2004 3:53 PM
> To: Matt Porter
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: 440GX MMU problem
>=0D
> actually, I just loaded linux at memory offset=0D
> 0x10000000(above 256MB) and in this case it is able to boot=0D
> and use the full 512MB.
> there maybe indeed something broken.
>=0D
> Originally, U-boot did not map the full 512MB but only 256MB.
> I wonder if that could be a possible source of my problem.
Disclaimer: I don't have experience with the 4xx family, but won't stop
me from speculating (which drives Wolfgang crazy when I guess wrong ;-).
On the 82xx u-boot uses BATs to map memory. On the 82xx, BATs are
limited to 256MBytes per BAT. I'm guessing you are running into this.
Somewhere in your u-boot it doesn't know how to go beyond the 256MByte
boundary.
On u-boot, check out the use of "CONFIG_VERY_BIG_RAM". It doesn't look
like it applies directly to your board/processor, but you may be able to
enhance your system using it or a similar concept.
gvb
******************************************
I apologize for the following message brought to you by the Lawyers'
League of IdioSpeak:
******************************************
The information contained in, or attached to, this e-mail, may contain=
confidential information and is intended solely for the use of the=
individual or entity to whom they are addressed and may be subject to=
legal privilege. If you have received this e-mail in error you should=
notify the sender immediately by reply e-mail, delete the message from=
your system and notify your system manager. Please do not copy it for any=
purpose, or disclose its contents to any other person. The views or=
opinions presented in this e-mail are solely those of the author and do=
not necessarily represent those of the company. The recipient should=
check this e-mail and any attachments for the presence of viruses. The=
company accepts no liability for any damage caused, directly or=
indirectly, by any virus transmitted in this email.
******************************************
^ permalink raw reply
* RE: 440GX MMU problem
From: Barbier, Renaud (GE Infrastructure) @ 2004-12-03 20:52 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
actually, I just loaded linux at memory offset 0x10000000(above 256MB)
and in this case it is able to boot and use the full 512MB.
there maybe indeed something broken.
Originally, U-boot did not map the full 512MB but only 256MB.
I wonder if that could be a possible source of my problem.
-----Original Message-----
From: Matt Porter [mailto:mporter@kernel.crashing.org]
Sent: Friday, December 03, 2004 6:06 PM
To: Barbier, Renaud (GE Infrastructure)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 440GX MMU problem
On Fri, Dec 03, 2004 at 06:12:31AM -0600, Barbier, Renaud (GE =
Infrastructure) wrote:
>=20
> I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
> >From U-boot I can see the whole memory.
> If I boot Linux, unless I set the boot parameter mem=3D256M (or less).
> it will not boot. Linux does not seem to go further than the =
MMU_setup.
Verified that the 440GX eval with 512MB works on both 2.4.26 and current
2.4. Works For Me(tm).
=20
> Any idea why it cannot use 512MB?
A broken board port would do it. If you deviate for any reason
from the stock kernel configuration you can shoot yourself in the
foot real fast. If you can provide some details on your custom
board and port, somebody may be able to help you.
-Matt
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Kjetil Ørbekk @ 2004-12-03 16:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: fedora-ppc, gentoo-ppc-user, linuxppc-dev list,
debian-powerpc@lists.debian.org
In-Reply-To: <1101877409.5672.2.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> http://gate.crashing.org/~benh/albook-ibookg4-sleep-6.diff
Worked like a charm.
--
Kjetil Orbekk
^ permalink raw reply
* Re: 440GX MMU problem
From: Matt Porter @ 2004-12-03 18:08 UTC (permalink / raw)
To: Barbier, Renaud (GE Infrastructure); +Cc: linuxppc-embedded
In-Reply-To: <45ABD2373C33C4459D42B40EC4F346F20482F5DA@FTWMLVEM03.e2k.ad.ge.com>
On Fri, Dec 03, 2004 at 11:45:25AM -0600, Barbier, Renaud (GE Infrastructure) wrote:
> the memory test from U-boot does not complain as well as vxWorks.
>
> I will do my own test anyway.
>From experience, these simple memory tests are often not
sufficient...i.e. they can pass even with incorrect timing.
-Matt
^ permalink raw reply
* Re: 440GX MMU problem
From: Matt Porter @ 2004-12-03 18:05 UTC (permalink / raw)
To: Barbier, Renaud (GE Infrastructure); +Cc: linuxppc-embedded
In-Reply-To: <45ABD2373C33C4459D42B40EC4F346F2047DC3D4@FTWMLVEM03.e2k.ad.ge.com>
On Fri, Dec 03, 2004 at 06:12:31AM -0600, Barbier, Renaud (GE Infrastructure) wrote:
>
> I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
> >From U-boot I can see the whole memory.
> If I boot Linux, unless I set the boot parameter mem=256M (or less).
> it will not boot. Linux does not seem to go further than the MMU_setup.
Verified that the 440GX eval with 512MB works on both 2.4.26 and current
2.4. Works For Me(tm).
> Any idea why it cannot use 512MB?
A broken board port would do it. If you deviate for any reason
from the stock kernel configuration you can shoot yourself in the
foot real fast. If you can provide some details on your custom
board and port, somebody may be able to help you.
-Matt
^ permalink raw reply
* RE: 440GX MMU problem
From: Barbier, Renaud (GE Infrastructure) @ 2004-12-03 17:45 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
the memory test from U-boot does not complain as well as vxWorks.
I will do my own test anyway.
-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]
Sent: Friday, December 03, 2004 5:40 PM
To: Barbier, Renaud (GE Infrastructure)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 440GX MMU problem
On Fri, Dec 03, 2004 at 06:12:31AM -0600, Barbier, Renaud (GE =
Infrastructure) wrote:
>=20
> I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
> >From U-boot I can see the whole memory.
> If I boot Linux, unless I set the boot parameter mem=3D256M (or less).
> it will not boot. Linux does not seem to go further than the =
MMU_setup.
>=20
> Any idea why it cannot use 512MB?
Incorrect SDRAM setup? Try running at least simple memory tests.
--
Eugene
^ permalink raw reply
* Re: 440GX MMU problem
From: Eugene Surovegin @ 2004-12-03 17:40 UTC (permalink / raw)
To: Barbier, Renaud (GE Infrastructure); +Cc: linuxppc-embedded
In-Reply-To: <45ABD2373C33C4459D42B40EC4F346F2047DC3D4@FTWMLVEM03.e2k.ad.ge.com>
On Fri, Dec 03, 2004 at 06:12:31AM -0600, Barbier, Renaud (GE Infrastructure) wrote:
>
> I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
> >From U-boot I can see the whole memory.
> If I boot Linux, unless I set the boot parameter mem=256M (or less).
> it will not boot. Linux does not seem to go further than the MMU_setup.
>
> Any idea why it cannot use 512MB?
Incorrect SDRAM setup? Try running at least simple memory tests.
--
Eugene
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Federico Gamio @ 2004-12-03 17:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: fedora-ppc, gentoo-ppc-user, linuxppc-dev list, Debian PowerPC
In-Reply-To: <1101877409.5672.2.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
With patch #6 in some random situations, my PowerBook G4 (ATI 9600)
doesn't goes to sleep.
One situation is:
- Turn PB
- Work
- Sleep
- 14 hours of sleep
- Turn back from sleep (perfect, no problem at all)
- Work for 4 hours (mails, www, no USB, Bluetooth, etc)
- Try to sleep and problem...
When I try to make sleep my PB, nothing happens (in X), and I can't
switch from X to console.
Sorry, I can't help you more with this bug, I will keep trying to
establish which are the events that trigger this bug.
Federico
On Wed, 2004-12-01 at 16:03 +1100, Benjamin Herrenschmidt wrote:
> (As usual, I'm cross posting several lists, please don't reply to all of them,
> and CC me as I'm not subscribed to all of them neither)
>
> Ok, here's the 6th version of the sleep patch for ATI based albooks &
> iBook G4. Other machine users, please test too as it may cause
> regressions (or improvements) as well.
>
> This one fixes finally the cache flush problem that made cpufreq (on machines
> using the PMU for the switch) and sleep/wake unreliable occasionally (memory
> corruption would occur on some CPUs at least). It improves bits here or there
> too, and adds the sungem wake-on-lan feature.
>
> There are still pending issues, like cpufreq on some machines will
> "think" it's running at full speed on wakeup while it's in fact running
> at slow speed (thankfully not the opposite). I don't think I'll fix this one
> in 2.6.9, but rather in 2.6.10.
>
> http://gate.crashing.org/~benh/albook-ibookg4-sleep-6.diff
>
> I'll post a 2.6.10-rc2-bk* based version of the patch soon.
>
> Ben.
>
>
>
--
My software never has bugs. | ASCII Ribbon Campaign /"\
It just develops random features. | For Standards-Complaint Email \ /
Public GnuPG key available at: http://www.keyserver.net X
1024D/203E154B 2003-10-03 Federico Gamio <federico@gamio.net> / \
Key fingerprint = 0B9E 3A19 C88B EBAC 5422 C05F 76B5 B922 203E 154B
sub 2048g/32D2F465 2003-10-03
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* 440GX MMU problem
From: Barbier, Renaud (GE Infrastructure) @ 2004-12-03 12:12 UTC (permalink / raw)
To: linuxppc-embedded
I am using linux 2.4.26 on a 440GX with 512MB of SDRAM.
>From U-boot I can see the whole memory.
If I boot Linux, unless I set the boot parameter mem=3D256M (or less).
it will not boot. Linux does not seem to go further than the MMU_setup.
Any idea why it cannot use 512MB?
thanks.
^ permalink raw reply
* Re: [PATCH][PPC32] Fix gianfar netdriver oops when using bootp...
From: Gerhard Jaeger @ 2004-12-03 10:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: Embedded PPC Linux list
In-Reply-To: <200412020925.35851.g.jaeger@sysgo.com>
Hi,
On Thursday 02 December 2004 09:25, Gerhard Jaeger wrote:
> On Thursday 02 December 2004 09:14, Kumar Gala wrote:
> > Fun with mailers. Try this url:
> >
> > http://tinyurl.com/6skww
>
> Thanks that works (I mean the URL ;)
> I have not tested, but this might will work, as I noticed, that when
> addidionally CONFIG_RARP is enabled, there are also no problems.
>
> Anyway, I'll test ASAP and will tell you the results.
I've now applied this ipconfig patch and removed my piece of code and:
it works - so ignore my patch ;)
Thanx,
Gerhard
>
> Thanx so far,
> Gerhard
>
> > - kumar
> >
> > On Dec 2, 2004, at 2:07 AM, Gerhard Jaeger wrote:
> > > Hi,
> > >
> > > On Wednesday 01 December 2004 23:19, Kumar Gala wrote:
> > > > There is some belief that the following patch should fix the iss=
ue:
> > > >
> > > > http://linux.bkbits.net:8080/linux-2.5/cset@1.2249.2.2?
> > >
> > > nav=3Dindex.html|ChangeSet@-3d
> > >
> > > > I would be interested to know if this helps w/o your patch.
> > >
> > > I'd like to cross-check this, but are you sure, you're referencing =
the
> > > correct
> > > changeset? Currently I only got:
> > > Error 500
> > > Unable to find revision 1.2249.2.2
> > >
> > > Gerhard
> > >
> > > > - kumar
> > > >
> > > > On Dec 1, 2004, at 10:07 AM, Gerhard Jaeger wrote:
> > > > > Hi,
> > > > >
> > > > > this patch fixes an issue, that occurs on my MPC8541CDS, when
> > >
> > > trying to
> > >
> > > > > use bootp to get the IP parameters. It seems, that the patch
> > >
> > > only=20
> > >
> > > > > cures
> > > > > the symptom but obviously not the cause ;)
> > > > >
> > > > > Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com>
> > > > >
> > > > > --- linux-2.6.10-rc2-mm4/drivers/net/gianfar.c.orig =20
> > >
> > > 2004-11-15=20
> > >
> > > > > 02:26:34.000000000 +0100
> > > > >
> > > > > +++ linux-2.6.10-rc2-mm4/drivers/net/gianfar.c 2004-12-01=20
> > > > >
> > > > > 17:00:19.000000000 +0100
> > > > >
> > > > > @@ -1477,6 +1477,9 @@ static void gfar_phy_change(void *data)
> > > > > struct gfar_private *priv =3D netdev_priv(dev);
> > > > >
> > > > > int result =3D 0;
> > > > >
> > > > > =20
> > > > > + if( !priv->mii_info->phyinfo )
> > > > > + return;
> > > > > +
> > > > > /* Delay to give the PHY a chance to change the
> > > > > * register state */
> > > > >
> > > > > msleep(1);
--=20
Gerhard Jaeger g.jaeger@sysgo.com
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
^ permalink raw reply
* Current PID in static kernel memory
From: Robin Gilks @ 2004-12-03 3:07 UTC (permalink / raw)
To: ppc embedded list
Greetings
On a 2.4.22 kernel running on an 8xx CPU, I'm trying to find useful
static kernel memory locations that will help diagnose problems after a
crash has occured.
So far I have identified load averages, uptime, active & inactive memory
and interrupt counts and I can dump these out from the bootloader.
What I'd really like is the pid of the current task but I can't find it
as the current task structure pointer is held in a register (r2) and
hence is not available after a reset.
Any clues as to where I could find this information?
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* [patch]: pmac_cpufreq: .get for gpois, use generic cpufreq debugging
From: Guido Guenther @ 2004-12-02 23:49 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi Ben,
the attached (against 2.6.10-rc2-bk14) cleans up some minor things in
pmac_cpufreq:
- use the generic cpufreq-debugging functions
- fix return value in gpios init (no problem, since currently unused)
- implement get for gpio driven frequency scaling (is it too expensive
to look up the of node every time?)
I couldn't test the gpios part since my pbook uses pmu driven frequency
scaling, but it's simple. Can you think of a clean way to get the
current frequency on these beasts? Maybe you point me to the correct
place area in the darwin sources?
Please apply the patch if appropriate.
-- Guido
Singed-Off-By: Guido Guenther <agx@sigxcpu.org>
--- linux-2.6.10-rc2-bk14/arch/ppc/platforms/pmac_cpufreq.c.orig 2004-12-02 20:55:51.000000000 +0100
+++ linux-2.6.10-rc2-bk14/arch/ppc/platforms/pmac_cpufreq.c 2004-12-03 00:03:37.000000000 +0100
@@ -36,6 +36,7 @@
#include <asm/system.h>
#include <asm/open_pic.h>
+#define dprintk(msg...) cpufreq_debug_printk(CPUFREQ_DEBUG_DRIVER, "pmac-cpufreq", msg)
/* WARNING !!! This will cause calibrate_delay() to be called,
* but this is an __init function ! So you MUST go edit
* init/main.c to make it non-init before enabling DEBUG_FREQ
@@ -118,14 +119,12 @@
*/
static int __pmac cpu_750fx_cpu_speed(int low_speed)
{
-#ifdef DEBUG_FREQ
- printk(KERN_DEBUG "HID1, before: %x\n", mfspr(SPRN_HID1));
-#endif
+ dprintk("HID1, before: %x\n", mfspr(SPRN_HID1));
#ifdef CONFIG_6xx
low_choose_750fx_pll(low_speed);
#endif
+ dprintk("HID1, after: %x\n", mfspr(SPRN_HID1));
#ifdef DEBUG_FREQ
- printk(KERN_DEBUG "HID1, after: %x\n", mfspr(SPRN_HID1));
debug_calc_bogomips();
#endif
@@ -202,9 +201,7 @@
preempt_disable();
-#ifdef DEBUG_FREQ
- printk(KERN_DEBUG "HID1, before: %x\n", mfspr(SPRN_HID1));
-#endif
+ dprintk("HID1, before: %x\n", mfspr(SPRN_HID1));
/* Disable all interrupt sources on openpic */
openpic_set_priority(0xf);
@@ -262,9 +259,7 @@
/* Restore userland MMU context */
set_context(current->active_mm->context, current->active_mm->pgd);
-#ifdef DEBUG_FREQ
- printk(KERN_DEBUG "HID1, after: %x\n", mfspr(SPRN_HID1));
-#endif
+ dprintk("HID1, after: %x\n", mfspr(SPRN_HID1));
/* Restore low level PMU operations */
pmu_unlock();
@@ -354,15 +349,33 @@
return 0x50 + (*reg);
}
+static struct freq_attr* pmac_cpufreq_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
static struct cpufreq_driver pmac_cpufreq_driver = {
.verify = pmac_cpufreq_verify,
.target = pmac_cpufreq_target,
.init = pmac_cpufreq_cpu_init,
.name = "powermac",
.owner = THIS_MODULE,
+ .attr = pmac_cpufreq_attr,
};
+static unsigned int __pmac pmac_cpufreq_get_gpios(unsigned int cpu)
+{
+ struct device_node *freq_gpio_np = of_find_node_by_name(NULL,
+ "frequency-gpio");
+ int rc;
+
+ frequency_gpio = read_gpio(freq_gpio_np);
+ rc = pmac_call_feature(PMAC_FTR_READ_GPIO, NULL, frequency_gpio, 0);
+ return (rc & 0x01) ? hi_freq : low_freq;
+}
+
+
static int __pmac pmac_cpufreq_init_MacRISC3(struct device_node *cpunode)
{
struct device_node *volt_gpio_np = of_find_node_by_name(NULL,
@@ -371,6 +384,7 @@
"frequency-gpio");
struct device_node *slew_done_gpio_np = of_find_node_by_name(NULL,
"slewing-done");
+ struct cpufreq_driver *driver = &pmac_cpufreq_driver;
u32 *value;
/*
@@ -395,6 +409,7 @@
int lenp, rc;
u32 *freqs, *ratio;
+ dprintk("using GIO\n.");
freqs = (u32 *)get_property(cpunode, "bus-frequencies", &lenp);
lenp /= sizeof(u32);
if (freqs == NULL || lenp != 2) {
@@ -423,14 +438,15 @@
low_freq = (low_freq * (*ratio)) / 2000;
hi_freq = (hi_freq * (*ratio)) / 2000;
- /* Now we get the frequencies, we read the GPIO to see what is out current
+ /* Now we get the frequencies, we read the GPIO to see what is our current
* speed
*/
rc = pmac_call_feature(PMAC_FTR_READ_GPIO, NULL, frequency_gpio, 0);
cur_freq = (rc & 0x01) ? hi_freq : low_freq;
set_speed_proc = gpios_set_cpu_speed;
- return 1;
+ driver->get = pmac_cpufreq_get_gpios;
+ return 0;
}
/* If we use the PMU, look for the min & max frequencies in the
@@ -450,7 +466,8 @@
return 1;
hi_freq = (*value) / 1000;
set_speed_proc = pmu_set_cpu_speed;
+ dprintk("using PMU\n.");
return 0;
}
^ permalink raw reply
* Re: PPC debug setcontext syscall implementation
From: Tom Rini @ 2004-12-02 23:16 UTC (permalink / raw)
To: Corey Minyard; +Cc: linuxppc-dev
In-Reply-To: <41AF9E25.2080109@acm.org>
On Thu, Dec 02, 2004 at 04:58:45PM -0600, Corey Minyard wrote:
> I'll test gdb on classic and an ebony that I have. I assume that gdb
> has a built-in test suite?
The GDB sources, yes. You do need to build GDB first, have dejagnu
installed and then run a 'make check'. Ping me off-list if you want
some help getting it all done.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: PPC debug setcontext syscall implementation
From: Corey Minyard @ 2004-12-02 22:58 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev
In-Reply-To: <20041202154901.B20211@home.com>
I'll test gdb on classic and an ebony that I have. I assume that gdb
has a built-in test suite?
-Corey
Matt Porter wrote:
>On Thu, Dec 02, 2004 at 03:23:50PM -0700, Tom Rini wrote:
>
>
>>On Thu, Dec 02, 2004 at 02:41:32PM -0600, Corey Minyard wrote:
>>
>>
>>
>>>Hello all,
>>>
>>>I have attached a patch with the implementation of the debug_setcontext
>>>system call. The syscall has been reserved for a while and I've posted
>>>this before. So I've ported to the newest kernel and here it is again.
>>>
>>>This syscall allows signal handlers to perform debug functions. It
>>>allows the signal handler to turn on single-stepping, for instance, and
>>>the thread will get a trap after executing the next instruction. It can
>>>also (on supported PPC processors) turn on branch tracing and get a trap
>>>after the next branch instruction is executed. This is useful for
>>>in-application debugging.
>>>
>>>
>>I asked Corey off-list, and this is vs 2.6.10-rc2-mm3.
>>I propose (and will update the patch tracker
>>(http://ozlabs.org/ppc32-patches/, I don't recall if/how well it was
>>advertised)) that so long as KGDB still works (I'll even go test it on
>>classic) as well as GDB testsuite (this is a 'touchy' area, so I'd like
>>to well-test changes) is still 'OK', pushing this into 2.6.11.
>>
>>
>
>I don't see a problem so long as both the 40x||booke and classic paths
>are tested with gdb and kgdb. I don't want to fix the former path again.
>
>-Matt
>
>
^ permalink raw reply
* Re: PPC debug setcontext syscall implementation
From: Matt Porter @ 2004-12-02 22:49 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20041202222349.GE14005@smtp.west.cox.net>
On Thu, Dec 02, 2004 at 03:23:50PM -0700, Tom Rini wrote:
> On Thu, Dec 02, 2004 at 02:41:32PM -0600, Corey Minyard wrote:
>
> > Hello all,
> >
> > I have attached a patch with the implementation of the debug_setcontext
> > system call. The syscall has been reserved for a while and I've posted
> > this before. So I've ported to the newest kernel and here it is again.
> >
> > This syscall allows signal handlers to perform debug functions. It
> > allows the signal handler to turn on single-stepping, for instance, and
> > the thread will get a trap after executing the next instruction. It can
> > also (on supported PPC processors) turn on branch tracing and get a trap
> > after the next branch instruction is executed. This is useful for
> > in-application debugging.
>
> I asked Corey off-list, and this is vs 2.6.10-rc2-mm3.
> I propose (and will update the patch tracker
> (http://ozlabs.org/ppc32-patches/, I don't recall if/how well it was
> advertised)) that so long as KGDB still works (I'll even go test it on
> classic) as well as GDB testsuite (this is a 'touchy' area, so I'd like
> to well-test changes) is still 'OK', pushing this into 2.6.11.
I don't see a problem so long as both the 40x||booke and classic paths
are tested with gdb and kgdb. I don't want to fix the former path again.
-Matt
^ permalink raw reply
* Re: PPC debug setcontext syscall implementation
From: Tom Rini @ 2004-12-02 22:23 UTC (permalink / raw)
To: Corey Minyard; +Cc: linuxppc-dev
In-Reply-To: <41AF7DFC.9040009@acm.org>
On Thu, Dec 02, 2004 at 02:41:32PM -0600, Corey Minyard wrote:
> Hello all,
>
> I have attached a patch with the implementation of the debug_setcontext
> system call. The syscall has been reserved for a while and I've posted
> this before. So I've ported to the newest kernel and here it is again.
>
> This syscall allows signal handlers to perform debug functions. It
> allows the signal handler to turn on single-stepping, for instance, and
> the thread will get a trap after executing the next instruction. It can
> also (on supported PPC processors) turn on branch tracing and get a trap
> after the next branch instruction is executed. This is useful for
> in-application debugging.
I asked Corey off-list, and this is vs 2.6.10-rc2-mm3.
I propose (and will update the patch tracker
(http://ozlabs.org/ppc32-patches/, I don't recall if/how well it was
advertised)) that so long as KGDB still works (I'll even go test it on
classic) as well as GDB testsuite (this is a 'touchy' area, so I'd like
to well-test changes) is still 'OK', pushing this into 2.6.11.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* PPC debug setcontext syscall implementation
From: Corey Minyard @ 2004-12-02 20:41 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
Hello all,
I have attached a patch with the implementation of the debug_setcontext
system call. The syscall has been reserved for a while and I've posted
this before. So I've ported to the newest kernel and here it is again.
This syscall allows signal handlers to perform debug functions. It
allows the signal handler to turn on single-stepping, for instance, and
the thread will get a trap after executing the next instruction. It can
also (on supported PPC processors) turn on branch tracing and get a trap
after the next branch instruction is executed. This is useful for
in-application debugging.
A small test program is also attached that demonstrates the use of this
interface.
Thanks,
-Corey
[-- Attachment #2: ppc_debug_setcontext --]
[-- Type: text/plain, Size: 8838 bytes --]
Add a debugging interface for PowerPC that allows signal handlers (or any
jump to a context, really) to perform debug functions. It allows the
a user program to turn on single-stepping, for instance, and the thread
will get a trap after executing the next instruction. It can also
(on supported PPC processors) turn on branch tracing and get a trap after
the next branch instruction is executed. This is useful for in-application
debugging.
Note that you can enable single-stepping on x86 processors directly
from signal handlers. Newer x86 processors have the equivalent of
a branch-trace bit in the IA32_DEBUGCTL MSR and could have similar
function to this syscall. Most other processors could benefit from
a similar interface, except for ARM which is extraordinarily broken
for debugging.
Future uses of this could be adding the ability to set the hardware
breakpoint registers from a signal handler.
Signed-off-by: Corey Minyard <minyard@mvista.com>
Index: arch/ppc/kernel/entry.S
===================================================================
--- arch/ppc/kernel/entry.S.orig 2004-10-25 08:08:32.000000000 -0500
+++ arch/ppc/kernel/entry.S 2004-12-01 09:04:40.000000000 -0600
@@ -111,8 +111,10 @@
addi r11,r1,STACK_FRAME_OVERHEAD
stw r11,PT_REGS(r12)
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
- lwz r12,PTRACE-THREAD(r12)
- andi. r12,r12,PT_PTRACED
+ /* Check to see if the dbcr0 register is set up to debug. Use the
+ single-step bit to do this. */
+ lwz r12,THREAD_DBCR0(r12)
+ andis. r12,r12,DBCR0_IC@h
beq+ 3f
/* From user and task is ptraced - load up global dbcr0 */
li r12,-1 /* clear all pending debug events */
@@ -242,9 +244,10 @@
bne- syscall_exit_work
syscall_exit_cont:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- /* If the process has its own DBCR0 value, load it up */
- lwz r0,PTRACE(r2)
- andi. r0,r0,PT_PTRACED
+ /* If the process has its own DBCR0 value, load it up. The single
+ step bit tells us that dbcr0 should be loaded. */
+ lwz r0,THREAD+THREAD_DBCR0(r2)
+ andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
stwcx. r0,0,r1 /* to clear the reservation */
@@ -599,9 +602,10 @@
restore_user:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- /* Check whether this process has its own DBCR0 value */
- lwz r0,PTRACE(r2)
- andi. r0,r0,PT_PTRACED
+ /* Check whether this process has its own DBCR0 value. The single
+ step bit tells us that dbcr0 should be loaded. */
+ lwz r0,THREAD+THREAD_DBCR0(r2)
+ andis. r10,r0,DBCR0_IC@h
bnel- load_dbcr0
#endif
@@ -876,17 +880,17 @@
/*
* Load the DBCR0 value for a task that is being ptraced,
- * having first saved away the global DBCR0.
+ * having first saved away the global DBCR0. Note that r0
+ * has the dbcr0 value to set upon entry to this.
*/
load_dbcr0:
- mfmsr r0 /* first disable debug exceptions */
- rlwinm r0,r0,0,~MSR_DE
- mtmsr r0
+ mfmsr r10 /* first disable debug exceptions */
+ rlwinm r10,r10,0,~MSR_DE
+ mtmsr r10
isync
mfspr r10,SPRN_DBCR0
lis r11,global_dbcr0@ha
addi r11,r11,global_dbcr0@l
- lwz r0,THREAD+THREAD_DBCR0(r2)
stw r10,0(r11)
mtspr SPRN_DBCR0,r0
lwz r10,4(r11)
Index: arch/ppc/kernel/misc.S
===================================================================
--- arch/ppc/kernel/misc.S.orig 2004-12-01 08:59:37.000000000 -0600
+++ arch/ppc/kernel/misc.S 2004-12-01 09:04:40.000000000 -0600
@@ -1434,7 +1434,7 @@
.long sys_fstatfs64
.long ppc_fadvise64_64
.long sys_ni_syscall /* 255 - rtas (used on ppc64) */
- .long sys_ni_syscall /* 256 reserved for sys_debug_setcontext */
+ .long sys_debug_setcontext
.long sys_ni_syscall /* 257 reserved for vserver */
.long sys_ni_syscall /* 258 reserved for new sys_remap_file_pages */
.long sys_ni_syscall /* 259 reserved for new sys_mbind */
Index: arch/ppc/kernel/signal.c
===================================================================
--- arch/ppc/kernel/signal.c.orig 2004-12-01 08:49:25.000000000 -0600
+++ arch/ppc/kernel/signal.c 2004-12-01 09:04:40.000000000 -0600
@@ -509,6 +509,96 @@
return 0;
}
+int sys_debug_setcontext(struct ucontext __user *ctx,
+ int ndbg, struct sig_dbg_op *dbg,
+ int r6, int r7, int r8,
+ struct pt_regs *regs)
+{
+ struct sig_dbg_op op;
+ int i;
+ unsigned long new_msr = regs->msr;
+#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
+ unsigned long new_dbcr0 = current->thread.dbcr0;
+#endif
+
+ for (i=0; i<ndbg; i++) {
+ if (__copy_from_user(&op, dbg, sizeof(op)))
+ return -EFAULT;
+ switch (op.dbg_type) {
+ case SIG_DBG_SINGLE_STEPPING:
+#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
+ if (op.dbg_value) {
+ new_msr |= MSR_DE;
+ new_dbcr0 |= (DBCR0_IDM | DBCR0_IC);
+ } else {
+ new_msr &= ~MSR_DE;
+ new_dbcr0 &= ~(DBCR0_IDM | DBCR0_IC);
+ }
+#else
+ if (op.dbg_value)
+ new_msr |= MSR_SE;
+ else
+ new_msr &= ~MSR_SE;
+#endif
+ break;
+ case SIG_DBG_BRANCH_TRACING:
+#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
+ return -EINVAL;
+#else
+ if (op.dbg_value)
+ new_msr |= MSR_BE;
+ else
+ new_msr &= ~MSR_BE;
+#endif
+ break;
+
+ default:
+ return -EINVAL;
+ }
+ }
+
+ /* We wait until here to actually install the values in the
+ registers so if we fail in the above loop, it will not
+ affect the contents of these registers. After this point,
+ failure is a problem, anyway, and it's very unlikely unless
+ the user is really doing something wrong. */
+ regs->msr = new_msr;
+#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
+ current->thread.dbcr0 = new_dbcr0;
+#endif
+
+ /*
+ * If we get a fault copying the context into the kernel's
+ * image of the user's registers, we can't just return -EFAULT
+ * because the user's registers will be corrupted. For instance
+ * the NIP value may have been updated but not some of the
+ * other registers. Given that we have done the verify_area
+ * and successfully read the first and last bytes of the region
+ * above, this should only happen in an out-of-memory situation
+ * or if another thread unmaps the region containing the context.
+ * We kill the task with a SIGSEGV in this situation.
+ */
+ if (do_setcontext(ctx, regs, 1)) {
+ force_sig(SIGSEGV, current);
+ goto out;
+ }
+
+ /*
+ * It's not clear whether or why it is desirable to save the
+ * sigaltstack setting on signal delivery and restore it on
+ * signal return. But other architectures do this and we have
+ * always done it up until now so it is probably better not to
+ * change it. -- paulus
+ */
+ do_sigaltstack(&ctx->uc_stack, NULL, regs->gpr[1]);
+
+ sigreturn_exit(regs);
+ /* doesn't actually return back to here */
+
+ out:
+ return 0;
+}
+
/*
* OK, we're invoking a handler
*/
Index: arch/ppc/kernel/traps.c
===================================================================
--- arch/ppc/kernel/traps.c.orig 2004-12-01 08:49:25.000000000 -0600
+++ arch/ppc/kernel/traps.c 2004-12-01 09:04:40.000000000 -0600
@@ -566,7 +566,7 @@
void SingleStepException(struct pt_regs *regs)
{
- regs->msr &= ~MSR_SE; /* Turn off 'trace' bit */
+ regs->msr &= ~(MSR_SE | MSR_BE); /* Turn off 'trace' bits */
if (debugger_sstep(regs))
return;
_exception(SIGTRAP, regs, TRAP_TRACE, 0);
Index: include/asm-ppc/signal.h
===================================================================
--- include/asm-ppc/signal.h.orig 2004-08-18 08:40:22.000000000 -0500
+++ include/asm-ppc/signal.h 2004-12-01 09:04:40.000000000 -0600
@@ -157,4 +157,23 @@
#define ptrace_signal_deliver(regs, cookie) do { } while (0)
#endif /* __KERNEL__ */
+/*
+ * These are parameters to dbg_sigreturn syscall. They enable or
+ * disable certain debugging things that can be done from signal
+ * handlers. The dbg_sigreturn syscall *must* be called from a
+ * SA_SIGINFO signal so the ucontext can be passed to it. It takes an
+ * array of struct sig_dbg_op, which has the debug operations to
+ * perform before returning from the signal.
+ */
+struct sig_dbg_op {
+ int dbg_type;
+ unsigned long dbg_value;
+};
+
+/* Enable or disable single-stepping. The value sets the state. */
+#define SIG_DBG_SINGLE_STEPPING 1
+
+/* Enable or disable branch tracing. The value sets the state. */
+#define SIG_DBG_BRANCH_TRACING 2
+
#endif
Index: include/asm-ppc/unistd.h
===================================================================
--- include/asm-ppc/unistd.h.orig 2004-12-01 08:59:57.000000000 -0600
+++ include/asm-ppc/unistd.h 2004-12-01 09:04:40.000000000 -0600
@@ -260,7 +260,7 @@
#define __NR_fstatfs64 253
#define __NR_fadvise64_64 254
#define __NR_rtas 255
-/* Number 256 is reserved for sys_debug_setcontext */
+#define __NR_sys_debug_setcontext 256
/* Number 257 is reserved for vserver */
/* Number 258 is reserved for new sys_remap_file_pages */
/* Number 259 is reserved for new sys_mbind */
[-- Attachment #3: test_dbg_setcontext.c --]
[-- Type: text/plain, Size: 4620 bytes --]
#include <signal.h>
#include <stdio.h>
#include <errno.h>
#include <sys/mman.h>
#include <asm/unistd.h>
struct my_sig_dbg_op {
int dbg_type;
unsigned long dbg_value;
};
/* Enable or disable single-stepping. The value sets the state. */
#define MY_SIG_DBG_SINGLE_STEPPING 1
/* Enable or disable branch tracing. The value sets the state. */
#define MY_SIG_DBG_BRANCH_TRACING 2
#ifndef __NR_dbg_sigreturn
#define __NR_dbg_sigreturn 256
#endif
/* Create the debug return syscall. */
_syscall3(int, dbg_sigreturn,
void *, ucontext,
int, ndbg,
struct my_sig_dbg_op *, op);
volatile int called = 0;
volatile int called2 = 0;
volatile int called3 = 0;
volatile int trap_called = 0;
void sighand(int sig, siginfo_t *info, void *ucontext)
{
struct my_sig_dbg_op op;
called++;
kill(getpid(), SIGUSR2);
op.dbg_type = MY_SIG_DBG_SINGLE_STEPPING;
op.dbg_value = 1;
dbg_sigreturn(ucontext, 1, &op);
}
void sighand2(int sig, siginfo_t *info, void *ucontext)
{
kill(getpid(), SIGPWR);
called2++;
}
void sighand3(int sig, siginfo_t *info, void *ucontext)
{
struct my_sig_dbg_op op;
called3++;
op.dbg_type = MY_SIG_DBG_SINGLE_STEPPING;
op.dbg_value = 1;
dbg_sigreturn(ucontext, 1, &op);
}
#define PAGE_SIZE 4096
#define TO_PAGEBASE(a) (((unsigned int) (a)) & (~(PAGE_SIZE-1)))
#define TRAP_INSTRUCTION 0x0ce00097
static int
write_instruction(unsigned char *address,
unsigned long new_instr,
unsigned long *old_instr)
{
char *pagebase = (char *) TO_PAGEBASE(address);
/* FIXME - currently assuming read-only executable memory, need a
way to fetch the old memory protection. */
if (mprotect(pagebase,
PAGE_SIZE,
PROT_READ | PROT_WRITE | PROT_EXEC) != 0) {
/* Couldn't change memory protection, return an error */
return -1;
}
if (old_instr)
*old_instr = *((volatile unsigned long *) address);
*((volatile unsigned long *) address) = new_instr;
mprotect(pagebase, PAGE_SIZE, PROT_READ | PROT_EXEC);
/* Flush the cache for the instruction. */
__asm__ ("dcbst 0,%0\n\ticbi 0,%0" : : "r" (address));
return 0;
}
unsigned char *instr_addr;
unsigned long old_instr;
int restore = 0;
int tracing = 0;
/* The "old" ucontext. */
struct old_sigcontext_struct {
unsigned long _unused[4];
int signal;
unsigned long handler;
unsigned long oldmask;
struct pt_regs *regs;
};
struct old_ucontext {
unsigned long uc_flags;
struct ucontext *uc_link;
stack_t uc_stack;
struct sigcontext_struct uc_mcontext;
sigset_t uc_sigmask; /* mask last for extensibility */
};
unsigned long
dbg_get_instruction_ptr_from_ucontext(void *ucontext)
{
struct old_ucontext *uc = ucontext;
struct pt_regs *regs = uc->uc_mcontext.regs;
return regs->nip;
}
void sigtrap(int sig, siginfo_t *info, void *ucontext)
{
int old_errno = errno;
trap_called++;
if (restore) {
write_instruction(instr_addr, old_instr, NULL);
restore = 0;
}
if (tracing) {
char buf[100];
sprintf(buf, "Trap at %8.8x\n", dbg_get_instruction_ptr_from_ucontext(ucontext));
write(2, buf, strlen(buf));
if (trap_called > 20)
tracing = 0;
else {
struct my_sig_dbg_op op;
errno = old_errno;
op.dbg_type = MY_SIG_DBG_BRANCH_TRACING;
op.dbg_value = 1;
dbg_sigreturn(ucontext, 1, &op);
}
}
errno = old_errno;
}
void call_printf(void)
{
printf("test\n");
}
int main(int argc, char *argv)
{
struct sigaction act;
int rv;
act.sa_sigaction = sighand;
act.sa_flags = SA_SIGINFO;
sigemptyset(&act.sa_mask);
sigaddset(&act.sa_mask, SIGUSR2);
rv = sigaction(SIGUSR1, &act, NULL);
if (rv == -1) {
perror("sigaction");
exit(1);
}
act.sa_sigaction = sighand2;
rv = sigaction(SIGUSR2, &act, NULL);
if (rv == -1) {
perror("sigaction");
exit(1);
}
act.sa_sigaction = sighand3;
rv = sigaction(SIGPWR, &act, NULL);
if (rv == -1) {
perror("sigaction");
exit(1);
}
act.sa_sigaction = sigtrap;
rv = sigaction(SIGTRAP, &act, NULL);
if (rv == -1) {
perror("sigaction");
exit(1);
}
kill(getpid(), SIGUSR1);
if (!called)
printf("Didn't get called\n");
else
printf("Got called %d times\n", called);
if (!called2)
printf("Didn't get called 2\n");
else
printf("Got called 2 %d times\n", called2);
if (!called3)
printf("Didn't get called 3\n");
else
printf("Got called 3 %d times\n", called3);
if (!trap_called) {
printf("ERROR: Didn't get trapped\n");
exit(1);
} else
printf("Got trapped %d times\n", trap_called);
instr_addr = (unsigned char *) call_printf;
write_instruction(instr_addr, TRAP_INSTRUCTION, &old_instr);
restore = 1;
tracing = 1;
call_printf();
exit(0);
}
^ permalink raw reply
* [PATCH][PPC32] Fix prototypes & externs in e500 oprofile support
From: Kumar Gala @ 2004-12-02 17:10 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Andrew,
Remove prototypes and externs out of the .c files
Signed-off-by: Andy Fleming <afleming@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
--
diff -Nru a/arch/ppc/kernel/perfmon_fsl_booke.c b/arch/ppc/kernel/perfmon_fsl_booke.c
--- a/arch/ppc/kernel/perfmon_fsl_booke.c 2004-12-02 10:44:03 -06:00
+++ b/arch/ppc/kernel/perfmon_fsl_booke.c 2004-12-02 10:44:03 -06:00
@@ -32,15 +32,7 @@
#include <asm/io.h>
#include <asm/reg.h>
#include <asm/xmon.h>
-
-void init_pmc_stop(int ctr);
-void set_pmc_event(int ctr, int event);
-void set_pmc_user_kernel(int ctr, int user, int kernel);
-void set_pmc_marked(int ctr, int mark0, int mark1);
-void pmc_start_ctr(int ctr, int enable);
-void pmc_start_ctrs(int enable);
-void pmc_stop_ctrs(void);
-void dump_pmcs(void);
+#include <asm/perfmon.h>
static inline u32 get_pmlca(int ctr);
static inline void set_pmlca(int ctr, u32 pmlca);
diff -Nru a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
--- a/arch/ppc/kernel/traps.c 2004-12-02 10:44:03 -06:00
+++ b/arch/ppc/kernel/traps.c 2004-12-02 10:44:03 -06:00
@@ -41,6 +41,7 @@
#ifdef CONFIG_PMAC_BACKLIGHT
#include <asm/backlight.h>
#endif
+#include <asm/perfmon.h>
#ifdef CONFIG_XMON
void (*debugger)(struct pt_regs *regs) = xmon;
@@ -70,8 +71,6 @@
/*
* Trap & Exception support
*/
-
-extern void (*perf_irq)(struct pt_regs *);
spinlock_t die_lock = SPIN_LOCK_UNLOCKED;
diff -Nru a/arch/ppc/oprofile/common.c b/arch/ppc/oprofile/common.c
--- a/arch/ppc/oprofile/common.c 2004-12-02 10:44:03 -06:00
+++ b/arch/ppc/oprofile/common.c 2004-12-02 10:44:03 -06:00
@@ -25,7 +25,6 @@
#include "op_impl.h"
-extern struct op_ppc32_model op_model_fsl_booke;
static struct op_ppc32_model *model;
static struct op_counter_config ctr[OP_MAX_COUNTER];
diff -Nru a/include/asm-ppc/perfmon.h b/include/asm-ppc/perfmon.h
--- a/include/asm-ppc/perfmon.h 2004-12-02 10:44:03 -06:00
+++ b/include/asm-ppc/perfmon.h 2004-12-02 10:44:03 -06:00
@@ -1,6 +1,8 @@
#ifndef __PERFMON_H
#define __PERFMON_H
+extern void (*perf_irq)(struct pt_regs *);
+
int request_perfmon_irq(void (*handler)(struct pt_regs *));
void free_perfmon_irq(void);
@@ -13,6 +15,8 @@
void pmc_start_ctrs(int enable);
void pmc_stop_ctrs(void);
void dump_pmcs(void);
+
+extern struct op_ppc32_model op_model_fsl_booke;
#endif
#endif /* __PERFMON_H */
^ permalink raw reply
* Re: [micropatch]mpc852t
From: Mark Chambers @ 2004-12-02 15:41 UTC (permalink / raw)
To: 김 창식, Linuxppc-embedded
In-Reply-To: <20041202111332.41ae7a4c000d614500056bfc.1632@empal.com>
I have an 852t board with 2.4.19 running. It uses smc1, scc3 and scc4.
I used a stock configuration so that smc2 comes up as though it were
present and is tts/1. But I made no modifications to the kernel and
there were no conflicts.
Are you trying to use a microcode patch? If so, tell us which one(s)
The whole 8xx microcode patch issue went through a big discussion
a couple of months ago.
Mark Chambers
wvcomputronics.com
----- Original Message -----
From: 김 창식
To: Linuxppc-embedded@ozlabs.org
Sent: Wednesday, December 01, 2004 9:13 PM
Subject: [micropatch]mpc852t
I use proting linux2.4.18 in mpc852t.
I found overlay smc1 and scc3 in dpram paramater.
I try to micropatch mpc852t. but it didn't
Let's me know how to use micropatch.
Thank you for reading a mail.
from cs. kim.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Benjamin Herrenschmidt @ 2004-12-02 11:24 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev list
In-Reply-To: <20041202120827.24635143@pirandello>
On Thu, 2004-12-02 at 12:08 +0100, Colin Leroy wrote:
> On 01 Dec 2004 at 16h12, Benjamin Herrenschmidt wrote:
>
> Hi,
>
> > This one fixes finally the cache flush problem that made cpufreq (on machines
> > using the PMU for the switch) and sleep/wake unreliable occasionally (memory
> > corruption would occur on some CPUs at least). It improves bits here or there
> > too, and adds the sungem wake-on-lan feature.
>
> By the way, I noticed a problem when the laptop is put to sleep by closing lid:
> wake-on-lan still works, but as soon as the laptop's awake, pbbuttonsd sleeps
> it again.
Useland shit :)
> Combined with the fact that a closed iBook G4 not sleeping shutdowns
> by itself, it would be nice if sungem could disable wol when suspending and the
> lid is closed - if such info is available.
Userland shit (bis) :)
> Or maybe such a thing should be done in the pbbuttonsd scripts by calling
> ethtool?
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Colin Leroy @ 2004-12-02 11:08 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <1101877409.5672.2.camel@gaston>
On 01 Dec 2004 at 16h12, Benjamin Herrenschmidt wrote:
Hi,
> This one fixes finally the cache flush problem that made cpufreq (on machines
> using the PMU for the switch) and sleep/wake unreliable occasionally (memory
> corruption would occur on some CPUs at least). It improves bits here or there
> too, and adds the sungem wake-on-lan feature.
By the way, I noticed a problem when the laptop is put to sleep by closing lid:
wake-on-lan still works, but as soon as the laptop's awake, pbbuttonsd sleeps
it again. Combined with the fact that a closed iBook G4 not sleeping shutdowns
by itself, it would be nice if sungem could disable wol when suspending and the
lid is closed - if such info is available.
Or maybe such a thing should be done in the pbbuttonsd scripts by calling
ethtool?
--
Colin
^ 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