-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate SBSA ACS into BSA ACS #101
Comments
Also SBSA ACS info block is worse at some entries than same in BSA ACS:
PCIe info:
|
Hi @hrw, Thanks for the feedback and we will discuss this internally. The reason for separate BSA and SBSA binaries is due to BSA and SBSA being separate specification and their applicability. Also from the SystemReady side, BSA is required across all the 3 SystemReady bands (IR, ES, SR), whereas SBSA is only required for SR. Thanks, |
Hi @hrw, Is your concern around the difference between the number of PCIe devices reported in BSA and SBSA? That is due to BSA checking compliance of non-integrated devices (RP, EP) and SBSA checking compliance of integrated devices (RCiEP, iEP, iRP, RCEC). Thanks, |
Now SBSA spec is built on top of BSA, was separate before (as it is older than BSA). Many tests present in SBSA ACS moved to BSA one and now it is written "BSA ACS has to be run" at the end of SBSA ACS output. One binary with "-sbsa -l X" would run BSA tests and SBSA level X ones. Listed one after another.
You forgot SystemReady LS ;D |
Any update in 2024? |
Hello @hrw, We are working on this and changes are expected to be upstreamed by April month.
We are also discussing on having mechanism to build a unified Sbsa binary with Bsa tests. Thanks, |
Why bother with two binaries? We have "BSA.efi -sbsa" now. Change argument to take SBSA level as argument, add SBSA tests and done. "BSA.efi -sbsa 6" would run BSA tests + SBSA level 6 tests. Interleaved with each other so we still have PE/Memory/GIC/PCIe/etc sections:
One tool to test everything. |
We can have one tool called xbsa to test everything by wrapping sbsa-acs, bsa-acs, and future xbsa-acs to achieve that goal that One tool to test everything, but I don't see a reason why we need to remove the existing capability of building the binaries separately. It is straightforward to run specific tool for checking compliance with specific specification. Users won't need to figure out the complicated meaning behind the tool options. Ideally, users can run the tool without adding any options. |
Several tests from SBSA ACS moved to BSA ACS to the level when running sbsa.efi orders to run also BSA ACS.
So maybe it is time to merge two of them into one application?
One binary to test compliance with BSA spec, all levels of SBSA one and in future also other xBSA specs.
The text was updated successfully, but these errors were encountered: