UniXNU

English

简体中文

English

简体中文

Appearance

realme GT5 240W (RMX3823), kalama, 24 GiB, 1240x2772 AMOLED ​

Janit8r/UniXNU-rmx3823-new

realme GT5 240W (RMX3823). Reuses UniXNU-sm8550-common; board inputs and firmware pending.

Source record: porting.toml, e75657692fc4eca7d49dba26941690264dd1dc09.

This page is generated from the device record.

AreaStatus
Configurationimplemented
Firmware and bootplanned
CPU and interruptsplanned
Memory and DMAimplemented
Storage and rootplanned
Displayplanned
Inputplanned
GPUplanned
Networkplanned
Audioplanned
Powerplanned
Image assemblyplanned
Diagnosticsplanned

Configuration ​

implemented

Components: ArmDTPlatform, ArmCpu, SoftwareAES, XnuPrelink, DarwinBoot.

Hardware and dependencies ​

  • SM8550 kalama SoC support from UniXNU-sm8550-common, pinned at a9f45dc6.

Configuration ​

  • board.toml sets soc_source = sm8550, defconfig = rmx3823_defconfig, device_tree.source = device:dts/board.dts.
  • dts/board.dts includes sm8550.dtsi and enables ufs, ufsphy, gpu, gmu and gpu_smmu.
  • configs/rmx3823_defconfig carries only board deltas; the arch, soc and os fragments supply the base.

Procedure ​

  • Read the device over adb: getprop, /proc/cpuinfo, /sys/devices/soc0, /sys/firmware/devicetree/base/reserved-memory.
  • Unpacked the stock dtbo.img (big-endian dt_table_header, 4 entries) and decompiled each DTB.
  • Ran `unixnu defconfig rmx3823_defconfig --device .` and inspected the merged out/rmx3823/<profile>/rmx3823/.config.

Development findings ​

  • soc_id 519 and machine KALAMA match sm8550.dtsi: 3x A510, 2x A710, 2x A715, 1x X3, and GPU Adreno740v2.
  • Page size is 4096, which the Sm8550Platform kit requires; a 16K-page SM8550 would not work.
  • dtbo entries 1 and 2 carry qcom,msm-id 0x207 (519) and are the board overlays; entries 0 and 3 carry 0x258/0x259 and do not match this device.
  • soc:configs/sm8550.config sets CONFIG_XNU_NATIVE_ADRENO=y while the device defconfig is applied last, so the two must be changed together with [components].
  • unixnu builds only on macOS and Linux. On Windows, defconfig and status run, but the kernel, payload and firmware steps do not.
  • .github/workflows/build.yml builds from this repository alone: it checks out upstream UniXNU/UniXNU as the engine, so the board needs no fork of the engine repository.
  • The firmware checkout is Janit8r/uefi-rmx3823, a fork of UniXNU/uefi-sheng on branch sheng. [firmware] now names config, dsc, fd, submodules and the full PACKAGES_PATH; Mu_Basecore is left out because the engine supplies it as {edk2}.
  • rmx3823Pkg is derived from Platforms/Qualcomm/qrd8550Pkg rather than nuwaPkg or shengPkg: RMX3823 is a non-Xiaomi board on the same Qualcomm boot_images baseline, and no rmx3823 set exists in Device-Binaries or Silicium-ACPI, so Binaries/qrd8550 and the qrd8550 ACPI tables are reused deliberately.
  • rmx3823Pkg is not buildable with Mu-Silicium's build_uefi.py: it carries UniXNUPkg and DarwinBootPkg in its DSC/FDF the way shengPkg does, and build_uefi.py has no PACKAGES_PATH for them. It must go through ./unixnu build firmware --uefi.
  • rmx3823Pkg compiles. uefi-rmx3823 run 41276749199 built it on ubuntu-24.04 with UniXNU.efi, UniXNUDxe.efi, UniXNURamDiskDxe.efi, UniXNULib and DarwinBoot.efi in the volume, and the firmware volume came out at exactly 0x300000 bytes.
  • That build needed a fix first: [boot_image] carried only header_version, so build_uefi.py fell back to mkbootimg.py's defaults and produced kernel_addr 0x10008000 with pagesize 2048. SM8550's DDR starts at 0x80000000, so that address is not memory. The engine's own bootimg step uses different defaults (base 0, pagesize 4096), which is why the two paths disagreed silently. All five fields are now explicit.
  • The stock uefi.elf is an ELF with a single 3 MiB LOAD segment at 0xA7000000, which is where the vendor firmware volume actually lives; the entry point is 0xA7000000.
  • uefi.elf carries its uefiplatLA.cfg as an embedded string blob (the stock UEFI parses that text at boot: PlatConfigFileName = "uefiplatLA.cfg"). Extracting it gives the authoritative memory map: Version 3, MaxMemoryRegions 74, 39 regions in use - 25 DDR, 2 IMEM, 12 register windows.
  • [uefi_fd] moved from 0xA7100000+0x300000 to 0xA7000000+0x400000, the carveout the vendor cfg reserves as "UEFI FD". The stock image is 3 MiB of that 4 MiB window, so this occupies exactly the reserved range and leaves 1 MiB of headroom.
  • The ADT generator reads exactly one contiguous device_type = memory range from the hardware DTS and rejects anything else; /chosen/memory-map only ever carries RAMDisk, TrustCache, GpuAddon and RootPolicies. reserved-memory in dts/board.dts therefore does not become an ADT reservation - the handoff range is the only thing that keeps XNU out of firmware memory.

