doc: PCI: altera: Fix the 'ranges' property in example

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

[1] http://rocketboards.org/foswiki/view/Projects/PCIeRootPortWithMSI

Signed-off-by Marek Vasut <[email protected]>

Cc Bjorn Helgaas <[email protected]>

Cc Ley Foon Tan <[email protected]>

Cc Marc Zyngier <[email protected]>

Cc Rob Herring <[email protected]>

---
 Documentation/devicetree/bindings/pci/altera-pcie.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Documentation/devicetree/bindings/pci/altera-pcie.txt +2 -2

index 2951a6a..d2427c1 100644
@@ -44,6 +44,6 @@ Example
 			            <0 0 0 2 &pcie_0 2>,
 			            <0 0 0 3 &pcie_0 3>,
 			            <0 0 0 4 &pcie_0 4>;
-		ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x10000000
-			    0x82000000 0x00000000 0x10000000 0xd0000000 0x00000000 0x10000000>;
+		ranges = <0x82000000 0x00000000 0xc0000000 0xc0000000 0x00000000 0x10000000
+			  0x82000000 0x00000000 0xd0000000 0xd0000000 0x00000000 0x10000000>;
 	};

Quoted 5 lines · Marek Vasut

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

The original "ranges" is working for me. What error did you encounter?

Thanks.

Quoted 19 lines

[1] http://rocketboards.org/foswiki/view/Projects/PCIeRootPortWithMSI

Signed-off-by Marek Vasut <[email protected]>

Cc Bjorn Helgaas <[email protected]>

Cc Ley Foon Tan <[email protected]>

Cc Marc Zyngier <[email protected]>

Cc Rob Herring <[email protected]>

---

 Documentation/devicetree/bindings/pci/altera-pcie.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(quoted diff) +0 -0

b/Documentation/devicetree/bindings/pci/altera-pcie.txt index 2951a6a..d2427c1 100644

Documentation/devicetree/bindings/pci/altera-pcie.txt +0 -0

@@ -44,6 +44,6 @@ Example
 

Quoted 6 lines

Documentation/devicetree/bindings/pci/altera-pcie.txt +0 -1

 			            <0 0 0 2 &pcie_0 2>,
 			            <0 0 0 3 &pcie_0 3>,
 			            <0 0 0 4 &pcie_0 4>;
 
-		ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000

0x10000000 - 0x82000000 0x00000000 0x10000000

Quoted 1 line

0x00000000 0x10000000>; + ranges = <0x82000000 0x00000000

Quoted 1 line

0xc0000000 0x00000000 0x10000000 + 0x82000000 0x00000000

Quoted 3 lines

0xd0000000 0x00000000 0x10000000>;

};

Quoted 8 lines · Ley Foon Tan

Quoted 5 lines · Marek Vasut

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 1 line

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 2 lines

Thanks.

Quoted 18 lines · Marek Vasut

Quoted 8 lines · Ley Foon Tan

Quoted 5 lines · Marek Vasut

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 1 line

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

Quoted 10 lines

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 1 line

Thanks.

Hi Marek

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

Quoted 32 lines · Ley Foon Tan

Quoted 18 lines · Marek Vasut

Quoted 8 lines · Ley Foon Tan

Quoted 5 lines · Marek Vasut

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 1 line

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

Quoted 10 lines

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 1 line

Thanks.

Hi Marek

Quoted 5 lines

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

I'm using next from 20151223, crude patch is attached.

Quoted 40 lines · Marek Vasut

Quoted 38 lines · Ley Foon Tan

Quoted 19 lines · Marek Vasut

Quoted 8 lines · Ley Foon Tan

Quoted 5 lines · Marek Vasut

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 2 lines

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

Quoted 10 lines

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 1 line

Thanks.

Hi Marek

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

Quoted 1 line

I'm using next from 20151223, crude patch is attached.

Hi Marek

Your dts looks fine, same as mine; except the 'ranges' parameter. Not sure why it is not working on your side.

I may try again with the linux-next later.

Quoted 43 lines · Ley Foon Tan

Quoted 41 lines · Marek Vasut

Quoted 31 lines · Ley Foon Tan

Quoted 19 lines · Marek Vasut

Quoted 8 lines · Ley Foon Tan

Quoted 5 lines · Marek Vasut

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 2 lines

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

Quoted 10 lines

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 1 line

Thanks.

Quoted 7 lines

Hi Marek

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

I'm using next from 20151223, crude patch is attached.

Quoted 6 lines

Hi Marek

Your dts looks fine, same as mine; except the 'ranges' parameter. Not sure why it is not working on your side.

I may try again with the linux-next later.

Looking forward to your observations ;-)

btw the other difference is location of the Cra port, in my case it's at 0xff220000 , which matches the altera reference design. The example code uses 0xff240000 for whatever reason.

Quoted 47 lines · Marek Vasut

Quoted 46 lines · Ley Foon Tan

Quoted 35 lines · Marek Vasut

Quoted 34 lines · Ley Foon Tan

