Hi All,
The next release of the Firmware-A bundle of projects tagged v2.13 has an expected code freeze date of May, 2nd 2025.
In order to accommodate the Linaro connect event occurring during the week of May 12th we may extend the release completion date up until the week of May 26th.
v2.13 release preparation tasks start from now.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude.
As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 labels in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
Regards,
Olivier.
Hi Maheedhar,
Previously, the RXPX check was still being performed, but its result was simply ignored. This patch changes that behavior by enforcing failures when the check doesn't pass.
There are two scenarios where the RXPX check is applied: one under EM_NOT_AFFECTED and the other under EM_HIGHER_EL_MITIGATION.
*
In the EM_NOT_AFFECTED case, the CPU revision should fall outside the erratum’s affected range.
*
In the EM_HIGHER_EL_MITIGATION case, where mitigation has been applied at a higher exception level, the CPU revision should be within the affected range.
The RXPX check validates both of these expectations. If it fails in either case, it typically indicates a mismatch between the ABI test case and the actual errata check logic.
If a CPU revision falls outside the test case range but is categorized under EM_HIGHER_EL_MITIGATION, that should be treated as a failure.
If you're seeing a situation that doesn't align with these conditions and could share some more info—I'd be happy to take a look,
Regards,
Arvind
Bollapalli, Maheedhar Sai wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> Hi TF-A-Tests team,
> We are observing EM-ABI tests failures with latest Tf-a-tests upstream code where-in CPU revision is retrieved and RXPX range is compared based on the errata list per
> CPU core and if the CPU revision is outside of the errata revision range test case is deemed as failure, which doesn't seem to be appropriate.
> Patch change that marked RXPX out of range as failure.
> Change that marks range check as test failure:
> https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/he...
> Patch: https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/5668f34...
> Regards,
> Maheedhar.
[AMD Official Use Only - AMD Internal Distribution Only]
Hi TF-A-Tests team,
We are observing EM-ABI tests failures with latest Tf-a-tests upstream code where-in CPU revision is retrieved and RXPX range is compared based on the errata list per
CPU core and if the CPU revision is outside of the errata revision range test case is deemed as failure, which doesn't seem to be appropriate.
Patch change that marked RXPX out of range as failure.
Change that marks range check as test failure:
https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/refs/h…
Patch: https://review.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/5668f3…
Regards,
Maheedhar.
