### System details

Laptop Hardware: Framework Laptop 13 / 16 (AMD Ryzen AI 9 HX 370 / Strix Point APU) 64GB DDR5 System memory; Firmware: InsydeH2O UEFI BIOS (Latest framework deployment); Omarchy Quattro from Iso: v. 4.0.1

### What's wrong?

# Problem 
When attempting to boot the official Omarchy installer ISO on an AMD Ryzen AI 9 HX 370 Framework platform, the system immediately crashes prior to displaying the GRUB boot menu or crashes right at the menu selection with the following memory allocation 

`error:textloader/efi/linux.c:grub_cmd_linux:542 ran out of memory`

Subsequent manual reboots yield the exact same error, resulting in an inability to reach the live installation media environment.

# Root Cause

The issue stems from a critical limitation in GNU GRUB's physical memory allocator mapping logic combined with the aggressive early memory mapping on Zen 5 architectures:

- Large Installer Footprint: The Omarchy installation payload utilizes a large initramfs (often 240MB+) to account for its pre-configured developer environments and Hyprland styling assets.GRUB Low-Memory
- Allocation Boundary: GRUB's linux.c module attempts to open a single, contiguous memory allocation heap strictly below the 4GB physical memory boundary to unpack vmlinuz and initramfs.
- Firmware Fragmentation: On the AMD Strix Point architecture, the Framework InsydeH2O BIOS, combined with Microsoft Pluton/fTPM infrastructure and the Radeon integrated GPU memory tracking tables, heavily segments and reserves regions inside this low 4GB block.
- Immediate Heap Allocation Panic: Because the lower memory chunks are fragmented, GRUB cannot find a unified block large enough to fit the installer ramdisk payload. Line 542 flags an immediate heap overflow failure and halts execution.

# Troubleshooting

1. Secure Boot Disabling
**Action**: Confirmed Secure Boot was disabled in the Framework BIOS.
**Result**: No Change. The problem persists independently of Secure Boot parameters.
2. Restricting UMA Framebuffer Memory
**Action**: Manually altered the integrated GPU memory allocation configuration inside the BIOS from Auto down to a hardcoded 2G.
**Result**: No Change. Confirmed that the allocation block collision is happening within firmware tables rather than being dynamically stripped by standard VRAM adjustments.
3. Hiding/Disabling TPM in BIOS
**Action**: Navigated to the Security tab and switched TPM Availability to Hidden to try to prevent fTPM from logging table allocations in low RAM blocks.
**Result**: No Change. The memory fragmentation footprint remained large enough to trigger the GRUB error.
4. Interactive GRUB Drop (rmmod tpm)
**Action**: Attempted to hit c at the GRUB menu loader to manually issue rmmod tpm and unload the measurement hooks before handoff.
**Result**: Failed. On raw dd flashes, the system typically threw the error before rendering the screen to access the prompt interface. When accessed, dropping the module did not free a clean, contiguous allocation region.

# Suggested Fixes

To improve out-of-the-box hardware compatibility for cutting-edge laptop architectures, please consider:

**Migrate ISO Bootloader Architecture**: Evaluate transitioning the installer image's fallback wrapper away from GNU GRUB over to systemd-boot or exposing the raw native Limine bootloader binary directory structure directly as the primary fallback target inside /EFI/BOOT/BOOTX64.EFI.
**Optimize Kernel Compression**: Compress the installer's initramfs utilizing high-ratio ZSTD schemes to keep its memory chunk requirement beneath the fragmented thresholds of modern AMD/Intel platform layouts.