* How to access uboot environment variables from Linux?
From: Heiko Schocher @ 2006-02-14 11:31 UTC (permalink / raw)
To: linuxppc-dev
Hello Bizhan,
> How could I access the uboot environment variables from Linux? For
> example I would like to access the "serverip"
have a look at
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux
Best regards,
Heiko
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: Andy Hawkins @ 2006-02-14 10:43 UTC (permalink / raw)
To: atul.sabharwal, bgholikh, linuxppc-dev
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA21A8@us-bv-m23.global.tektronix.net>
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
Hi,
> I think you will have to write a program to access and decode u-boot
environment setup
> format in linux.
Or you could use the one that comes with u-boot...
Look in tools/env
Andy
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 1584 bytes --]
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: Bizhan Gholikhamseh (bgholikh) @ 2006-02-14 12:45 UTC (permalink / raw)
To: Jenkins, Clive, atul.sabharwal, linuxppc-dev
I am aware of fw_printenv and fw_setenv. But they are uboot utilities,
and I am trying to access the parameter from Linux, what am I missing?
Thanks,
Bizhan=20
-----Original Message-----
From: Jenkins, Clive [mailto:Clive.Jenkins@xerox.com]=20
Sent: Tuesday, February 14, 2006 2:56 AM
To: atul.sabharwal@exgate.tek.com; Bizhan Gholikhamseh (bgholikh);
linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
Have you not discovered internet search engines?
If you paste the original question ("How could I access the uboot
environment variables from Linux?") into Google, you get the answer as
the first result:
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariables
InLinux
[Continuing the current style of top-posting. Sorry] Clive
=20
-----Original Message-----
From: linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org
[mailto:linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org] On
Behalf Of atul.sabharwal@exgate.tek.com
Sent: 14 February 2006 01:09
To: bgholikh@cisco.com; linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
I think you will have to write a program to access and decode u-boot
environment setup format in linux.
If you come across some open source app for this, plz. share with me. It
should be a standard method but typically a small optimization if you
want your main code to be independent of the boot loader your are using
or if you have common code base which works across multiple
processors/multiple loaders.
=20
--
Atul
From: linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org
[mailto:linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org] On
Behalf Of Bizhan Gholikhamseh (bgholikh)
Sent: Monday, February 13, 2006 4:54 PM
To: linuxppc-dev@ozlabs.org
Subject: How to access uboot environment variables from Linux?
=20
All,
How could I access the uboot environment variables from Linux? For
example I would like to access the "serverip"
and change that to a different ip address during run time.
=20
Many thanks in advance,
Bizhan
^ permalink raw reply
* [PATCH] kprobes depends on xmon
From: Olaf Hering @ 2006-02-14 13:10 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
KPROBES depends on XMON.
arch/powerpc/lib/step.c is only compiled if CONFIG_XMON is enabled.
arch/powerpc/kernel/built-in.o:
In function `resume_execution':arch/powerpc/kernel/kprobes.c:331: undefined reference to
`.emulate_step'
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.16-rc3-olh/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.16-rc3-olh.orig/arch/powerpc/Kconfig
+++ linux-2.6.16-rc3-olh/arch/powerpc/Kconfig
@@ -963,7 +963,7 @@ source "arch/powerpc/oprofile/Kconfig"
config KPROBES
bool "Kprobes (EXPERIMENTAL)"
- depends on PPC64
+ depends on PPC64 && XMON
help
Kprobes allows you to trap at almost any kernel address and
execute a callback function. register_kprobe() establishes
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: Jenkins, Clive @ 2006-02-14 13:31 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh), atul.sabharwal, linuxppc-dev
fw_printenv and fw_setenv _are_ normal userland Linux utilities, which
can be run from the shell command line. If you want your own program
to directly get/set environment variables, just call the appropriate
functions. Read and understand the code.
Clive
[continuing to top-post. sorry]
-----Original Message-----
From: Bizhan Gholikhamseh (bgholikh) [mailto:bgholikh@cisco.com]=20
Sent: 14 February 2006 12:45
To: Jenkins, Clive; atul.sabharwal@exgate.tek.com;
linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
I am aware of fw_printenv and fw_setenv. But they are uboot utilities,
and I am trying to access the parameter from Linux, what am I missing?
Thanks,
Bizhan=20
-----Original Message-----
From: Jenkins, Clive [mailto:Clive.Jenkins@xerox.com]=20
Sent: Tuesday, February 14, 2006 2:56 AM
To: atul.sabharwal@exgate.tek.com; Bizhan Gholikhamseh (bgholikh);
linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
Have you not discovered internet search engines?
If you paste the original question ("How could I access the uboot
environment variables from Linux?") into Google, you get the answer as
the first result:
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariables
InLinux
[Continuing the current style of top-posting. Sorry] Clive
=20
-----Original Message-----
From: linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org
[mailto:linuxppc-dev-bounces+clive.jenkins=3Dxerox.com@ozlabs.org] On
Behalf Of atul.sabharwal@exgate.tek.com
Sent: 14 February 2006 01:09
To: bgholikh@cisco.com; linuxppc-dev@ozlabs.org
Subject: RE: How to access uboot environment variables from Linux?
I think you will have to write a program to access and decode u-boot
environment setup format in linux.
If you come across some open source app for this, plz. share with me. It
should be a standard method but typically a small optimization if you
want your main code to be independent of the boot loader your are using
or if you have common code base which works across multiple
processors/multiple loaders.
=20
--
Atul
From: linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org
[mailto:linuxppc-dev-bounces+atul.sabharwal=3Dtek.com@ozlabs.org] On
Behalf Of Bizhan Gholikhamseh (bgholikh)
Sent: Monday, February 13, 2006 4:54 PM
To: linuxppc-dev@ozlabs.org
Subject: How to access uboot environment variables from Linux?
=20
All,
How could I access the uboot environment variables from Linux? For
example I would like to access the "serverip"
and change that to a different ip address during run time.
=20
Many thanks in advance,
Bizhan
^ permalink raw reply
* Re: 440gx GPIO
From: Ed Goforth @ 2006-02-14 13:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060214065934.GA12465@gate.ebshome.net>
I posted the original from home, and didn't have the contents of the
config register. It is
cfg 0x00103e00
Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
from the manual.
I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, but go=
t
"unresolved symbol ioremap64". From inspection of ioremap(), the
fixup for 0x40000700 translates to 0x140000700, and I get the same
values in my code as I see from a "/proc/ocotea/gpio".
Is my approach valid?
Thanks,
Ed
On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Tue, Feb 14, 2006 at 12:20:35AM -0500, Ed Goforth wrote:
> > I am struggling with a problem and I hope someone can give me some
> > pointers. We have a custom board with a 440gx. I need to drive GPIO11
> > low. The best as I can tell from the docs, I need to set bit 11 of the
> > TCR to 1 and bit 11 of the OR to 0 to do this.
>
> Check that this pin is enabled as GPIO not as a function pin
> (SDR0_PFC0 register).
>
> Also, just to be sure that you remapped GPIO registers correctly, use
> ioremap64 with full physical address (not just low 32 bits).
>
> --
> Eugene
>
>
^ permalink raw reply
* Gianfar is slower than fcc_enet on MPC8541 ???
From: Laurent Lagrange @ 2006-02-14 15:26 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I work on a cutom MPC8541 board with Linux 2.6.9.
The kernel activates the L1 cache (instructions and data)
and the L2 cache (entirely used as cache and not as sram).
I configure
1 FCC (FCC1),
2 TSECs with or without NAPI (no effect) but without stashing in L2 sram.
All PHYs are automatically configured in 100MB full duplex.
eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
eth1: Running with NAPI disabled
eth1: 64/64 RX/TX BD ring size
eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
Then I launch 3 simple TCP servers, one on each ports.
>From remote machines I runs 3 TCP clients.
The client sends messages of 1000 bytes,
The server receives and echoes the message
The client receives the echoed message, check the content
and sends a new message again.
The result is that the 2 TSECs are 2 times slower than the FCC.
If I run a "top" application on the board, I use less than 10% of the CPU
Each port consumes about 1/3 of the CPU.
Any idea on how to configure the gianfar driver ?
Thanks
Laurent
^ permalink raw reply
* Re: Gianfar is slower than fcc_enet on MPC8541 ???
From: Pantelis Antoniou @ 2006-02-14 15:28 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000001c6317b$148162c0$5201a8c0@GEG2400>
[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]
Hi Laurent,
I found that pretty hard to believe.
What are you measuring exactly?
Speed of replies? If so it's explainable since the TSECs use
NAPI.
Regards
Pantelis
On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
>
>
> Hello,
>
> I work on a cutom MPC8541 board with Linux 2.6.9.
> The kernel activates the L1 cache (instructions and data)
> and the L2 cache (entirely used as cache and not as sram).
>
> I configure
> 1 FCC (FCC1),
> 2 TSECs with or without NAPI (no effect) but without stashing in L2 sram.
> All PHYs are automatically configured in 100MB full duplex.
>
> eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
> eth0: Running with NAPI disabled
> eth0: 64/64 RX/TX BD ring size
> eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
> eth1: Running with NAPI disabled
> eth1: 64/64 RX/TX BD ring size
> eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
>
> Then I launch 3 simple TCP servers, one on each ports.
>
> From remote machines I runs 3 TCP clients.
> The client sends messages of 1000 bytes,
> The server receives and echoes the message
> The client receives the echoed message, check the content
> and sends a new message again.
>
> The result is that the 2 TSECs are 2 times slower than the FCC.
>
> If I run a "top" application on the board, I use less than 10% of the CPU
> Each port consumes about 1/3 of the CPU.
>
> Any idea on how to configure the gianfar driver ?
>
> Thanks
> Laurent
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2485 bytes --]
^ permalink raw reply
* RE: Gianfar is slower than fcc_enet on MPC8541 ???
From: Laurent Lagrange @ 2006-02-14 16:14 UTC (permalink / raw)
To: 'Pantelis Antoniou'; +Cc: linuxppc-embedded
In-Reply-To: <449c76a00602140728g3a9eb46sd70f23b894c4b96@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]
Hi Pantelis,
Thanks for the express reply.
I know that what I say seems incredible. But I don't understand what NAPI
does.
My measure is very simple. I display a message on the client when 1000
exchanges are done.
I already check the ifconfig stats on the board after some seconds.
The measures seems the same with or without NAPI.
More details ?
Thanks again
Laurent
-----Message d'origine-----
De : Pantelis Antoniou [mailto:pantelis.antoniou@gmail.com]
Envoyé : mar. 14 février 2006 16:29
À : Laurent Lagrange
Cc : linuxppc-embedded@ozlabs.org
Objet : Re: Gianfar is slower than fcc_enet on MPC8541 ???
Hi Laurent,
I found that pretty hard to believe.
What are you measuring exactly?
Speed of replies? If so it's explainable since the TSECs use
NAPI.
Regards
Pantelis
On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
Hello,
I work on a cutom MPC8541 board with Linux 2.6.9.
The kernel activates the L1 cache (instructions and data)
and the L2 cache (entirely used as cache and not as sram).
I configure
1 FCC (FCC1),
2 TSECs with or without NAPI (no effect) but without stashing in L2
sram.
All PHYs are automatically configured in 100MB full duplex.
eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
eth1: Running with NAPI disabled
eth1: 64/64 RX/TX BD ring size
eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
Then I launch 3 simple TCP servers, one on each ports.
From remote machines I runs 3 TCP clients.
The client sends messages of 1000 bytes,
The server receives and echoes the message
The client receives the echoed message, check the content
and sends a new message again.
The result is that the 2 TSECs are 2 times slower than the FCC.
If I run a "top" application on the board, I use less than 10% of the
CPU
Each port consumes about 1/3 of the CPU.
Any idea on how to configure the gianfar driver ?
Thanks
Laurent
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 5369 bytes --]
^ permalink raw reply
* Re: Gianfar is slower than fcc_enet on MPC8541 ???
From: Pantelis Antoniou @ 2006-02-14 16:17 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000201c63181$cf2c3180$5201a8c0@GEG2400>
[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]
Can you provide some more information?
Actual timings, and a tcpdump fragment?
On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
>
> Hi Pantelis,
>
> Thanks for the express reply.
>
> I know that what I say seems incredible. But I don't understand what NAPI
> does.
> My measure is very simple. I display a message on the client when 1000
> exchanges are done.
> I already check the ifconfig stats on the board after some seconds.
> The measures seems the same with or without NAPI.
>
> More details ?
> Thanks again
> Laurent
>
>
>
> -----Message d'origine-----
> *De :* Pantelis Antoniou [mailto:pantelis.antoniou@gmail.com]
> *Envoyé :* mar. 14 février 2006 16:29
> *À :* Laurent Lagrange
> *Cc :* linuxppc-embedded@ozlabs.org
> *Objet :* Re: Gianfar is slower than fcc_enet on MPC8541 ???
>
> Hi Laurent,
>
> I found that pretty hard to believe.
>
> What are you measuring exactly?
>
> Speed of replies? If so it's explainable since the TSECs use
> NAPI.
>
> Regards
>
> Pantelis
>
> On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
> >
> >
> > Hello,
> >
> > I work on a cutom MPC8541 board with Linux 2.6.9.
> > The kernel activates the L1 cache (instructions and data)
> > and the L2 cache (entirely used as cache and not as sram).
> >
> > I configure
> > 1 FCC (FCC1),
> > 2 TSECs with or without NAPI (no effect) but without stashing in L2
> > sram.
> > All PHYs are automatically configured in 100MB full duplex.
> >
> > eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
> > eth0: Running with NAPI disabled
> > eth0: 64/64 RX/TX BD ring size
> > eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
> > eth1: Running with NAPI disabled
> > eth1: 64/64 RX/TX BD ring size
> > eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
> >
> > Then I launch 3 simple TCP servers, one on each ports.
> >
> > From remote machines I runs 3 TCP clients.
> > The client sends messages of 1000 bytes,
> > The server receives and echoes the message
> > The client receives the echoed message, check the content
> > and sends a new message again.
> >
> > The result is that the 2 TSECs are 2 times slower than the FCC.
> >
> > If I run a "top" application on the board, I use less than 10% of the
> > CPU
> > Each port consumes about 1/3 of the CPU.
> >
> > Any idea on how to configure the gianfar driver ?
> >
> > Thanks
> > Laurent
> >
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
>
[-- Attachment #2: Type: text/html, Size: 5752 bytes --]
^ permalink raw reply
* Re: Gianfar is slower than fcc_enet on MPC8541 ???
From: Vitaly Bordug @ 2006-02-14 16:42 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <449c76a00602140817k4cf1af22w6d6c930a9d847ba@mail.gmail.com>
Laurent,
btw, have you gived netperf test a try?
It is a commonly-used tool to measure network performance, and has dozens of settings to test...
On Tue, 14 Feb 2006 11:17:46 -0500
Pantelis Antoniou <pantelis.antoniou@gmail.com> wrote:
> Can you provide some more information?
>
> Actual timings, and a tcpdump fragment?
>
> On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
> >
> > Hi Pantelis,
> >
> > Thanks for the express reply.
> >
> > I know that what I say seems incredible. But I don't understand what NAPI
> > does.
> > My measure is very simple. I display a message on the client when 1000
> > exchanges are done.
> > I already check the ifconfig stats on the board after some seconds.
> > The measures seems the same with or without NAPI.
> >
> > More details ?
> > Thanks again
> > Laurent
> >
> >
> >
> > -----Message d'origine-----
> > *De :* Pantelis Antoniou [mailto:pantelis.antoniou@gmail.com]
> > *Envoyé :* mar. 14 février 2006 16:29
> > *À :* Laurent Lagrange
> > *Cc :* linuxppc-embedded@ozlabs.org
> > *Objet :* Re: Gianfar is slower than fcc_enet on MPC8541 ???
> >
> > Hi Laurent,
> >
> > I found that pretty hard to believe.
> >
> > What are you measuring exactly?
> >
> > Speed of replies? If so it's explainable since the TSECs use
> > NAPI.
> >
> > Regards
> >
> > Pantelis
> >
> > On 2/14/06, Laurent Lagrange <lagrange@fr.oleane.com> wrote:
> > >
> > >
> > > Hello,
> > >
> > > I work on a cutom MPC8541 board with Linux 2.6.9.
> > > The kernel activates the L1 cache (instructions and data)
> > > and the L2 cache (entirely used as cache and not as sram).
> > >
> > > I configure
> > > 1 FCC (FCC1),
> > > 2 TSECs with or without NAPI (no effect) but without stashing in L2
> > > sram.
> > > All PHYs are automatically configured in 100MB full duplex.
> > >
> > > eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
> > > eth0: Running with NAPI disabled
> > > eth0: 64/64 RX/TX BD ring size
> > > eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
> > > eth1: Running with NAPI disabled
> > > eth1: 64/64 RX/TX BD ring size
> > > eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
> > >
> > > Then I launch 3 simple TCP servers, one on each ports.
> > >
> > > From remote machines I runs 3 TCP clients.
> > > The client sends messages of 1000 bytes,
> > > The server receives and echoes the message
> > > The client receives the echoed message, check the content
> > > and sends a new message again.
> > >
> > > The result is that the 2 TSECs are 2 times slower than the FCC.
> > >
> > > If I run a "top" application on the board, I use less than 10% of the
> > > CPU
> > > Each port consumes about 1/3 of the CPU.
> > >
> > > Any idea on how to configure the gianfar driver ?
> > >
> > > Thanks
> > > Laurent
> > >
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> >
> >
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: 440gx GPIO
From: Eugene Surovegin @ 2006-02-14 17:01 UTC (permalink / raw)
To: Ed Goforth; +Cc: linuxppc-embedded
In-Reply-To: <75b39f010602140548u18f30145tf2ddf529467b2605@mail.gmail.com>
On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
> I posted the original from home, and didn't have the contents of the
> config register. It is
> cfg 0x00103e00
> Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
> from the manual.
>
> I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, but got
> "unresolved symbol ioremap64". From inspection of ioremap(), the
> fixup for 0x40000700 translates to 0x140000700, and I get the same
> values in my code as I see from a "/proc/ocotea/gpio".
>
> Is my approach valid?
It seems to be.
Try writing the same GPIO output register value as you read from it
(without clearing bit 11). Also, try changing some other GPIO bit
(e.g. one which is not connected in your design). Maybe board hangs
exactly because you set GPIO bit 11 low :).
Also, connect scope to that GPIO pin and see what is really going on.
--
Eugene
^ permalink raw reply
* Re: 440gx GPIO
From: Ed Goforth @ 2006-02-14 17:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060214170140.GB12465@gate.ebshome.net>
On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
> On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
> > I posted the original from home, and didn't have the contents of the
> > config register. It is
> > cfg 0x00103e00
> > Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
> > from the manual.
> >
> > I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, bu=
t got
> > "unresolved symbol ioremap64". From inspection of ioremap(), the
> > fixup for 0x40000700 translates to 0x140000700, and I get the same
> > values in my code as I see from a "/proc/ocotea/gpio".
> >
> > Is my approach valid?
>
> It seems to be.
At least I've got that. :)
>
> Try writing the same GPIO output register value as you read from it
> (without clearing bit 11). Also, try changing some other GPIO bit
> (e.g. one which is not connected in your design). Maybe board hangs
> exactly because you set GPIO bit 11 low :).
I have successfully written back the same values that were read from
it. I will try your suggestion about fiddling with other GPIO bits
that we aren't (supposed to be) using.
>
> Also, connect scope to that GPIO pin and see what is really going on.
>
> --
> Eugene
>
Thanks,
Ed
^ permalink raw reply
* Re: Stability of MPC5200 FEC
From: John Rigby @ 2006-02-14 17:35 UTC (permalink / raw)
To: Asier Llano Palacios; +Cc: John Rigby, linuxppc-embedded
In-Reply-To: <1139818081.14894.45.camel@localhost.localdomain>
Asier,
I tried copying 700MB files to my lite board with ftp on sylvain's
latest kernel
and was not able to reproduce the problem. One thing I did see
though were lots of RX framing errors. I will investigate this further.
I consulted with someone in Freescale who knows a lot more about
bestcomm dma and the 5200 than me and his best guess was
that there is a problem in error handling. Can you have your
partner report what the error counts reported by ifconfig are?
This might give us some clue about what is leading to the problem.
Thanks
John
jrigby@freescale.com
jcrigby@gmail.com
On 2/13/06, Asier Llano Palacios <a.llano@ziv.es> wrote:
> El s=E1b, 11-02-2006 a las 16:28 +0100, Sylvain Munaut escribi=F3:
> > Asier Llano Palacios wrote:
> > Did you ever observe that behavior on a lite5200 ?
> > What is 'long uptime' and do you have sustained transfer during that
> > period ? (To try reproduice the problem).
>
> Weeks uptime. We don't work with the lite5200 for so long time, but our
> board is based on a lite5200, and the FEC configuration is exactly
> equal.
>
> > Also, what are the 'symptoms' ? (anything in dmesg ?)
>
> FEC doesn't work at all, everything else works. If using a console I
> execute 'ifconfig eth0 down && ifconfig eth0 up <IP>' the fec starts
> working again.
> I haven't reproduced it directly, but a partner and a customer. I'll try
> to reproduce this behaviour myself and bring back more information.
>
> > I haven't touched the FEC code much except to remove the
> > aligment code (newer bestcomm microcode doesn't require alignement of
> > the skb).
> >
> > You can send me the driver/net/fec_mpc52xx and arch/ppc/syslib/bestcomm
> > you're using, I'll tell you if there was major changes.
>
> I've sent to you the patches that I extracted from your kernel source
> tree some time ago.
> I have all the patches until the 1.2161 one. But I've only sent to you
> the ones related to the FEC and the bestcomm.
>
>
> --
> Asier Llano Palacios
> ZIV I+D Smart Energy Networks
> Dpto. Ingenier=EDa de Desarrollo.
>
> ZIV, Aplicaciones y Tecnolog=EDa.
> Parque Tecnol=F3gico, 210
> 48170 ZAMUDIO (Bizkaia)
>
> E-mail: a.llano@ziv.es
> Tlfno: 944037400
>
> ----------------------------------------- PLEASE NOTE -------------------=
------------------------
> This message, along with any attachments, may be confidential or legally =
privileged.
> It is intended only for the named person(s), who is/are the only authoriz=
ed recipients.
> If this message has reached you in error, kindly destroy it without revie=
w and notify the sender immediately.
> Thank you for your help.
> =B5SysCom uses virus scanning software but excludes any liability for vir=
uses contained in any attachment.
>
> ------------------------------------ ROGAMOS LEA ESTE TEXTO -------------=
------------------
> Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.
> Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas co=
mo =FAnico destinatario autorizado.
> Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin r=
evisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. Gracias=
por su colaboraci=F3n.
> =B5SysCom utiliza software antivirus, pero no se hace responsable de los =
virus contenidos en los ficheros anexos.
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
^ permalink raw reply
* Re: Gianfar is slower than fcc_enet on MPC8541 ???
From: Andy Fleming @ 2006-02-14 17:36 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000001c6317b$148162c0$5201a8c0@GEG2400>
My guess is that you are measuring latency. By default, interrupt
coalescing is on, and used to be set to very poor default values. In
drivers/net/gianfar.h, change the defaults to look like this:
#define DEFAULT_TX_COALESCE 1
#define DEFAULT_TXCOUNT 16
#define DEFAULT_TXTIME 4
#define DEFAULT_RX_COALESCE 1
#define DEFAULT_RXCOUNT 16
#define DEFAULT_RXTIME 4
The problem was that the timeout was quite long, so a small number of
packets would have to wait a whole millisecond (or more!) to get
processed. While it wouldn't affect bandwidth tests, which send many
packets, it would affect a simple test like ping.
If you don't feel like recompiling the kernel, you can use ethtool to
change the timeout values.
On Feb 14, 2006, at 09:26, Laurent Lagrange wrote:
>
> Hello,
>
> I work on a cutom MPC8541 board with Linux 2.6.9.
> The kernel activates the L1 cache (instructions and data)
> and the L2 cache (entirely used as cache and not as sram).
>
> I configure
> 1 FCC (FCC1),
> 2 TSECs with or without NAPI (no effect) but without stashing in L2
> sram.
> All PHYs are automatically configured in 100MB full duplex.
>
> eth0: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e0
> eth0: Running with NAPI disabled
> eth0: 64/64 RX/TX BD ring size
> eth1: Gianfar Ethernet Controller Version 1.1, 00:10:cd:48:48:e1
> eth1: Running with NAPI disabled
> eth1: 64/64 RX/TX BD ring size
> eth2: FCC ENET Version custom, 00:10:cd:48:48:e2
>
> Then I launch 3 simple TCP servers, one on each ports.
>
>> From remote machines I runs 3 TCP clients.
> The client sends messages of 1000 bytes,
> The server receives and echoes the message
> The client receives the echoed message, check the content
> and sends a new message again.
>
> The result is that the 2 TSECs are 2 times slower than the FCC.
>
> If I run a "top" application on the board, I use less than 10% of
> the CPU
> Each port consumes about 1/3 of the CPU.
>
> Any idea on how to configure the gianfar driver ?
>
> Thanks
> Laurent
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* u-boot relocate_code routine...
From: atul.sabharwal @ 2006-02-14 18:26 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>>You can reinvent the wheel, or read the documented experience of
>>others who went the same way long time ago.
I don't prefer re-inventing unless it adds some real value. I had
mentioned the same thing to the design team and changing the memory map
solved the problem.
My hypothesis is that there still is a bug in relocate_code routine as
if I comment out trap_init routine which relocates the exception vectors
from flash to ram (in this case 0x10000000), the processor dies. With
I-cache Off, and trap_init/interrupt_enable commented, it runs to u-boot
prompt.
With I-cache On, it dies 100% in this code.
Putting memory to 0x0 solves the problem and I am able to enable
trap_init & interrupt enable. Also, can turn I-cache on but seems to be
some cache problem as without BDI, it dies 100% but with BDI connected,
it runs with
Some fpga errors. =20
If you get a chance, you could review the relocate_code routine if it
handles all input data values. I am new to PPC assembly, so if this was
written in C/as, it would have been lot simpler. That is not important
but handling all data values seems to be a bug.
Best Regards,
Atul
^ permalink raw reply
* RE: How to access uboot environment variables from Linux?
From: atul.sabharwal @ 2006-02-14 18:33 UTC (permalink / raw)
To: Clive.Jenkins, bgholikh; +Cc: linuxppc-dev
>>Have you not discovered internet search engines?
Have you ever been hit by IP spoofing? Do you trust everything you find
on the net? =20
Just that you know something which somebody else does not know does not
entitle you to ask such questions...=20
--
Atul
^ permalink raw reply
* [PATCH] ppc32: handle Book E debug exceptions on kernel stack
From: Dale Farnsworth @ 2006-02-14 19:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
From: Dale Farnsworth <dale@farnsworth.org>
On PPC Book E processsors, we currently handle debug
exceptions on the critical exception stack (debug stack
for E200). This causes problems with the kgdb single
step handler, which calls smp_processor_id() and spin_lock(),
which reference current_thread_info(), which only works when
we are on the kernel stack.
We address this by switching to the kernel stack early while
handling debug exceptions. Note that the entry values of r10
and r11 are still saved on the critical exception (or debug) stack.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
This is low level code and needs careful review.
I've only tested it on mpc8548cds.
I didn't find the corresponding code in arch/powerpc,
so I assume Book E support hasn't been merged yet.
arch/ppc/kernel/head_booke.h | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
index f3d274c..a5eec51 100644
--- a/arch/ppc/kernel/head_booke.h
+++ b/arch/ppc/kernel/head_booke.h
@@ -92,7 +92,8 @@
* registers as the normal prolog above. Instead we use a portion of the
* critical/machine check exception stack at low physical addresses.
*/
-#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, exc_level_srr1) \
+#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, \
+ exc_level_srr1, kernel_sp_reg) \
mtspr exc_level##_SPRG,r8; \
BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the exc_level stack*/ \
stw r10,GPR10-INT_FRAME_SIZE(r8); \
@@ -100,7 +101,7 @@
mfcr r10; /* save CR in r10 for now */\
mfspr r11,exc_level_srr1; /* check whether user or kernel */\
andi. r11,r11,MSR_PR; \
- mr r11,r8; \
+ mr r11,kernel_sp_reg; \
mfspr r8,exc_level##_SPRG; \
beq 1f; \
/* COMING FROM USER MODE */ \
@@ -128,11 +129,13 @@
SAVE_2GPRS(7, r11)
#define CRITICAL_EXCEPTION_PROLOG \
- EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1)
+ EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1, r8)
+#define CRITICAL_EXCEPTION_ON_KERNEL_STACK_PROLOG \
+ EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1, r1)
#define DEBUG_EXCEPTION_PROLOG \
- EXC_LEVEL_EXCEPTION_PROLOG(DEBUG, SPRN_DSRR0, SPRN_DSRR1)
+ EXC_LEVEL_EXCEPTION_PROLOG(DEBUG, SPRN_DSRR0, SPRN_DSRR1, r1)
#define MCHECK_EXCEPTION_PROLOG \
- EXC_LEVEL_EXCEPTION_PROLOG(MCHECK, SPRN_MCSRR0, SPRN_MCSRR1)
+ EXC_LEVEL_EXCEPTION_PROLOG(MCHECK, SPRN_MCSRR0, SPRN_MCSRR1, r8)
/*
* Exception vectors.
@@ -268,7 +271,7 @@ label:
#else
#define DEBUG_EXCEPTION \
START_EXCEPTION(Debug); \
- CRITICAL_EXCEPTION_PROLOG; \
+ CRITICAL_EXCEPTION_ON_KERNEL_STACK_PROLOG; \
\
/* \
* If there is a single step or branch-taken exception in an \
^ permalink raw reply related
* Re: [PATCH] kprobes depends on xmon
From: Christoph Hellwig @ 2006-02-14 19:54 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060214131050.GA25820@suse.de>
On Tue, Feb 14, 2006 at 02:10:50PM +0100, Olaf Hering wrote:
>
> KPROBES depends on XMON.
> arch/powerpc/lib/step.c is only compiled if CONFIG_XMON is enabled.
>
> arch/powerpc/kernel/built-in.o:
> In function `resume_execution':arch/powerpc/kernel/kprobes.c:331: undefined reference to
> `.emulate_step'
Please compile step.o if either CONFIG_KPROBES or CONFIG_XMON is defined
instead of adding a depency.
^ permalink raw reply
* [PATCH] kprobes needs emulate_step()
From: Olaf Hering @ 2006-02-14 21:26 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20060214195442.GA21583@lst.de>
On Tue, Feb 14, Christoph Hellwig wrote:
> On Tue, Feb 14, 2006 at 02:10:50PM +0100, Olaf Hering wrote:
> >
> > KPROBES depends on XMON.
> > arch/powerpc/lib/step.c is only compiled if CONFIG_XMON is enabled.
> >
> > arch/powerpc/kernel/built-in.o:
> > In function `resume_execution':arch/powerpc/kernel/kprobes.c:331: undefined reference to
> > `.emulate_step'
>
> Please compile step.o if either CONFIG_KPROBES or CONFIG_XMON is defined
> instead of adding a depency.
(This one seems to work without warning about duplicate object files or
something.)
KPROBES needs emulate_step()
arch/powerpc/kernel/built-in.o:
In function `resume_execution':arch/powerpc/kernel/kprobes.c:331: undefined reference to
`.emulate_step'
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/lib/Makefile | 1 +
1 files changed, 1 insertion(+)
Index: linux-2.6.16-rc3-olh/arch/powerpc/lib/Makefile
===================================================================
--- linux-2.6.16-rc3-olh.orig/arch/powerpc/lib/Makefile
+++ linux-2.6.16-rc3-olh/arch/powerpc/lib/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PPC64) += checksum_64.o cop
memcpy_64.o usercopy_64.o mem_64.o string.o \
strcase.o
obj-$(CONFIG_PPC_ISERIES) += e2a.o
+obj-$(CONFIG_KPROBES) += sstep.o
obj-$(CONFIG_XMON) += sstep.o
ifeq ($(CONFIG_PPC64),y)
^ permalink raw reply
* Re: 440gx GPIO
From: Ed Goforth @ 2006-02-14 21:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <75b39f010602140910v39bc60dcxeba0acb6065a4bbd@mail.gmail.com>
On 2/14/06, Ed Goforth <egoforth@gmail.com> wrote:
> On 2/14/06, Eugene Surovegin <ebs@ebshome.net> wrote:
> > On Tue, Feb 14, 2006 at 08:48:56AM -0500, Ed Goforth wrote:
> > > I posted the original from home, and didn't have the contents of the
> > > config register. It is
> > > cfg 0x00103e00
> > > Which I interpret as having bit 11 set: "1 Enable GPIO11 as GPIO11"
> > > from the manual.
> > >
> > > I originally tried to call ioremap64(PPC440GX_GPIO0_ADDR,) directly, =
but got
> > > "unresolved symbol ioremap64". From inspection of ioremap(), the
> > > fixup for 0x40000700 translates to 0x140000700, and I get the same
> > > values in my code as I see from a "/proc/ocotea/gpio".
> > >
> > > Is my approach valid?
> >
> > It seems to be.
>
> At least I've got that. :)
>
> >
> > Try writing the same GPIO output register value as you read from it
> > (without clearing bit 11). Also, try changing some other GPIO bit
> > (e.g. one which is not connected in your design). Maybe board hangs
> > exactly because you set GPIO bit 11 low :).
>
> I have successfully written back the same values that were read from
> it. I will try your suggestion about fiddling with other GPIO bits
> that we aren't (supposed to be) using.
Well, I was able to manipulate GPIO9, GPIO10 and GPIO12. It's time to
turn it over to the hardware people.
> >
> > Also, connect scope to that GPIO pin and see what is really going on.
> >
> > --
> > Eugene
> >
Thanks for your feedback & suggestions.
Ed
^ permalink raw reply
* no sys folder under /proc
From: dibacco @ 2006-02-14 21:58 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I don't find the directory sys under /proc. Someone knows why?
Furthermore, printk from a driver are not found in /var/log/messages, wha=
t could be missing?
Bye,
Antonio.
^ permalink raw reply
* Re: no sys folder under /proc
From: Kumar Gala @ 2006-02-14 21:52 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUP6CT$AB62363556CBF94AF9C57C018B7462E3@libero.it>
On Tue, 14 Feb 2006, dibacco@inwind.it wrote:
> Hi,
>
> I don't find the directory sys under /proc. Someone knows why?
> Furthermore, printk from a driver are not found in /var/log/messages, what could be missing?
If I were to guess, the first issue maybe due to your kernel not having
something built into it like SYSCTL, but I'm only guessing thst SYSCTL is
related to /proc/sys.
The second requires you having something like syslog running.
- k
^ permalink raw reply
* Re: [PATCH] ppc32: handle Book E debug exceptions on kernel stack
From: Kumar Gala @ 2006-02-14 21:57 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20060214190700.GB17822@xyzzy.farnsworth.org>
Let me look at this a little, however, I'm amused by the
smp_processor_id() usage on 8548. Its a single core SoC, so any reason
SMP is turned on in your kernel?
Not, that your patch, isn't needed for a SMP Book-E, just wondering.
- k
On Tue, 14 Feb 2006, Dale Farnsworth wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> On PPC Book E processsors, we currently handle debug
> exceptions on the critical exception stack (debug stack
> for E200). This causes problems with the kgdb single
> step handler, which calls smp_processor_id() and spin_lock(),
> which reference current_thread_info(), which only works when
> we are on the kernel stack.
>
> We address this by switching to the kernel stack early while
> handling debug exceptions. Note that the entry values of r10
> and r11 are still saved on the critical exception (or debug) stack.
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
>
> ---
>
> This is low level code and needs careful review.
> I've only tested it on mpc8548cds.
>
> I didn't find the corresponding code in arch/powerpc,
> so I assume Book E support hasn't been merged yet.
>
> arch/ppc/kernel/head_booke.h | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
> index f3d274c..a5eec51 100644
> --- a/arch/ppc/kernel/head_booke.h
> +++ b/arch/ppc/kernel/head_booke.h
> @@ -92,7 +92,8 @@
> * registers as the normal prolog above. Instead we use a portion of the
> * critical/machine check exception stack at low physical addresses.
> */
> -#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, exc_level_srr1) \
> +#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, \
> + exc_level_srr1, kernel_sp_reg) \
> mtspr exc_level##_SPRG,r8; \
> BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the exc_level stack*/ \
> stw r10,GPR10-INT_FRAME_SIZE(r8); \
> @@ -100,7 +101,7 @@
> mfcr r10; /* save CR in r10 for now */\
> mfspr r11,exc_level_srr1; /* check whether user or kernel */\
> andi. r11,r11,MSR_PR; \
> - mr r11,r8; \
> + mr r11,kernel_sp_reg; \
> mfspr r8,exc_level##_SPRG; \
> beq 1f; \
> /* COMING FROM USER MODE */ \
> @@ -128,11 +129,13 @@
> SAVE_2GPRS(7, r11)
>
> #define CRITICAL_EXCEPTION_PROLOG \
> - EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1)
> + EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1, r8)
> +#define CRITICAL_EXCEPTION_ON_KERNEL_STACK_PROLOG \
> + EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1, r1)
> #define DEBUG_EXCEPTION_PROLOG \
> - EXC_LEVEL_EXCEPTION_PROLOG(DEBUG, SPRN_DSRR0, SPRN_DSRR1)
> + EXC_LEVEL_EXCEPTION_PROLOG(DEBUG, SPRN_DSRR0, SPRN_DSRR1, r1)
> #define MCHECK_EXCEPTION_PROLOG \
> - EXC_LEVEL_EXCEPTION_PROLOG(MCHECK, SPRN_MCSRR0, SPRN_MCSRR1)
> + EXC_LEVEL_EXCEPTION_PROLOG(MCHECK, SPRN_MCSRR0, SPRN_MCSRR1, r8)
>
> /*
> * Exception vectors.
> @@ -268,7 +271,7 @@ label:
> #else
> #define DEBUG_EXCEPTION \
> START_EXCEPTION(Debug); \
> - CRITICAL_EXCEPTION_PROLOG; \
> + CRITICAL_EXCEPTION_ON_KERNEL_STACK_PROLOG; \
> \
> /* \
> * If there is a single step or branch-taken exception in an \
>
^ permalink raw reply
* Re: [PATCH] ppc32: handle Book E debug exceptions on kernel stack
From: Dale Farnsworth @ 2006-02-14 22:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0602141556200.2609-100000@gate.crashing.org>
On Tue, Feb 14, 2006 at 03:57:58PM -0600, Kumar Gala wrote:
> Let me look at this a little, however, I'm amused by the
Thanks.
> smp_processor_id() usage on 8548. Its a single core SoC, so any reason
> SMP is turned on in your kernel?
I haven't turned on SMP in my 8548 kernel.
The kgdb singlestep code calls smp_processor_id() even on UP.
It doesn't really need to call it on UP, but smp_processor_id()
still should work. I would have preferred seeing #ifdef
CONFIG_SMP scattered throughout that code, but it's not my code.
Anyway, the smp_processor_id() calls happen to return the
correct value on UP, even on the critical exception stack,
since that stack area is initialized to 0.
The issue I actually hit is that for CONFIG_PREEMPT, the calls
to spin_lock() and spin_unlock() increment and decrement
current_thread_info()->preempt_count. This breaks things
when the preempt_count goes negative.
> Not, that your patch, isn't needed for a SMP Book-E, just wondering.
Yes, I'm looking forward to trying out a dual-core processor.
-Dale
> On Tue, 14 Feb 2006, Dale Farnsworth wrote:
>
> > From: Dale Farnsworth <dale@farnsworth.org>
> >
> > On PPC Book E processsors, we currently handle debug
> > exceptions on the critical exception stack (debug stack
> > for E200). This causes problems with the kgdb single
> > step handler, which calls smp_processor_id() and spin_lock(),
> > which reference current_thread_info(), which only works when
> > we are on the kernel stack.
> >
> > We address this by switching to the kernel stack early while
> > handling debug exceptions. Note that the entry values of r10
> > and r11 are still saved on the critical exception (or debug) stack.
> >
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
^ 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