XIO2001: firmware issue

Hello Shu-Cheng,

We will look into this and get back to you shortly.

Regards,
I.K.

Sorry for pushed, any update on this?
Thanks!!

Hi Shu-Cheng,

Sorry for the delay, I don't have an update yet. I am still trying to get in contact with people that have more knowledge about this device. To confirm if it's an overflow issue can you check the RX_OVERFLOW field?

Regards,
I.K.

Hi Sirs,

Thanks for your reply

Please refer our update as below

It’s not an Rx overflow. It’s address counter of XIO2001. Or we should said : memory boundary. For example,

Case1 :

if you get a destination address 0x2F389000 with size 128 double words. It will work fine :

PCIe Wr : 0x2F389000 : 32dword : data sec1

PCIe Wr : 0x2F389080 : 32dword : data sec2

PCIe Wr : 0x2F389100 : 32dword : data sec3

PCIe Wr : 0x2F389180 : 32dword : data sec4

 

Case2 :

if you get a destination address 0x2F389EC0 with size 128 double words. The address will be incorrect after counter reach 0x2F389FFF :

PCIe Wr : 0x2F389EC0 : 32dword : data sec1

PCIe Wr : 0x2F389F40 : 32dword : data sec2

PCIe Wr : 0x2F389FC0 : 16dword : data sec3

PCIe Wr : 0x2F389EC0 : 32dword : data sec4 – why it’s not 0x2F38A000 (0x2F389FC0 + 16dword)

 

There should be some setting for adjusting this kind of counter boundary.

 

PS : The destination address should be allocated by OS, we can’t change it in easy way.

Hi Shu-Cheng,

Sorry for the delay in resolving this issue, our XIO experts have been out of office this week. We hope to have an answer to this issue early next week.

Regards,
I.K.

Hi Shu-Cheng,

Sorry for the delay, and thank you for your patience.

Do you know how many PCI devices the customer is attaching to the XIO2001? It turns out there may be an issue when attaching 4 or more. Do they see this issue with less than 4 PCI devices attached?

Regards,
I.K.

Hi Sirs,
Thanks for your reply.
We attached only one PCI device to the XIO2001.

Hi Shu-Cheng,

Do they see this issue with both a 33MHz and 66MHz clock? Also, have they made sure to implement everything in the errata? www.ti.com/.../scpz008b.pdf

Regards,
I.K.

Hi Sirs,

Thanks for your reply.

Our update as below

I think this document descripted 5 discovered issue for XIO2001…

Should I implement those work around even we don’t have the issue listed in the descript?

 

For issue 1 and 2

We are not using Serial Interrupts, Legacy INIT_A instead.

For issue 3

We didn’t find issue related to power and CLK_REQ# yet

For issue 4.

We don’t have TLP transfer halt issue?

For issue 5.

The issue occurred with floating EXT_ARB_EN and CLKRUN_EN unconnected. We are pulling down with 10k currently.

 

If those issue impact the address calculating during DMA section?

Hi Shu-Cheng,

Can they still go ahead and implement the workaround for issue 4?

And does this issue happen at both 33 and 66 MHz clock frequency?

Regards,
I.K.

Hi Sirs,

Our update as below

If there has instruction for implementing the work around for issue 4 for XIO2001?

 

We don’t have 66Mhz solution and test environment yet. So we have tested 33Mhz currently.

 

By the way, what’s exactly relationship between issue 4 and address? I mean, if the address related to power even there have no power state change during DMA?

 

Hi Sirs,

Sorry for pushed, any update on this?

I think this is a simple address calculator overflow due to memory boundary. Can TI explain how this address calculated or which parameters of XIO2001 related to it? When the destination address is “0xXXXXXEFC”, Issue will always occur during the carry from 0xEFC to 1000 . If it’s “0xXXXXX000”, the issue will never happened because the maximum Ethernet frame is 1522 byte(without jumbo frame) and There will never have carry like previously 0xEFC to 1000 case. Simply, Could you please help us to find out what’s happen during address calculate with the carry like 0xEFC to 1000?

Hi Shu-Cheng,

Sorry for the delay. This seems to be quite an in-depth issue so I will once again need to try and find some experts for this device and see if we can get any insight into the problem. I hope to have something this week.

Regards,
I.K.

Hi Sirs,

Thanks for the answer, I think it’s a confirmed about this is a memory boundary limitation. Could you please tell me which solution is the most common solution?

1. System provided a space(or a destination space) which will not have boundary crossing possibility
2. PCI card separated the transmit request by themselves