Completion criteria ​

  • All source pins resolve; every selected component has a record; status shows the intended overrides and patch order.

Current limits ​

  • Installed RAM is still inferred from MemTotal 23645600 kB. The vendor memory map stops at 0x100000000 and does not state the DRAM size.
  • Panel and touch are not identified; the stock boot.img is header_version 4, so the base device tree lives in vendor_boot.img, which is not available.
  • Nothing has run on hardware. Whether the RMX3823 ABL accepts the boot image is unverified; a rejection shows as the device dropping to fastboot with nothing on screen.

Next action ​

  • Flash the CI boot image and capture the serial log; then widen the handoff range once the booter's carveout exclusions are verified.

Evidence ​

Firmware and boot ​

planned

Hardware and dependencies ​

  • Identify the firmware and boot hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for firmware and boot.

Procedure ​

  • Follow the firmware and boot stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first firmware and boot observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • Firmware image builds, enters UniXNU, publishes the framebuffer and preserves the documented memory reservations.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required firmware and boot inputs before implementation.

Evidence ​

Collect evidence using the next action.

CPU and interrupts ​

planned

Hardware and dependencies ​

  • Identify the cpu and interrupts hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for cpu and interrupts.

Procedure ​

  • Follow the cpu and interrupts stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first cpu and interrupts observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • Every enabled CPU reaches its entry checkpoint and timer/IPI handling works on each enabled CPU.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required cpu and interrupts inputs before implementation.

Evidence ​

Collect evidence using the next action.

Memory and DMA ​

implemented

Hardware and dependencies ​

  • The stock firmware set: uefi.elf (the vendor UEFI, 3 MiB at 0xA7000000), tz.mbn, uefi_sec.mbn, boot.img and recovery.img.
  • The board's uefiplatLA.cfg, recovered from the string blob inside uefi.elf.
  • The 28 reserved-memory regions previously listed from /sys/firmware/devicetree/base/reserved-memory, addresses only.

Configuration ​

  • dts/board.dts declares one contiguous handoff range, memory@bab00000, reg = <0 0xbab00000 0 0x0d1c0000>.
  • 0xBAB00000 + 0x0D1C0000 is the "DXE Heap" entry of the vendor memory map and the only region it marks EFI_RESOURCE_SYSTEM_MEMORY with EfiConventionalMemory.
  • aop_cmd_db_region@81c60000 keeps 0x20000, which the map supports: "AOP" is 0x81C00000 + 0xA0000 and aop_config_merged@81c80000 starts immediately after it.
  • smem_region@81d00000 corrected from 0x400000 to 0x200000, the map's "SMEM" size. The old value would have covered adsp_mhi@81f00000, which begins where SMEM ends.

Procedure ​

  • Parsed the ELF program headers of uefi.elf: one LOAD segment, vaddr 0xA7000000, filesz 0x300000, entry 0xA7000000.
  • Located the embedded config text by searching for "[MemoryMap]" and dumped it between the [Config] and [ConfigParameters] markers, replacing NULs with newlines.
  • Parsed both the cfg and MemoryMapLib.c and compared address, size and name row by row; 39 rows, exact match, no overlaps within any section.
  • Cross-checked against tz.mbn's program headers and the dtbo overlay's carveout addresses.

