UniXNU

简体中文

English

简体中文

English

外观

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.

源记录: porting.toml, e75657692fc4eca7d49dba26941690264dd1dc09.

本页按设备记录自动生成。

部分状态
配置implemented
固件与启动planned
CPU 与中断planned
内存与 DMAimplemented
存储与根卷planned
显示planned
输入planned
GPUplanned
网络planned
音频planned
电源planned
镜像组装planned
诊断planned

配置 ​

implemented

组件: ArmDTPlatform, ArmCpu, SoftwareAES, XnuPrelink, DarwinBoot.

硬件与依赖 ​

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

配置 ​

  • 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.

操作步骤 ​

  • 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.

开发经验 ​

  • 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.

完成条件 ​

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

当前范围 ​

  • 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.

下一步 ​

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

证据 ​

固件与启动 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

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

当前范围 ​

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

下一步 ​

  • Inventory the required firmware and boot inputs before implementation.

证据 ​

按下一步操作收集证据。

CPU 与中断 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

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

当前范围 ​

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

下一步 ​

  • Inventory the required cpu and interrupts inputs before implementation.

证据 ​

按下一步操作收集证据。

内存与 DMA ​

implemented

硬件与依赖 ​

  • 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.

配置 ​

  • 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.

操作步骤 ​

  • 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.

开发经验 ​

  • 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.

完成条件 ​

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

当前范围 ​

  • 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.

下一步 ​

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

证据 ​

存储与根卷 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

  • 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.

当前范围 ​

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

下一步 ​

  • Inventory the required storage and root inputs before implementation.

证据 ​

按下一步操作收集证据。

显示 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

  • 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.

开发经验 ​

  • 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.

完成条件 ​

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

当前范围 ​

  • 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.

下一步 ​

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

证据 ​

输入 ​

planned

硬件与依赖 ​

  • 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.

配置 ​

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

操作步骤 ​

  • 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.

开发经验 ​

  • 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.

完成条件 ​

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

当前范围 ​

  • 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.

下一步 ​

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

证据 ​

GPU ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

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

当前范围 ​

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

下一步 ​

  • Inventory the required gpu inputs before implementation.

证据 ​

按下一步操作收集证据。

网络 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

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

当前范围 ​

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

下一步 ​

  • Inventory the required network inputs before implementation.

证据 ​

按下一步操作收集证据。

音频 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

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

当前范围 ​

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

下一步 ​

  • Inventory the required audio inputs before implementation.

证据 ​

按下一步操作收集证据。

电源 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

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

当前范围 ​

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

下一步 ​

  • Inventory the required power inputs before implementation.

证据 ​

按下一步操作收集证据。

镜像组装 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

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

当前范围 ​

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

下一步 ​

  • Inventory the required image assembly inputs before implementation.

证据 ​

按下一步操作收集证据。

诊断 ​

planned

硬件与依赖 ​

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

配置 ​

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

操作步骤 ​

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

开发经验 ​

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

完成条件 ​

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

当前范围 ​

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

下一步 ​

  • Inventory the required diagnostics inputs before implementation.

证据 ​

按下一步操作收集证据。

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

Copyright 2026 UniXNU contributors