| Message ID | 201512280926.53004.marex@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote: > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote: > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote: > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote: > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote: > > >> > 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, > > > > > >> 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. > > > > > >> 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? > > 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. Regards Ley Foon
On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote: > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote: > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote: > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote: > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote: > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote: > > > >> > 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, > > > > > > > >> 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. > > > > > > > >> 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? > > > > 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 ;-) 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. Best regards, Marek Vasut
On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote: > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote: > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote: > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote: > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote: > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote: > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote: > > > > >> > 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, > > > > > > > > > >> 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. > > > > > > > > > >> 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? > > > > > > 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 ;-) Tested with 20151223 linux-next, it is working with original dts. > > 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?
On Thursday, December 31, 2015 at 04:09:01 AM, Ley Foon Tan wrote: > On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote: > > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote: > > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote: > > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote: > > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote: > > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote: > > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote: > > > > > >> > 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, > > > > > > > > > > > >> 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. > > > > > > > > > > > >> 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? > > > > > > > > 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 ;-) > > 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. > > 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? I thought the ccb_lw_50_to_125 was at +0x40000 in the original design, but I can't seem to be able to find that. I've been studying multiple PCIe designs and this notion somehow crawled into my skull. Sorry, please ignore then. Best regards, Marek Vasut
On Thu, 2015-12-31 at 10:04 +0100, Marek Vasut wrote: > On Thursday, December 31, 2015 at 04:09:01 AM, Ley Foon Tan wrote: > > On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote: > > > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote: > > > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote: > > > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote: > > > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote: > > > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote: > > > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote: > > > > > > >> > 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, > > > > > > > > > > > > > >> 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. > > > > > > > > > > > > > >> 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? > > > > > > > > > > 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 ;-) > > > > 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? Regards Ley Foon
On Monday, January 04, 2016 at 12:29:40 AM, Ley Foon Tan wrote: > On Thu, 2015-12-31 at 10:04 +0100, Marek Vasut wrote: > > On Thursday, December 31, 2015 at 04:09:01 AM, Ley Foon Tan wrote: > > > On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote: > > > > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote: > > > > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote: > > > > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote: > > > > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote: > > > > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote: > > > > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote: > > > > > > > >> > 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, > > > > > > > > > > > > > > > >> 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. > > > > > > > > > > > > > > > >> 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? > > > > > > > > > > > > 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 ;-) > > > > > > 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? No, I didn't change the driver. What do you refer to please ? Best regards,
On Mon, 2016-01-04 at 00:36 +0100, Marek Vasut wrote: > On Monday, January 04, 2016 at 12:29:40 AM, Ley Foon Tan wrote: > > On Thu, 2015-12-31 at 10:04 +0100, Marek Vasut wrote: > > > On Thursday, December 31, 2015 at 04:09:01 AM, Ley Foon Tan wrote: > > > > On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote: > > > > > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote: > > > > > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote: > > > > > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote: > > > > > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> > wrote: > > > > > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote: > > > > > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote: > > > > > > > > >> > 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, > > > > > > > > > > > > > > > > > >> 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. > > > > > > > > > > > > > > > > > >> 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? > > > > > > > > > > > > > > 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 ;-) > > > > > > > > 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? > > 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? Regards Ley Foon
On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: Hi! > > > > 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? > 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) Best regards, Marek Vasut
On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: > > Hi! > > > > > > 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? > > > 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. Regards Ley Foon
On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote: > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: > > > > Hi! > > > > > > > > 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? > > > > > 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. btw I am honestly surprised that Quartus cannot export the address map into some text file :-( Best regards, Marek Vasut
On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote: > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote: > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: > > > > > > Hi! > > > > > > > > > > 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? > > > > > > > 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. Address map looks fine. > > 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. Regards Ley Foon
On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote: > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote: > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote: > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: > > > > > > > > Hi! > > > > > > > > > > > > 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? > > > > > > > > > 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. > > Address map looks fine. Well do you have any other idea then ? I guess I should pull out the SOCDK, huh? > > 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! Best regards, Marek Vasut
On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote: > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote: > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote: > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote: > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: > > > > > > > > > > Hi! > > > > > > > > > > > > > > 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? > > > > > > > > > > > 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. > > > > 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? > > > > 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! >
On Tuesday, January 05, 2016 at 02:18:18 AM, Ley Foon Tan wrote: > On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote: > > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote: > > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote: > > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote: > > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > 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. > > > > > > 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 yes > AV yes > A10 SoC devkit? Not yet ;-) I'll try to find some time to test it on CV SoCDK tomorrow. [...] Best regards, Marek Vasut
On Tuesday, January 05, 2016 at 02:18:18 AM, Ley Foon Tan wrote: > On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote: > > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote: > > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote: > > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote: > > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > 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. > > > > > > 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? 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 ? [...] Best regards, Marek Vasut
On Tue, 2016-01-05 at 14:49 +0100, Marek Vasut wrote: > On Tuesday, January 05, 2016 at 02:18:18 AM, Ley Foon Tan wrote: > > On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote: > > > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote: > > > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote: > > > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote: > > > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > > > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote: > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > 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. > > > > > > > > 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? > > 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? Regards Ley Foon
On Thursday, January 07, 2016 at 09:56:06 AM, Ley Foon Tan wrote: > On Tue, 2016-01-05 at 14:49 +0100, Marek Vasut wrote: > > On Tuesday, January 05, 2016 at 02:18:18 AM, Ley Foon Tan wrote: > > > On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote: > > > > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote: > > > > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote: > > > > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote: > > > > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote: > > > > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > 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? > > > > 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? If you mean ccb_h2f_50_to_125 , then yes, they are exactly the same. The only difference I can think of is in altr_xcvr_reconfig_0 , where I have 2 reconfiguration interfaces instead of 5 because I am using only PCIe x1 instead of x4 as it is on the CV SoCDK. The pcie_cv_hip_avmm_0 is configured exactly the same too (but for x1 Gen1 port instead of x4 Gen1 port). Best regards, Marek Vasut
From 1dad1fbe4c5fb50e3f1672348de4a2b50ffd6ff1 Mon Sep 17 00:00:00 2001 From: Marek Vasut <marex@denx.de> Date: Thu, 24 Dec 2015 09:21:45 +0100 Subject: [PATCH] ARM: socfpga: Enable PCIe support Add DT bits to enable PCIe support on the DENX MCV EVK with MCV SoM. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alan Tull <atull@altera.com> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Cc: Olof Johansson <olof@lixom.net> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de> Cc: Thor Thayer <tthayer@altera.com> Cc: Vince Bridgers <vbridgers2013@gmail.com> --- arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 34 +++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts index 7186a29..e56e23e 100644 --- a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts +++ b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts @@ -29,6 +29,40 @@ chosen { stdout-path = "serial0:115200n8"; }; + + pcie_0: pcie@0xc00000000 { + compatible = "altr,pcie-root-port-1.0"; + reg = <0xc0000000 0x20000000>, + <0xff220000 0x00004000>; + reg-names = "Txs", "Cra"; + interrupt-parent = <&intc>; + interrupts = <0 40 4>; + interrupt-controller; + #interrupt-cells = <1>; + bus-range = <0x0 0xFF>; + device_type = "pci"; + msi-parent = <&msi0>; + #address-cells = <3>; + #size-cells = <2>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_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 0xc0000000 0xc0000000 0x00000000 0x10000000 + 0x82000000 0x00000000 0xd0000000 0xd0000000 0x00000000 0x10000000>; + }; + + msi0: msi@0xFF200000 { + compatible = "altr,msi-1.0"; + reg = <0xFF200080 0x00000010 + 0xFF200000 0x00000080>; + reg-names = "csr", "vector_slave"; + interrupt-parent = <&intc>; + interrupts = <0 41 4>; + msi-controller; + num-vectors = <32>; + }; }; &can0 { -- 2.1.4