Re: Problem with mini-PCI-E slot on P2020RDB
Felix, On Tue, Apr 12, 2011 at 6:54 AM, Felix Radensky fe...@embedded-sol.com wrote: On 04/12/2011 07:05 AM, Aggrwal Poonam-B10812 wrote: As such there is no hardware fix related to this issue between RevC to RevD. The solution was a software patch to resolve the issue related to IRQ0. Are you sure ? Please take a look at Freescale document titled P1020E/P2020E RDB System Errata. There's errata CE10, IRQ0 held low. It is fixed in Rev D. Vivek Mahajan, who looked at the issue back in 2009, estimated that problem can be related to missing pull-up on IRQ0. This is exactly what is fixed in Rev D. That's my understanding as well. Check if R420 and R423 are populated. These are the required pull-ups. On Rev D they are populated. You might be able to add them yourself. Even if you have an Rev A-C PCB, this fix can already be applied; it was on my board! (the bottom of the board mentions the schematic revision) The resistors have a silkscreen designator block called X, the resistors are situated to the left and bottom of the silkscreen X. IIRC, between the flash and Px020 part. On the left side of R420 (or R423) I measured the block wave from the RTC, which fires the 32kHz interrupt rate on IRQ0. This fixed by the u-boot patch. Regards, Leon. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
Hello Prabhakar,
On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
b32...@freescale.com wrote:
-Original Message-
From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
Sent: Thursday, April 07, 2011 10:23 PM
To: Kushwaha Prabhakar-B32579
Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo;
Jeff Garzik
Subject: Re: known working sata_sil24.c setup on powerpc platforms?
On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
b32...@freescale.com wrote:
Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
In order to work in legacy mode, IDSEL entries are required.
No, the p1020rdb and p2020rdb do not have the IDSEL entries:
What would the correct IDSEL entries be?
For legacy interrupt to work IDSEL values are required.. please find the
correct IDSEL values for pci0/1.
pci0: pcie@ffe09000 {
...
Please try with this.. I am in process of pushing these IDSEL values to
upstream.
Do you have these for P1020RDB as well? I found a P1020RDB board that
has the CE10 errata fixed, so IRQ0 is properly pulled up.
Regards,
--
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
Hello Prabhakar,
On Fri, Apr 8, 2011 at 10:31 AM, Kushwaha Prabhakar-B32579
b32...@freescale.com wrote:
Hi Leon,
-Original Message-
From: Leon Woestenberg [mailto:leon.woestenb...@gmail.com]
Sent: Friday, April 08, 2011 1:55 PM
To: Kushwaha Prabhakar-B32579
Cc: Moffett, Kyle D; linux-...@vger.kernel.org; Tejun Heo; Jeff Garzik;
Linux PPC; Gupta Maneesh-B18878
Subject: Re: known working sata_sil24.c setup on powerpc platforms?
Hello Prabhakar,
On Fri, Apr 8, 2011 at 5:44 AM, Kushwaha Prabhakar-B32579
b32...@freescale.com wrote:
-Original Message-
From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide-
ow...@vger.kernel.org] On Behalf Of Leon Woestenberg
Sent: Thursday, April 07, 2011 10:23 PM
To: Kushwaha Prabhakar-B32579
Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo;
Jeff Garzik
Subject: Re: known working sata_sil24.c setup on powerpc platforms?
On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
b32...@freescale.com wrote:
Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
In order to work in legacy mode, IDSEL entries are required.
No, the p1020rdb and p2020rdb do not have the IDSEL entries:
What would the correct IDSEL entries be?
For legacy interrupt to work IDSEL values are required.. please find
the correct IDSEL values for pci0/1.
pci0: pcie@ffe09000 {
...
Please try with this.. I am in process of pushing these IDSEL values to
upstream.
Do you have these for P1020RDB as well? I found a P1020RDB board that
has the CE10 errata fixed, so IRQ0 is properly pulled up.
Same IDSEL values are valid for P1020RDB also.
I compiled the new device tree binary, the dump is below(*) and booted
the P1020RDB from that.
I verified using an oscilloscope that IRQ0 indeed remains high.
However, no interrupt seems to come in from the sata_sil24 driver, see
boot log (**).
(*) dtb dump:
$ dtc -I dtb -O dts /tftpboot/p1020rdb/uImage.dtb
pcie@ffe09000 {
compatible = fsl,mpc8548-pcie;
device_type = pci;
#interrupt-cells = 0x1;
#size-cells = 0x2;
#address-cells = 0x3;
reg = 0x0 0xffe09000 0x0 0x1000;
bus-range = 0x0 0xff;
ranges = 0x200 0x0 0xa000 0x0 0xa000 0x0 0x2000
0x100 0x0 0x0 0x0 0xffc3 0x0 0x1;
clock-frequency = 0x1fca055;
interrupt-parent = 0x2;
interrupts = 0x10 0x2;
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map = 0x0 0x0 0x0 0x1 0x2 0x4 0x1 0x0 0x0 0x0 0x2
0x2 0x5
0x1 0x0 0x0 0x0 0x3 0x2 0x6 0x1 0x0 0x0 0x0 0x4 0x2 0x7 0x1;
pcie@0 {
reg = 0x0 0x0 0x0 0x0 0x0;
#size-cells = 0x2;
#address-cells = 0x3;
device_type = pci;
ranges = 0x200 0x0 0xa000 0x200 0x0
0xa000 0x0
0x2000 0x100 0x0 0x0 0x100 0x0 0x0 0x0 0x10;
};
};
pcie@ffe0a000 {
compatible = fsl,mpc8548-pcie;
device_type = pci;
#interrupt-cells = 0x1;
#size-cells = 0x2;
#address-cells = 0x3;
reg = 0x0 0xffe0a000 0x0 0x1000;
bus-range = 0x0 0xff;
ranges = 0x200 0x0 0xc000 0x0 0xc000 0x0 0x2000
0x100 0x0 0x0 0x0 0xffc2 0x0 0x1;
clock-frequency = 0x1fca055;
interrupt-parent = 0x2;
interrupts = 0x10 0x2;
interrupt-map = 0x0 0x0 0x0 0x1 0x2 0x0 0x1 0x0 0x0 0x0 0x2
0x2 0x1
0x1 0x0 0x0 0x0 0x3 0x2 0x2 0x1 0x0 0x0 0x0 0x4 0x2 0x3 0x1;
pcie@0 {
reg = 0x0 0x0 0x0 0x0 0x0;
#size-cells = 0x2;
#address-cells = 0x3;
device_type = pci;
ranges = 0x200 0x0 0xc000 0x200 0x0
0xc000 0x0
0x2000 0x100 0x0 0x0 0x100 0x0 0x0 0x0 0x10;
};
};
};
(**) boot log
[0.00] Using P1020 RDB machine description
[0.00] Memory CAM mapping: 256/256 Mb, residual: 0Mb
[0.00] Linux version 2.6.38 (leon@lunar) (gcc version 4.3.3
(GCC) ) #6 Fri Apr 8 11:00:10 CEST 2011
[0.00] Found legacy serial port 0 for /soc@ffe0/serial@4500
[0.00] mem=ffe04500, taddr=ffe04500, irq=0, clk=39996, speed=0
[0.00] Found legacy serial port 1 for /soc@ffe0/serial@4600
[0.00] mem=ffe04600, taddr=ffe04600, irq=0, clk=39996, speed=0
[0.00] bootconsole [udbg0] enabled
[0.00] Found FSL PCI host bridge at 0xffe09000.
Firmware bus number: 0-255
[0.00] PCI host bridge /pcie@ffe09000 ranges:
[0.00] MEM
Re: known working sata_sil24.c setup on powerpc platforms?
Hello Prabhakar, thanks for your response. My answer below: On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579 b32...@freescale.com wrote: Hi Leon, Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node? In order to work in legacy mode, IDSEL entries are required. No, the p1020rdb and p2020rdb do not have the IDSEL entries: http://lxr.linux.no/#linux+v2.6.38/arch/powerpc/boot/dts/p2020rdb.dts whereas the p2020ds has: http://lxr.linux.no/#linux+v2.6.38/arch/powerpc/boot/dts/p2020ds.dts What would the correct IDSEL entries be? Also, did you see the reference to Felix' thread? Problem with mini-PCI-E slot on P2020RDB Best regards, Leon. --Prabhakar -Original Message- From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide- ow...@vger.kernel.org] On Behalf Of Leon Woestenberg Sent: Thursday, April 07, 2011 12:20 AM To: Jeff Garzik Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo Subject: Re: known working sata_sil24.c setup on powerpc platforms? Hello Jeff, all, On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik j...@garzik.org wrote: On 04/06/2011 01:48 PM, Moffett, Kyle D wrote: On Apr 06, 2011, at 13:00, Leon Woestenberg wrote: after investigating problems with sata_sil24.c on a freescale p2020 soc, I wonder if this driver works on powerpc at all? Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil3124 over PCI-E); the only deficiency is that MSI does not seem to work. We've definitely had issues with sata_sil24 + MSI, also... sata_sil24 does work on big endian in general. On my system, I have the contrary to Kyle's experience (thanks for sharing). PowerPC P2020RDB vanilla 2.6.38 Sil3132 on mini-PCI Express card Enabling msi gets me further than disabling it (default). modprobe sata_sil [ 8.834613] sata_sil24 0001:03:00.0: version 1.1 [ 8.885581] scsi0 : sata_sil24 [ 8.901420] scsi1 : sata_sil24 [ 8.904642] ata1: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 16 [ 8.911961] ata2: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 16 [ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 14.906986] eth0: no IPv6 routers present [ 16.099016] ata1.00: qc timeout (cmd 0xec) [ 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 28.303026] ata1.00: qc timeout (cmd 0xec) [ 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 28.313233] ata1: limiting SATA link speed to 1.5 Gbps [ 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10) modprobe sata_sil msi=1 [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to virtual irq 41 [ 92.996229] sata_sil24 0001:03:00.0: Using MSI [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering [ 93.011628] scsi2 : sata_sil24 [ 93.022463] scsi3 : sata_sil24 [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 41 [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 41 [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag -84148995 sactive 0x0) [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133 [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32) [ 95.230905] ata3.00: configured for UDMA/100 [ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL SSDSA2M080 2CV1 PQ: 0 ANSI: 5 [ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0 [ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [ 95.260219] sd 2:0:0:0: [sda] Write Protect is off [ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 95.283779] sda: sda1 sda2 sda3 sda4 [ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk [ 95.965897] EXT3-fs: barriers not enabled [ 95.977279] kjournald starting. Commit interval 5 seconds [ 95.983296] EXT3-fs (sda2): using internal journal [ 95.988143] EXT3-fs (sda2): recovery complete [ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data mode [ 96.111587] NTFS volume version 3.1. [ 97.331005] ata4: SATA link down (SStatus 0 SControl 0) root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1000 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1 1+0 records in 1+0 records out 4096 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=10
Re: known working sata_sil24.c setup on powerpc platforms?
Hello Martyn, thanks for a confirmation. On Thu, Apr 7, 2011 at 10:27 AM, Martyn Welch martyn.we...@ge.com wrote: On 06/04/11 18:00, Leon Woestenberg wrote: Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Yes, I think we even use it on a p2020 board, though I think our current kernel on that product is 2.6.34. Could you check if that's using MSI or legacy interrupting on PCIe? Thanks in advance for the effort, Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with mini-PCI-E slot on P2020RDB
Hello, On Thu, Dec 17, 2009 at 9:28 PM, Felix Radensky fe...@embedded-sol.com wrote: Kumar Gala wrote: On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote: Thanks a lot. If I understand you correctly, the only way I can get ath9k driver to work on this board using legacy interrupts is to wait for a hardware fix. Right ? Correct I'm confused. What's the issue with IRQ0 on the P2020RDB? Is it used for another purpose? There's a problem with IRQ0 with respect to mini-PCI-E slot. I have Atheros wireless card plugged into it. ath9k wireless driver for this card uses legacy PCI-E interrupts, and I get irq 16: nobody cared message when driver executes request_irq(). Vivek has come to a conclusion that the problem is related to incorrect IRQ0 routing for mini-PCI-E slot on P2020RDB. I would like to understand this issue better, as I seem to be running into something similar, and it puts my board design on hold. Can someone (from Freescale) explain what happens if a PCI Express end point on the mini-PCIe slot raises a legacy interrupt, and where this goes wrong? From what document or source code file can I conclude that the PCIe legacy interrupt is shared with IRQ0? I found this: P1020E/P2020E RDB System Errata, Last Update: 2/15/2010: Problem:IRQ0 held low Fix: Add 4.7K pull-up (to 3.3.V) for RTC_INT_N. See R420 in Rev D schematic. Add 4.7K pull-up (to 3.3.V) for MCU_INT_N. See R423 in Rev D schematic. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
known working sata_sil24.c setup on powerpc platforms?
Hello, after investigating problems with sata_sil24.c on a freescale p2020 soc, I wonder if this driver works on powerpc at all? Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
Hello Jeff, all, On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik j...@garzik.org wrote: On 04/06/2011 01:48 PM, Moffett, Kyle D wrote: On Apr 06, 2011, at 13:00, Leon Woestenberg wrote: after investigating problems with sata_sil24.c on a freescale p2020 soc, I wonder if this driver works on powerpc at all? Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil3124 over PCI-E); the only deficiency is that MSI does not seem to work. We've definitely had issues with sata_sil24 + MSI, also... sata_sil24 does work on big endian in general. On my system, I have the contrary to Kyle's experience (thanks for sharing). PowerPC P2020RDB vanilla 2.6.38 Sil3132 on mini-PCI Express card Enabling msi gets me further than disabling it (default). modprobe sata_sil [8.834613] sata_sil24 0001:03:00.0: version 1.1 [8.885581] scsi0 : sata_sil24 [8.901420] scsi1 : sata_sil24 [8.904642] ata1: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 16 [8.911961] ata2: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 16 [ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 14.906986] eth0: no IPv6 routers present [ 16.099016] ata1.00: qc timeout (cmd 0xec) [ 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 28.303026] ata1.00: qc timeout (cmd 0xec) [ 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 28.313233] ata1: limiting SATA link speed to 1.5 Gbps [ 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10) modprobe sata_sil msi=1 [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to virtual irq 41 [ 92.996229] sata_sil24 0001:03:00.0: Using MSI [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering [ 93.011628] scsi2 : sata_sil24 [ 93.022463] scsi3 : sata_sil24 [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 41 [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 41 [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag -84148995 sactive 0x0) [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133 [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32) [ 95.230905] ata3.00: configured for UDMA/100 [ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL SSDSA2M080 2CV1 PQ: 0 ANSI: 5 [ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0 [ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [ 95.260219] sd 2:0:0:0: [sda] Write Protect is off [ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 95.283779] sda: sda1 sda2 sda3 sda4 [ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk [ 95.965897] EXT3-fs: barriers not enabled [ 95.977279] kjournald starting. Commit interval 5 seconds [ 95.983296] EXT3-fs (sda2): using internal journal [ 95.988143] EXT3-fs (sda2): recovery complete [ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data mode [ 96.111587] NTFS volume version 3.1. [ 97.331005] ata4: SATA link down (SStatus 0 SControl 0) root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1000 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1 1+0 records in 1+0 records out 4096 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=10 That stalls, I see the controller fail. See dmesg below: ^C^Cdd: reading `/dev/sda': Input/output error 51804+0 records in 51804+0 records out 212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s dd: closing input file `/dev/sda': Bad file descriptor [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to virtual irq 41 [ 92.996229] sata_sil24 0001:03:00.0: Using MSI [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering [ 93.011628] scsi2 : sata_sil24 [ 93.022463] scsi3 : sata_sil24 [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 41 [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 41 [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag -84148995 sactive 0x0) [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133 [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32) [ 95.230905] ata3.00: configured for UDMA/100 [ 95.235399] scsi 2:0:0:0
Re: known working sata_sil24.c setup on powerpc platforms?
Hello Felix, On Wed, Apr 6, 2011 at 10:49 PM, Felix Radensky fe...@embedded-sol.com wrote: I think there's a hardware problem with mini PCI-E slot on P2020RDB related to legacy IRQ routing. See this thread for details http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html Thanks for the heads-up. You may have better luck with PCI-E slot and mini PCI-E to PCI-E adapter. Unfortunately the PCIe is slot already occupied, so that's why I searched for and found the Mini PCIe Sil3132 card. Legacy IRQ routing on PCIe is broken in what sense? Software (device tree, kernel) or silicon (p2020) ? On the MSI side, I'm getting quite far on transfers, but at one point the device stalls. Maybe a race condition in interrupt handling in sata_sil24.c? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts:Update PCIe memory maps to match u-boot of Px020RDB
Hello Prabhakar, Kumar, (I missed the original post, due to temporarely being unsubscribed, I am responding to Kumar's reply). On Thu, Mar 31, 2011 at 10:22 AM, Kumar Gala ga...@kernel.crashing.org wrote: On Mar 24, 2011, at 11:47 PM, Prabhakar Kushwaha wrote: PCIe memory address space is 1:1 mapped with u-boot. Update dts of Px020RDB i.e. P1020RDB and P2020RDB to match the address map changes in u-boot. Does this mean u-boot and Linux versions should be selectively matched, or not? What commit in u-boot does this apply to? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Market research for new PowerPC system
Hello, first off, I like your idea. This is my public reply, I'll give a personal reply later. On Sat, Sep 26, 2009 at 1:38 PM, Konstantinos Margaritis mar...@codex.gr wrote: I'm considering funding the design production of a new PowerPC system (well, the motherboard, the rest are typical pc stuff and a case). No this What makes the system stand out, from say a Atom based PC? (I know, playing devil's advocate here) 1. MPC8640D-based. It will be dual core at 1Ghz -most likely, higher frequencies are much more expensive and the cost of the final board would be prohibitive. 2. MPC8610-based. Single core at 1Ghz, slightly less expensive, and includes a 2D DIU display unit -quite fast, but no 3D unfortunately. 3. QorIQ P1022-based. Again dual core at 1Ghz (1055Mhz to be precise). Apart from the much lower chip price, this one includes dual gigabit ethernet, dual SATA, USB 2.0 and a 2D DIU display unit (same as the MPC8610). So this Go for QorIQ P1022, it's the ideal SoC for many applications. Alternatively, it's predecessor MPC8536E available now, ~same specs, but higher power. But not the two you mention please. End price is estimated to be ~around~ 350EUR for the P1022 board or ~500EUR Pico P1022 or Pico MPC8536E pls. and throw PCI Express (x4) in the party! (hint: I haven't seen an Intel board with Atom and PCI Express yet). Will the board be open hardware? I.e. an open sourced design? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FPGA access over PCI-E on MPC8536
Hello Felix, On Thu, Sep 17, 2009 at 6:17 AM, Felix Radensky fe...@embedded-sol.com wrote: On my custom MPC8536 based board running 2.6.31 kernel FPGA is connected via x2 PCI-E lane. FPGA is identified during PCI scan and is visible via lspci. I committed a PCI Express device driver for an Altera FPGA (chaining DMA reference) design upstream that resides in the upstream Linux kernel at drivers/staging/altpciechdma/ It can act as a reference for the generic part of your design. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC8536DS: u-boot detects PCIe card but Linux 2.6.30 does not.
Hello, On Mon, Sep 7, 2009 at 1:01 PM, Leon Woestenbergleon.woestenb...@gmail.com wrote: on my MPC8536DS development board, a PCIe card does not get detected by Linux, u-boot does list it. I'm suspecting the PCIe bridge (?) to not initialize correctly, but that is a wild guess. See the u-boot log and kernel boot log with PCI It seems this might be a endpoint hardware issue where the PCIe hot reset signal is ignored. Investigating further. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spin_is_locked() broken for uniprocessor?
Hello,
On Wed, Aug 19, 2009 at 12:53 PM, Alan Coxa...@lxorguk.ukuu.org.uk wrote:
On Wed, 19 Aug 2009 10:38:06 +0100
in drivers because there is driver code that uses spin_is_locked() in
fairly sensible fashion when dealing with locking.
One use is to measure lock contention hits on a particular spin lock.
However I wonder if there are tracing capabilities to measure lock
contention on a particular lock?
Currently I have inserted code much like this to get a feeling on the
contention:
this_cpu = get_cpu();
put_cpu();
contention = spin_is_locked(lock);
spin_lock*(lock);
if (contention) {
/* spin lock was contended, prev_cpu, this_cpu */
/* no hard guarantee, as we had a possible race inbetween
is_locked() and lock(), but works for driver/irq spin lock */
}
/* critical section */
prev_cpu = this_cpu;
spin_unlock*(lock);
Regards,
--
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
Hello, On Thu, Jun 18, 2009 at 4:04 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 18, 2009, at 8:09 AM, Anton Vorontsov wrote: On Thu, Jun 18, 2009 at 08:19:44AM +0200, Rini van Zetten wrote: This patch adds the possibility to have a spi device without a cs. That is a good question. What HW is this for (I don't think its for eSPI but I could be wrong). We need SPI without CS too on our MPC8313E design. In our case having a CS line to each slave (18 of them) is too expensive and we use a chip select which piggy backs on another signal. Once the slave is selected, SPI is used to send large amounts of data. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
Hello, On Wed, Jun 17, 2009 at 2:16 PM, Norbert van Bolhuisnvbolh...@aimvalley.nl wrote: I'll be testing the design tomorrow on the reference board, I'll report results in this thread. Interesting. Looking forward to the results. Design works as expected on the now slightly modified MPC8313E-RDB board. Kudos to David. Cheers, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
Hello all, On Wed, Jun 17, 2009 at 10:35 AM, Norbert van Bolhuisnvbolh...@aimvalley.nl wrote: Hi Leon, I doubt if there are working designs for this. ... In u-boot the watchdog (if enabled with CONFIG_WATCHDOG) is normally strobed in the decrementer interrupt routine (timer_interrupt). So I guess there's not a big chance it triggers a reset. ... Most designs do not care about the watchdog, or only pet in their non-critical paths... That's not what the watchdog is for. Also, I don't care about u-boot. I care about a design where the Flash NOR could be in write mode at any time when the watchdog triggers, when the hardware is running critical software. No lifes in danger when it happens, only jobs, so no biggy :-) David has been helpful in thinking this through, but we followed-up offline, and we independently came up with the following design, so this must therefore work (disclaimer applies). Note, it DOES require a NOR flash that has a RY/BUSY# pin. Quoting David Hawkins, who gave a very clear explanation: --- How about using the RDY/BUSY# pin on the Flash in conjunction with PORESET#. If the flash is busy, then the processor gets PORESET#, otherwise, the HRESET# just does its normal thing. That way PORESET# only ever asserts when you have the combo of the Flash being busy and HRESET# asserting. ... If you have the Flash BUSY# signal, then this scheme works great, since using HRESET# low and BUSY# low to create a PORESET# source is only active until the Flash RESET# is asserted long enough for it to get out of the BUSY# state and back into read-array mode. --- Kudos to David. I'll be testing the design tomorrow on the reference board, I'll report results in this thread. Regards / Groeten, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
Hello, On Wed, Jun 17, 2009 at 12:09 PM, Leon Woestenbergleon.woestenb...@gmail.com wrote: Quoting David Hawkins, who gave a very clear explanation: ... If you have the Flash BUSY# signal, then this scheme works great, since using HRESET# low and BUSY# low to create a PORESET# source is only active until the Flash RESET# is asserted long enough for it to get out of the BUSY# state and back into read-array mode. I just found out from a Spansion datasheet that the RY/BUSY# of a typical Flash NOR is enabled by CE#, and tri-state otherwise. CE# in turn is driven by the LCS# from the PowerPC. So basically, the first configuration access cycle while the NOR is in write mode, will pull CE# low, which results in RY/BUSY# being driven. I have measured this pulse is ~1.9 us. So the reset circuitry needs a maximum minimum pulse duration of 1.9 us. Our reset controller (DS1818) fulfills this requirement, with a T,PB of 1 us. A reset controller will extend the reset pulse. This is needed because: for Flash NOR: I have seen a mininum of 35 us reset pulse. (for the PowerPC: PORESET# should be asserted externally for at least 32 input clock cycles) Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
Hello Kumar, all, On Mon, Jun 8, 2009 at 4:59 PM, Leon Woestenbergleon.woestenb...@gmail.com wrote: using 2.6.30-rc6, I get the following problems when I read from a SSD disk, connected to the 3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6. Result on a first batch of bisects. I decided to go with the kernel releases rather than git-bisect (still too scary for me). All kernel releases 2.6.25 through -30 kernel gave the same error. 2.6.25 crashed on it, whereas 2.6.26+ recovered after each dd run. The BSP 2.6.24.3-rt3 kernel did not give the error. So on my todo is diff between 2.6.25 and .2.6.24.3-rt3 from the BSP. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
MPC83xx watchdog reset board dead lock
Hello, this is a hardware, even board issue, but I hope to find the right target audience here. In our MPC83xx design I would like to prevent dead lock in case where a field upgrade is performed, i.e. NOR Flash is erased or written, and the MPC83xx built-in hardware watchdog triggers. In u-boot the scenario can be easily reproduced by running this command (WARNING, erases some sectors!) on an MPC8313E-RDB: erase_wdg=mw.l 0xe204 0x1007 1;mw.w 0xe20e 0x556c 1;mw.w 0xe20e 0xaa39 1;erase 1:10-30 This sets up the watchdog to reset soonish, then starts erasing NOR sectors. Watchdog triggers and resets - Dead lock. Most MPC8xxx board designs I have seen suffer from this possible dead lock: - NOR Flash is put in erase mode or write mode - Hardware watchdog triggers - HRESET# is asserted by the processor, during which the configuration words are read from NOR Flash. Either HRESET# is not attached to NOR, NOR stays in erase/write mode and invalid words will be read - dead lock or either: HRESET# is attached to NOR reset, NOR is reset, but stays in reset as HRESET# stays asserted. We have been looking at several solutions hardware wise that reset the NOR flash on HRESET# going low, but the processors are stubborn, read the config words only once, than dead lock. I wonder if there are known-working designs for this. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
Hello, On Tue, Jun 16, 2009 at 6:30 PM, David Hawkinsd...@ovro.caltech.edu wrote: Most MPC8xxx board designs I have seen suffer from this possible dead lock: - NOR Flash is put in erase mode or write mode - Hardware watchdog triggers - HRESET# is asserted by the processor, during which the configuration words are read from NOR Flash. Either HRESET# is not attached to NOR, NOR stays in erase/write mode and invalid words will be read - dead lock or either: HRESET# is attached to NOR reset, NOR is reset, but stays in reset as HRESET# stays asserted. We have been looking at several solutions hardware wise that reset the NOR flash on HRESET# going low, but the processors are stubborn, read the config words only once, than dead lock. I wonder if there are known-working designs for this. What do you do in the case of blank flash on a board? The problem is not with blank flash or firmware upgrades, we know how to handle that. Your solution is (a solution) to a different problem. The problem lies in the fact that board dead lock can occur if the watchdog triggers, for all reference designs I have seen. Thanks for thinking along. I would like to solve the original problem though. BTW, we use CPLD/FPGAs on most of our boards, this one we do not for cost reasons. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC PCI DMA issues (prefetch/coherency?)
Hello all,
On Wed, Jun 17, 2009 at 2:37 AM, FUJITA
Tomonorifujita.tomon...@lab.ntt.co.jp wrote:
On Wed, 17 Jun 2009 10:18:45 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
On Tuesday 16 June 2009, Scott Wood wrote:
If the
device is the only one, you can also use dma_alloc_noncoherent() and
flush explicitly with dma_cache_sync().
I don't see how that would help -- aren't those also controlled by
CONFIG_NOT_COHERENT_CACHE?
Ah, yes you are right. PowerPC implements dma_alloc_noncoherent as
dma_alloc_coherent, so dma_cache_sync() is actually a NOP (or should be).
But we still need to sync the result of dma_map_* when used multiple
times for a single mapping.
We have dma_sync_{single|sg}_for_{cpu|device} API for the above
purpose.
dma_cache_sync is supposed to be used only with the buffers that
dma_alloc_noncoherent() returns. On architecutures that maps
dma_alloc_noncoherent to dma_alloc_coherent, dma_cache_sync() is
supposed to be NOP.
This discussion raised some doubt with me about my use case:
I my case (note I am not the poster) I am using (what LDD3 calls)
streaming mappings:
I use pci_map_sg(), have the device perform either DMA master reads or
writes to the bus address using PCIe.
After that, I use pci_unmap_sg().
My assumption is that pci_unmap_sg() either makes the cache coherent
or invalidated and thus I do not need to take further actions.
This is on a MPC83xx or 85xx system.
Is this assumption correct?
Regards,
Leon/
--
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
Adding the sata_fsl.c developers to the recipients:
On Mon, Jun 8, 2009 at 4:59 PM, Leon
Woestenbergleon.woestenb...@gmail.com wrote:
Hello,
using 2.6.30-rc6, I get the following problems when I read from a SSD
disk, connected to the
3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6.
Below see the output from two dd read runs.
The disk behaves fine on a x86 box.
What I can do to (help) pin-point the problem?
Regards,
Leon.
r...@mpc8315e-rdb:~# dd if=/dev/sda of=/dev/null bs=4k
ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:3e:1e:e0:01/00:00:00:00:00/e0 tag 0 dma 31744 in
res 50/00:3e:e0:df:01/00:00:00:00:00/e0 Emask 0x1 (device error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: Signature Update detected @ 3528 msecs
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 01 df e0
sd 1:0:0:0: [sda] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 122910
__ratelimit: 52 callbacks suppressed
Buffer I/O error on device sda, logical block 122910
Buffer I/O error on device sda, logical block 122911
Buffer I/O error on device sda, logical block 122912
Buffer I/O error on device sda, logical block 122913
Buffer I/O error on device sda, logical block 122914
Buffer I/O error on device sda, logical block 122915
Buffer I/O error on device sda, logical block 122916
Buffer I/O error on device sda, logical block 122917
Buffer I/O error on device sda, logical block 122918
Buffer I/O error on device sda, logical block 122919
ata2: EH complete
dd: /dev/sda: Input/output error
r...@mpc8315e-rdb:~# dd if=/dev/sda of=/dev/null bs=4k
ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:32:9a:6e:00/00:00:00:00:00/e0 tag 0 dma 25600 in
res 50/00:3e:5c:6e:00/00:00:00:00:00/e0 Emask 0x1 (device error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: Signature Update detected @ 3528 msecs
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 00 6e 5c
sd 1:0:0:0: [sda] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 28314
__ratelimit: 52 callbacks suppressed
Buffer I/O error on device sda, logical block 28314
Buffer I/O error on device sda, logical block 28315
Buffer I/O error on device sda, logical block 28316
Buffer I/O error on device sda, logical block 28317
Buffer I/O error on device sda, logical block 28318
Buffer I/O error on device sda, logical block 28319
Buffer I/O error on device sda, logical block 28320
Buffer I/O error on device sda, logical block 28321
Buffer I/O error on device sda, logical block 28322
Buffer I/O error on device sda, logical block 28323
ata2: EH complete
dd: /dev/sda: Input/output error
r...@mpc8315e-rdb:~# uname -a
Linux mpc8315e-rdb 2.6.30-rc6 #1 Mon Jun 8 15:54:00 CEST 2009 ppc unknown
r...@mpc8315e-rdb:~# hdparm -i /dev/sda
/dev/sda:
Model=Solidata X SSD , FwRev=0955 ,
SerialNo=...
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=128, MultSect=?1?
CurCHS=16383/16/63, CurSects=16514064, LBA=no
IORDY=no, tPIO={min:240,w/IORDY:120}
PIO modes: pio0 pio3 pio4
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=yes: disabled (255) WriteCache=disabled
Drive conforms to: Unspecified: ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6
ATA/ATAPI-7
* signifies the current active mode
--
Leon
--
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
Hello,
using 2.6.30-rc6, I get the following problems when I read from a SSD
disk, connected to the
3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6.
Below see the output from two dd read runs.
The disk behaves fine on a x86 box.
What I can do to (help) pin-point the problem?
Regards,
Leon.
r...@mpc8315e-rdb:~# dd if=/dev/sda of=/dev/null bs=4k
ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:3e:1e:e0:01/00:00:00:00:00/e0 tag 0 dma 31744 in
res 50/00:3e:e0:df:01/00:00:00:00:00/e0 Emask 0x1 (device error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: Signature Update detected @ 3528 msecs
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 01 df e0
sd 1:0:0:0: [sda] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 122910
__ratelimit: 52 callbacks suppressed
Buffer I/O error on device sda, logical block 122910
Buffer I/O error on device sda, logical block 122911
Buffer I/O error on device sda, logical block 122912
Buffer I/O error on device sda, logical block 122913
Buffer I/O error on device sda, logical block 122914
Buffer I/O error on device sda, logical block 122915
Buffer I/O error on device sda, logical block 122916
Buffer I/O error on device sda, logical block 122917
Buffer I/O error on device sda, logical block 122918
Buffer I/O error on device sda, logical block 122919
ata2: EH complete
dd: /dev/sda: Input/output error
r...@mpc8315e-rdb:~# dd if=/dev/sda of=/dev/null bs=4k
ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:32:9a:6e:00/00:00:00:00:00/e0 tag 0 dma 25600 in
res 50/00:3e:5c:6e:00/00:00:00:00:00/e0 Emask 0x1 (device error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: Signature Update detected @ 3528 msecs
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 00 6e 5c
sd 1:0:0:0: [sda] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 28314
__ratelimit: 52 callbacks suppressed
Buffer I/O error on device sda, logical block 28314
Buffer I/O error on device sda, logical block 28315
Buffer I/O error on device sda, logical block 28316
Buffer I/O error on device sda, logical block 28317
Buffer I/O error on device sda, logical block 28318
Buffer I/O error on device sda, logical block 28319
Buffer I/O error on device sda, logical block 28320
Buffer I/O error on device sda, logical block 28321
Buffer I/O error on device sda, logical block 28322
Buffer I/O error on device sda, logical block 28323
ata2: EH complete
dd: /dev/sda: Input/output error
r...@mpc8315e-rdb:~# uname -a
Linux mpc8315e-rdb 2.6.30-rc6 #1 Mon Jun 8 15:54:00 CEST 2009 ppc unknown
r...@mpc8315e-rdb:~# hdparm -i /dev/sda
/dev/sda:
Model=Solidata X SSD , FwRev=0955, SerialNo=...
Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=128, MultSect=?1?
CurCHS=16383/16/63, CurSects=16514064, LBA=no
IORDY=no, tPIO={min:240,w/IORDY:120}
PIO modes: pio0 pio3 pio4
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=yes: disabled (255) WriteCache=disabled
Drive conforms to: Unspecified: ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6
ATA/ATAPI-7
* signifies the current active mode
--
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] Add MSI interrupts to DTS of MPC8315E-RDB
The PCIe MSI interrupts are missing from the device tree source, and
thus were not enabled. This patch adds them.
v2 of the patch fixes inconsistent white space, reported by David Gibson.
Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
Signed-off-by: Leon Woestenberg l...@sidebranch.com
Tested-by: Leon Woestenberg l...@sidebranch.com
Index: git/arch/powerpc/boot/dts/mpc8315erdb.dts
===
--- git.orig/arch/powerpc/boot/dts/mpc8315erdb.dts 2009-05-23
20:49:40.0 +0200
+++ git/arch/powerpc/boot/dts/mpc8315erdb.dts 2009-06-06 10:35:14.0
+0200
@@ -322,6 +322,21 @@
reg = 0x700 0x100;
device_type = ipic;
};
+
+ ipic-...@7c0 {
+ compatible = fsl,ipic-msi;
+ reg = 0x7c0 0x40;
+ msi-available-ranges = 0 0x100;
+ interrupts = 0x43 0x8
+ 0x4 0x8
+ 0x51 0x8
+ 0x52 0x8
+ 0x56 0x8
+ 0x57 0x8
+ 0x58 0x8
+ 0x59 0x8;
+ interrupt-parent = ipic ;
+ };
};
pci0: p...@e0008500 {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[no subject]
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 3f4c5fb..4f04667 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -322,6 +322,21 @@
reg = 0x700 0x100;
device_type = ipic;
};
+
+ ipic-...@7c0 {
+ compatible = fsl,ipic-msi;
+reg = 0x7c0 0x40;
+msi-available-ranges = 0 0x100;
+ interrupts = 0x43 0x8
+ 0x4 0x8
+ 0x51 0x8
+ 0x52 0x8
+ 0x56 0x8
+ 0x57 0x8
+ 0x58 0x8
+ 0x59 0x8 ;
+ interrupt-parent = ipic ;
+ };
};
pci0: p...@e0008500 {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Add MSI interrupts to DTS of MPC8315E-RDB
The PCIe MSI interrupts are missing from the device tree source, and
thus were not enabled. This patch adds them.
Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
Signed-off-by: Leon Woestenberg l...@sidebranch.com
Tested-by: Leon Woestenberg l...@sidebranch.com
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 3f4c5fb..4f04667 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -322,6 +322,21 @@
reg = 0x700 0x100;
device_type = ipic;
};
+
+ ipic-...@7c0 {
+ compatible = fsl,ipic-msi;
+reg = 0x7c0 0x40;
+msi-available-ranges = 0 0x100;
+ interrupts = 0x43 0x8
+ 0x4 0x8
+ 0x51 0x8
+ 0x52 0x8
+ 0x56 0x8
+ 0x57 0x8
+ 0x58 0x8
+ 0x59 0x8 ;
+ interrupt-parent = ipic ;
+ };
};
pci0: p...@e0008500 {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mpc8315e-rdb: pci_enable_msi() fails (using today's galak/powerpc.git tree)
Hello, On Sun, May 24, 2009 at 8:38 AM, Michael Ellerman mich...@ellerman.id.au wrote: On Sun, 2009-05-24 at 00:12 +0200, Leon Woestenberg wrote: Hello, On Sat, May 23, 2009 at 10:58 PM, Leon Woestenberg leon.woestenb...@gmail.com wrote: using this tree: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git pci_enable_msi() fails on my MPC8315E-RDB board with PCIe device in snip good bug report 'lspci -vvv' of the device in question is often useful too. Good point. Here's the full list, the last device is my target: :00:00.0 0b20: 1957:00b4 (rev 10) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 128, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 17 Region 2: Memory at unassigned (64-bit, prefetchable) Region 4: Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] CompactPCI hot-swap ? Capabilities: [80] Power Management version 3 Flags: PMEClk+ DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 0002:02:00.0 : 1957:00b4 (rev 10) !!! Invalid class for header type 01 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=02, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: c000-cfff Prefetchable memory behind bridge: 0010-000f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [4c] Express (v1) Root Port (Slot-), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 2us, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [138] Virtual Channel ? Capabilities: [3f8] Vendor Specific Information ? 0002:03:00.0 ff00: 1172:0004 (rev 01) Subsystem: 1172:0004 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 25 Region 0: Memory at c000 (32-bit, non-prefetchable) [size=32K] Capabilities: [50] MSI: Mask- 64bit+ Count=1/4 Enable+ Address: e7f8 Data: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes
Re: mpc8315e-rdb: pci_enable_msi() fails (using today's galak/powerpc.git tree)
Hello,
On Sat, May 23, 2009 at 10:58 PM, Leon Woestenberg
leon.woestenb...@gmail.com wrote:
using this tree:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
pci_enable_msi() fails on my MPC8315E-RDB board with PCIe device in
I found that the DTS for the MPC8315E-RDB is missing the msi bits. I
added these, converted from the BSP (in old non-hex format):
ipic-...@7c0 {
compatible = fsl,ipic-msi;
reg = 0x7c0 0x40;
msi-available-ranges = 0 0x100;
interrupts = 0x43 8
0x4 8
0x51 8
0x52 8
0x56 8
0x57 8
0x58 8
0x59 8 ;
interrupt-parent = ipic ;
};
Now the MSI stuff gets set-up, pci_enable_msi() does not fault. My
interrupt handler is still not called though.
Partial log below:
[ 246.907366] Setting up Freescale MSI support
[ 247.858192] irq: irq 67 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 67
[ 249.323654] irq: irq 4 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 21
[ 250.779210] irq: irq 81 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 81
[ 252.244662] irq: irq 82 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 82
[ 253.710192] irq: irq 86 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 86
[ 255.175651] irq: irq 87 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 87
[ 256.641100] irq: irq 88 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 88
[ 258.106549] irq: irq 89 on host
/i...@e000/interrupt-control...@700 mapped to virtual irq 89
[ 309.396138] pci_enable_msi()
[ 309.399735] irq: irq 0 on host /i...@e000/ipic-...@7c0 mapped
to virtual irq 24
[ 309.408030] fsl_compose_msi_msg: allocated srs: 0, ibs: 0
[ 309.414160] Enabled MSI interrupting.
[ 309.418449] pci_read_config_byte(..., PCI_REVISION_ID, ...)
[ 309.424754] Board revision: 0x01.
[ 309.428690] pci_request_regions()
[ 309.432654] pci_set_dma_mask()
[ 309.436337] Using a 64-bit DMA mask.
[ 309.455605] request_irq()
[ 309.458925] Succesfully requested IRQ #24 with dev_id 0xc71c5440
debugfs shows:
virq hwirqchip namehost name
17 0x9 IPIC/i...@e000/interrupt-control...@700
22 0x00010 IPIC/i...@e000/interrupt-control...@700
23 0xe IPIC/i...@e000/interrupt-control...@700
24 0x0 FSL-MSI /i...@e000/ipic-...@7c0
32 0x00020 IPIC/i...@e000/interrupt-control...@700
33 0x00021 IPIC/i...@e000/interrupt-control...@700
34 0x00022 IPIC/i...@e000/interrupt-control...@700
35 0x00023 IPIC/i...@e000/interrupt-control...@700
36 0x00024 IPIC/i...@e000/interrupt-control...@700
37 0x00025 IPIC/i...@e000/interrupt-control...@700
38 0x00026 IPIC/i...@e000/interrupt-control...@700
Regards, Leon.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
Hello, On Sat, May 23, 2009 at 1:55 AM, Jeremy Fitzhardinge jer...@goop.org wrote: Ian Campbell wrote: On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote: I can work with that, but it's going to be a bit inefficient, as I actually need the dma_addr_t, not the phys_addr_t, so I'll have to convert. In every case, this is a conversion I've already done and that I need in the calling code as well. Does dma_addr_t dma_map_range(struct device *hwdev, phys_addr_t addr, size_t size); work for you? If the range does not need mapping then it returns the dma address, if you needed to calculate the dma address anyway to figure out if mapping is required then this is fine. If the range does need mapping then it returns NULL. My only concern is whether dma_addr_t == 0 is actually equivalent to NULL. That is, can we be sure that address 0 will never be used? Indeed, I remember seeing 0 returned on pci_alloc_coherent() as an address (cookie). Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [U-Boot] ppc4xx: u-boot sees PCIe endpoint, linux does not.
Hello Stefan, On Mon, Dec 1, 2008 at 8:46 PM, Stefan Roese s...@denx.de wrote: On Monday 01 December 2008, Leon Woestenberg wrote: Now, if I re-program the end-point FPGA during the u-boot boot time-out, Linux will recognize the end-point. It's possible that either the reset in between goes bonkers or something else causes your FPGA to stop responding. It looks like a programming problem with the FPGA to me. I have verified that the end point does not receive any kind of reset. Also, this problem only happens on the Canyonlands board; on x86 and powerpc MPC8315E it remains properly working after soft/hard resets, u-boot init etc. This could be because only the 4xx Linux PCI(e) driver really resets the endpoint (PHY reset). But you seem to have analyzed this already. Some progress: Using au-boot GIT checkout of 9-2-2009 (one month old) I now have different behaviour: u-boot does report a link, but no longer the PCIe vendor id: CPU: AMCC PowerPC 460EX Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 I2C: ready DTT: 1 is 44 C DRAM: 512 MB (ECC not enabled, 400 MHz, CL3) FLASH: 64 MB NAND: 128 MiB PCI: Bus Dev VenId DevId Class Int PCIE0: link is not up. PCIE0: initialization as root-complex failed PCIE1: successfully set as root-complex Linux now correctly recognizes the device. The FPGA with PCIe end point now also survives both a hard reset (reset button) and soft reset (shutdown -r now in Linux). Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: Make serial ports work on MPC8315E-RDB w/FSL U-Boots
Hello, On Mon, Jan 12, 2009 at 4:07 PM, Kumar Gala ga...@kernel.crashing.org wrote: On Jan 12, 2009, at 1:55 AM, Li Yang wrote: -Original Message- Freescale BSP is for customer who needs the out-of-box experience. It's better tested, but doesn't update very frequently. I would suggest the customer to use the upstream u-boot, if they decide to use latest upstream kernel. The upstream u-boot did however not support PCI Express, which the latest Freescale kernel did. So it was a chicken-egg problem experience for people wanting to test both the latest Freescale kernel as well as Antov's work to bring the PCI Express support upstream. Thanks Antov et al, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/4] powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E
Hello, On Mon, Jan 5, 2009 at 7:01 PM, Anton Vorontsov avoront...@ru.mvista.com wrote: On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote: [...] My statement was to convey that the kernel.org kernel should only worry itself with the denx.de u-boot (w/regards to compatibility). Why? Unless the BSP u-boots do something insane, I think we should try to have the upstream kernel boot on the u-boot that comes on the board (it's not nice to require users to reflash unnecessarily). The u-boot that came with the boards (at least MPC8315E-RDB) is too old for 2.6.25+ kernels: I have run into this earlier: http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg06551.html Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/4] powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E
Hello Anton, On Mon, Jan 5, 2009 at 7:01 PM, Anton Vorontsov avoront...@ru.mvista.com wrote: On Mon, Jan 05, 2009 at 11:46:45AM -0600, Scott Wood wrote: Why? Unless the BSP u-boots do something insane, I think we should try to have the upstream kernel boot on the u-boot that comes on the board (it's not nice to require users to reflash unnecessarily). Just in case, the latest version of this patch set is compatible with the FSL u-boots. Up to now, I was testing PCIe with this combo: - U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX, was on the board - dtc 1.1.0 - Linux 2.6.24.3 w/ Freescale patches from http://www.bitshrine.org/gpp/ That u-boot (i.e. on the mpc8315e-rdb board) had PCIe initialization. Is u-boot PCIe initialization required for this kernel patch to work? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/4] powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E
Hello Anton,
On Tue, Jan 6, 2009 at 10:15 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Tue, Jan 06, 2009 at 02:38:57PM -0600, Kumar Gala wrote:
Is u-boot PCIe initialization required for this kernel patch to work?
Yup.
Really? what for?
Hm. U-Boot should initialize SerDes and PCI-E controller (pcie laws,
inbound/outbound windows, clocks, etc.)
Though if PCI-E controller wasn't initialized (i.e. board reflashed
with the community u-boot), Linux just won't probe the pcie controller:
cfg_bar = in_le32(hose-cfg_data + PEX_OUTWIN0_BAR);
if (!cfg_bar) {
/* PCI-E isn't configured. */
ret = -ENODEV;
goto err1;
}
Or did I misunderstand the question?
You understood correctly, thanks for answering.
So to summarize, we need u-boot to initialize the PCIe controller, in
order for Linux to further take it over.
What u-boot versions/releases do provide this initialization?
I know the u-boot with the board works, but it's incompatible with
recent Linux kernels.
Regards,
--
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/4] powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E
Hello Anton, On Wed, Jan 7, 2009 at 12:42 AM, Anton Vorontsov avoront...@ru.mvista.com wrote: On Tue, Jan 06, 2009 at 11:33:35PM +0100, Leon Woestenberg wrote: So to summarize, we need u-boot to initialize the PCIe controller, in order for Linux to further take it over. What u-boot versions/releases do provide this initialization? Only FSL U-Boots so far (i.e. community u-boot + fsl patches). Could you be more specific? I would like to test your Linux kernel patch for 83xx/PCIe mainlining. What version (and what patches) of u-boot do both initialize pcie *and* work with recent Linux kernels? I am aware of the latest MPC8315E BSP (~2008-06), bitshrine.org/gpp/, the 83xx git tree at denx, and master git. The first works with 2.6.24, but not with 2.6.25+ The patches at bitshrine are not newer than that. The tree's are not FSL, or is this the FSL U-Boot you mean? I know the u-boot with the board works, but it's incompatible with recent Linux kernels. We should fix that (if possible). I was told just to upgrade u-boot, not what the actual problem was, although I would like to learn that. http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg06551.html Basically, this means I am unable to ship a bootloader now, supporting 2.6.24.7 now and 2.6.28 later. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28 does not boot on MPC8315E-RDB, or...?
Hello Anton, On Mon, Jan 5, 2009 at 5:58 PM, Anton Vorontsov avoront...@ru.mvista.com wrote: On Sun, Jan 04, 2009 at 01:45:15AM +0100, Leon Woestenberg wrote: Earlier release kernels booted for me, and I use the device tree compiled from the device tree source that comes with the tree. I used the exact same build procedure for the kernel and device tree blob, it's just that 2.6.28 seems to reset on start for the MPC8315E-RDB for me. Just wanted to hear if the problem is with me alone, or not. 2.6.28 works fine here... using arch/powerpc/configs/83xx/mpc8315_rdb_defconfig and arch/powerpc/boot/dts/mpc8315erdb.dts ... Hope this helps, Thanks for the report, I went back to the defconfig and at least it gives me a partial boot: Need to look into this tomorrow, it's too late for me here to spoil the night on this. Regards, Leon. U-Boot 1.3.0-rc2 (Oct 7 2008 - 11:57:25) MPC83XX Reset Status: CPU: e300c3, MPC8315E, Rev: 10 at 400 MHz, CSB: 133 MHz Board: Freescale MPC8315ERDB Rev 0.0 I2C: ready DRAM: 128 MB PCIE0: No link PCIE1: No link FLASH: 8 MB NAND: 32 MiB In:serial Out: serial Err: serial Net: eTSEC0, eTSEC1 Hit any key to stop autoboot: 0 eTSEC0: No link. eTSEC1: No link. Using eTSEC0 device TFTP from server 192.168.1.24; our IP address is 192.168.1.15 Filename 'uImage-mpc8315e-rdb.bin'. Load address: 0x40 Loading: T Got error 4 # done Bytes transferred = 1771462 (1b07c6 hex) Speed: 1000, full duplex Using eTSEC0 device TFTP from server 192.168.1.24; our IP address is 192.168.1.15 Filename 'uImage-mpc8315e-rdb.dtb'. Load address: 0x70 Loading: # done Bytes transferred = 12288 (3000 hex) ## Booting image at 0040 ... Image Name: Linux-2.6.28 Created: 2009-01-05 21:23:37 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1771398 Bytes = 1.7 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0x70 Using MPC831x RDB machine description Linux version 2.6.28 (l...@witty) (gcc version 4.2.4) #5 Mon Jan 5 22:23:31 CET9 console [udbg0] enabled setup_arch: bootmem mpc831x_rdb_setup_arch() No pci config register base in dev tree, using default Found FSL PCI host bridge at 0xe0008500. Firmware bus number: 0-0 PCI host bridge /p...@e0008500 (primary) ranges: MEM 0x9000..0x9fff - 0x9000 MEM 0x8000..0x8fff - 0x8000 Prefetch IO 0xe030..0xe03f - 0x arch: exit Zone PFN ranges: DMA 0x - 0x8000 Normal 0x8000 - 0x8000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x8000 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/nfs rw nfsroot=192.168.1.24:/nfsroot/mpc8315e ip8 IPIC (128 IRQ sources) at fdefa700 PID hash table entries: 512 (order: 9, 2048 bytes) clocksource: timebase mult[781] shift[22] registered Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 125992k/131072k available (3484k kernel code, 4936k reserved, 160k data) SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 66.56 BogoMIPS (lpj=133120) Mount-cache hash table entries: 512 net_namespace: 288 bytes NET: Registered protocol family 16 PCI: Probing PCI hardware pci :00:00.0: PME# supported from D0 D1 D2 D3hot pci :00:00.0: PME# disabled bus: 00 index 0 io port: [0x00-0xf] bus: 00 index 1 mmio: [0x9000-0x9fff] bus: 00 index 2 mmio: [0x8000-0x8fff] SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered NET: Registered protocol family 1 JFFS2 version 2.2. (NAND) �(c) 2001-2006 Red Hat, Inc. msgmni has been set to 246 alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Serial: 8250/16550 driver4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A console handover: ] serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A brd: module loaded loop: module loaded eth0: Gianfar Ethernet Controller Version 1.2, 04:00:00
Re: Unsubscribe
Hello Frank, On Sun, Jan 4, 2009 at 1:22 PM, Frank Lautenbach frank.lautenb...@gmx.de wrote: can you please unsubscribe me from this mailing list? Frank Every email from the list comes with this footer: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev Visit that URL and use the unsubscribe feature. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.28 does not boot on MPC8315E-RDB, or...?
Hello, I cannot get my 2.6.28 kernel to boot. The board resets after u-boot starts the kernel. I would like to verify if someone got it booting already? Regards, Leon. TFTP from server 192.168.1.24; our IP address is 192.168.1.15 Filename 'uImage-mpc8315e-rdb.bin'. Load address: 0x40 Loading: T # # # done Bytes transferred = 2033899 (1f08eb hex) Speed: 1000, full duplex Using eTSEC0 device TFTP from server 192.168.1.24; our IP address is 192.168.1.15 Filename 'uImage-mpc8315e-rdb.dtb'. Load address: 0x70 Loading: # done Bytes transferred = 12288 (3000 hex) ## Booting image at 0040 ... Image Name: Angstrom/2.6.28/mpc8315e-rdb Created: 2009-01-03 22:44:25 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:2033835 Bytes = 1.9 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0x70 U-Boot 1.3.0-rc2 (Oct 7 2008 - 11:57:25) MPC83XX -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.28 does not boot on MPC8315E-RDB, or...?
Hello, On Sun, Jan 4, 2009 at 1:33 AM, Steve DeLaney onramp...@yahoo.com wrote: we are booting 2.6.26 on MPC8349-MITXE do you need a device tree? this can be tftp loaded, or flashed in the board and cp.b from flash to ram before booting. Earlier release kernels booted for me, and I use the device tree compiled from the device tree source that comes with the tree. I used the exact same build procedure for the kernel and device tree blob, it's just that 2.6.28 seems to reset on start for the MPC8315E-RDB for me. Just wanted to hear if the problem is with me alone, or not. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Long boot delay on 460EX with 2.6.28-rc8
Felix, On Sat, Dec 20, 2008 at 7:51 AM, Felix Radensky fe...@embedded-sol.com wrote: I've found the cause of the delay. It was a stupid error on my part, not related to ndfc driver, which is fine. Thanks a lot for you work on this. Could you share the error?* (I'm sure I can easily exceed your level of stupidity) It helps people who are curiously following the thread (either now or in two years time, hi there!) learn if it matches their problem. I apologize for the noise. Apologies not required. Regards, -- Leon * unless of course, it was really really really stupid in the first place and will cost you your daytime job. Then you are excused. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [U-Boot] NAND only (no NOR)
Hello, On Wed, Dec 3, 2008 at 8:40 AM, Trent Piepho [EMAIL PROTECTED] wrote: On Wed, 3 Dec 2008, Sean MacLennan wrote: Yes, I would recommend to do it this way if possible. A small NOR for U-Boot and environment and everything else in NAND. This makes things much easier. But I understand that this is sometimes a problem with space (2 FLASH chips) and costs. Mainly cost. We didn't want to pay for a second chip. I think for NAND the latches necessary to de-multiplex the localbus aren't necessary like they are for NOR? On our board the latches might even take more space than the flash chip. The local bus can be configured to run non-multiplexed. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc4xx: u-boot sees PCIe endpoint, linux does not.
Hello all, On Mon, Dec 1, 2008 at 9:12 AM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Fri, 2008-11-28 at 13:50 +0100, Leon Woestenberg wrote: AMCC PPC460EX canyonlands board with an FPGA PCIe end point: u-boot sees the end point, but Linux does not: U-Boot 1.3.3-00249-ga524e11 (Jun 30 2008 - 16:05:51) CPU: AMCC PowerPC 460EX Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) ... Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 ... PCIE1: successfully set as root-complex 02 00 2071 2071 00ff 00 Now, if I re-program the end-point FPGA during the u-boot boot time-out, Linux will recognize the end-point. It's possible that either the reset in between goes bonkers or something else causes your FPGA to stop responding. It looks like a programming problem with the FPGA to me. I have verified that the end point does not receive any kind of reset. Also, this problem only happens on the Canyonlands board; on x86 and powerpc MPC8315E it remains properly working after soft/hard resets, u-boot init etc. Could it be u-boot overwrites a too large payload into the config space or something similar, which makes subsequent accesses fail? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC PPC460EX Canyonlands does not see PCIe end point with only non-prefetchable memory (both 2.6.27.7 and -next)
Hello all, On Wed, Nov 26, 2008 at 7:26 PM, Leon Woestenberg [EMAIL PROTECTED] wrote: On Wed, Nov 26, 2008 at 4:25 PM, Leon Woestenberg [EMAIL PROTECTED] wrote: The non-detected end point boot: pci 0001:80:00.0: scanning behind bridge, config bf8180, pass 0 PCI: Scanning bus 0001:81 PCI: Fixups for bus 0001:81 Progress on this issue: I found out that re-programming the end point FPGA again *just* after *uboot* read it, and before Linux kernel has started, makes the end point appear properly. Either u-boot leaves the end point in bad state, or the root complex reset also requires an end point reset. (or a third option I could not think of yet). I'll pick this up on ppc and u-boot mailing list with new info, especially with the ppc4xx maintainers. Consider this thread closed. Thanks for ignoring my ranting :-) Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ppc4xx: u-boot sees PCIe endpoint, linux does not.
Hello, AMCC PPC460EX canyonlands board with an FPGA PCIe end point: u-boot sees the end point, but Linux does not: U-Boot 1.3.3-00249-ga524e11 (Jun 30 2008 - 16:05:51) CPU: AMCC PowerPC 460EX Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) ... Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 ... PCIE1: successfully set as root-complex 02 00 2071 2071 00ff 00 Now, if I re-program the end-point FPGA during the u-boot boot time-out, Linux will recognize the end-point. Any takers on what I should start looking for? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
AMCC PPC460EX Canyonlands does not see PCIe end point with only non-prefetchable memory (both 2.6.27.7 and -next)
Hello, AMCC PPC460EX Canyonlands development board with PCI Express x1 card in PCIe x4 slot labeled 'PCIE-1'. The PCI Express card has a soft-programmable PCIe end point. Problem: The end point with only non-prefetchable BAR does not appear behind the PPC SoC internal bridge. It does show up on two other setups: MPC8315E-RDB PPC as well as a PC x86. It has BARs 0-5 each as a 32-bit non-prefetchable memory region. This is the kernel boot: pci 0001:80:00.0: PCI bridge, secondary bus 0001:81 pci 0001:80:00.0: IO window: disabled pci 0001:80:00.0: MEM window: disabled pci 0001:80:00.0: PREFETCH window: disabled ... bus: 81 index 0 mmio: [0xfffe-0xfffe0fff] bus: 81 index 1 mmio: [0xeb800-0xeb80f] bus: 81 index 2 mmio: [0x0-0x0] bus: 81 index 3 mmio: [0x0-0x0] lspci -v does not show the device. The default end point design does have a prefetchable region and does show up properly: pci 0001:80:00.0: PCI bridge, secondary bus 0001:81 pci 0001:80:00.0: IO window: disabled pci 0001:80:00.0: MEM window: 0x8100-0x810f pci 0001:80:00.0: PREFETCH window: 0x008000-0x0080ff ... bus: 81 index 0 mmio: [0xfffe-0xfffe0fff] bus: 81 index 1 mmio: [0xe8100-0xe810f] bus: 81 index 2 mmio: [0xe8000-0xe80ff] bus: 81 index 3 mmio: [0x0-0x0] Working and non-working behaviour is identical on 2.6.27.7 and today's -next tree. Full u-boot, kernel and lspci -v output attached. Also put online on: http://www.sidebranch.com/leon/next_broken.txt http://www.sidebranch.com/leon/next_works.txt Any ideas why/where this might go wrong? I'm diving into the code now, especially seeing why the memory behind the bridge was disabled. Regards, -- Leon u-boot U-Boot 1.3.3-00249-ga524e11 (Jun 30 2008 - 16:05:51) CPU: AMCC PowerPC 460EX Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 I2C: ready DTT: 1 is 46 C DRAM: 512 MB (ECC not enabled, 400 MHz, CL3) FLASH: 64 MB NAND: 128 MiB PCI: Bus Dev VenId DevId Class Int PCIE0: link is not up. PCIE0: initialization as root-complex failed PCIE1: successfully set as root-complex 02 00 1a0b 5331 ff00 00 Net: ppc_4xx_eth0, ppc_4xx_eth1 kernel Linux version 2.6.28-rc6-next-20081125-dirty ([EMAIL PROTECTED]) (gcc version 4.2.4) #1 Wed Nov 26 15:02:52 CET 2008 Zone PFN ranges: DMA 0x - 0x0002 Normal 0x0002 - 0x0002 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x0002 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/nfs rw nfsroot=172.16.0.50:/nfsroot/canyonlands ip=172.16.0.46:172.16.0.50:::canyonlands:eth0:off panic=1 console=ttyS0,115200 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 UIC2 (32 IRQ sources) at DCR 0xe0 UIC3 (32 IRQ sources) at DCR 0xf0 PID hash table entries: 2048 (order: 11, 8192 bytes) clocksource: timebase mult[50] shift[22] registered Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 516736k/524288k available (2432k kernel code, 7232k reserved, 100k data, 119k bss, 144k init) SLUB: Genslabs=10, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 1597.44 BogoMIPS (lpj=3194880) Mount-cache hash table entries: 512 net_namespace: 300 bytes NET: Registered protocol family 16 256k L2-cache enabled PCIE0: Checking link... PCIE0: No device detected. PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x000e..0x000e7fff - 0x8000 IO 0x000f8000..0x000f8000 - 0x 4xx PCI DMA offset set to 0x PCIE0: successfully set as root-complex PCIE1: Checking link... PCIE1: Device detected, waiting for link... PCIE1: link is up ! PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x000e8000..0x000e - 0x8000 IO 0x000f8001..0x000f8001 - 0x 4xx PCI DMA offset set to 0x PCIE1: successfully set as root-complex PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x000d8000..0x000d - 0x8000 IO 0x000c0800..0x000c0800 - 0x 4xx PCI DMA offset set to 0x PCI: Probing PCI hardware PCI: Hiding 4xx host bridge resources :40:00.0 PCI: Hiding 4xx host bridge resources 0001:80:00.0 pci 0001:81:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' pci :40:00.0: PCI bridge, secondary bus :41 pci :40:00.0: IO window: disabled pci :40:00.0: MEM window: disabled pci :40:00.0: PREFETCH window: disabled pci 0001:80:00.0:
Re: too few bogoMips on MPC8313E-RDB ?
Hello, On Wed, Nov 26, 2008 at 3:20 PM, Norbert van Bolhuis [EMAIL PROTECTED] wrote: Thanks for the answer, but that's not it. I checked the jiffies variable, it increases about 250 times per second. So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250) is OK. It must be something else, I still think 83.20 BogoMIPS can't be correct for a MPC8313 running at 333 MHz. For an extra data point, I checked on my MPC8315E-RDB: [EMAIL PROTECTED]:~# cat /proc/cpuinfo processor : 0 cpu : e300c3 clock : 400.02MHz revision: 2.0 (pvr 8085 0020) bogomips: 66.56 timebase: platform: MPC831x RDB I can check on a MPC8313E-RDB later. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC PPC460EX Canyonlands does not see PCIe end point with only non-prefetchable memory (both 2.6.27.7 and -next)
Hello, I enabled more DEBUG output, the online files have been updated. Snippets: The detected end point boot: pci 0001:80:00.0: scanning behind bridge, config bf8180, pass 0 PCI: Scanning bus 0001:81 pci 0001:81:00.0: found [1a0b:5331] class 00ff00 header type 00 pci 0001:81:00.0: reg 10 64bit mmio: [0xb800-0xb8ff] pci 0001:81:00.0: reg 18 32bit mmio: [0xb900-0xb903] pci 0001:81:00.0: calling pcibios_fixup_resources+0x0/0xec pci 0001:81:00.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154 pci 0001:81:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' PCI: Fixups for bus 0001:81 The non-detected end point boot: pci 0001:80:00.0: scanning behind bridge, config bf8180, pass 0 PCI: Scanning bus 0001:81 PCI: Fixups for bus 0001:81 Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Floating inputs on unused GPIO pins
Hello Laurent, On Mon, Oct 13, 2008 at 11:56 AM, Laurent Pinchart [EMAIL PROTECTED] wrote: our hardware engineer asked me to make sure all unused GPIO pins are configured as outputs to avoid floating inputs. He got theory on his side (floating inputs can lead to higher current consumption, metastability or even permanent damage), but I'd like to ask the list for practical feedback. Ideally, configure them as inputs or tri-state (both mean high impedance), and do use pull-down or -up resistors. Now, the answer might be different when your pins are not connected. Check on the processor if internal pull resistors are present. If so, use as input. If not, then your h/w engineer *may* have a point, not sure on that though. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Floating inputs on unused GPIO pins
Hello Laurent, On Mon, Oct 13, 2008 at 3:12 PM, Bill Gatliff [EMAIL PROTECTED] wrote: At least until someone plugs in that expansion module! Bill's remark made a neuron connection in my head: Can you detect if the module is inserted or not? (By reading a known state of some pin)? You could then configure the pins dynamically in your driver. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Floating inputs on unused GPIO pins
Hi Laurent, On Mon, Oct 13, 2008 at 1:04 PM, Laurent Pinchart [EMAIL PROTECTED] wrote: There are no internal pull-up or pull-down resistors on the MPC8248 GPIO pins. I know our hardware engineer has a valid point theoretically. Does the point stand practically, or does the MPC8248 state-of-the-art(tm)(c)(whatever) technology make floating inputs safe ? Ask Freescale? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: performance: memcpy vs. __copy_tofrom_user
Hello all, On Thu, Oct 9, 2008 at 1:41 PM, Dominik Bozek [EMAIL PROTECTED] wrote: Paul Mackerras wrote: Dominik Bozek writes: Actually I made couple of other tests on that mpc8313. Most of them are to ugly to publish them, but... My problem is that I have to boost the gigabit interface on the mpc8313. I made simple substitution and Very interesting. Can you work out where memcpy is being called on the network data? I wouldn't have expected that. Also see this recent thread David Jander on August 25th, Efficient memcpy()/memmove() for G2/G3 cores... on [EMAIL PROTECTED] http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062449.html BTW, I am interested in this work as well, I'm currently working with a 8313 and 8315 design, both are e300 cores. My current goal is PCIe though, but I need fast GbE performance as well. Also, did you test Freescale's 2.6.24.3 patches that tune the gianfar interfaces for higher performance? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8315ERDB PCI Express support status?
Kumar, John, On Mon, Oct 6, 2008 at 5:09 PM, Kumar Gala [EMAIL PROTECTED] wrote: On Oct 6, 2008, at 8:42 AM, Leon Woestenberg wrote: can Freescale or any of the powerpc maintainers indicate to what extend PCI Express support for the MPC8315E processor has been merged to Linux mainline, or what is still needs review or attention? I could find u-boot and Linux patches provided by Freescale in their [...] but I could not easily identify what has been merged upstream. My first goal (and hardware on my desk) would be to test an Intel PCIe PRO/1000 Ethernet adapter, as a start to add a custom PCIe FPGA device. No PCI-e support for 83xx has been merged in any mainline kernel. I got MPC8315E working with PCI Express, using an Intel PRO/1000 GbE PCIe x1 card, using 2.6.24.3-rt3 with a lot of Freescale patches, as well as u-boot 1.2.0 forward patched to 1.3.0 by Freescale with some PCIe initialization work. So, basically the BSP 20080627. I would like these patches to be ported forward to mainline, and I can put some time in this, but I'ld rather first know what the Freescale status on the patches is? John, Stuart, could you please check if there is ongoing work in Freescale? I hate double efforts when I'm short on time :-) Thanks. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC8315ERDB PCI Express support status?
Hello all, can Freescale or any of the powerpc maintainers indicate to what extend PCI Express support for the MPC8315E processor has been merged to Linux mainline, or what is still needs review or attention? I could find u-boot and Linux patches provided by Freescale in their open-source patch pool: http://www.bitshrine.org/gpp/ http://www.bitshrine.org/gpp/linux-fsl-2.6.24.3-MPC8315ERDB-pcie-INTx-support.patch but I could not easily identify what has been merged upstream. My first goal (and hardware on my desk) would be to test an Intel PCIe PRO/1000 Ethernet adapter, as a start to add a custom PCIe FPGA device. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)
André, On Tue, Sep 30, 2008 at 12:05 AM, Leon Woestenberg [EMAIL PROTECTED] wrote: Since you also have to assert HRESET when you assert PORESET But when I assert PORESET, the processor will assert HRESET itself AFAIK, so why do this? you can wire-or them with a low drop schottky diode. MPC8313E PowerQUICC II Pro Integrated Processor Family Reference Manual, Rev. 1, section 4.2.2, page 4-6: Directly after the negation of PORESET, the device starts the configuration process. The device asserts HRESET throughout the power-on reset process, including configuration So, I will not drive HRESET myself but depend on the ppc to drive it for me. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)
Hello all, not Linux related per se*, but I wonder how your board designs deal with the reset circuitry for embedded PowerPC processors (MPC8313E in my case). My requirement is that both a processor-external hard reset and processor-internal hard reset must both reset the boot device NOR FlashROM, so that it does not remain in write mode (if it is). Given those processor pins: PORESET# (input pin to the processor, power on reset) HRESET# (bidirectional pin on the processor, asserted by processor on hard reset such as watchdog) I see many designs (even the Freescale reference designs) where the HRESET# resets some of the board, but not the FlashROM, and where PORESET# resets the FlashROM. This can cause a deadlock in the case where the watchdog resets during writing to FlashROM, as the FlashROM is not reset and remains in write mode, not allowing the processor to boot from it. I am thinking of using this approach: PORESET# - processor -- HRESET# - board reset. Would that work? or why not? Regards, -- Leon * to make this Linux related: suppose MTD is writing new firmware to your NOR FlashROM and then /dev/wdg is not petted due to some programmer bug in the firmware update code. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)
Hello André, On Mon, Sep 29, 2008 at 11:50 PM, André Schwarz [EMAIL PROTECTED] wrote: Leon, you're right. PORESET is just there to prevent the core from running as long as power may be unstable and/or PLLs are out of lock. HRESET is the signal that should reset everything. I did it on my board and it works fine. Understood so far. Since you also have to assert HRESET when you assert PORESET But when I assert PORESET, the processor will assert HRESET itself AFAIK, so why do this? you can wire-or them with a low drop schottky diode. Ooh, analog electronics, long time ago. Let me think: arrow of diode symbol pointing from HRESET# to PORESET#, right, so that PORESET# going low will pull HRESET# low enough, right? Hope this helps. Yes it does, thanks. Regards, Leon. Leon Woestenberg wrote: Hello all, not Linux related per se*, but I wonder how your board designs deal with the reset circuitry for embedded PowerPC processors (MPC8313E in my case). My requirement is that both a processor-external hard reset and processor-internal hard reset must both reset the boot device NOR FlashROM, so that it does not remain in write mode (if it is). Given those processor pins: PORESET# (input pin to the processor, power on reset) HRESET# (bidirectional pin on the processor, asserted by processor on hard reset such as watchdog) I see many designs (even the Freescale reference designs) where the HRESET# resets some of the board, but not the FlashROM, and where PORESET# resets the FlashROM. This can cause a deadlock in the case where the watchdog resets during writing to FlashROM, as the FlashROM is not reset and remains in write mode, not allowing the processor to boot from it. I am thinking of using this approach: PORESET# - processor -- HRESET# - board reset. Would that work? or why not? Regards, MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Any benchmarks on PCIe performance MPC83xx?
Hello, did anyone yet perform benchmarks on a combination of PCIe device (off-the-shelf or custom) doing bulk data transfers, and bringing this off the chip via GbE or SATA using a recent Linux kernel? Also, can someone suggest a readily available PCIe device that has a driver that is supported under Linux/ppc, and allows me to do such benchmarks before we implement a custom PCIe target? Thanks for any info. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
