DirectXIP on a single fixed execution address via Realtek Ameba RSIP — how should the app entry hand-off look?

[minyuan-xue]

TL;DR

Ameba SoCs (rtl8721dx / rtl8721f) have a flash-side hardware block called
RSIP ("Runtime Secure Image Protection"). Per region, it independently supports
address remap (pointing a fixed logical/virtual window at an arbitrary physical flash
offset) and OTF AES decryption keyed on that logical address, using a key in OTP. I'm
using the remap side here to run a single application build from either slot.

Together these let me run DirectXIP from a single application build linked at one fixed
logical address, with RSIP remapping whichever slot MCUboot picks onto that window — no
per-slot build, no position-independent code.

Most of this reuses existing generic MCUboot/Zephyr mechanisms as-is. Two pieces touch
generic code, and those are what I'd like feedback on:

1. The do_boot() jump in boot/zephyr/main.c needs a vendor #ifdef, because the
   entry address is a fixed logical address, not flash_base + br_image_off.
2. Runtime slot resolution (boot_fetch_active_slot() and friends), gated on RAM-load
   only upstream, gets generalized behind a new hidden Kconfig symbol so fixed-remap
   DirectXIP can reuse it. RAM-load behavior is unchanged, but it's a refactor of three
   generic files.

Details and questions below.

---

Goal

Run BOOT_DIRECT_XIP (and ..._WITH_REVERT) such that:

• slot0 and slot1 both remap onto the same fixed logical execution address;
• the application is built once (no per-slot variant, no relinking, no PIC);
• MCUboot picks the highest-version valid slot as usual; the SoC just re-points RSIP at
  that slot's physical offset before the jump;
• swap mode is completely unaffected.

This is Ameba-specific only in that "DirectXIP ⇒ one fixed-address build" is true because
RSIP's remap exists. A generic DirectXIP target instead links a distinct per-slot variant
and resolves the address at compile time.

What maps cleanly onto existing mechanisms

1. Winning slot, bootloader → SoC remap code.
boot_go() already records the running slot in shared data (BLINFO_RUNNING_SLOT TLV) once
the retention backend is enabled. I default that backend on for Ameba DirectXIP:

# bootloader/mcuboot/boot/zephyr/Kconfig (BOOT_SHARE_BACKEND choice)
default BOOT_SHARE_BACKEND_RETENTION if SOC_FAMILY_REALTEK_AMEBA && BOOT_DIRECT_XIP

2. Programming RSIP before the jump.
The SoC's boot_prepare() re-points RSIP at the winning slot. I call it from the existing,
payload-less mcuboot_status_change(BOOTABLE_IMAGE_FOUND) hook, reading
BLINFO_RUNNING_SLOT back out inside the SoC hook — so nothing vendor-specific lands in
generic main.c for this part.

3. Telling the app-side DFU stack the slot is runtime-resolved.
Upstream already does this for RAM load: boot_fetch_active_slot() reads the same TLV, and
img_mgmt / flash_img / the MCUboot DFU shim take a runtime path instead of the
compile-time zephyr,code-partition — but gated directly on
CONFIG_MCUBOOT_BOOTLOADER_MODE_RAM_LOAD[_WITH_REVERT], duplicated across three files.
Fixed-remap DirectXIP has the same need, so instead of adding || MCUBOOT_AMEBA_... at each
site, I named the concept:

# zephyr/modules/Kconfig.mcuboot
config MCUBOOT_RUNTIME_ACTIVE_SLOT
	bool
	default y if MCUBOOT_BOOTLOADER_MODE_RAM_LOAD || MCUBOOT_BOOTLOADER_MODE_RAM_LOAD_WITH_REVERT
	help
	  Running slot must be queried at runtime via boot_fetch_active_slot() rather than
	  derived from the compile-time zephyr,code-partition. True for RAM load; other
	  platforms (e.g. remap-based DirectXIP) select it explicitly.

The three sites switch from #if defined(...RAM_LOAD...) to
#if defined(CONFIG_MCUBOOT_RUNTIME_ACTIVE_SLOT). RAM-load behavior is unchanged
byte-for-byte — this is the larger of the two generic-code changes, so I'd especially like a
read on it (see the questions below).

Apart from that refactor, nothing vendor-specific lands in generic sources: it's all in the
SoC directory plus two Ameba-conditioned Kconfig defaults.

The one part I can't do cleanly: do_boot()'s entry

