On Thu, 21 April 2005 15:02:48 +0200, Marco Schramel wrote:
/dev # date /dev/mtd1
MTD_open
MTD_ioctl
MTD_write
MTD do_write_buffer(): software timeout
^
ERROR ERROR ERROR ERROR ERROR ERROR ERROR
This only occurs if i write the second
On Thu, 21 April 2005 18:55:52 -0700, Eugene Surovegin wrote:
On Thu, Apr 21, 2005 at 06:53:37PM -0700, Eugene Surovegin wrote:
On Fri, Apr 22, 2005 at 03:31:34AM +0200, J?rn Engel wrote:
[snip]
1. Erase the flash partition. Either
o eraseall /dev/mtdX or
o cat
Mark A. Greer mgreer at mvista.com wrote:
BTW, Could I use KGDB to try it?
It may help but it depends on how far you're getting
and what your problem is.
OK, Mark. Thanks so much for your help. Let me try
how far I could go:)
Sam
Wolfgang Denk wd at denx.de wrote:
Interesting to me as well. I also have such a
similar problem. But I wanna to know how I can
return to u-boot with software workaround after
kernel hanging.
Press the reset button?
The pity is that hardware reset doesn't work on my
board. Sadly...
-- next part --
A non-text attachment was scrubbed...
Name: hxie.vcf
Type: text/x-vcard
Size: 160 bytes
Desc: not available
Url :
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050422/a4be961f/attachment.vcf
://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050422/6b39522a/attachment.htm
From the log I gather that there is no exception. That's good news
What we did was verified the value of PSDMR register value found in your
board specific header file in include/configs/boardname.h
We changed this value and it worked fine. Its worth a try.
Atit
-Original Message-
From:
Suresh,
I think you fixed a symptom but not the problem. By default, the rx
buffers are indeed 32 bytes long (i.e., a cacheline in size). When
receiving, the mpsc will generate an interrupt when there is an error,
when the buffer is full (32 bytes--unlikely if you're typing), or
Atit_Shah Atit_Shah at satyam.com wrote?
What we did was verified the value of PSDMR register
value found in your board specific header file in
include/configs/boardname.h
Ummm, PSDMR register is for 8260 perhaps? I even
didn't find it in 8245UM. Do you mean MCCR of 8245?
Thanks,
Sam
All I know is PSDMR is for 8260 and it pertains to burst mode operation. I
don?t know MCCR :)
-Original Message-
From: Sam Song [mailto:[EMAIL PROTECTED]
Sent: Friday, April 22, 2005 11:05 AM
To: Atit_Shah; Kishore Devireddy
Cc: linuxppc-embedded at ozlabs.org
Subject: RE: MPC8245
Marcelo Tosatti wrote:
On Thu, Apr 21, 2005 at 03:32:39PM -0300, Marcelo Tosatti wrote:
Capture session of /proc/tlbmiss with 1 second interval:
Forgot to attach /proc/tlbmiss patch, here it is.
[snip]
Thanks Marcelo.
I'll try to run this on my 870 board mail the results.
Atit_Shah Atit_Shah at satyam.com wrote:
All I know is PSDMR is for 8260 and it pertains to
burst mode operation. I don?t know MCCR :)
OK, get it. Your experience is about 8260 not for
824x.
Thanks,
Sam
_
Do You Yahoo!?
Hello all!
Does anybody know ppclinux mailing archives with ability to search by
subject in them. I would appreciate a lot.
Kind regards,
Kirnasov A.
Google probably will do the similar job
using: site:http://ozlabs.org/pipermail/linuxppc-embedded/ {keyword}
Best Regards,
Leo
-Original Message-
From: linuxppc-embedded-bounces at ozlabs.org
[mailto:linuxppc-embedded-bounces at ozlabs.org] On Behalf Of
Sent:
Hello all!
My name is Alex. I am porting linux to shr4162 target. This is PPC based
target. It has Inic940P SCSI
controller. When attaching a SCSI disk I can monitor from time to time
the folloing problem:
even first request for
OK! Thanks for the info.
I've implemented the gfp_debug and fiddled around a bit. Memory
problems is not my specialty and the only new info attached to the error
message is:
This architecture does not implement dump_stack()
...Which seems fair for a ppc.
I have however carefully studied the
Hello,
could somebody give me some information about current
status of FEC support
in 2.6.x kernels for 8xx?
What I've already found:
-some code in arch/ppc/8xx_io, but it seems that it
isn't up to date.
- moreover there is a patch from Pantelis Antoniou,
FEC driver was moved to
On 4/20/05, Kishore Devireddy kishorekrd at gmail.com wrote:
Hi
I am trying to run Embedded linux (ELDK) (2.4 kerenl) on a custom powerpc
board,
which is similar to Artis A3000 board. This board has
mpc8245(XPC8245LZY266B), natsemi 83815 ethernet, 4MB intel e28f320
flash, 16MB winbond
Sam Song wrote:
had, is it possible to flush the content of __log_buf
after reset?
Sam,
I thought I finally noticed yesterday that you're using 2.4. If that is
the case, you want to dump log_buf not __log_buf.
Mark
Sylvain, I'm wondering what the status is of the linux-2.5-mpc52xx
tree that you're maintaining. Specifically, what patches have not yet
been merged into Linus' tree? Also, with the whole BK debacle, have
you given any thought to what you are going to transition to?
BTW, thank you very much for
Hi,
I've tested the Jon's patch with the changes by Jakob on ML300 board
couple days ago (just before 2.6.12-rc3) - works OK.
(got few rejects for some lite5200 files)
Thanks,
Andrei
Jakob Viketoft wrote:
Has any more happened on this off-list, or it is just in testing-mode
right now?
I
I should have asked what version of U-Boot you were using. I've had
U-Boot 1.1.1 on this thing from the beginning, but I've heard that some
people are sticking with 1.0 on production stuff.
I've found that I can't use the watchdog timer for a reboot, since it is
write once (SYCPR) and I'm
/linuxppc-embedded/attachments/20050422/a417dfe4/attachment.htm
On Fri, Apr 22, 2005 at 09:18:17AM +0300, Pantelis Antoniou wrote:
Marcelo Tosatti wrote:
On Thu, Apr 21, 2005 at 03:32:39PM -0300, Marcelo Tosatti wrote:
Capture session of /proc/tlbmiss with 1 second interval:
Forgot to attach /proc/tlbmiss patch, here it is.
[snip]
On Fri, Apr 22, 2005 at 12:46:38PM -0700, Paul Gortmaker wrote:
I should have asked what version of U-Boot you were using.
This is not relevant, because Linux doesn't use this checkstop
trick. It directly just jumps to U-Boot warm-reboot entry point.
--
Eugene
I am looking for information in the kernel or elsewhere about flash usage
statistics. I'm interested in knowing how
many times a sector has been erased and written to. This doesn't have to be
for all time, since other tools
can erase and write the flash (U-boot), but just what the activity during
On Fri, 2005-04-22 at 17:19 -0400, Jeff.Fellin at rflelect.com wrote:
I am looking for information in the kernel or elsewhere about flash usage
statistics. I'm interested in knowing how
many times a sector has been erased and written to. This doesn't have to be
for all time, since other tools
On Fri, Apr 22, 2005 at 05:19:17PM -0400, Jeff.Fellin at rflelect.com wrote:
I am looking for information in the kernel or elsewhere about flash usage
statistics. I'm interested in knowing how
many times a sector has been erased and written to. This doesn't have to be
for all time, since
On Fri, 2005-04-22 at 14:53 -0700, Eugene Surovegin wrote:
On Fri, Apr 22, 2005 at 05:19:17PM -0400, Jeff.Fellin at rflelect.com wrote:
I am looking for information in the kernel or elsewhere about flash usage
statistics. I'm interested in knowing how
many times a sector has been erased
Dan,
I haven't heard your opinion on Joakim's proposed change yet.
It looks plausible, and its more complete than dcbst's reimplementation
with 8xx specific cache functions (because it also covers userspace dcbst
callers).
I would love to see this getting fixed in v2.6 mainline.
Thanks
On
On Sat, Apr 23, 2005 at 12:25:56AM +0200, Wolfgang Denk wrote:
In message 20050422210610.GA9158 at gate.ebshome.net you wrote:
This is not relevant, because Linux doesn't use this checkstop
trick. It directly just jumps to U-Boot warm-reboot entry point.
Which is a bad design desicion,
31 matches
Mail list logo
