* 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: [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
* 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: 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
* 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: 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
* 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: 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: 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: 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
* 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: 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
* 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: 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: 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: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: 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: 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: 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: 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: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
* [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: pci error recovery procedure
From: Zhang, Yanmin @ 2006-09-04 5:47 UTC (permalink / raw)
To: Linas Vepstas
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <20060901212548.GS8704@austin.ibm.com>
On Sat, 2006-09-02 at 05:25, Linas Vepstas wrote:
> 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?
I worked out error handlers for tg3 NIC driver. I'm also checking e1000 driver
to try to move all I/O operations from e1000_io_error_detected to e1000_io_slot_reset.
>
> > > > 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.
I think most drivers' error_detected callbacks return PCI_ERS_RESULT_NEED_RESET,
so the slot will be reset. Then, the example that one wants DMA disabled
until after the card reset is not reasonable.
> 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.
Does here 'reset' mean hardware slot reset? In error_detected, driver
needs cancel all pending request and don't start any I/O operations.
Then, if the slot is always reset, there will be no the problem. Function
handle_eeh_events always resets slot except hard failure. See beow more comments.
As you know, all functions of a device share the same bus number and 5 bit dev number.
They just have different 3 bit function number. We could deduce if functions are in the same
device (slot).
If mmio_enabled is not used currently, I think we could delete it firstly. Later on,
if a platform really need it, we could add it, so we could keep the simplied codes.
>
> > 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.
Thanks. Now I understand why you specified mmio_enabled and slot_reset. They are just
to map to pSeries platform hardware operation steps. I know little about pSeries hardware,
but is it possible to merge such hardware steps from software point of view?
I checked the source codes of pSeries eeh_driver. Function handle_eeh_events does nothing
between pci_walk_bus(frozen_bus, eeh_report_reset, NULL) and
pci_walk_bus(frozen_bus, eeh_report_resume, NULL), that is, it doesn't enable DMA after
slot_reset. handle_eeh_events always resets slot except hard failure. So, slot_reset
could be merged with resume.
>
>
> > > > 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.
It doesn't matter with the simplification. I don't mean that a device function
should be disabled immediately after the error_resume of the function driver
returns.The disable operation could be delayed till all error_resume return.
>
>
> > > > 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.
Thanks for your explanation. I assume after the electrical reset, all device
functions of the device slot will go back to the initial status before
attaching their drivers.
>
> > 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.
I found a problem of e1000 driver when testing its error handlers. After the NIC is resumed,
its RX/TX packets numbers are crazy. Now, I think it's a bug of function e1000_reset, not
the error handlers. Sorry for bothering you on e1000.
I copy another email below, so we could keep the discussion in one thread.
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.
Thanks.
>
> > 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,
As above discussion, reset slot could resolve it like you did for pSeries.
> and for cards that may not want to get
> a full electrical reset.
So I think slot is reset only when a error_detected returns
PCI_ERS_RESULT_NEED_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.
The new pci_error_handlers could process it easily. The driver's error_resume just
need schedule a driver-specific worker and returns PCI_ERS_RESULT_RECOVERED. The
worker could do recover on the driver own later on.
By checking drivers who support err_handler in the latest kernel, we could find
they all returns PCI_ERS_RESULT_NEED_RESET. They all could be converted to
use the new simplified pci_error_handlers. The new pci_error_handlers also gives
drivers flexibility to have more control on error recovery.
It's hard to look for a perfect solution. I mean, it's a trade-off. As long as
it could finish most functionality, the simpler, the better.
Yanmin
^ permalink raw reply
* Re: pci error recovery procedure
From: Benjamin Herrenschmidt @ 2006-09-04 9:03 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: Yanmin Zhang, LKML, Rajesh Shah, linuxppc-dev, linux-pci maillist
In-Reply-To: <1157348850.20092.304.camel@ymzhang-perf.sh.intel.com>
> As you know, all functions of a device share the same bus number and 5 bit dev number.
> They just have different 3 bit function number. We could deduce if functions are in the same
> device (slot).
Until you have a P2P bridge ...
> Thanks. Now I understand why you specified mmio_enabled and slot_reset. They are just
> to map to pSeries platform hardware operation steps. I know little about pSeries hardware,
> but is it possible to merge such hardware steps from software point of view?
One of the ideas we had when defining those steps is to be precise
enough to let drivers who _can_ deal with those fine grained pSeries
step implement them, but also have the fallback to slot reset whenever
possible.
Now, if in practice, after actually implementing this in a number of
drivers, we see that slot reset is the only ever used path, then we
might want to simplify things a bit. I didn't want to impose that
restriction in the initial design though.
It's my understanding that doing no slot reset (hardware reset) but just
re-enabling MMIO, DMA and clearing pending error status in the PCI
config space is, as far as the driver is concerned, almost functionally
equivalent to a PCIe link reset. That is, the link reset might not (or
will not) actually reset the hardware beyond the PCIe link layer.
Thus we could simplify the split between link reset / hard reset. The
former is an attempt at recovery with only resetting the PCI path to the
device, which on PCIe becomes a link reset, and on old PCI, just
clearing of the various error bits along the path (and on pSeries,
re-enabling MMIO and DMA access). However, there is still the problem
that if you do that, on pSeries at least, you really want to 1- enable
MMIO, 2- soft reset the card using MMIO, that is make sure all pending
DMA is stopped, and 3- re-enable DMA. While if we collapse that into a
single 'link reset' type of operation, we'll end up re-enabling MMIO and
DMA before the driver has a chance to stop pending DMA's and thus
increase the chance that we crap out due to a pending DMA on the chip.
Ben.
^ permalink raw reply
* [2.6.19 PATCH 0/7] ehea: IBM eHEA Ethernet Device Driver
From: Jan-Bernd Themann @ 2006-09-04 10:36 UTC (permalink / raw)
To: netdev, Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
Hi,
this is our current version of the IBM eHEA Ethernet Device Driver. We adde=
d=20
minor bug fixes and changes to the last version.
Jeff, this driver has been discussed on the netdev, linux-ppc and=20
kernel mailing list. We didn't receive any further comments since our previ=
ous
patch set from August 23. Please consider our driver for
upstream inclusion.
Thanks,
Jan-Bernd Themann & Christoph Raisch
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
Changelog-by: =A0Jan-Bernd Themann <themann@de.ibm.com>
Differences to patch set http://www.spinics.net/lists/netdev/msg12820.html
Changelog:
=2D struct ehea_q_skb_arr introduced to simplify struct ehea_port_res
=2D promiscuous mode added
=2D enhanced ethtool support (set port speed)
=2D destroy functions for QPs, CQs, EQs, MRs reduced to single function
=2D Bux fix: xmit locking
drivers/net/Kconfig | 9=20
drivers/net/Makefile | 1=20
drivers/net/ehea/Makefile | 6=20
drivers/net/ehea/ehea.h | 444 ++++++
drivers/net/ehea/ehea_ethtool.c | 292 ++++
drivers/net/ehea/ehea_hcall.h | 51=20
drivers/net/ehea/ehea_hw.h | 290 ++++
drivers/net/ehea/ehea_main.c | 2694 +++++++++++++++++++++++++++++++++++=
+++++
drivers/net/ehea/ehea_phyp.c | 705 ++++++++++
drivers/net/ehea/ehea_phyp.h | 454 ++++++
drivers/net/ehea/ehea_qmr.c | 605 ++++++++
drivers/net/ehea/ehea_qmr.h | 361 +++++
12 files changed, 5912 insertions(+)
^ 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