Detailed description
- No major new features, just small fixes to target support.
- The existing problem is "ARM Cortex-A A7" detected, with memory map missing, in Production Boot, where "STM32MP15 A7" would be detected in Engineering Boot.
- This PR solves it by redirecting back the DBGMCU IDCODE register read from System bus alias 0x50081000 (as observed by
cortexar_mem_read) to Debug APB address 0xe0081000 on AP1.
Tested on STM32MP157C with STLINK/V3MINIE driven by BMDA.
I suppose this happens because Linux kernel unmaps peripherals via MMU, leaving only DRAM identity-mapped. Before it boots (e.g. in U-boot shell with stopped autoboot), the registers are still readable, because U-Boot only enables identity mapping in MMU. Linux device drivers rely on the kernel creating some secondary virtual mapping to used peripherals in kernel-private regions, and it should not stay predictable on every boot (ASLR etc.)
To be able to unwind kernel stacks, I register 512 MiB of DRAM at an address, which is conveniently both a physical DDR SoC base address (thanks ST) and VMSPLIT=PAGE_OFFSET=0xc0000000 3G/1G "entire DRAM is in low memory" address. Boards with 1024 MiB of DDR3 and this SoC are extremely rare and need a modified bootloader chain. I also add the 128 KiB BootROM at 0x0 for CA7 (CM4 sees 64 KiB RETRAM at 0x0), which you can dump ihex memory and compare-sections for a reliable benchmark.
Your checklist for this pull request
Closing issues
## Detailed description
* No major new features, just small fixes to target support.
* The existing problem is "ARM Cortex-A A7" detected, with memory map missing, in Production Boot, where "STM32MP15 A7" would be detected in Engineering Boot.
* This PR solves it by redirecting back the DBGMCU IDCODE register read from System bus alias 0x50081000 (as observed by `cortexar_mem_read`) to Debug APB address 0xe0081000 on AP1.
Tested on STM32MP157C with STLINK/V3MINIE driven by BMDA.
I suppose this happens because Linux kernel unmaps peripherals via MMU, leaving only DRAM identity-mapped. Before it boots (e.g. in U-boot shell with stopped autoboot), the registers are still readable, because U-Boot only enables identity mapping in MMU. Linux device drivers rely on the kernel creating some secondary virtual mapping to used peripherals in kernel-private regions, and it should not stay predictable on every boot (ASLR etc.)
To be able to unwind kernel stacks, I register 512 MiB of DRAM at an address, which is conveniently both a physical DDR SoC base address (thanks ST) and VMSPLIT=PAGE_OFFSET=0xc0000000 3G/1G "entire DRAM is in low memory" address. Boards with 1024 MiB of DDR3 and this SoC are extremely rare and need a modified bootloader chain. I also add the 128 KiB BootROM at 0x0 for CA7 (CM4 sees 64 KiB RETRAM at 0x0), which you can `dump ihex memory` and `compare-sections` for a reliable benchmark.
## Your checklist for this pull request
* [x] I've read the [Code of Conduct](https://codeberg.org/blackmagic-debug/blackmagic/src/CODE_OF_CONDUCT.md)
* [x] I've read the [guidelines for contributing](https://codeberg.org/blackmagic-debug/blackmagic/src/CONTRIBUTING.md) to this repository
* [x] It builds for hardware native (see [Building the firmware](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-the-firmware))
* [x] It builds as BMDA (see [Building the BMDA](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app))
* [x] I've tested it to the best of my ability
* [x] My commit messages provide a useful short description of what the commits do
## Closing issues