/* Ground-truth C for FUN_00000da4 @ blob offset 0xda4 (40 bytes / 9 insts).
 *
 * Pattern:  magic-number check at absolute address, then tail-call to memset.
 * Signature:  void check_and_zero(void);
 *
 * AArch64 ABI:  no args, no return value
 * Scratch:      X0..X2, W1, W2
 *
 * Behaviour:
 *   uint32_t *magic = (uint32_t *)0x1fe000;
 *   if (magic[1] == 0x54410001)           // 'TA'\x01 — Trusted App header?
 *       memset(magic, 0, 0x32c);          // tail-call to FUN_00000aac
 *   // else: fall through, return
 *
 * Notes the decompiler should ideally recover:
 *   - `orr x0, xzr, #0x1fe000` is an immediate-load idiom for `x0 = 0x1fe000`;
 *     encoded as OR-with-zero so ARM assemblers can pack it.
 *     Tools that don't know the ORR-imm trick may render this as
 *     `x0 = 0 | 0x1fe000` or worse `x0 = 0 | 0x1FE000UL` with weird types.
 *   - `MOV w1, #0x1 ; MOVK w1, #0x5441, LSL #16` composes a 32-bit literal
 *     0x54410001. A good tool collapses both into `w1 = 0x54410001`.
 *   - `LDR w2, [X0, #0x4]` reads `magic[1]`, i.e. the second word at the
 *     magic region. Comparing against 0x54410001 = 'TA'\x01 is the
 *     ARMv8 "Trusted Application" header signature convention.
 *   - `B 0xaac` is a tail-call: control transfers to memset with X0, W1, X2
 *     already set up; no BL / return path. Tools should emit this as
 *     `return memset(x0, w1, x2);` or at least a clear call — not an
 *     inlined body.
 *
 * Address 0x1fe000 lies in RK3588 SRAM (PMU-SRAM region 0x1fe0_0000–…).
 * Not MMIO in the strict sense — it's memory — but tools may flag it as
 * special because of the large constant.
 */
#include <stddef.h>
#include <stdint.h>

extern void memset_byte(void *buf, uint8_t val, size_t len); /* FUN_00000aac */

void check_and_zero(void) {
    uint32_t *magic = (uint32_t *)0x1fe000UL;
    if (magic[1] == 0x54410001U) {
        memset_byte(magic, 0, 0x32c);
    }
}