Development findings ​

  • The vendor memory map has 39 regions: 25 DDR, 2 IMEM and 12 register windows. That is the whole of what UEFI may touch, and it is now what rmx3823Pkg carries.
  • tz.mbn's entry point and first LOAD vaddr are 0x14680000, exactly the map's "IMEM Base", and its 0xd830a000 segment falls inside "TZApps Reserved" 0xD8800000 + 0x07400000. Two independent files agreeing on the same extraction.
  • The map stops at 0x100000000 and does not describe installed RAM, so 24 GiB remains an inference from MemTotal. The DDR base 0x80000000 is confirmed by the map's first entry.
  • Twelve of the device's 28 reserved regions fall in gaps the vendor map does not describe at all - chipinfo@81cf4000, adsp_mhi@81f00000, global_sync@82600000, tz_stat@82700000, mpss@89800000, mpss_dsm@d4d00000, xbl_sc@d8100000, cpucp_fw@d8140000, qtee@d8300000, oem_vm@f7c00000, oem_vm_swiotlb@f7b00000, trust_ui_vm@f3800000 - so UEFI neither reserves nor maps them.
  • The handoff range cannot be the whole 24 GiB: the carveouts are interleaved through the low address space and no single contiguous range avoids them. The vendor's "Kernel" window 0xA8000000 + 0x10000000 is specifically wrong, because it is where ABL loads the boot image and this device's boot partition is 192 MiB, matching payload.size_mib.
  • reserved-memory in dts/board.dts does not protect anything: the ADT generator only reads the memory node, and /chosen/memory-map carries RAMDisk, TrustCache, GpuAddon and RootPolicies only. The nodes are kept as verified documentation and because ShengGmuCommandDbInputs and the GPU driver name those addresses.

Completion criteria ​

  • All handoff regions are accounted for and each enabled DMA engine accesses its allocated range with the documented cache policy.

Current limits ​

  • The handoff range is 210 MiB, enough to bring up but not to run a full system. Widening it needs the booter to exclude the carveouts, which is unverified.
  • Individual extents inside "PIL Reserved" are still unknown; only the enclosing range 0x8A800000 + 0x18280000 is established.
  • mpss@89800000 sits below 0x8A800000 and is not covered by any map entry, so its extent is unknown.
  • Installed RAM is unconfirmed; the map does not state it.

Next action ​

  • Verify the handoff range on hardware, then extend it once the booter's carveout exclusions are established.

Evidence ​

Storage and root ​

planned

Hardware and dependencies ​

  • Identify the storage and root hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for storage and root.

Procedure ​

  • Follow the storage and root stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first storage and root observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • Host: register, clock, link and SMMU facts match the board inventory.
  • Reads: SCSI capacity, GPT and known blocks are correct; OS/SystemOS windows stay within userdata.
  • Root: the configured volume mounts and launchd starts. Persistence: writes survive reboot within the allocated Data region.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required storage and root inputs before implementation.

Evidence ​

Collect evidence using the next action.

Display ​

planned

Hardware and dependencies ​

  • Identify the display hardware, resources and existing component interfaces for this board.
  • The DSI controller and PHY nodes in dtbo.img entry 1.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for display.

Procedure ​

  • Follow the display stage in the porting guide and record the actual commands.
  • Decompiled the stock dtbo.img; the overlay carries qcom,dsi-ctrl-hw-v2.7, qcom,dsi-phy-v5.2 and qcom,dsi-display, but no panel node.

Development findings ​

  • The panel itself is still unidentified. The overlay carries the DSI controller (v2.7), PHY (v5.2) and display nodes, but the panel node lives in the base device tree, which is in vendor_boot.img - and boot.img is header_version 4, so it does not carry it either.
  • Two facts about the panel are established. Its resolution is 1240x2772, confirmed independently by the touch node's display-coords 0x4D8 x 0xAD4, and the touch node reports panel_type 7.
  • Display Reserved is 0xB8000000 + 0x02B00000 and Display Demura is 0xA2A80000 + 0x02B00000 in the vendor memory map, so the framebuffer carveouts are known even though the panel is not.

Completion criteria ​

  • A known frame appears with correct geometry and colors, then userland presentation and backlight controls work.

Current limits ​

  • No panel model, and therefore no initialisation sequence. vendor_boot.img or a device-side /sys/firmware/fdt dump is required.
  • The firmware volume runs with RMX3823_VENDOR_HW = 0 and publishes a GOP over the framebuffer ABL already scans out, so this does not block bringing up the menu.

