SBSA test 835 needs additional check for "Present but not yet configured"

[cdwilde]

In this loop, we are currently checking for Vendor ID, but we also need to check for Present but not yet configured (as coded below). We ran into a problem where the loop exited before it was ready because we were detected but not yet ready.

In this file: test_pool/pcie/operating_system/test_p035.c
/* If Vendor Id is 0xFF after max FLR period, wait
* for 1 ms and read again. Keep polling for 5 secs */
timeout = (5 * TIMEOUT_LARGE);
while (timeout-- > 0)
{
val_pcie_read_cfg(bdf, 0, &reg_value);
// Need to check both Vendor ID (already there) AND 0xFFFF0001 (Present but not yet configured completely)
vendor_id = reg_value & TYPE01_VIDR_MASK;
device_id = (reg_value >> TYPE01_DIDR_SHIFT) & TYPE01_DIDR_MASK;
if ((vendor_id == 0xFFFF) || ((device_id == 0xFFFF) && (vendor_id == 1)))
{
status = val_time_delay_ms(ONE_MILLISECOND);
continue;
}
else
break;
}

[Sujana-M]

Hi @cdwilde,

When the FLR is initiated, the PCIe spec mentions that the functions must complete the FLR within 100ms. In the test if the device is not identified even after 100ms, we poll the vendor ID of the device after every millisecond for 5 seconds. Therefore, according to the PCIe spec, the device should be up by the mentioned time.

With reference to ARM-software/bsa-acs#419 raised, If the PAL API pal_time_delay_ms has been modified to ensure that the wait time is less than 100ms. It is possible for the behaviour of the device to vary. If the PAL API is not modified and you are still facing this issue, please share the details of the system that the test is being run on, the number and type of PCIe devices in the system and the logs with -v 1 prints.

Request you to also provide the information on whether the Vendor ID did respond with the 0xFFFF0001 when polled for the additional 5 seconds

Thanks,
ACS Team

[cdwilde]

We have to modify the time in pre-silicon to be able to test it during a reasonable time (100 ms is too long to run). As you can see, with a lot of the issues I am filing, they come into play when you are trying to run in a pre-silicon environment and time matters. :) The problem we had with the original code is that we would see the transition to 0xFFFF0001 and that was not equal to TYPE01_VIDR_MASK. It would allow the code to continue before it was ready.