* Re: porting linux on power pc mpc8xx
From: David Jander @ 2005-04-29 11:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY17-F312F5680735EFB466C3993BE240@phx.gbl>
Hi Prinson,
On Friday 29 April 2005 12:32, prinson varghese wrote:
> I am new to the embedded system development .How i can port linux kenel to
> power pc MPC 8XX
It is already ported to most known mpc8xx devices. You should start off, going
through the archives of this mailing-list, and visit this site:
http://www.denx.de
There you can download actual sources of linux-2.4 kernels. My advice, use
linux_2_4_devel cvs tree if you have no particular reason to use another
tree.
What processor do you use? What board? Is it a custom design or an existing
board?
You might be interested in u-boot also (the most commonly used bootloader for
these kind of embedded processors).
> and where i can get the kernel for the same?
www.denx.de, but probably also from www.mvista.com, and many others.
> awaiting rpaly ASAP
I am OK with this, but "ASAP" does not sound as polite as you should be
addressing a mailing list ;-)
Sincerely,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Embedded Linux on PQ III
From: Steven Russ @ 2005-04-29 12:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 672 bytes --]
I came across this site that has a PowerQUICC III with embedded linux, online so you can test it out. You are able to access a remote desktop that has the eval board set-up in a way that you can control the hardware, write code and download it to the board. They even have a licensed version of CodeWarrior to use. They don’t even charge you to use it. I’ve been on it for hours since I broke my MPC8260ADS ECOM board. Has anyone else seen these? http://www.techonline.com/community/ed_resource/virtualab/37245
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[-- Attachment #2: Type: text/html, Size: 1063 bytes --]
^ permalink raw reply
* Performance issue - VoIP application on Linux 2.4.22
From: bobys @ 2005-04-29 15:01 UTC (permalink / raw)
To: linuxppc-embedded
Hello everybody,
I have a multithreaded VoIP application in user space and a kernel driver
module on MPC 8248 based board.
During media data transfer( Video Call) I have observed one strange behavior
that at specific interval, cpu utilization is reaching to 100 % and then
rolls back to 0 %. This behavior repeats at regular intervals of time
during the call.
During this time, data rate and memory utilization is constant throughout
the Call. Also number of interrupts received and processed in the kernel
driver is constant. We have checked the code many times, but couldn't find
any of the threads/driver hogging the processor time.
We are using Linux kernel 2.4.22 with kernel preemption enabled and low
latency patch added. Please let me know anybody have seen same behavior and
how to sort this out.
Thanks and Regards
Boby
^ permalink raw reply
* problem compiling linux with ELDK: `bd_t' undeclared
From: Peter Asemann @ 2005-04-29 15:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi there!
I'm having a problem compiling Linux 2.4.25 as included in ELDK version
3.1 / Build 2004-11-10.
When trying to compile ppc_8xx/usr/src/linux-2.4.25/drivers/char/flash.c
it throws an error:
ppc_8xx-gcc -D__KERNEL__
-I/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer
-I/opt/asemann/eldk/ppc_8xx/usr/src/linux-2.4.25/arch/ppc -fsigned-char
-msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring
-nostdinc -I /opt/asemann/eldk/usr/lib/gcc-lib/ppc-linux/3.3.3/include
-DKBUILD_BASENAME=flash -c -o flash.o flash.c
flash.c: In function `flash_init':
flash.c:446: error: `bd_t' undeclared (first use in this function)
flash.c:446: error: (Each undeclared identifier is reported only once
flash.c:446: error: for each function it appears in.)
flash.c:446: error: `bd' undeclared (first use in this function)
flash.c:446: error: parse error before ')' token
make[3]: *** [flash.o] Error 1
It looks like it misses ppcboot.h or something. Is there something I
need to select in the kernel configuration to get rid of that error?
Thanks for reading,
Peter Asemann
^ permalink raw reply
* Re: rsync mirrors of linuxppc-* on source.mvista.com
From: David Woodhouse @ 2005-04-29 17:44 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <20050428153733.GD1221@smtp.west.cox.net>
On Thu, 2005-04-28 at 08:37 -0700, Tom Rini wrote:
> With the shift away from BitKeeper, and with PowerPC work having long
> shifted away from the linuxppc-* bitkeeper trees and towards a more
> direct relationship with Andrew / et al, is there any value in keeping
> the rsync mirrors of the last state of the linuxppc-* trees available?
>
> As there's no metadata, my slant is towards no. But it wouldn't be hard
> to have these still exist, if people speak up.
You could just convert them to git format?
--
dwmw2
^ permalink raw reply
* Re: rsync mirrors of linuxppc-* on source.mvista.com
From: Tom Rini @ 2005-04-29 17:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <1114796691.27227.224.camel@hades.cambridge.redhat.com>
On Fri, Apr 29, 2005 at 06:44:50PM +0100, David Woodhouse wrote:
> On Thu, 2005-04-28 at 08:37 -0700, Tom Rini wrote:
> > With the shift away from BitKeeper, and with PowerPC work having long
> > shifted away from the linuxppc-* bitkeeper trees and towards a more
> > direct relationship with Andrew / et al, is there any value in keeping
> > the rsync mirrors of the last state of the linuxppc-* trees available?
> >
> > As there's no metadata, my slant is towards no. But it wouldn't be hard
> > to have these still exist, if people speak up.
>
> You could just convert them to git format?
The linuxppc-* trees? They really aren't useful nowadays. Maybe the
linuxppc-2.4 tree should be, assuming Marcelo switches to git, and
there's some desire to continue the practice of letting work that's done
vs 2.4 exist somewhere in the community and added to.
But for 2.6, thankfully, folks are either using quilt (or similar) to
track their own work, or a project-specific tree, which I fully expect
to become git trees. I think we can finally kill the notion of a
'master' PPC tree that's not Linus' tree, via Andrew's tree.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] ppc32: backport Book-E decrementer handling fix from 2.6
From: Marcelo Tosatti @ 2005-04-29 13:56 UTC (permalink / raw)
To: Matt Porter, Paul Mackerras, Kumar Gala, linuxppc-embedded
In-Reply-To: <20050426184828.GA22714@gate.ebshome.net>
On Tue, Apr 26, 2005 at 11:48:28AM -0700, Eugene Surovegin wrote:
> Marcelo,
>
> this is backport of Matt Porter's patch for Book-E decrementer
> handling in timer_interrupt.
>
> The fix has been in 2.6 from August but never made it to 2.4, and I
> re-discovered this fix last week :)
>
> Original Matt's post to linuxppc-dev with explanation can be found at:
> http://ozlabs.org/pipermail/linuxppc-dev/2004-August/017458.html
Applied, thanks.
> Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
>
> ===== arch/ppc/kernel/time.c 1.16 vs edited =====
> --- 1.16/arch/ppc/kernel/time.c 2003-07-03 09:56:34 -07:00
> +++ edited/arch/ppc/kernel/time.c 2005-04-26 11:37:58 -07:00
> @@ -150,7 +150,7 @@
>
> hardirq_enter(cpu);
>
> - while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) < 0) {
> + while ((next_dec = tb_ticks_per_jiffy - tb_delta(&jiffy_stamp)) <= 0) {
> jiffy_stamp += tb_ticks_per_jiffy;
> if (!user_mode(regs))
> ppc_do_profile(instruction_pointer(regs));
^ permalink raw reply
* RE: gcc 3.4.3 on e500 (was Linux Kernel Issue: MPC8540 Errata (CPU29))
From: Chiradeep Vittal @ 2005-04-29 19:16 UTC (permalink / raw)
To: Kumar Gala, kylo; +Cc: linuxppc-embedded
We're planning to drop back to gcc-3.2.3 (built for 8245) for now.=20
Do you think there will be a substantial performance penalty for this?
Thanks
--
Chiradeep
-----Original Message-----
From: Kumar Gala [mailto:kumar.gala@freescale.com]=20
Sent: Thursday, April 28, 2005 4:19 PM
To: kylo@kylo.net
Cc: linuxppc-embedded@ozlabs.org; Chiradeep Vittal
Subject: Re: Linux Kernel Issue: MPC8540 Errata (CPU29)
All of the suggestions are good ones.. Also, in 2.6 I've recently =20
submitted patches that add emulation of these instructions in the =20
kernel.
Its odd, but I would have expected a GCC configured for e500 not to =20
generate the ld/st string instructions by default, but the -mno-string =20
is what we do in the kernel to ensure that.
- kumar
On Apr 28, 2005, at 5:21 PM, Kylo Ginsberg wrote:
> Chiradeep,
>
> I have the same issue with gcc3.4.3 and an e500 target.=A0 You can =
give
> gcc the -mno-string to inhibit generation of those load/store string
> instructions.=A0 I don't know if gcc can be configured such that its
> default is not to generate those instructions.
>
> Cheers,
> Kylo
>
> On 4/28/05, Chiradeep Vittal <chiradeep@matissenetworks.com> wrote:
> > It turns out to be a compiler issue.
> > We're using gcc 3.4.3 with optimization level -Os. The following =20
> program will generate the illegal instruction with -Os but not with =20
> -O2
>
> >=A0=A0=A0=A0=A0=A0=A0=A0 int main (int argc, char** argv)
> >=A0=A0=A0=A0=A0=A0=A0=A0 {
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 int seq[] =3D {0, 1, 2};
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return 0;
> >=A0=A0=A0=A0=A0=A0=A0=A0 }
> > The reason is that the compiler generates code with the stswi =20
> instruction which is not supported by the e500. Here's our compiler =20
> configuration:
>
> > Configured with: =20
> /home/steve/perforce/sw/opt/crosstool/build/powerpc-8540-linux-gnu/=20
> gcc-3.4.3-glibc-2.3.2/gcc-3.4.3/configure =20
> --target=3Dpowerpc-8540-linux-gnu --host=3Di686-host_pc-linux-gnu =20
> =
--prefix=3D/home/steve/perforce/sw/opt/cross-compile/powerpc-8540-linux- =
> gnu/gcc-3.4.3-glibc-2.3.2 --with-cpu=3D8540 =20
> --enable-cxx-flags=3D-mcpu=3D8540 =20
> =
--with-headers=3D/home/steve/perforce/sw/opt/cross-compile/powerpc-8540- =
> linux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540-linux-gnu/include =20
> =
--with-local-prefix=3D/home/steve/perforce/sw/opt/cross-compile/powerpc=20
> -8540-linux-gnu/gcc-3.4.3-glibc-2.3.2/powerpc-8540-linux-gnu =20
> --disable-nls --enable-threads=3Dposix --enable-symvers=3Dgnu =20
> --enable-__cxa_atexit --enable-languages=3Dc,c++ --enable-shared =20
> --enable-c99 --enable-long-long
>
> >
> > Any recommendations?
> >
> > Thanks
> > --
> > Chiradeep
> >
> > -----Original Message-----
> > From: Kumar Gala [mailto:kumar.gala@freescale.com]
> > Sent: Wednesday, April 27, 2005 11:37 AM
> > To: Chiradeep Vittal
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: Linux Kernel Issue: MPC8540 Errata (CPU29)
> >
> > On Apr 27, 2005, at 12:46 PM, Chiradeep Vittal wrote:
> >
> > > We're running Linux Kernel 2.4.26 on an 8540 ADS derivative. We're
> > >=A0 seeing an
> > > "illegal instruction" (SIGILL) exception under some circumstances
> > > (during a pthread_create call). We were wondering if this could =20
> be a
> > > symptom of
> > > CPU29 and if there is a patch available for CPU29.
> > >
> > > "CPU29 L1 instruction cache gets multiple entries for same line =20
> after
> > >=A0 change
> > > in MSR[IS] bit "
> > >
> > > www.freescale.com/files/32bit/doc/errata/MPC8540CE.pdf
> >
> > The way the Linux kernel manages the MMU on e500 it doesn't actually
> > ever modify MSR[IS] or MSR[DS].=A0 They are always zero so I dont =20
> believe
> > you are hitting this errata.
> >
> > Are you running with math emulation turned on?=A0 Do you know what =
the
> > instruction is that causes the SIGILL?
> >
> > - kumar
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
^ permalink raw reply
* gdb with pthreads on MPC8540
From: Chiradeep Vittal @ 2005-04-29 19:25 UTC (permalink / raw)
To: linuxppc-embedded
Has anybody got gdb 6.x working with the e500 (MPC85xx) to do
multithreaded debugging?
gdb gets a SIGTRAP upon a pthread_create, but doesn't seem to know what
to do with it. Seems like a simple configuration issue...
Configuration tested: Linux 2.4.26 on MPC8540 ADS derivative,
powerpc-8540-linux-gnu-gcc-3.4.3, libc-2.3.2 (libc.so.6), gdb (native)
6.2
Thanks
--
Chiradeep
^ permalink raw reply
* Re: MPC8245 custom board, Linux 2.4 kernel hangs after uncompressing
From: Kishore Devireddy @ 2005-04-29 20:54 UTC (permalink / raw)
To: Sam Song; +Cc: Atit_Shah, linuxppc-embedded
In-Reply-To: <20050422053530.43298.qmail@web15805.mail.cnb.yahoo.com>
SGkKCldoYXQgc2hvdWxkIEkgY2hhbmdlIHJlbGF0ZWQgdG8gTUNDUiB0byBkaXNhYmxlIFNEUkFN
IGJ1cnN0IG1vZGU/CgpUaGFua3MKS2lzaG9yZQoKT24gNC8yMS8wNSwgU2FtIFNvbmcgPHNhbWxp
bnV4cHBjQHlhaG9vLmNvbS5jbj4gd3JvdGU6Cj4gQXRpdF9TaGFoIDxBdGl0X1NoYWhAc2F0eWFt
LmNvbT4gd3JvdGWjugo+ID4gV2hhdCB3ZSBkaWQgd2FzIHZlcmlmaWVkIHRoZSB2YWx1ZSBvZiBQ
U0RNUiByZWdpc3Rlcgo+ID4gdmFsdWUgZm91bmQgaW4geW91ciBib2FyZCBzcGVjaWZpYyBoZWFk
ZXIgZmlsZSBpbgo+ID4gaW5jbHVkZS9jb25maWdzLzxib2FyZG5hbWUuaD4KPiAKPiBVbW1tLCBQ
U0RNUiByZWdpc3RlciBpcyBmb3IgODI2MCBwZXJoYXBzPyBJIGV2ZW4KPiBkaWRuJ3QgZmluZCBp
dCBpbiA4MjQ1VU0uIERvIHlvdSBtZWFuIE1DQ1Igb2YgODI0NT8KPiAKPiBUaGFua3MsCj4gCj4g
U2FtCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCj4gRG8gWW91IFlhaG9vIT8KPiAxNTDN8sf6TVAzt+i/8cvRo6y0+MT6tLPI69L0
wNa17szDCj4gaHR0cDovL211c2ljLnlpc291LmNvbS8KPiDDwMWuw/fQx9Om09C+odPQo6zL0bHp
w8DNvKGi0d7NvLrNv+HNvAo+IGh0dHA6Ly9pbWFnZS55aXNvdS5jb20KPiAxR77NyscxMDAw1dej
rNHFu6K159PK19TW+sCpyN2joQo+IGh0dHA6Ly9jbi5yZC55YWhvby5jb20vbWFpbF9jbi90YWcv
MWcvKmh0dHA6Ly9jbi5tYWlsLnlhaG9vLmNvbS9ldmVudC9tYWlsXzFnLwo+Cg==
^ permalink raw reply
* Re: problem compiling linux with ELDK: `bd_t' undeclared
From: Wolfgang Denk @ 2005-04-29 20:55 UTC (permalink / raw)
To: Peter Asemann; +Cc: linuxppc-embedded
In-Reply-To: <427256F5.8080903@web.de>
In message <427256F5.8080903@web.de> you wrote:
>
> I'm having a problem compiling Linux 2.4.25 as included in ELDK version
> 3.1 / Build 2004-11-10.
>
> When trying to compile ppc_8xx/usr/src/linux-2.4.25/drivers/char/flash.c
> it throws an error:
You are using an inappropriate configuration of the Linux kernel.
> It looks like it misses ppcboot.h or something. Is there something I
> need to select in the kernel configuration to get rid of that error?
Not to select, but to unselect: don't try enabling the CONFIG_FLASH
option if (1) you don't know exactly what you're doing *and* (2) you
are really using on of the boards supported by this driver (which is
obsolete und unsupported, btw.).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A failure will not appear until a unit has passed final inspection.
^ permalink raw reply
* RE: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to thestock linux-2.5 (updated)
From: Rune Torgersen @ 2005-04-29 22:23 UTC (permalink / raw)
To: Vitaly Bordug, Kumar Gala; +Cc: Tom Rini, linuxppc-embedded list
The patch works on MPC8266ADS board using PQ2FADS setup with a couple of
hacks to disable some stuff the PQ2 has that the 8266ADS doesn't
> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]=20
> Sent: Friday, April 29, 2005 06:29
> To: Kumar Gala
> Cc: Rune Torgersen; Wolfgang Denk; Tom Rini; linuxppc-embedded list
> Subject: Re: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge=20
> support to thestock linux-2.5 (updated)
>=20
> Kumar,
>=20
> This is what currently intended to represent on-chip PCI=20
> bridge support=20
> for PQ2 family.
> It's approved working on my 8272 and have a very good probably of the=20
> same on the PQ2FADS-VR board. It contains low-level (SIUMCR & CPLD IC=20
> chip select ) setup only for 8272 and PQ2FADS, considering=20
> that u-boot=20
> does this stuff for 8266 boards. The actual source files are=20
> renamed to=20
> m82xx_pci.[ch].
>=20
> Rune, can you test this for m8266/8265 ? I guess while IRQ stuff is=20
> nearly the same, this _should_ work as is or with minimum=20
> effort. Note=20
> that you'll need to define PCI_INT_TO_SIU in platforms/pq2ads.h (I=20
> suppose it's the same as PQ2FADS - SIU_INT_IRQ6, but I'm not sure).
>=20
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
>=20
> --=20
> Sincerely,=20
> Vitaly
>=20
>=20
^ permalink raw reply
* Re: 824x sandpoint and 2.6.x
From: Sam Song @ 2005-04-30 5:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
"Mark A. Greer" <mgreer@mvista.com> wrote:
[snip]
> Here is the output of a 7457 sandpoint on a very old
> root filesystem.
> Output for any other processor will be the same.
Thanks. Some useful hints inside.
[snip]
> ttyS0 at MMIO 0x0 (irq = 4) is a NS16550A
Mine is "ttyS0 at MMIO 0xfdfce500 (irq = 5) is a
16450". Have some ideas to try but I am on vacation:)
> ttyS1 at MMIO 0x0 (irq = 3) is a NS16550A
I masked ttyS1 manually.
Thanks again,
Have a nice Labor Day:)
Sam
_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
^ permalink raw reply
* test
From: sen lin @ 2005-04-30 8:47 UTC (permalink / raw)
To: Linuxppc-embedded
test
^ permalink raw reply
* 2.6.12-rc3-mm2: ppc pte_offset_map()
From: Sean Neakums @ 2005-05-01 15:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20050430164303.6538f47c.akpm@osdl.org>
On my Mackertosh (PowerBook5.4), build fails with the following:
fs/proc/task_mmu.c: In function `smaps_pte_range':
fs/proc/task_mmu.c:177: warning: implicit declaration of function `kmap_atomic'
fs/proc/task_mmu.c:177: error: `KM_PTE0' undeclared (first use in this function)
fs/proc/task_mmu.c:177: error: (Each undeclared identifier is reported only once
fs/proc/task_mmu.c:177: error: for each function it appears in.)
fs/proc/task_mmu.c:207: warning: implicit declaration of function `kunmap_atomic'
With the naive patch below, it builds with this warning and everything works.
fs/proc/task_mmu.c: In function `smaps_pte_range':
fs/proc/task_mmu.c:208: warning: passing arg 1 of `kunmap_atomic' makes pointer from integer without a cast
I tried including linux/highmem.h in asm-ppc/pgtable.h
(smaps_pte_range() -> pte_offset_map() -> kmap_atomic()), but that
doesn't work.
--- S12-rc3-mm2/fs/proc/task_mmu.c~ 2005-05-01 15:52:55.000000000 +0100
+++ S12-rc3-mm2/fs/proc/task_mmu.c 2005-05-01 15:23:22.000000000 +0100
@@ -1,4 +1,5 @@
#include <linux/mm.h>
+#include <linux/highmem.h>
#include <linux/hugetlb.h>
#include <linux/mount.h>
#include <linux/seq_file.h>
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: 2.6.12-rc3-mm2: ppc pte_offset_map()
From: Jesper Juhl @ 2005-05-01 15:50 UTC (permalink / raw)
To: Sean Neakums; +Cc: Andrew Morton, linuxppc-dev, linux-kernel
In-Reply-To: <6uu0lnf0gm.fsf@zork.zork.net>
On Sun, 1 May 2005, Sean Neakums wrote:
> On my Mackertosh (PowerBook5.4), build fails with the following:
>
> fs/proc/task_mmu.c: In function `smaps_pte_range':
> fs/proc/task_mmu.c:177: warning: implicit declaration of function `kmap_atomic'
> fs/proc/task_mmu.c:177: error: `KM_PTE0' undeclared (first use in this function)
> fs/proc/task_mmu.c:177: error: (Each undeclared identifier is reported only once
> fs/proc/task_mmu.c:177: error: for each function it appears in.)
> fs/proc/task_mmu.c:207: warning: implicit declaration of function `kunmap_atomic'
>
> With the naive patch below, it builds with this warning and everything works.
>
> fs/proc/task_mmu.c: In function `smaps_pte_range':
> fs/proc/task_mmu.c:208: warning: passing arg 1 of `kunmap_atomic' makes pointer from integer without a cast
>
Try this patch :
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
--- linux-2.6.12-rc3-mm2-orig/fs/proc/task_mmu.c 2005-05-01 04:04:25.000000000 +0200
+++ linux-2.6.12-rc3-mm2/fs/proc/task_mmu.c 2005-05-01 17:49:14.000000000 +0200
@@ -2,6 +2,7 @@
#include <linux/hugetlb.h>
#include <linux/mount.h>
#include <linux/seq_file.h>
+#include <linux/highmem.h>
#include <asm/elf.h>
#include <asm/uaccess.h>
@@ -204,7 +205,7 @@ static void smaps_pte_range(pmd_t *pmd,
}
}
} while (address < end);
- pte_unmap(pte);
+ pte_unmap((void *)pte);
}
static void smaps_pmd_range(pud_t *pud,
^ permalink raw reply
* Re: 2.6.12-rc3-mm2: ppc pte_offset_map()
From: Andrew Morton @ 2005-05-01 22:46 UTC (permalink / raw)
To: Jesper Juhl; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.62.0505011749280.2488@dragon.hyggekrogen.localhost>
Jesper Juhl <juhl-lkml@dif.dk> wrote:
>
> On Sun, 1 May 2005, Sean Neakums wrote:
>
> > On my Mackertosh (PowerBook5.4), build fails with the following:
> >
> > fs/proc/task_mmu.c: In function `smaps_pte_range':
> > fs/proc/task_mmu.c:177: warning: implicit declaration of function `kmap_atomic'
> > fs/proc/task_mmu.c:177: error: `KM_PTE0' undeclared (first use in this function)
> > fs/proc/task_mmu.c:177: error: (Each undeclared identifier is reported only once
> > fs/proc/task_mmu.c:177: error: for each function it appears in.)
> > fs/proc/task_mmu.c:207: warning: implicit declaration of function `kunmap_atomic'
> >
> > With the naive patch below, it builds with this warning and everything works.
> >
> > fs/proc/task_mmu.c: In function `smaps_pte_range':
> > fs/proc/task_mmu.c:208: warning: passing arg 1 of `kunmap_atomic' makes pointer from integer without a cast
> >
>
> Try this patch :
>
> Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
>
> --- linux-2.6.12-rc3-mm2-orig/fs/proc/task_mmu.c 2005-05-01 04:04:25.000000000 +0200
> +++ linux-2.6.12-rc3-mm2/fs/proc/task_mmu.c 2005-05-01 17:49:14.000000000 +0200
> @@ -2,6 +2,7 @@
> #include <linux/hugetlb.h>
> #include <linux/mount.h>
> #include <linux/seq_file.h>
> +#include <linux/highmem.h>
>
> #include <asm/elf.h>
> #include <asm/uaccess.h>
> @@ -204,7 +205,7 @@ static void smaps_pte_range(pmd_t *pmd,
> }
> }
> } while (address < end);
> - pte_unmap(pte);
> + pte_unmap((void *)pte);
> }
Should be
pte_unmap(ptep);
^ permalink raw reply
* Re: 2.6.12-rc3-mm2: ppc pte_offset_map()
From: Jesper Juhl @ 2005-05-01 23:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: Rogério Brito, linuxppc-dev, linux-kernel
In-Reply-To: <20050501154654.2bf7606d.akpm@osdl.org>
On Sun, 1 May 2005, Andrew Morton wrote:
> Jesper Juhl <juhl-lkml@dif.dk> wrote:
> >
> > On Sun, 1 May 2005, Sean Neakums wrote:
> >
> > > On my Mackertosh (PowerBook5.4), build fails with the following:
> > >
> > > fs/proc/task_mmu.c: In function `smaps_pte_range':
> > > fs/proc/task_mmu.c:177: warning: implicit declaration of function `kmap_atomic'
> > > fs/proc/task_mmu.c:177: error: `KM_PTE0' undeclared (first use in this function)
> > > fs/proc/task_mmu.c:177: error: (Each undeclared identifier is reported only once
> > > fs/proc/task_mmu.c:177: error: for each function it appears in.)
> > > fs/proc/task_mmu.c:207: warning: implicit declaration of function `kunmap_atomic'
> > >
> > > With the naive patch below, it builds with this warning and everything works.
> > >
> > > fs/proc/task_mmu.c: In function `smaps_pte_range':
> > > fs/proc/task_mmu.c:208: warning: passing arg 1 of `kunmap_atomic' makes pointer from integer without a cast
> > >
> >
> > Try this patch :
> >
> > Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
> >
> > --- linux-2.6.12-rc3-mm2-orig/fs/proc/task_mmu.c 2005-05-01 04:04:25.000000000 +0200
> > +++ linux-2.6.12-rc3-mm2/fs/proc/task_mmu.c 2005-05-01 17:49:14.000000000 +0200
> > @@ -2,6 +2,7 @@
> > #include <linux/hugetlb.h>
> > #include <linux/mount.h>
> > #include <linux/seq_file.h>
> > +#include <linux/highmem.h>
> >
> > #include <asm/elf.h>
> > #include <asm/uaccess.h>
> > @@ -204,7 +205,7 @@ static void smaps_pte_range(pmd_t *pmd,
> > }
> > }
> > } while (address < end);
> > - pte_unmap(pte);
> > + pte_unmap((void *)pte);
> > }
>
> Should be
>
> pte_unmap(ptep);
>
Of course, stupid me. I should have seen the
[...]
ptep = pte_offset_map(pmd, address);
[...]
pte = *ptep;
address += PAGE_SIZE;
ptep++;
[...]
bit a few lines above. Guess I should have spend more than 2min creating
the patch.
Thanks.
Here's an updated patch.
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
--- linux-2.6.12-rc3-mm2-orig/fs/proc/task_mmu.c 2005-05-01 04:04:25.000000000 +0200
+++ linux-2.6.12-rc3-mm2/fs/proc/task_mmu.c 2005-05-02 00:59:11.000000000 +0200
@@ -2,6 +2,7 @@
#include <linux/hugetlb.h>
#include <linux/mount.h>
#include <linux/seq_file.h>
+#include <linux/highmem.h>
#include <asm/elf.h>
#include <asm/uaccess.h>
@@ -204,7 +205,7 @@ static void smaps_pte_range(pmd_t *pmd,
}
}
} while (address < end);
- pte_unmap(pte);
+ pte_unmap(ptep);
}
static void smaps_pmd_range(pud_t *pud,
^ permalink raw reply
* [PATCH] ppc32: Workaround a cache flush issue on sleep
From: Benjamin Herrenschmidt @ 2005-05-02 1:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Linus Torvalds
Hi !
We are experiencing a problem when flushing the CPU caches before sleep
on some laptop models using the 750FX CPU rev 1.X. While I haven't been
able to figure out a proper explanation for what's going on, I do have a
workaround that seem to work reliably and allows those machine to sleep
and wakeup properly again. This should be applied for 2.6.12. I'll
re-update that code if/when I ever find exactly what is happening with
those CPU revisions.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/platforms/pmac_cache.S
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_cache.S 2005-04-24 11:37:38.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_cache.S 2005-04-24 12:00:46.000000000 +1000
@@ -64,27 +64,39 @@
mtspr SPRN_HID0,r4 /* Disable DPM */
sync
- /* disp-flush L1 */
- li r4,0x4000
- mtctr r4
+ /* Disp-flush L1. We have a weird problem here that I never
+ * totally figured out. On 750FX, using the ROM for the flush
+ * results in a non-working flush. We use that workaround for
+ * now until I finally understand what's going on. --BenH
+ */
+
+ /* ROM base by default */
lis r4,0xfff0
-1: lwzx r0,r0,r4
+ mfpvr r3
+ srwi r3,r3,16
+ cmplwi cr0,r3,0x7000
+ bne+ 1f
+ /* RAM base on 750FX */
+ li r4,0
+1: li r4,0x4000
+ mtctr r4
+1: lwz r0,0(r4)
addi r4,r4,32
bdnz 1b
sync
isync
- /* disable / invalidate / enable L1 data */
+ /* Disable / invalidate / enable L1 data */
mfspr r3,SPRN_HID0
- rlwinm r0,r0,0,~HID0_DCE
+ rlwinm r3,r3,0,~(HID0_DCE | HID0_ICE)
mtspr SPRN_HID0,r3
sync
isync
- ori r3,r3,HID0_DCE|HID0_DCI
+ ori r3,r3,(HID0_DCE|HID0_DCI|HID0_ICE|HID0_ICFI)
sync
isync
mtspr SPRN_HID0,r3
- xori r3,r3,HID0_DCI
+ xori r3,r3,(HID0_DCI|HID0_ICFI)
mtspr SPRN_HID0,r3
sync
@@ -110,11 +122,20 @@
lis r4,2
mtctr r4
lis r4,0xfff0
-1: lwzx r0,r0,r4
+1: lwz r0,0(r4)
+ addi r4,r4,32
+ bdnz 1b
+ sync
+ isync
+ lis r4,2
+ mtctr r4
+ lis r4,0xfff0
+1: dcbf 0,r4
addi r4,r4,32
bdnz 1b
sync
isync
+
/* now disable L2 */
rlwinm r5,r5,0,~L2CR_L2E
b 2f
@@ -135,6 +156,13 @@
mtspr SPRN_L2CR,r4
sync
isync
+
+ /* Wait for the invalidation to complete */
+1: mfspr r3,SPRN_L2CR
+ rlwinm. r0,r3,0,31,31
+ bne 1b
+
+ /* Clear L2I */
xoris r4,r4,L2CR_L2I@h
sync
mtspr SPRN_L2CR,r4
@@ -142,16 +170,18 @@
/* now disable the L1 data cache */
mfspr r0,SPRN_HID0
- rlwinm r0,r0,0,~HID0_DCE
+ rlwinm r0,r0,0,~(HID0_DCE|HID0_ICE)
mtspr SPRN_HID0,r0
sync
isync
/* Restore HID0[DPM] to whatever it was before */
sync
- mtspr SPRN_HID0,r8
+ mfspr r0,SPRN_HID0
+ rlwimi r0,r8,0,11,11 /* Turn back HID0[DPM] */
+ mtspr SPRN_HID0,r0
sync
-
+
/* restore DR and EE */
sync
mtmsr r11
@@ -201,7 +231,7 @@
mtctr r4
li r4,0
1:
- lwzx r0,r0,r4
+ lwz r0,0(r4)
addi r4,r4,32 /* Go to start of next cache line */
bdnz 1b
isync
^ permalink raw reply
* [PATCH] ppc32: More fixlet for pmac sound
From: Benjamin Herrenschmidt @ 2005-05-02 4:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Linus Torvalds
Hi !
As Al Viro noticed, my previous fix missed one instance of "device" in
the driver local debug code. Harmless unless you tweak the #define's in
there but still work fixing.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/sound/ppc/toonie.c
===================================================================
--- linux-work.orig/sound/ppc/toonie.c 2005-05-02 12:14:14.000000000 +1000
+++ linux-work/sound/ppc/toonie.c 2005-05-02 14:01:01.000000000 +1000
@@ -320,7 +320,7 @@
}
DBG("(I) GPIO device %s found, offset: %x, active state: %d !\n",
- device, gp->addr, gp->active_state);
+ name, gp->addr, gp->active_state);
return (np->n_intrs > 0) ? np->intrs[0].line : 0;
}
^ permalink raw reply
* [PATCH] ppc32: Fix might_sleep() warning with clock spreading
From: Benjamin Herrenschmidt @ 2005-05-02 6:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Linus Torvalds
Hi !
The clock spreading disable/enable code was called to late/early during
the suspend/resume code on some laptops and would trigger a
might_sleep() warning due to the down() call in the low level i2c code.
This fixes it by calling those functions earlier/later when interrupts
are still enabled.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/include/asm-ppc/pmac_feature.h
===================================================================
--- linux-work.orig/include/asm-ppc/pmac_feature.h 2005-05-02 10:49:57.000000000 +1000
+++ linux-work/include/asm-ppc/pmac_feature.h 2005-05-02 15:43:08.000000000 +1000
@@ -316,6 +316,9 @@
extern void pmac_suspend_agp_for_card(struct pci_dev *dev);
extern void pmac_resume_agp_for_card(struct pci_dev *dev);
+/* Used by the via-pmu driver for suspend/resume
+ */
+extern void pmac_tweak_clock_spreading(int enable);
/*
* The part below is for use by macio_asic.c only, do not rely
Index: linux-work/arch/ppc/platforms/pmac_feature.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_feature.c 2005-05-02 13:16:22.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_feature.c 2005-05-02 15:43:55.000000000 +1000
@@ -1591,8 +1591,10 @@
}
-static void __pmac pmac_tweak_clock_spreading(struct macio_chip* macio, int enable)
+void __pmac pmac_tweak_clock_spreading(int enable)
{
+ struct macio_chip* macio = &macio_chips[0];
+
/* Hack for doing clock spreading on some machines PowerBooks and
* iBooks. This implements the "platform-do-clockspreading" OF
* property as decoded manually on various models. For safety, we also
@@ -1707,9 +1709,6 @@
macio->type != macio_intrepid)
return -ENODEV;
- /* Disable clock spreading */
- pmac_tweak_clock_spreading(macio, 0);
-
/* We power off the wireless slot in case it was not done
* by the driver. We don't power it on automatically however
*/
@@ -1852,9 +1851,6 @@
UN_OUT(UNI_N_CLOCK_CNTL, save_unin_clock_ctl);
udelay(100);
- /* Enable clock spreading */
- pmac_tweak_clock_spreading(macio, 1);
-
return 0;
}
@@ -2822,7 +2818,7 @@
* clock spreading now. This should be a platform function but we
* don't do these at the moment
*/
- pmac_tweak_clock_spreading(&macio_chips[0], 1);
+ pmac_tweak_clock_spreading(1);
#endif /* CONFIG_POWER4 */
Index: linux-work/drivers/macintosh/via-pmu.c
===================================================================
--- linux-work.orig/drivers/macintosh/via-pmu.c 2005-05-02 10:48:11.000000000 +1000
+++ linux-work/drivers/macintosh/via-pmu.c 2005-05-02 15:45:49.000000000 +1000
@@ -2351,6 +2351,10 @@
return -EBUSY;
}
+ /* Disable clock spreading on some machines */
+ pmac_tweak_clock_spreading(0);
+
+ /* Stop preemption */
preempt_disable();
/* Make sure the decrementer won't interrupt us */
@@ -2417,11 +2421,12 @@
/* Re-enable local CPU interrupts */
local_irq_enable();
-
mdelay(100);
-
preempt_enable();
+ /* Re-enable clock spreading on some machines */
+ pmac_tweak_clock_spreading(1);
+
/* Resume devices */
device_resume();
^ permalink raw reply
* [PATCH] ppc/fcc_enet: replace schedule_timeout() with ssleep()
From: Nishanth Aravamudan @ 2005-05-02 6:26 UTC (permalink / raw)
To: dmalek; +Cc: Kernel-Janitors, linuxppc-embedded
In-Reply-To: <20050502061446.GB10173@us.ibm.com>
I couldn't find an appropriate entry in MAINTAINERS for this patch.
Use ssleep() instead of schedule_timeout() to guarantee the task delays
as expected.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
--- 2.6.12-rc3/arch/ppc/8260_io/fcc_enet.c 2005-04-29 11:03:03.000000000 -0700
+++ 2.6.12-rc3-dev/arch/ppc/8260_io/fcc_enet.c 2005-05-01 19:10:58.000000000 -0700
@@ -1305,12 +1305,11 @@ static void mii_parse_dm9161_scsr(uint m
static void mii_dm9161_wait(uint mii_reg, struct net_device *dev)
{
- int timeout = HZ;
+ int timeout_secs = 1;
/* Davicom takes a bit to come up after a reset,
* so wait here for a bit */
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(timeout);
+ ssleep(timeout_secs);
}
static phy_info_t phy_info_dm9161 = {
^ permalink raw reply
* Memory Usage Growth in File access
From: s.deepak @ 2005-05-02 6:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 1224 bytes --]
Hi All,
I am facing an issue in file operation, when we read/write continuously to a large file in our ppc 405 based device , memory usage shown in /proc/meminfo increases by the number of bytes accessed.And after closing the application also the memory used is not released and it goes to cached memory .
We are using 2.4.20 kernel in our device.We are not sure whether the /proc/meminfo shows the erroneous output or the file read/write routines got any problem.
Can anyone suggest me some idea how to trace out the problem.
I have given the sample code below.
The memory consumption grows and it takes about 10 MB memory space [10000 * 1024] when i run the below given code.
When i look into /proc/meminfo the free memory is reduced by 10 MB and Cache Memory & Used memory is increased by 10 mb after running this application.
When i run the below given code first time the memory grows,when i run succesively it doesn't grow again , may be using the already taken memory.
int main()
{
FILE *fp;
unsigned long int i;
unsigned char data[1024];
fp=fopen("test.txt","r");
for(i=0;i<10000;i++)
{
fread(data,1024,1,fp);
}
fclose(fp);
}
With Thanks & Regards,
Deepak S
[-- Attachment #1.2: Type: text/html, Size: 2246 bytes --]
[-- Attachment #2: BitDefender.txt --]
[-- Type: text/plain, Size: 824 bytes --]
--
This message contains information from GDA Technologies LTD and affiliates, and is intended for the sole use of the individual and entity to whom it is addressed. It may contain information, including any attachments, that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this electronic transmission in error, please notify the sender immediately by a "reply to sender only" message and destroy all electronic and hard copies of the communication, including attachments.
This message was scanned for spam and viruses by BitDefender.
^ permalink raw reply
* [PATCH] ppc32: platform-specific functions missing from kallsyms.
From: David Woodhouse @ 2005-05-02 7:57 UTC (permalink / raw)
To: akpm, linuxppc-dev
The PPC32 kernel puts platform-specific functions into separate sections
so that unneeded parts of it can be freed when we've booted and actually
worked out what we're running on today.
This makes kallsyms ignore those functions, because they're not between
_[se]text or _[se]inittext. Rather than teaching kallsyms about the
various pmac/chrp/etc sections, this patch adds '_[se]extratext' markers
for kallsyms.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- linux-2.6.11/arch/ppc/kernel/vmlinux.lds~ 2005-05-01 10:43:10.000000000 +0100
+++ linux-2.6.11/arch/ppc/kernel/vmlinux.lds 2005-05-02 08:06:52.000000000 +0100
@@ -147,6 +147,7 @@ SECTIONS
__init_end = .;
. = ALIGN(4096);
+ _sextratext = .;
__pmac_begin = .;
.pmac.text : { *(.pmac.text) }
.pmac.data : { *(.pmac.data) }
@@ -173,6 +174,7 @@ SECTIONS
.openfirmware.data : { *(.openfirmware.data) }
. = ALIGN(4096);
__openfirmware_end = .;
+ _eextratext = .;
__bss_start = .;
.bss :
--- linux-2.6.11/include/asm-generic/sections.h~ 2005-03-02 07:37:31.000000000 +0000
+++ linux-2.6.11/include/asm-generic/sections.h 2005-05-02 08:43:04.000000000 +0100
@@ -8,6 +8,8 @@ extern char _data[], _sdata[], _edata[];
extern char __bss_start[], __bss_stop[];
extern char __init_begin[], __init_end[];
extern char _sinittext[], _einittext[];
+extern char _sextratext[] __attribute__((weak));
+extern char _eextratext[] __attribute__((weak));
extern char _end[];
#endif /* _ASM_GENERIC_SECTIONS_H_ */
--- linux-2.6.11/scripts/kallsyms.c~ 2005-03-02 07:38:33.000000000 +0000
+++ linux-2.6.11/scripts/kallsyms.c 2005-05-02 08:09:11.000000000 +0100
@@ -67,7 +67,7 @@ struct sym_entry {
static struct sym_entry *table;
static int size, cnt;
-static unsigned long long _stext, _etext, _sinittext, _einittext;
+static unsigned long long _stext, _etext, _sinittext, _einittext, _sextratext, _eextratext;
static int all_symbols = 0;
struct token {
@@ -132,6 +132,10 @@ read_symbol(FILE *in, struct sym_entry *
_sinittext = s->addr;
else if (strcmp(str, "_einittext") == 0)
_einittext = s->addr;
+ else if (strcmp(str, "_sextratext") == 0)
+ _sextratext = s->addr;
+ else if (strcmp(str, "_eextratext") == 0)
+ _eextratext = s->addr;
else if (toupper(s->type) == 'A')
{
/* Keep these useful absolute symbols */
@@ -182,16 +186,18 @@ symbol_valid(struct sym_entry *s)
* and inittext sections are discarded */
if (!all_symbols) {
if ((s->addr < _stext || s->addr > _etext)
- && (s->addr < _sinittext || s->addr > _einittext))
+ && (s->addr < _sinittext || s->addr > _einittext)
+ && (s->addr < _sextratext || s->addr > _eextratext))
return 0;
/* Corner case. Discard any symbols with the same value as
- * _etext or _einittext, they can move between pass 1 and 2
- * when the kallsyms data is added. If these symbols move then
- * they may get dropped in pass 2, which breaks the kallsyms
- * rules.
+ * _etext _einittext or _eextratext; they can move between pass
+ * 1 and 2 when the kallsyms data is added. If these symbols
+ * move then they may get dropped in pass 2, which breaks the
+ * kallsyms rules.
*/
if ((s->addr == _etext && strcmp(s->sym + 1, "_etext")) ||
- (s->addr == _einittext && strcmp(s->sym + 1, "_einittext")))
+ (s->addr == _einittext && strcmp(s->sym + 1, "_einittext")) ||
+ (s->addr == _eextratext && strcmp(s->sym + 1, "_eextratext")))
return 0;
}
--- linux-2.6.11/kernel/kallsyms.c~ 2005-05-01 10:37:45.000000000 +0100
+++ linux-2.6.11/kernel/kallsyms.c 2005-05-02 08:42:59.000000000 +0100
@@ -46,6 +46,14 @@ static inline int is_kernel_inittext(uns
return 0;
}
+static inline int is_kernel_extratext(unsigned long addr)
+{
+ if (addr >= (unsigned long)_sextratext
+ && addr <= (unsigned long)_eextratext)
+ return 1;
+ return 0;
+}
+
static inline int is_kernel_text(unsigned long addr)
{
if (addr >= (unsigned long)_stext && addr <= (unsigned long)_etext)
@@ -169,7 +177,7 @@ const char *kallsyms_lookup(unsigned lon
namebuf[0] = 0;
if ((all_var && is_kernel(addr)) ||
- (!all_var && (is_kernel_text(addr) || is_kernel_inittext(addr)))) {
+ (!all_var && (is_kernel_text(addr) || is_kernel_inittext(addr) || is_kernel_extratext(addr)))) {
unsigned long symbol_end=0;
/* do a binary search on the sorted kallsyms_addresses array */
--
dwmw2
^ permalink raw reply
* Re: [PATCH] ppc32: platform-specific functions missing from kallsyms.
From: David Woodhouse @ 2005-05-02 8:28 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev
In-Reply-To: <1115020651.3287.0.camel@localhost.localdomain>
On Mon, 2005-05-02 at 08:57 +0100, David Woodhouse wrote:
> The PPC32 kernel puts platform-specific functions into separate sections
> so that unneeded parts of it can be freed when we've booted and actually
> worked out what we're running on today.
>
> This makes kallsyms ignore those functions, because they're not between
> _[se]text or _[se]inittext. Rather than teaching kallsyms about the
> various pmac/chrp/etc sections, this patch adds '_[se]extratext' markers
> for kallsyms.
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>
> --- linux-2.6.11/arch/ppc/kernel/vmlinux.lds~ 2005-05-01 10:43:10.000000000 +0100
> +++ linux-2.6.11/arch/ppc/kernel/vmlinux.lds 2005-05-02 08:06:52.000000000 +0100
Bah. s/vmlinux.lds/vmlinux.lds.S/
--- linux-2.6.11/arch/ppc/kernel/vmlinux.lds.S~ 2005-05-01 10:43:10.000000000 +0100
+++ linux-2.6.11/arch/ppc/kernel/vmlinux.lds.S 2005-05-02 08:06:52.000000000 +0100
@@ -147,6 +147,7 @@ SECTIONS
__init_end = .;
. = ALIGN(4096);
+ _sextratext = .;
__pmac_begin = .;
.pmac.text : { *(.pmac.text) }
.pmac.data : { *(.pmac.data) }
@@ -173,6 +174,7 @@ SECTIONS
.openfirmware.data : { *(.openfirmware.data) }
. = ALIGN(4096);
__openfirmware_end = .;
+ _eextratext = .;
__bss_start = .;
.bss :
--- linux-2.6.11/include/asm-generic/sections.h~ 2005-03-02 07:37:31.000000000 +0000
+++ linux-2.6.11/include/asm-generic/sections.h 2005-05-02 08:43:04.000000000 +0100
@@ -8,6 +8,8 @@ extern char _data[], _sdata[], _edata[];
extern char __bss_start[], __bss_stop[];
extern char __init_begin[], __init_end[];
extern char _sinittext[], _einittext[];
+extern char _sextratext[] __attribute__((weak));
+extern char _eextratext[] __attribute__((weak));
extern char _end[];
#endif /* _ASM_GENERIC_SECTIONS_H_ */
--- linux-2.6.11/scripts/kallsyms.c~ 2005-03-02 07:38:33.000000000 +0000
+++ linux-2.6.11/scripts/kallsyms.c 2005-05-02 08:09:11.000000000 +0100
@@ -67,7 +67,7 @@ struct sym_entry {
static struct sym_entry *table;
static int size, cnt;
-static unsigned long long _stext, _etext, _sinittext, _einittext;
+static unsigned long long _stext, _etext, _sinittext, _einittext, _sextratext, _eextratext;
static int all_symbols = 0;
struct token {
@@ -132,6 +132,10 @@ read_symbol(FILE *in, struct sym_entry *
_sinittext = s->addr;
else if (strcmp(str, "_einittext") == 0)
_einittext = s->addr;
+ else if (strcmp(str, "_sextratext") == 0)
+ _sextratext = s->addr;
+ else if (strcmp(str, "_eextratext") == 0)
+ _eextratext = s->addr;
else if (toupper(s->type) == 'A')
{
/* Keep these useful absolute symbols */
@@ -182,16 +186,18 @@ symbol_valid(struct sym_entry *s)
* and inittext sections are discarded */
if (!all_symbols) {
if ((s->addr < _stext || s->addr > _etext)
- && (s->addr < _sinittext || s->addr > _einittext))
+ && (s->addr < _sinittext || s->addr > _einittext)
+ && (s->addr < _sextratext || s->addr > _eextratext))
return 0;
/* Corner case. Discard any symbols with the same value as
- * _etext or _einittext, they can move between pass 1 and 2
- * when the kallsyms data is added. If these symbols move then
- * they may get dropped in pass 2, which breaks the kallsyms
- * rules.
+ * _etext _einittext or _eextratext; they can move between pass
+ * 1 and 2 when the kallsyms data is added. If these symbols
+ * move then they may get dropped in pass 2, which breaks the
+ * kallsyms rules.
*/
if ((s->addr == _etext && strcmp(s->sym + 1, "_etext")) ||
- (s->addr == _einittext && strcmp(s->sym + 1, "_einittext")))
+ (s->addr == _einittext && strcmp(s->sym + 1, "_einittext")) ||
+ (s->addr == _eextratext && strcmp(s->sym + 1, "_eextratext")))
return 0;
}
--- linux-2.6.11/kernel/kallsyms.c~ 2005-05-01 10:37:45.000000000 +0100
+++ linux-2.6.11/kernel/kallsyms.c 2005-05-02 08:42:59.000000000 +0100
@@ -46,6 +46,14 @@ static inline int is_kernel_inittext(uns
return 0;
}
+static inline int is_kernel_extratext(unsigned long addr)
+{
+ if (addr >= (unsigned long)_sextratext
+ && addr <= (unsigned long)_eextratext)
+ return 1;
+ return 0;
+}
+
static inline int is_kernel_text(unsigned long addr)
{
if (addr >= (unsigned long)_stext && addr <= (unsigned long)_etext)
@@ -169,7 +177,7 @@ const char *kallsyms_lookup(unsigned lon
namebuf[0] = 0;
if ((all_var && is_kernel(addr)) ||
- (!all_var && (is_kernel_text(addr) || is_kernel_inittext(addr)))) {
+ (!all_var && (is_kernel_text(addr) || is_kernel_inittext(addr) || is_kernel_extratext(addr)))) {
unsigned long symbol_end=0;
/* do a binary search on the sorted kallsyms_addresses array */
--
dwmw2
^ 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