Next action ​

  • Obtain vendor_boot.img or a device FDT dump to identify the panel, then extract its init sequence.

Evidence ​

Input ​

planned

Hardware and dependencies ​

  • Identify the input hardware, resources and existing component interfaces for this board.
  • The touch fragments in dtbo.img entry 1, machine Kalama MTP,zonda-A/B.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for input.

Procedure ​

  • Follow the input stage in the porting guide and record the actual commands.
  • Decompiled the stock dtbo.img and read fragment@66, which carries all three touch candidates.

Development findings ​

  • The active touch controller is a Synaptics S3910 over SPI, from fragment@66 of the dtbo overlay. synaptics_tcm@0 is the only one of three candidates marked status = ok; goodix-berlin@5d and synaptics_tcm_hbp@0 are both disabled.
  • Wiring from that node: SPI CS0 at 15 MHz, IRQ GPIO 25 with interrupts = <25 0x2008> (falling edge, ONESHOT), reset GPIO 24, avdd GPIO 10, TX 17 x RX 38, panel_type 7, firmware AB641.
  • drivers/ShengNovatekTouch does not apply to this board; a Synaptics TCM (SPI) implementation is needed instead.
  • The same overlay carries a goodix node for a 1080x2400 panel, so the model ships with more than one touch and panel SKU. This unit is the 1240x2772 + S3910 combination.

Completion criteria ​

  • Touches map to the display, simultaneous contacts keep stable IDs, release events arrive, and buttons produce expected HID reports.

Current limits ​

  • No Synaptics TCM driver exists in this tree yet.
  • The SPI bus instance is not identified: the overlay fragment targets a phandle rather than a named controller, so the bus number and its GPIO controller base still have to be resolved.
  • Touch firmware AB641 has not been extracted.

Next action ​

  • Resolve the SPI bus instance and GPIO controller, then write a Synaptics TCM reader against the addresses above.

Evidence ​

GPU ​

planned

Hardware and dependencies ​

  • Identify the gpu hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for gpu.

Procedure ​

  • Follow the gpu stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first gpu observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • GPU submissions complete, mapping/fence handling is correct, a known image renders, and the selected Metal client presents it.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required gpu inputs before implementation.

Evidence ​

Collect evidence using the next action.

Network ​

planned

Hardware and dependencies ​

  • Identify the network hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for network.

Procedure ​

  • Follow the network stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first network observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • Scanning, association, address configuration and sustained receive/transmit traffic pass with the selected firmware.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required network inputs before implementation.

Evidence ​

Collect evidence using the next action.

Audio ​

planned

Hardware and dependencies ​

  • Identify the audio hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for audio.

Procedure ​

  • Follow the audio stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first audio observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • Each declared route carries the selected audio format through playback or capture and handles start/stop correctly.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required audio inputs before implementation.

Evidence ​

Collect evidence using the next action.

Power ​

planned

Hardware and dependencies ​

  • Identify the power hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for power.

Procedure ​

  • Follow the power stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first power observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • Declared power controls and battery readings match observations; each claimed sleep/resume transition restores its dependent peripherals.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required power inputs before implementation.

Evidence ​

Collect evidence using the next action.

Image assembly ​

planned

Hardware and dependencies ​

  • Identify the image assembly hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for image assembly.

Procedure ​

  • Follow the image assembly stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first image assembly observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • Kernel and prelink succeed, payload contains all declared inputs, and the boot image matches the bootloader format and size limit.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required image assembly inputs before implementation.

Evidence ​

Collect evidence using the next action.

Diagnostics ​

planned

Hardware and dependencies ​

  • Identify the diagnostics hardware, resources and existing component interfaces for this board.

Configuration ​

  • Record the board.toml fields, DTS properties and defconfig values used for diagnostics.

Procedure ​

  • Follow the diagnostics stage in the porting guide and record the actual commands.

Development findings ​

  • Collect the first diagnostics observation, its cause when established, and the resulting implementation decision.

Completion criteria ​

  • Each claimed milestone has a reproducible command, a matching source/image revision and an accessible result.

Current limits ​

  • Hardware inputs and implementation are pending for this example board.

Next action ​

  • Inventory the required diagnostics inputs before implementation.

Evidence ​

Collect evidence using the next action.

Released under the BSD-2-Clause-Patent License.

Copyright 2026 UniXNU contributors