Thanks for reviewing this!
SRAM1 at address 0x20000000 is remapped to 0x00000000.
The reference manual (RM0090) shows in figure 2 that SRAM1 (but not SRAM2 or SRAM3) can be accessed through the I-Bus and the D-Bus. That looks like it 'd have better performance than using only the S-Bus.
Section 2.3.1 says:
The CPU can access the SRAM1, SRAM2, and SRAM3 through the System Bus or through
the I-Code/D-Code buses when boot from SRAM is selected or when physical remap is
selected (Section 9.2.1: SYSCFG memory remap register (SYSCFG_MEMRMP) in the
SYSCFG controller). To get the max performance on SRAM execution, physical remap
should be selected (boot or software selection).
That contradicts figure 2. Execution from the remapped memory area was chosen to enable max performance, but it is not clear if just remapping 'd be enough, or if it needs to address the remapped area. I can't remember if this had an effect on performance.
The memory remap table (Table 4) shows only SRAM1 remapped to 0x00000000.
I'm not sure what the reason is for the gap between SRAM1 for firmware 0x200000000 to 0x2000B000 and SRAM1 for patch starting at 0x20011000. I think I started to squeeze firmware usage of SRAM1, since code can only execute from SRAM1 at full speed it is a precious resource, but then did not close the gap to avoid hard crashes when transitioning to a new patch entry point - loading old patches at a new location. I believe the first check (matching firmware crc) in xpatch_init2 does not depend on absolute code location, but I'm not sure that I verified that this is indeed the case.