* [PATCH] powerpc: Fix typo in powermac platform functions
From: Benjamin Herrenschmidt @ 2006-09-04 0:36 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linuxppc-dev list, Paul Mackerras
New sparse caught that typo which could have caused erratic hardware
behaviour on some machines if the platform functions are used by the
firmware to change bits in some FCR registers.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/platforms/powermac/pfunc_base.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/pfunc_base.c 2006-07-04 09:37:03.000000000 +1000
+++ linux-work/arch/powerpc/platforms/powermac/pfunc_base.c 2006-09-04 10:34:02.000000000 +1000
@@ -256,7 +256,7 @@
.write_reg32 = macio_do_write_reg32,
.read_reg32 = macio_do_read_reg32,
.write_reg8 = macio_do_write_reg8,
- .read_reg32 = macio_do_read_reg8,
+ .read_reg8 = macio_do_read_reg8,
.read_reg32_msrx = macio_do_read_reg32_msrx,
.read_reg8_msrx = macio_do_read_reg8_msrx,
.write_reg32_slm = macio_do_write_reg32_slm,
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Benjamin Herrenschmidt @ 2006-09-03 21:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0609031432430.27779@g5.osdl.org>
On Sun, 2006-09-03 at 14:33 -0700, Linus Torvalds wrote:
>
> On Mon, 4 Sep 2006, Benjamin Herrenschmidt wrote:
> >
> > I'll send a fix later today. I don't think the read32 is used that much
> > in practice, but yeah, that could have cause subtle issues on some
> > machine....
>
> Well, it's not only read32 that is broken. read8 will obviously be NULL,
> which may or may not mean that it is ever actually used.
>
> Not knowing how this actually all ties together with users means that I
> didn't just want to check in the obvious fix..
Those things are used to "interpret" kind of blobs provided by the
firmware that muck around various magic IOs and control bits in Apple
ASIC. The "read" variants are rarely used (except for GPIOs but it's a
different set of primitives), except in a few cases where those blobs
are doing read, then and/or a bit, then write back. Is difficult to tell
precisely on what machine and in what circumstances though the firmware
will have used those and thus in which case we have a subtle breakage or
on the contrary subtely hiding a problem... I would fix them for 2.6.18
anyway.
Ben.
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Linus Torvalds @ 2006-09-03 21:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1157318122.32334.8.camel@localhost.localdomain>
On Mon, 4 Sep 2006, Benjamin Herrenschmidt wrote:
>
> I'll send a fix later today. I don't think the read32 is used that much
> in practice, but yeah, that could have cause subtle issues on some
> machine....
Well, it's not only read32 that is broken. read8 will obviously be NULL,
which may or may not mean that it is ever actually used.
Not knowing how this actually all ties together with users means that I
didn't just want to check in the obvious fix..
Linus
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Benjamin Herrenschmidt @ 2006-09-03 21:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0609031213310.27779@g5.osdl.org>
On Sun, 2006-09-03 at 12:16 -0700, Linus Torvalds wrote:
> Hmm.
>
> I wrote a sparse extension that warns if an initializer tries to
> initialize the same entry multiple times.
>
> Look what it found:
>
> - arch/powerpc/platforms/powermac/pfunc_base.c:259
>
> static struct pmf_handlers macio_mmio_handlers = {
> .write_reg32 = macio_do_write_reg32,
> .read_reg32 = macio_do_read_reg32,
> .write_reg8 = macio_do_write_reg8,
> .read_reg32 = macio_do_read_reg8,
Yeah, a typo :) Go sparse !
I'll send a fix later today. I don't think the read32 is used that much
in practice, but yeah, that could have cause subtle issues on some
machine....
Ben.
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Segher Boessenkool @ 2006-09-03 20:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0609031227220.27779@g5.osdl.org>
>>> I wrote a sparse extension that warns if an initializer tries to
>>> initialize
>>> the same entry multiple times.
>>
>> Ugh, I expected the C compiler to catch this... :-/
>
> Yeah, me too.
Long ago, GCC used to catch this (with an error). C99 however
requires the overwriting behaviour. Having a warning would be
nice though; this is http://gcc.gnu.org/PR24010 .
Segher
^ permalink raw reply
* Re: Serial problem with MPC8241-based board
From: Guennadi Liakhovetski @ 2006-09-03 19:58 UTC (permalink / raw)
To: Zoltan HERPAI; +Cc: linuxppc-embedded
In-Reply-To: <44FAF68F.1080206@uid0.hu>
On Sun, 3 Sep 2006, Zoltan HERPAI wrote:
> I've recently acquired an Allnet 6250 NAS, which has an MPC8241-based
> board. Since its GPL tarball is not available fully, I began to build a
that's where I'd start from - are at least kernel sources completely
available? If not - would you consider politely asking the manufacturer
for them?
> toolchain based on gcc-3.4.6 and binutils-2.16.1, and an up-to-date
> kernel for it. PPCboot states that this is a Sandpoint 8241 Unity board,
> so the platforms/sandpoint.* was chosen as a starting point, however,
> after rewriting the irq and ioport values in sandpoint.h to the ones
> (irq 137, ioport 0x80004500), no output came out of the serial port.
> After a few days of tweaking around with variables is sandpoint.h, a
> google session revealed that this board is 99% the same as the Buffalo
> Linkstation's is, which has a 2.6.x port also, but those kernels are
> also failing to display any output.
Well, on Linkstation (at least on KuroboxHG) serial port 0 (0x80004500)
has irq 25 under 2.6. So, at least the irq assignment is different...
> Can anyone shed some light on what points should I check and what may I
> have done wrong?
No light, sorry, but some info - Mark Greer (CC'ed) has ported sandpoint
code recently from arch/ppc to arch/powerpc and to using the flattend
device tree, which is a general trend now. He has send his patches to the
list a couple of times. This work also depends on the boot-wrapper
development for non Open-Firmware platforms. I'm trying to do the same for
Kurobox(HG) / Linkstation, based on Mark's work. So, I think, it would be
useful if you could do your port also directly under arch/powerpc too
instead of arch/ppc.
Mark, may I use this opportunity to ask you for your current consistent
snapshot of both powerpc/boot and powerpc/platforms and whatever others? I
can compile a kernel with ARCH=powerpc for linkstation, now I have to find
a way to boot it. My choices are kexec or u-boot. Neither will run
out-of-the-box, so...
BTW, I would be greatful for any help with setting up kexec.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Linus Torvalds @ 2006-09-03 19:29 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <44FB2BAF.1080509@ru.mvista.com>
On Sun, 3 Sep 2006, Sergei Shtylyov wrote:
>
> Linus Torvalds wrote:
>
> > I wrote a sparse extension that warns if an initializer tries to initialize
> > the same entry multiple times.
>
> Ugh, I expected the C compiler to catch this... :-/
Yeah, me too. The reason I wrote the sparse logic to catch it was that I
got another patch where I noticed what was going on, and the author said
he had compile-tested it without any warnings. So gcc obviously does _not_
warn about the obvious error.
> Cut and paste error, should be .read_reg8...
Yeah, the fix is obvious, but somebody who has more knowledge about this
particular piece of code and how it would affect things should test that
the bug wasn't hiding somethign else on a piece of hardware that is
relevant to that initializer (which I don't know what it would be).
Linus
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Sergei Shtylyov @ 2006-09-03 19:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0609031213310.27779@g5.osdl.org>
Hello.
Linus Torvalds wrote:
> I wrote a sparse extension that warns if an initializer tries to
> initialize the same entry multiple times.
Ugh, I expected the C compiler to catch this... :-/
> Look what it found:
> - arch/powerpc/platforms/powermac/pfunc_base.c:259
>
> static struct pmf_handlers macio_mmio_handlers = {
> .write_reg32 = macio_do_write_reg32,
> .read_reg32 = macio_do_read_reg32,
> .write_reg8 = macio_do_write_reg8,
> .read_reg32 = macio_do_read_reg8,
Cut and paste error, should be .read_reg8...
> .read_reg32_msrx = macio_do_read_reg32_msrx,
> .read_reg8_msrx = macio_do_read_reg8_msrx,
> .write_reg32_slm = macio_do_write_reg32_slm,
> .write_reg8_slm = macio_do_write_reg8_slm,
> .delay = macio_do_delay,
> };
> Can anybody see anything suspicious there?
I'm sorry for spoiling the fun for everybody else. ;-)
WBR, Sergei
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Linus Torvalds @ 2006-09-03 19:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17654.26321.851991.285528@cargo.ozlabs.ibm.com>
Hmm.
I wrote a sparse extension that warns if an initializer tries to
initialize the same entry multiple times.
Look what it found:
- arch/powerpc/platforms/powermac/pfunc_base.c:259
static struct pmf_handlers macio_mmio_handlers = {
.write_reg32 = macio_do_write_reg32,
.read_reg32 = macio_do_read_reg32,
.write_reg8 = macio_do_write_reg8,
.read_reg32 = macio_do_read_reg8,
.read_reg32_msrx = macio_do_read_reg32_msrx,
.read_reg8_msrx = macio_do_read_reg8_msrx,
.write_reg32_slm = macio_do_write_reg32_slm,
.write_reg8_slm = macio_do_write_reg8_slm,
.delay = macio_do_delay,
};
Can anybody see anything suspicious there?
Linus
^ permalink raw reply
* Re: Serial problem with MPC8241-based board
From: Zoltan HERPAI @ 2006-09-03 18:13 UTC (permalink / raw)
To: Michael Galassi; +Cc: linuxppc-embedded
In-Reply-To: <200609031642.k83GgOuo089969@penguin.ncube.com>
None of the iterations worked with the Sandpoint and Linkstation setups.
Is there some way to test basic serial communication within the kernel,
to at least see if the CPU initialization is done correctly?
-w-
Michael Galassi wrote:
>> I've recently acquired an Allnet 6250 NAS, which has an MPC8241-based
>> board. Since its GPL tarball is not available fully, I began to build a
>> toolchain based on gcc-3.4.6 and binutils-2.16.1, and an up-to-date
>> kernel for it. PPCboot states that this is a Sandpoint 8241 Unity board,
>> so the platforms/sandpoint.* was chosen as a starting point, however,
>> after rewriting the irq and ioport values in sandpoint.h to the ones
>> (irq 137, ioport 0x80004500), no output came out of the serial port.
>> After a few days of tweaking around with variables is sandpoint.h, a
>> google session revealed that this board is 99% the same as the Buffalo
>> Linkstation's is, which has a 2.6.x port also, but those kernels are
>> also failing to display any output.
>> Can anyone shed some light on what points should I check and what may I
>> have done wrong?
>>
>
> I've recently spent a bunch of time chasing after display issues related
> to the goofy way Linux handles consoles early on. Try removing console=
> from your boot arguments and see where that puts you.
>
> -michael
>
>
^ permalink raw reply
* Re: Serial problem with MPC8241-based board
From: Michael Galassi @ 2006-09-03 16:42 UTC (permalink / raw)
To: Zoltan HERPAI; +Cc: linuxppc-embedded
In-Reply-To: <44FAF68F.1080206@uid0.hu>
>I've recently acquired an Allnet 6250 NAS, which has an MPC8241-based
>board. Since its GPL tarball is not available fully, I began to build a
>toolchain based on gcc-3.4.6 and binutils-2.16.1, and an up-to-date
>kernel for it. PPCboot states that this is a Sandpoint 8241 Unity board,
>so the platforms/sandpoint.* was chosen as a starting point, however,
>after rewriting the irq and ioport values in sandpoint.h to the ones
>(irq 137, ioport 0x80004500), no output came out of the serial port.
>After a few days of tweaking around with variables is sandpoint.h, a
>google session revealed that this board is 99% the same as the Buffalo
>Linkstation's is, which has a 2.6.x port also, but those kernels are
>also failing to display any output.
>Can anyone shed some light on what points should I check and what may I
>have done wrong?
I've recently spent a bunch of time chasing after display issues related
to the goofy way Linux handles consoles early on. Try removing console=
from your boot arguments and see where that puts you.
-michael
^ permalink raw reply
* Serial problem with MPC8241-based board
From: Zoltan HERPAI @ 2006-09-03 15:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I've recently acquired an Allnet 6250 NAS, which has an MPC8241-based
board. Since its GPL tarball is not available fully, I began to build a
toolchain based on gcc-3.4.6 and binutils-2.16.1, and an up-to-date
kernel for it. PPCboot states that this is a Sandpoint 8241 Unity board,
so the platforms/sandpoint.* was chosen as a starting point, however,
after rewriting the irq and ioport values in sandpoint.h to the ones
(irq 137, ioport 0x80004500), no output came out of the serial port.
After a few days of tweaking around with variables is sandpoint.h, a
google session revealed that this board is 99% the same as the Buffalo
Linkstation's is, which has a 2.6.x port also, but those kernels are
also failing to display any output.
Can anyone shed some light on what points should I check and what may I
have done wrong?
Regards,
Zoltan HERPAI
^ permalink raw reply
* Re: Choices of 2.4 Kernel for PPC
From: Theo Gjaltema @ 2006-09-03 11:07 UTC (permalink / raw)
To: Stephen Williams, linuxppc-embedded
In-Reply-To: <e2b1fi$klf$1@sea.gmane.org>
Stephen Williams schreef:
> I'd been using the BK tree (I know, old old) but it's been stable
> for me for a while. But I'm starting to see so problems and I want
> to work with a recent kernel tree. I'm using a PPC405GPr processor.
>
> I downloaded the linux-2.4.32 tree from kernel.org, but it has
> none of the Xilinx stuff so I immediately wonder about other things
> it lacks for embedded PPC.
>
> I downloaded the linux 2.4 .git tree from Denx, but the makefile
> in top says it's based on 2.4.25, which is even older then what
> I've got now.
>
> I've looked on the penguinppc.org page, but it points me back
> to the kernel.org distribution and possibly the bk repository.
> Hmm...
>
> So what tree is most universally accepted as current so far as
> embedded PPC goes? And can the penguinppc.org pages be updated
> to reflect the consensus?
>
I've run into the same problems with the kernel.org version of the linux
kernel 2.4.32.
the fec_enet module for the ppc was 0.3 instead of 0.4 (denx 2.4.25) and
the config.in file did not contain any of the physical driver info.
Apart from this the generated kernel crashed when accessing the flash,
this worked fine in the denx 2.4.25 kernel as well.
We decided that the kernel.org 2.4.32 is not suitable for the ppc and
stick to the 2.4.25 version as present in the ELDK3.1.1.
Succes,
Theo Gjaltema.
^ permalink raw reply
* Re: MPC8245 reset register
From: Jon Scully @ 2006-09-02 23:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <198592450609021546x57c71e48r9aed561b61f6e8aa@mail.gmail.com>
On 9/2/06, Reeve Yang <yang.reeve@gmail.com> wrote:
> Can anyone tell me which register should I use to do soft reset on MPC8241/5
> CPU? I searched its manuall but only find EPIC to send SRESET exception on
> offset 0x41090.
>
> Thanks.
>
> - Reeve
>
Use the reset instruction (RST in assembly).
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-09-02 23:28 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <20060902230858.GA2814@localhost>
Wolfgang Pfeiffer wrote:
> On Sat, Sep 02, 2006 at 09:18:07PM +0200, Stefan Richter wrote:
[...]
>> you could test the AluBook running Linux and TiBook
>> in target disk mode again to exclude the possibility of problems at the
>> AluBook's side. Use "hdparm -tT /dev/sda" to try a few actual block read
>> operations.
>
> I do not have to mount /dev/sda for the test. Correct?
That's right. This works on the block IO level, not via filesystem. It
is not even necessary to detect any partitions to run this test. On the
other hand, it is not very thorough because only about 50...100 MB will
be read. (You could also read from sda with dd or the like.)
[...]
> The only frustrating thing for me is my lacking
> knowledge when it comes to understand code like the one on the
> kernel.org page below ..
That's because it's extremely ugly code. Guess why it's buggy. :-) It's
just a debug printk though.
[...]
> Please let me know if I can help with tests if you want to patch
> ohci1394.
Thanks, I will Cc you.
--
Stefan Richter
-=====-=-==- =--= ---==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-09-02 23:26 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <44F9D8EF.6010101@s5r6.in-berlin.de>
On Sat, Sep 02, 2006 at 09:18:07PM +0200, Stefan Richter wrote:
>
> Alas I am out of ideas. Perhaps you should purchase a new enclosure.
> Before you do that, you could test the AluBook running Linux and TiBook
> in target disk mode again to exclude the possibility of problems at the
> AluBook's side. Use "hdparm -tT /dev/sda" to try a few actual block read
> operations. This should show about 20 MByte/s. It is a read-only test
> and therefore safe.
OK, I did this test with the unmounted Tibook /dev/sda
(target mode). So I executed the one-liners below on the
alubook. /dev/sda should be the hard disk on the tibook:
####################################################
# /sbin/hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1244 MB in 2.00 seconds = 620.49 MB/sec
Timing buffered disk reads: 34 MB in 3.02 seconds = 11.24 MB/sec
[root@ 01:21:02]# /sbin/hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1232 MB in 2.00 seconds = 615.19 MB/sec
Timing buffered disk reads: 34 MB in 3.04 seconds = 11.17 MB/sec
[root@ 01:21:20]# /sbin/hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1260 MB in 2.00 seconds = 628.93 MB/sec
Timing buffered disk reads: 36 MB in 3.07 seconds = 11.72 MB/sec
[root@ 01:21:35]#
##############################################################
Looks good, doesn't it?
Thanks again
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-09-02 23:08 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <44F9D8EF.6010101@s5r6.in-berlin.de>
On Sat, Sep 02, 2006 at 09:18:07PM +0200, Stefan Richter wrote:
> Wolfgang Pfeiffer wrote on 2006-08-24:
> >On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
> >>Some tests on the Alubook:
> >
> >
> >.. but this time with "modprobe ieee1394 disable_irm=1". 2 logs were be
> >created:
> >www.wolfgangpfeiffer.com/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
> >www.wolfgangpfeiffer.com/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
>
> Thanks for all the logs, and sorry for the delay.
>
> What happens is that the ieee1394 base driver or gscanbus via raw1394
> are able to read from the beginning of the ROM, but the disk's bridge
> does not send response packets anymore at some random point. In the
> first log, it happens at ROM offset ffff f000 0448, in the second at
> ffff f000 0414, in the third at ffff f000 042c, in the fourth at ffff
> f000 0494. The bridge still ack'ed the last attempted read requests with
> "ack_pending" like each previous successful read request, but suddenly
> it does not follow up with a response.
>
> Unfortunately I cannot see how to cure the problem.
Sorry to hear that ..
> There is no indication at all why the disk stops to respond at
> random points after the first chunks of the ROM were transferred
> OK. It is not extremely surprising; after all the Datafab's bridge
> is a pretty old one from before IEEE 1394a-2000. Nevertheless it
> should work OK with the 1394b-2002 PowerBook since the enclosure
> even has a 1394a-2000 PHY. I think I already mentioned that I have a
> similar pre-1394a CD-RW which works well on a 1394b card.
>
> Alas I am out of ideas. Perhaps you should purchase a new enclosure.
I'll be very careful before doing that: Yesterday I was at a computer
shop downtown for a little test whether the FW 800 port could detect
the enclosure. The service guy was really helpful, perhaps even
interested when I explained the FW problem we have with this
alubook. So we connected via a 9:6 (?) pin cable the enclosure to the
FW800 of the alubook. To no avail.
He then proposed to connect the disk instead via the FW enclosure via
a USB case. Didn't work, too. And this although any USB device (USB stick,
a camera, mouse) I connected to the USB ports was detected correctly.
> Before you do that, you could test the AluBook running Linux and TiBook
> in target disk mode again to exclude the possibility of problems at the
> AluBook's side. Use "hdparm -tT /dev/sda" to try a few actual block read
> operations.
I do not have to mount /dev/sda for the test. Correct?
> This should show about 20 MByte/s. It is a read-only test
> and therefore safe.
>
> BTW, I saw one thing in your logs which you are certainly not interested
> in at all. :-)
Not quite true :) ... The only frustrating thing for me is my lacking
knowledge when it comes to understand code like the one on the
kernel.org page below .. but I hope I find a way to change that
situation .. :)
> We seem to have an endianess bug in
> ohci1394.c::dma_rcv_tasklet's DBGMSG. My attempt to fix the printout of
> tlabels last year didn't get it completely right.
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dfe547ab872951949a1a2fcc5cedbedad27a2fe5
> I think the cond_le32_to_cpu has to be omitted there.
Please let me know if I can help with tests if you want to patch
ohci1394.
And thanks for all your efforts; for your explanations, too, for my
scsi.start.sh script in your email from Aug 19. It helped me a lot ...
Nice week-end
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* MPC8245 reset register
From: Reeve Yang @ 2006-09-02 22:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 186 bytes --]
Can anyone tell me which register should I use to do soft reset on MPC8241/5
CPU? I searched its manuall but only find EPIC to send SRESET exception on
offset 0x41090.
Thanks.
- Reeve
[-- Attachment #2: Type: text/html, Size: 206 bytes --]
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-09-02 19:18 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, billfink, linux1394-devel
In-Reply-To: <20060824192200.GA2715@localhost>
Wolfgang Pfeiffer wrote on 2006-08-24:
> On Wed, Aug 23, 2006 at 02:28:01AM +0200, Wolfgang Pfeiffer wrote:
>> Some tests on the Alubook:
>
>
> .. but this time with "modprobe ieee1394 disable_irm=1". 2 logs were be
> created:
> www.wolfgangpfeiffer.com/disable-irm.kern.log.when.fw.disk.is.switched.on.txt
> www.wolfgangpfeiffer.com/disable-irm.kern.log.with.gscanbus.after.failed.fw.connection.txt
Thanks for all the logs, and sorry for the delay.
What happens is that the ieee1394 base driver or gscanbus via raw1394
are able to read from the beginning of the ROM, but the disk's bridge
does not send response packets anymore at some random point. In the
first log, it happens at ROM offset ffff f000 0448, in the second at
ffff f000 0414, in the third at ffff f000 042c, in the fourth at ffff
f000 0494. The bridge still ack'ed the last attempted read requests with
"ack_pending" like each previous successful read request, but suddenly
it does not follow up with a response.
Unfortunately I cannot see how to cure the problem. There is no
indication at all why the disk stops to respond at random points after
the first chunks of the ROM were transferred OK. It is not extremely
surprising; after all the Datafab's bridge is a pretty old one from
before IEEE 1394a-2000. Nevertheless it should work OK with the
1394b-2002 PowerBook since the enclosure even has a 1394a-2000 PHY. I
think I already mentioned that I have a similar pre-1394a CD-RW which
works well on a 1394b card.
Alas I am out of ideas. Perhaps you should purchase a new enclosure.
Before you do that, you could test the AluBook running Linux and TiBook
in target disk mode again to exclude the possibility of problems at the
AluBook's side. Use "hdparm -tT /dev/sda" to try a few actual block read
operations. This should show about 20 MByte/s. It is a read-only test
and therefore safe.
BTW, I saw one thing in your logs which you are certainly not interested
in at all. :-) We seem to have an endianess bug in
ohci1394.c::dma_rcv_tasklet's DBGMSG. My attempt to fix the printout of
tlabels last year didn't get it completely right.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dfe547ab872951949a1a2fcc5cedbedad27a2fe5
I think the cond_le32_to_cpu has to be omitted there.
--
Stefan Richter
-=====-=-==- =--= ---=-
http://arcgraph.de/sr/
^ permalink raw reply
* A question about POST
From: enorm @ 2006-09-02 13:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 162 bytes --]
Hi,
I want to know after poweron, how can cpu(etc. e500) know how many bits he can get when reading flash.
would some one pls tell me?
Best regards
enorm
[-- Attachment #2: Type: text/html, Size: 675 bytes --]
^ permalink raw reply
* Re: [PATCH] Add new, missing argument to of_irq_map_raw().
From: Benjamin Herrenschmidt @ 2006-09-02 3:29 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1GJAlk-00053S-3U@jdl.com>
On Fri, 2006-09-01 at 10:17 -0500, Jon Loeliger wrote:
> Ben speaks; we follow.
Ooops, sorry. I din't grep around thinking nobody would need to use that
low level function but it looks like you do have a good reason to do
so.
Ben.
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
>
> Paul,
>
> This patch is needed in the 2.6.18 release for 86xx.
> Ben's recent changes to of_irq_map_raw() missed one caller.
> This patch cleans that up.
>
> Thanks,
> jdl
>
>
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> index 4a33d95..cdaf668 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -154,7 +154,7 @@ get_pci_irq_from_of(struct pci_controlle
>
> laddr[0] = (hose->first_busno << 16) | (PCI_DEVFN(slot, 0) << 8);
> laddr[1] = laddr[2] = 0;
> - of_irq_map_raw(hosenode, &pin, laddr, &oirq);
> + of_irq_map_raw(hosenode, &pin, 1, laddr, &oirq);
> DBG("mpc86xx_hpcn: pci irq addr %x, slot %d, pin %d, irq %d\n",
> laddr[0], slot, pin, oirq.specifier[0]);
> return oirq.specifier[0];
^ permalink raw reply
* RE: PPC405 system slow boot
From: Clint Thomas @ 2006-09-01 22:57 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Jason Lamb, Peter Ryser
In-Reply-To: <44F38E28.9020201@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]
The xparameters.h file is generated by the Xilinx EDK for our FPGA, so I
don't see how there could be a mismatch. Using Chipscope, we were able
to find that the interrupt controller is triggered on kernel
initialization, but after the kernel has finished loading, the system
moves to a snail's pace at login.
Does Linux use a different set of code to handle the UART, INTC, etc.
after the kernel is loaded? The system appears to work perfectly up
until after the kernel is done loading.
________________________________
From: Peter Ryser [mailto:peter.ryser@xilinx.com]
Sent: Monday, August 28, 2006 8:45 PM
To: Clint Thomas
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPC405 system slow boot
Clint,
check the interrupt sub-system of your design. What you describe
typically happens when the PPC does not get any interrupts from the
UART. It's most likely a mismatch between your hardware and the
xparameters.h.
- Peter
Clint Thomas wrote:
Hey guys,
I've run through the loops to try and figure what could be wrong
with this system. The board in question is modeled after the Xilinx
ML300 board. It uses a Xilinx System ACE chip to load a FPGA / Kernel
image from compact flash. Originally, I was trying to use the
CompactFlash as the root file system, but because of issues in either
the design or software, this would only work if SysAce was in polled I/O
mode. To circumvent this, I built my root filesystem into an initrd
image and built a single ELF file with the Kernel and RFS, then strapped
that to the FPGA bit file to make a single FPGA/Kernel/RFS SysAce file.
Upon decompression, the Linux kernel boots quickly and loads all
of the device drivers. However when it gets to the prompt, it starts
slowing down. Output and input to and from the board becomes very very
slow (it displays 2 characters roughly every 20 seconds). Originally I
believed this to be the CPU still polling SystemAce, so I disabled the
Linux System ACE drivers to remove that as a possibility, however after
doing this, the problem still persists, even with the RFS in ram! Has
anybody encountered a similar situation to this before, with possible
insight towards a solution? Thank you for your time.
Clinton Thomas
cthomas@soneticom.com
________________________________
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 3970 bytes --]
^ permalink raw reply
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-01 21:32 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <1157101449.20092.180.camel@ymzhang-perf.sh.intel.com>
On Fri, Sep 01, 2006 at 05:04:09PM +0800, Zhang, Yanmin wrote:
> One more comment: The second parameter of error_detected also could be deleted
> because recovery procedures will save error to pci_dev->error_state.
Yes, I beleive so.
> So, the err_handler pci_error_handlers could be:
> struct pci_error_handlers
> {
> pci_ers_result_t (*error_detected)(struct pci_dev *dev);
> pci_ers_result_t (*error_resume)(struct pci_dev *dev);
> };
No, as per other email, we still need a multi-step process for
multi-function cards, and for cards that may not want to get
a full electrical reset. Finally, there might be platforms
that cannot perform a per-slot electrical reset, and would
therefore require drivers that can recover on thier own.
--linas
^ permalink raw reply
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-01 21:25 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, linux-kernel,
Rajesh Shah
In-Reply-To: <1157081629.20092.167.camel@ymzhang-perf.sh.intel.com>
On Fri, Sep 01, 2006 at 11:33:49AM +0800, Zhang, Yanmin wrote:
> On Fri, 2006-09-01 at 01:50, Linas Vepstas wrote:
> > On Thu, Aug 31, 2006 at 03:10:12PM +0800, Zhang, Yanmin wrote:
> > > Linas,
> > >
> > > I am reviewing the error handlers of e1000 driver and got some ideas. My
> > > startpoint is to simplify the err handler implementations for drivers, or
> > > driver developers are *not willing* to add it if it's too complicated.
> >
> > I don't see that its to complicated ...
> Originally, I didn't think so, but after I try to add err_handlers to some
> drivers, I feel it's too complicated.
Which drivers are you working on?
> > > 1) Callback mmio_enabled looks useless. Documentation/pci-error-recovery.txt
> > > says the current powerpc implementation does not implement this callback.
> >
> > I don't know if its useless or not. I have not needed it yet for the
> > symbios, ipr and e1000 drivers, but its possible that some more
> > sophisticated device may want it. I'm tempted to keep it a while
> > longer befoe discarding it.
> >
> > The scenario is this: the device driver decides that, rather than asking
> > for a full electical reset of the card, instead, it wants to perform
> > its own recovery. It can do this as follows:
> >
> > a) enable MMIO
> > b) issue reset command to adapter
> > c) enable DMA.
> >
> > If we enabled both DMA and MMIO at the same time, there are mnay cases
> > where the card will immediately trap again -- for example, if its
> > DMA'ing to some crazy address. Thus, typically, one wants DMA disabled
> > until after the card reset. Withouth the mmio_enabled() reset, there
> > is no way of doing this.
> The new error_resume, or the old slot_reset could take care of it. The specific
> device driver knows all the details about how to initiate the devices. The
> error_resume could call the step a) b) c) sequencially while doing checking among
> steps.
Again, consider the multi-function cards. On pSeries, I can only enable
DMA on a er-slot basis, not a per-function basis. So if one driver
enables DMA before some other driver has reset appropriately, everything
breaks.
> If there is really a device having specific requirement to reinitiate it (very rarely),
> it could use walkaround, such like schedule a WORKER. No need to provide a generic
> mmio_enabled.
I don't understand. Enabling MMIO and enabling DMA both require specific
commands to be sent to the PCI-host bridge. These commands are not a
part of the PCI spec.
> > > 2) Callback slot_reset could be merged with resume. The new resume could be:
> > > int (*error_resume)(struct pci_dev *dev); I checked e1000 and e100 drivers and
> > > think there is no actual reason to have both slot_reset and resume.
> >
> > The idea here was to handle multi-function cards. On a multi-function card,
> > *all* devices need to indicate that they were able to reset. Once all devices
> > have been successfuly reset, then operation can be resumed. If the reset
> > of one function fails, then operation is not resumed for any f the
> > functions.
> I don't think we need slot_reset to coordinate multi-function devices. The new
> error_resume could take care of multi-function card.
How?
> 'reset' here means driver
> need do I/O to detect if the device (function) still works well. If a function
> of a multi-function device couldn't reset while other functions could reset,
> other functions could just go on to reinitiate. In the end, the error recovery
> procedure (handle_eeh_events in PowerPC implementation) could check all the
> returning values of error_resume. If there is a failure value, then removes
> all the functions' pci_dev of the device from the bus.
I can only enable or disable an entire PCI slot, and not individual PCI
functions. If there are some pins that are shorted, or parity errors or
whatever, I can only turn off the whole card.
> > > During
> > > our last discussion on LKML, you said PowerPC will block further I/O if the platform captures
> > > a pci error, so the all I/O in e1000_down will be blocked. Later on, e1000_io_slot_reset
> > > will reenable pci device and initiate NIC. I guess late initiate might fail because prior
> > > e1000_down I/O don't reach NIC.
> >
> > Why would it fail? The e1000_down serves primarily to get the Linux
> > kernel into a known state. It doesn't matter what happens to the card,
> > since the next step will be to perform an electrical reset of the card.
> Who will perform the electrical reset of the card? Function e1000_reset or the platform?
The platform. By "electrical reset", I mean "dropping the #RST pin low
for 200mS". Only the platform can do this.
> If it's the platform, I agree with you, but if it's e1000_reset, it might not work because
> e1000_reset uses a e1000-specific approach to reset the card.
The driver has to choices: it can ask for the electrical reset, by
returning PCI_ERS_RESULT_NEED_RESET. But if the driver doesn't need
the electrical reset, then it can return PCI_ERS_RESULT_CAN_RECOVER,
and issue whatever device-specific commands it needs to reset.
> I'm not sure if the e1000_reset
> will restore the NIC to fresh system power-on state. At least, from the source codes, e1000_reset
> couldn't.
I have no idea. That's why this driver issues PCI_ERS_RESULT_NEED_RESET,
which will get it into a fresh system power-on state. Its easy, its
brute-force, it works.
--linas
^ permalink raw reply
* Unable to boot kernel 2.6 from u-boot 1.1.4 in Xilinx ML403
From: Aleck Lin @ 2006-09-01 17:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.3.1157101919.2423.linuxppc-embedded@ozlabs.org>
Sorry ,that was a typo, I did use "uImage"
Thanks,
Aleck
>
> 1. When I directly download zImage.elf to the RAM and boot from there, I
see
...
> 2. When I tried to boot the zImage (sitting in the flash) from u-boot file
When you use U-Boot, you should use the correct image (uImage).
Best regards,
Wolfgang Denk
^ 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