Add support for PocketBeagle 2 rev A1

[Ayush1325]

• PocketBeagle 2 rev A0 has been replaced with rev A1
• rev A1 replaces AM6232 with AM6254.

[Ayush1325]

What is the proper way to limit which soc is available in which board revision?

[jadonk]

What is the proper way to limit which soc is available in which board revision?

Can you elaborate?

[jadonk]

Please simplify the wording in the docs just a bit more. Most people won't have heard of rev A0 before long, so it shouldn't be so "in your face". I tried to provide some simplified wording.

[Ayush1325]

What is the proper way to limit which soc is available in which board revision?

Can you elaborate?

Well, I want to disallow the following board combination: pocketbeagle_2@A1/am6232/{a53, m4f}, since rev A1 means am6254.
I did add checks in revision.cmake. However, twister still tries to build (and fail due to revision.cmake) for such combinations. So I was wondering if there was an established way to go about this.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jadonk]

What is the proper way to limit which soc is available in which board revision?

Can you elaborate?

Well, I want to disallow the following board combination: pocketbeagle_2@A1/am6232/{a53, m4f}, since rev A1 means am6254. I did add checks in revision.cmake. However, twister still tries to build (and fail due to revision.cmake) for such combinations. So I was wondering if there was an established way to go about this.

Not an area of my knowledge, but looking at test_plan.py, it seems like there are options for excluding with filters, though I haven't figured out where yet. The Twister doc page wasn't that helpful on this topic.

Based on the error, I'd wonder if there's some way to force a revision based on the SoC chosen, but I don't see that.

None of the existing yaml configurations seem to define any filters by version. The existing board yaml files with revisions seemed to have multiple SoCs listed, but Icarus at least had a variant, but it seems the variant is valid for the same board revision (secure vs. non-secure).

@kartben is there any chance you can recommend how to ask Twister to choose a specific board revision when going through the changed files and looking for the available target SoC? In this case, revision A0 must be selected if testing the AM6232 SoC, while the default revision, A1, is invalid for that SoC.

[jadonk]

Looks good, but might need an update to fix Twister.