do_boot() computes the jump target as flash_base + rsp->br_image_off + hdr_size. That's
wrong here: I must enter at the fixed logical address RSIP was just pointed at, and once
OTF decryption is on, the vector table is only decodable there — the physical
br_image_off is exactly what I don't want.

do_boot() is static with several arch-specific #if branches and no override hook, so my
change adds one more:

#ifdef MCUBOOT_RAM_LOAD
    vt = (struct arm_vector_table *)(rsp->br_hdr->ih_load_addr + rsp->br_hdr->ih_hdr_size);
#elif defined(CONFIG_MCUBOOT_AMEBA_FIXED_XIP_ADDR)
    /* RSIP has remapped a fixed logical window onto the winning slot (set up by
     * boot_prepare()); ignore the physical slot offset in rsp->br_image_off. */
    extern uintptr_t ameba_boot_xip_entry(uint32_t hdr_size);
    vt = (struct arm_vector_table *)ameba_boot_xip_entry(rsp->br_hdr->ih_hdr_size);
#else
    /* normal: flash_base + rsp->br_image_off + hdr_size */
#endif

Structurally this is the same kind of "entry address computed differently on this platform"
case as MCUBOOT_RAM_LOAD — but it's still a vendor symbol in generic code, which I'd rather
avoid if there's a cleaner path.

Questions for the community

1. Is a vendor #ifdef branch in do_boot() acceptable here, given it's structurally
   the same kind of case as MCUBOOT_RAM_LOAD? If so, would a more generic name than
   CONFIG_MCUBOOT_AMEBA_FIXED_XIP_ADDR be preferred (e.g. a CONFIG_BOOT_XIP_FIXED_ADDRESS
   / "remapped DirectXIP" concept other flash-remap SoCs could reuse)?

2. Is there an existing extension point I've overlooked for overriding the final jump
   target? boot_go_hook() looked promising at first glance, but it runs before
   boot_go()'s own slot-selection/validation logic: returning success from it skips
   boot_go() entirely and requires the hook to have already filled in rsp itself. There's
   no way to let MCUboot's normal selection run first and only override the entry address
   afterward — using it here would mean reimplementing boot_go()'s selection logic inside
   the hook rather than reacting to its result. do_boot() itself is static and
   non-overridable. A weak do_boot() or a boot_jump_hook(rsp) — invoked after slot
   selection, right before the jump — would let this live entirely in the SoC layer. Is there
   appetite for adding one?

3. Is generalizing boot_fetch_active_slot() behind MCUBOOT_RUNTIME_ACTIVE_SLOT the
   right move? My change replaces the three ...MODE_RAM_LOAD... guards with one hidden
   symbol meaning "running slot is runtime-resolved," defaulted y for RAM load (no behavior
   change) and selectable by fixed-remap DirectXIP platforms. Welcome abstraction, or would
   maintainers prefer plain || <ameba symbol> at each site instead?

4. Does the blinfo/retention approach for "winning slot → SoC remap" match the intended
   use of shared data, or is there a more idiomatic channel for a bootloader-internal
   pre-jump consumer (as opposed to the app-side blinfo reader it's normally used for)?

5. Defaulting BOOT_SHARE_BACKEND_RETENTION inside the generic BOOT_SHARE_BACKEND
   choice — I added default BOOT_SHARE_BACKEND_RETENTION if SOC_FAMILY_REALTEK_AMEBA && BOOT_DIRECT_XIP there rather than in a board/SoC Kconfig fragment on purpose: a
   choice's conditional default has to live inside the choice block, and the choice plus
   its members are declared only in boot/zephyr/Kconfig. Our SoC Kconfig is also parsed in
   the application image's tree, where those symbols don't exist, so referencing them there —
   or reopening the choice in a board Kconfig.defconfig that both images parse — is
   invalid. This mirrors the existing
   default MCUBOOT_BOOTLOADER_MODE_SWAP_USING_MOVE if SOC_FAMILY_ESPRESSIF_ESP32 in
   modules/Kconfig.mcuboot, so I followed that precedent. Shout if you'd prefer it driven
   some other way.

Status

This works end-to-end on the AmebaDplus EVB (rtl872xda_evb): DirectXIP v0→v1→v2 upgrade
over MCUmgr is validated. I'm preparing a PR, but would rather settle the two generic-code
questions (the do_boot() branch and the MCUBOOT_RUNTIME_ACTIVE_SLOT refactor) here first.
Happy to reshape the approach based on feedback.