Hello,
Martin, Tim wrote:
Could you tell me where exactly to get the xuartlite_serial.c
?
I could not find xuartlite_serial.c in the drivers folder
generated by EDK .
(\ppc405_0\libsrc\linux_mvl31_v1_01_b\linux\drivers\char\xilinx_uartlite
)
Here's the relevant snippet for
Hi!
Some fixes, improvements from last time:
- saving/restoring of some registers inside sleep code
(so bestcomm and pic patches can be dropped, yay)
- improvements in FEC code for deep-sleep
- set up wakeup GPIO so Efika can wake too
- patch against latest u-boot (doh)
Patches are based on
MPC52xx uart power management.
Not sure how exactly this should be written, but this seems
to work, and works around a few seconds delay in resume.
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Index: grant.git/drivers/serial/mpc52xx_uart.c
Suspend and resume for FEC on MPC52xx.
Note that resume is a bit different for lite5200b low-power mode.
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
drivers/net/fec_mpc52xx/fec.c | 60 --
drivers/net/fec_mpc52xx/fec_phy.c | 17 ++
Implement deep-sleep on MPC52xx.
SDRAM is put into self-refresh with help of SRAM code
(alternatives would be code in FLASH, I-cache).
Interrupt code must also not be in SDRAM, so put it
in I-cache.
MPC52xx core is static, so contents will remain intact even
with clocks turned off.
U-Boot part of Lite5200b low power mode support.
Puts SDRAM out of self-refresh and transfers control to
address saved at physical 0x0.
---
board/icecube/icecube.c | 50
1 file changed, 50 insertions(+)
Index:
Low-power mode implementation for Lite5200b.
Some I/O registers are also saved here.
A patch to U-Boot that wakes up SDRAM, and transfers control
to address saved at physical 0x0 is needed.
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/Makefile |3
On 3/15/07, Domen Puncer [EMAIL PROTECTED] wrote:
Trivial suspend and resume OF OHCI.
On MPC52xx turn off and on power to ports.
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Nak; see below
Index: grant.git/drivers/usb/host/ohci-ppc-of.c
On 3/15/07, Domen Puncer [EMAIL PROTECTED] wrote:
Low-power mode implementation for Lite5200b.
Some I/O registers are also saved here.
A patch to U-Boot that wakes up SDRAM, and transfers control
to address saved at physical 0x0 is needed.
I don't see any structural problems with this code,
I have a PPC8241 which does an
Oops: Exception in kernel mode, sig: 4 [#1]
PREEMPT
NIP: 0900 LR: C00E579C CTR: 3A55
When doing a 'tar -xvzf'. The NIP is pointing at the decrementer
interrupt, I believe.
As I understand the decrementer, this is basically the timer tick in the
ppc and
Hello.
Charles Krinke wrote:
I have a PPC8241 which does an
Oops: Exception in kernel mode, sig: 4 [#1]
PREEMPT
NIP: 0900 LR: C00E579C CTR: 3A55
When doing a 'tar -xvzf'. The NIP is pointing at the decrementer
interrupt, I believe.
As I understand the decrementer, this is
On 15/03/07 08:09 -0600, Grant Likely wrote:
On 3/15/07, Domen Puncer [EMAIL PROTECTED] wrote:
Low-power mode implementation for Lite5200b.
Some I/O registers are also saved here.
A patch to U-Boot that wakes up SDRAM, and transfers control
to address saved at physical 0x0 is needed.
I
On Wed, 2007-03-14 at 16:42, Benedict, Michael wrote:
dtc- development snapshot dtc-20060419.tar.gz and recent git
sources
U-boot - 1.2.0, git sources from denx.de, and git sources from freescale
Kernel - 2.6.20.1, 2.6.20.2, and freescale git sources
Do yourself a favor and get an
Obviously, you've got an exception in the decrementer exception
handler
itself -- and this was something like program check exception, judging
on the
signal you've got (SIGILL).
So, with that said:
What might be the causes of such an exception from the decrementer in
a
2.6.17.11
mtspr SPRN_SPRG0, r10
mtspr SPRN_SPRG1, r11
Which is, I believe, moving r10 to SPRG0 and r11 to SPRG1.
So, how do we know that r10 and r11 are always valid in an interrupt
context? Are we setting aside r10 and r11 somewhere else in
That doesn't matter to kernel at all -- they are
On Mar 15, 2007, at 1:55 PM, Charles Krinke wrote:
mtspr SPRN_SPRG0, r10
mtspr SPRN_SPRG1, r11
Which is, I believe, moving r10 to SPRG0 and r11 to SPRG1.
So, how do we know that r10 and r11 are always valid in an interrupt
context? Are we setting aside r10 and r11 somewhere else in
Can you post the oops that you are seeing, what you need to find out
is what instruction image that is causing the illegal instruction
exception. Once you have that it will be easier to figure out what's
going on.
- k
Dear Kumar:
Here is the Oops, and thank you for looking at this.
In message [EMAIL PROTECTED] you wrote:
Anyone knows which device is used to generate the system tick on 8xx
processor?
DEC
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell,
On Mar 15, 2007, at 4:17 PM, Charles Krinke wrote:
I ran a couple of more tests and the system did not Oops in the
timer_interupt except for the first test this morning. The last two
times, the NIP was
Oops: Exception in kernel mode, sig: 4 [#1]
PREEMPT
NIP: C002CE68 LR: C002CEC8 CTR:
Hello Domen,
* Domen Puncer [EMAIL PROTECTED] [15-03-07 10:57]:
Can you please try following patch.
ok, I patched the kernel now and was able to read the ic2 chip 100
times successfully. I will run the programm the next 20 hours and give
then a shot feedback.
But the first impression is good.
20 matches
Mail list logo