Quoted 23 lines · Marek Vasut

Quoted 8 lines · Ley Foon Tan

Quoted 5 lines · Marek Vasut

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 2 lines

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Quoted 7 lines

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 1 line

Thanks.

Hi Marek

Quoted 7 lines

Quoted 5 lines

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

I'm using next from 20151223, crude patch is attached.

Hi Marek

Quoted 6 lines

Quoted 4 lines

Your dts looks fine, same as mine; except the 'ranges' parameter. Not sure why it is not working on your side.

I may try again with the linux-next later.

Looking forward to your observations ;-)

Tested with 20151223 linux-next, it is working with original dts.

Quoted 3 lines

btw the other difference is location of the Cra port, in my case it's at 0xff220000 , which matches the altera reference design. The example code uses 0xff240000 for whatever reason.

The example code uses 0xff220000, where do you see 0xff240000?

Quoted 53 lines · Ley Foon Tan

Quoted 52 lines · Marek Vasut

Quoted 50 lines · Ley Foon Tan

Quoted 35 lines · Marek Vasut

Quoted 34 lines · Ley Foon Tan

Quoted 23 lines · Marek Vasut

Quoted 8 lines · Ley Foon Tan

Quoted 5 lines · Marek Vasut

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 2 lines

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Quoted 7 lines

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 1 line

Thanks.

Hi Marek

Quoted 7 lines

Quoted 5 lines

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

I'm using next from 20151223, crude patch is attached.

Hi Marek

Your dts looks fine, same as mine; except the 'ranges' parameter. Not sure why it is not working on your side.

I may try again with the linux-next later.

Quoted 3 lines

Quoted 1 line

Looking forward to your observations ;-)

Tested with 20151223 linux-next, it is working with original dts.

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Quoted 6 lines · Marek Vasut

Quoted 5 lines · Ley Foon Tan

Quoted 4 lines · Marek Vasut

Quoted 3 lines · Ley Foon Tan

Quoted 2 lines · Marek Vasut

Quoted 1 line · Ley Foon Tan

On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <[email protected]>

Quoted 51 lines

Quoted 51 lines

Quoted 50 lines

Quoted 40 lines

Quoted 40 lines

Quoted 39 lines

Quoted 24 lines · Ley Foon Tan

Quoted 9 lines · Marek Vasut

Quoted 6 lines

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 2 lines

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Quoted 7 lines

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 1 line

Thanks.

Hi Marek

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

Quoted 8 lines

Quoted 1 line

I'm using next from 20151223, crude patch is attached.

Hi Marek

Your dts looks fine, same as mine; except the 'ranges' parameter. Not sure why it is not working on your side.

I may try again with the linux-next later.

Looking forward to your observations ;-)

Quoted 5 lines

Quoted 1 line

Tested with 20151223 linux-next, it is working with original dts.

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

Quoted 7 lines · Ley Foon Tan

Quoted 6 lines · Marek Vasut

Quoted 5 lines · Ley Foon Tan

Quoted 4 lines · Marek Vasut

Quoted 3 lines · Ley Foon Tan

Quoted 2 lines · Marek Vasut

Quoted 1 line · Ley Foon Tan

On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <[email protected]>

Quoted 53 lines · wrote:

Quoted 53 lines

Quoted 52 lines

Quoted 42 lines

Quoted 42 lines

Quoted 41 lines

Quoted 32 lines

Quoted 24 lines · Ley Foon Tan

Quoted 9 lines · Marek Vasut

Quoted 6 lines

The example does not work on real hardware with the PCIe HIP [1]. The problem is with incorrect "ranges" property in the example, so one cannot just copy-paste the example into his DT and expect this to work. This patches aligns the "ranges" in the example with the reference FPGA design.

Hi Marek

Hi Ley,

Quoted 2 lines

The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard. The Cra access always worked fine though, so the PCIe devices were always detected.

I checked with signaltap and my impression is that the wrong address propagated into the request passed to the Txs port of the HardIP block, unless I change the range configuration.

Quoted 7 lines

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi card. The intel in particular uses both the Txs and even MSI , so to use the intel, the whole PCIe block has to work properly ; with this change, it does and I can use the intel card just fine.

Quoted 1 line

Thanks.

Quoted 7 lines

Hi Marek

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

I'm using next from 20151223, crude patch is attached.

Quoted 8 lines

Quoted 6 lines

Hi Marek

Your dts looks fine, same as mine; except the 'ranges' parameter. Not sure why it is not working on your side.

I may try again with the linux-next later.

Looking forward to your observations ;-)

Tested with 20151223 linux-next, it is working with original dts.

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Do you use the hardware design from the rocketboards.org or your own design?

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 9 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

Quoted 17 lines · Marek Vasut

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 9 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 5 lines

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

You may check again the base addresses use in the MCVEVK board.

Quoted 21 lines · Ley Foon Tan

Quoted 20 lines · Marek Vasut

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 9 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

Quoted 4 lines

Quoted 2 lines

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

