TMS320C6424: TMS320C6424 PCIBARnMSK configuration problem

Hi Kirill,
Let me take a look at the documentation and I will provide my feedback.

Best Regards,
Yordan

Hi,

I looked at C64X PCI document and didn't find relevant information. In your setup, what is the PCI host, is the Linux running on the host? And how two C64x connected to the host? "My firmware worked well until I connected 2 TMS320C6424 in same PCI bus" ===========>Is there a bridge in between? I knew that if you setup the BARnMSK to 0, then the BAR is disabled.

If you only have one C64 in the bus but with only two BAR, it worked correctly? When you have two same devices on the same bus, how the Linux determine which is which? So far I can use two TMS320C6424 on one bus by configuring all 6 BARs to same size and same location. =========> When you do a memory transaction from host, how do you determine which C64x should respond?

Regards, Eric  

Hi Eric!

Here is a diagram of my setup:

I have tested on Windows XP and Linux Ubuntu: same dual board problem.

I use FPGA based board to monitor PCI bus signals. All FPGA pins are configured to Input will Pull Up/Down disabled. I also got same result without this FPGA board. I will give you pictures from signal tap later.

Here is lspci output for 6Bar firmware boards:

It is possible to identify board by device number (0b and 0e in my case). These numbers are fixed for a certain PCI Bus topology. To find out which device number corresponds to a physical port I use JTAG: just read PCIBARnTRL:

Hi Eric!

"I knew that if you setup the BARnMSK to 0, then the BAR is disabled." -> This is exactly what I have expected! And this worked while I used only single C64 on bus.

"If you only have one C64 in the bus but with only two BAR, it worked correctly?" -> I have tested with only C64 board. I guess it might have same problem if I connect C64 + any other PCI board, but I did not try this setup. Yes, with only single C64 board my driver works. I can configure C64 and get data in Master Mode.

"When you have two same devices on the same bus, how the Linux determine which is which?" -> For dual C64 setup configuration phase works well. I guess there is a problem in C64 PCI Address Decoder. Configuration read/write transactions does not use it. Once I start reading/writing data in slave mode I got problems.

"When you do a memory transaction from host, how do you determine which C64x should respond?" -> Take a look at a my previous message. I use Signal Tap to monitor bus and JTAG to identify board on bus. I see address on bus and BAR at DSP.

Well, I have only a single JTAG and I did not check BAR setup for both boards simultaneously. I have checked BAR setup for one and another board though. Configuration order is always the same: one can see it on Signal Tap.

Regards,

Kirill

To demonstrate problem I have reverted back my firmware to use 2 BARs instead of 6.

Here is lspci output in Linux:

Here is a single configuration read transaction on Signal Tap:

And data read transaction is bogus:

I can see following in my JTAG connection:

And, why I suspect address decoding mechanism. Here is a screenshot from SPRUEN3C page 27:

If you have both PCIBARnMSK == 0 and PCIBARn == 0 you will have Match[n] == 1 for any AD. If this diagram has anything to do with real Address Decoding, than C6424's PCI is in trouble.

Kirill

Kirill,

Thanks for the diagram and detailed explanation! The Linux lspci results looks right when you have two C64 devices on the PCI bus, no matter you used 2 BARs or 6 BARs. Both devices are enumerated and 2 or 6 memory windows in the host side are allocated properly in terms of starting address and size, there is no overlapping and matched what you requested by the PCIBARnMSK register.

Also, the PCIBARnMIR register has the right value (the starting memory allocated by host) so I felt your driver can access either device 1 or device 2 memory without issue. 

The Figure 8 acts as an inbound translation using BAR matching. E.g, converting an income bus address 1280ABC into a C64x device address 1080ABC. So, If you have both PCIBARnMSK == 0 and PCIBARn == 0 you will have Match[n] == 1 for any AD. Then the output address would be the same as input 1280ABC. Can you confirm that with one C64 only and with only two BARs (the rest BARs are 0), there is no bogus results?

In the 2 devices case, as you saw the bogus data on AD{31..0], is there an easy way to understand where this read came from? Is it from the next address? or from an un-translated valid SOC address? You may fill-in some suspected memory regions with a pattern to see if helps to isolate where the data come from.  

Also, is programming all 6 BARs for the two devices (each BAR can be different for a device, AND device 1 and device 2 BAR can be different for real usage case) a workaround for the issue?

Regards, Eric 

Hi,

Any update?

Regards, Eric