Feature: Multi-AP handling on STM32MP15

[ALTracer]

Detailed description

• This is a completely new feature.
• There are existing problems on multi-AP chips like STM32H7, H5, MP15 regarding miscellaneous Debug features setup, some of which has to go through APB-D AP and not MCU's MEM-AP (AHB-AP).
• This PR solves some of these problems by introducing runtime management and hooks for AXI-AP AP0 and APB-D AP1 of MP15.

This was written as a PoC in December, before the cortexar STC/LDC DTRRX speedups got developed and tested. Using AXI-AP may provide background access to entire DDR3 and SYSRAM without halting either CA7 of the platform (or single CA7 on MP151).
I need in particular the APB-D to be able to setup the CoreSight SWO block in SoC system scope, which is shared between CA7 MPCore and CM4 and hence neither of them can write to its configuration registers page. The rest (ITM, DWT, RCC) are accessible in some sort and can be poked via Orbuculum's gdbtrace.init script.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

[dragonmux]

This is looking pretty decent and we can mostly work out the rationale behind each change (even if it took us a minute). We have some suggestions to improve that and a request to write out a little more of the intent in comments to aid with that, but with those taken care of we think this will be good to merge.

[dragonmux]

They're all MEM-AP's, think you mean AXI AP (AP0)?

[dragonmux]

Given how the setup functions are named (and we agree with this naming, though aren't sure where the d comes from in apbd here?), we suggest being absolutely consistent below - apb_ap, axi_ap, so the code's a little easier to follow. Either that or using the AP number instead of bus type for the naming - ap0, ap1? That one's up to you which you think would be more beneficial here.

[dragonmux]

As with the other places this apbd naming has come up, we do not know where this d is coming from in the naming - please either name by the AP number this AP represents, or just say ap_apb - if it's supposed to mean "debug", that's already implied by it being the bus attached to the AP, but those busses aren't some special thing.. they are normal APB's and AHB's, so including the d in the nomenclature just muddies things in our opinion. Readers not familiar with things would try searching for an APBD and get no results which is counter-productive, for example.