You may check again the base addresses use in the MCVEVK board.

The address map is attached ; I don't see anything which would differ from the reference design.

btw I am honestly surprised that Quartus cannot export the address map into some text file :-(

Quoted 26 lines · Marek Vasut

Quoted 25 lines · Ley Foon Tan

Quoted 23 lines · Marek Vasut

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 10 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

Quoted 4 lines

Quoted 1 line

You may check again the base addresses use in the MCVEVK board.

The address map is attached ; I don't see anything which would differ from the reference design.

Address map looks fine.

Quoted 2 lines

btw I am honestly surprised that Quartus cannot export the address map into some text file :-(

There is a *.html file in the generated directory.

Quoted 27 lines · Ley Foon Tan

Quoted 26 lines · Marek Vasut

Quoted 25 lines · Ley Foon Tan

Quoted 23 lines · Marek Vasut

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 10 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

You may check again the base addresses use in the MCVEVK board.

The address map is attached ; I don't see anything which would differ from the reference design.

Address map looks fine.

Well do you have any other idea then ? I guess I should pull out the SOCDK, huh?

Quoted 5 lines

Quoted 3 lines

btw I am honestly surprised that Quartus cannot export the address map into some text file :-(

There is a *.html file in the generated directory.

Oh, I didn't know that, thanks!

Quoted 33 lines · Marek Vasut

Quoted 32 lines · Ley Foon Tan

Quoted 30 lines · Marek Vasut

Quoted 19 lines · Ley Foon Tan

Quoted 18 lines · Marek Vasut

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 10 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

You may check again the base addresses use in the MCVEVK board.

The address map is attached ; I don't see anything which would differ from the reference design.

Quoted 4 lines

Quoted 1 line

Address map looks fine.

Well do you have any other idea then ? I guess I should pull out the SOCDK, huh?

Can't think of any other thing that impact this, I expect the bus width used in the pipeline/bridge are same with the example design. Do you have our CV

AV

A10 SoC devkit?

Quoted 33 lines · Marek Vasut

Quoted 32 lines · Ley Foon Tan

Quoted 30 lines · Marek Vasut

Quoted 19 lines · Ley Foon Tan

Quoted 18 lines · Marek Vasut

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 10 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

You may check again the base addresses use in the MCVEVK board.

The address map is attached ; I don't see anything which would differ from the reference design.

Quoted 4 lines

Quoted 1 line

Address map looks fine.

Well do you have any other idea then ? I guess I should pull out the SOCDK, huh?

Can't think of any other thing that impact this, I expect the bus width used in the pipeline/bridge are same with the example design. Do you have our CV, AV or A10 SoC devkit?

Quoted 39 lines · Ley Foon Tan

Quoted 37 lines · Marek Vasut

Quoted 27 lines · Ley Foon Tan

Quoted 26 lines · Marek Vasut

Quoted 25 lines · Ley Foon Tan

Quoted 23 lines · Marek Vasut

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 10 lines

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

You may check again the base addresses use in the MCVEVK board.

The address map is attached ; I don't see anything which would differ from the reference design.

Address map looks fine.

Well do you have any other idea then ? I guess I should pull out the SOCDK, huh?

Quoted 3 lines

Can't think of any other thing that impact this, I expect the bus width used in the pipeline/bridge are same with the example design. Do you have our CV, AV or A10 SoC devkit?

I tested CV SoCDK just now and you're right, the provided quartus project works without this change on the CV SoCDK. Do you have any suggestion for me where I should try looking then please ?

Quoted 47 lines · Marek Vasut

Quoted 45 lines · Ley Foon Tan

Quoted 33 lines · Marek Vasut

Quoted 32 lines · Ley Foon Tan

Quoted 31 lines · Marek Vasut

Quoted 29 lines · Ley Foon Tan

Quoted 18 lines · Marek Vasut

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

Well, do you have a good explanation why the system works with this change and doesn't work without it on my design ? I'd really love to understand this.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

Do you modify the driver to setup the translation
table?

No, I didn't change the driver. What do you refer to please ?

There is Address Translation Table at address offset 0x1000 in the IP.

Quoted 8 lines

Oh, I didn't configure that in any way. Should I or does the driver configure it in some way?

Quoted 2 lines

Do you use the hardware design from the rocketboards.org or your own design?

I use the one from rocketboards, I just ported it over to the MCVEVK (custom cyclone v soc board)

You may check again the base addresses use in the MCVEVK board.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

The address map is attached ; I don't see anything which would differ from the reference design.

Address map looks fine.

Well do you have any other idea then ? I guess I should pull out the SOCDK, huh?

Can't think of any other thing that impact this, I expect the bus width used in the pipeline/bridge are same with the example design. Do you have our CV, AV or A10 SoC devkit?

Quoted 3 lines

I tested CV SoCDK just now and you're right, the provided quartus project works without this change on the CV SoCDK. Do you have any suggestion for me where I should try looking then please ?

Do you check the hardware pipeline bridge in Qsys? Are they same configuration as CV SoCDK design?