• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 33 subscribers
  • Views 271 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

$core_v2_language.Truncate($relatedThread.Subject, 120, "...")

XIO2001: MABORT (PCIe) bit set condition

Hisao Uchikoshi
Genius 14330 points
Part Number: XIO2001
Other Parts Discussed in Thread: AM5728

Hi Experts,

My customer is seeing MABORT bit (PCIe, Status register at 0x06) set.

What does "a completion-with-unsupported-request status" mean? The PCIe root complex is AM5728, does that mean that AM5728 sent XIO2001 command to set this bit? Customer is understanding that this bit set is indicating some failure. When detecting this bit to set 1, how and what should customer debug it

“Unsupported request” is probably related to the PCI specification, but I didn’t see it from 'PCI Express Base Specification Revision 2.1.pdf'. Could you please advice us?

Regards,

Uchikoshi

  • 0
    Guru 287360 points

    All PCIe communication is done using request and response packets. An abort is an error response, and indicates that a request could not be handled.

    Aborts are normal during enumeration when the master tries to access devices that do not actually exist (this is probably what happened here). At other times, they usually indicate a real problem.

  • 0 in reply to Clemens Ladisch
    TI__Genius 14330 points

    For this use-case, PCIe root-complex is AM5728(Linux) and XIO2001 is endpoint. I think PCIe communication is hardwired under this condition, but why does abort occur? 

  • 0 in reply to Hisao Uchikoshi
    Guru 287360 points

    The XIO2001 is a switch that could have many downstream devices. But I guess you do not have the maximum number of them actually connected?

  • 0 in reply to Clemens Ladisch
    TI__Genius 14330 points

    For PCIe side, AM5728 is the only device and for PCE side, FPGA is the only device.

  • 0 in reply to Hisao Uchikoshi
    TI__Genius 17806 points

    Hi Uchikoshi-san,

    An unsupported request is defined in the PCIe specification as 

    1. A status that applies to a posted or non-posted Request that specifies some action or access to some space that is not supported by the Completer. 2. A status indication returned with a Completion for a non-posted Request that suffered an Unsupported Request at the Completer.

    As Clemens has indicated above, an enumeration which tries to enumerate a non-existing device would cause this error bit to be set. However, there are multiple conditions under which this could be set. Each of these are described in the XIO2001 data sheet.

    Best,
    David

  • 0 in reply to David Waier
    TI__Genius 14330 points

    Hi David,

    Thank you for your answer. So do you think we need to check why AM5728 sends the command for XIO2001 to set MABORT bit?

    Regards,

    Uchikoshi

  • 0 in reply to Hisao Uchikoshi
    Guru 287360 points

    No. During enumeration, MABORT is to be expected, and nothing needs to be done.

    If you clear the MABORT flag after enumeration, you are then able to detect later errors. (This is usually not done.)

  • 0 in reply to Clemens Ladisch
    TI__Genius 14330 points

    Thank you for your answer. Let me summarize the question once. On a customer's system, PCIe access may freeze at a rate of 1 in thousands of times during power-up, and upon examination, we find that the MABORT bit in XIO2001 is set to 1. Looking at the description of the MABORT bit, when a Master Abort is received, this bit is set to 1, but we want to solve the problem of freezing by knowing when this occurs.
    I have received the following answers in the past.

    Clemens Ladisch said:
    Aborts are normal during enumeration when the master tries to access devices that do not actually exist (this is probably what happened here).

    Is this correct because something went wrong during enumeration? If this is normal, is it correct that we need to look for another problem that freezes at startup? 

  • +1 in reply to Hisao Uchikoshi
    Guru 287360 points

    Every enumeration will search for all possible device numbers on all possible slots, so there will always be accesses to nonexistent devices. The MABORT flag will be set after every enumeration.

    During enumeration, aborts are normal. At other times, aborts are probably a sign of an error. If you want to be able to detect those other aborts, you need to clear MABORT after enumeration.

    (I doubt thar your problem is related to an abort.)