UniXNU

English

简体中文

English

简体中文

Appearance

Xiaomi Pad 6S Pro (TheArchitectEngineer) ​

TheArchitectEngineer/UniXNU-sheng

Xiaomi Pad 6S Pro 12.4 uses shared SM8550 support and board-owned storage, input, firmware and power integration. This record describes implementation coverage and the evidence required for each milestone.

Source record: porting.toml, d76556b8909e380961309e970d87b919a74e411e.

This page is generated from the device record.

AreaStatus
Configurationimplemented
Firmware and bootimplemented
CPU and interruptsimplemented
Memory and DMAimplemented
Storage and rootimplemented
Displayimplemented
Inputimplemented
GPUimplemented
Networkimplemented
Audioimplemented
Powerimplemented
Image assemblyimplemented
Diagnosticsimplemented

Configuration ​

implemented

Hardware and dependencies ​

  • SM8550 profile, iPadOS 17.7.11 build 21H461, device defconfig, pinned component sources.

Configuration ​

  • board.soc_source = sm8550; board.os_profile = ipados-17.7.11-21H461; schema_version = 2.
  • The device owns ShengUfs, ShengHidInput, ShengNovatekTouch and ShengPreflight submodules.

Procedure ​

Development findings ​

  • Tables merge in ARM64, SoC, OS, device order. Arrays replace inherited selections, so include every required component and fragment.
  • The selected defconfig applies after the explicit configuration fragments. Keep OS ABI and IPSW pins in the OS profile.
  • board.toml names the model J120AP, the Apple board of the iPadOS identity, and its kernel arguments enable Wi-Fi (sheng-wifi=5) and the CPU and GPU governors.

Completion criteria ​

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

Current limits ​

  • Local overrides can select a different source from the published pin; record the effective source in each verification result.

Next action ​

  • Compare the effective status output whenever a profile, source or component selection changes.

Evidence ​

Firmware and boot ​

implemented

Components: ShengPreflight.

Hardware and dependencies ​

  • uefi-sheng firmware, stock firmware DTB, GOP handoff, PSCI SMC interface and vendor firmware inventory.

Configuration ​

  • firmware.dsc = Platforms/Xiaomi/shengPkg/sheng.dsc; firmware.config = sheng.
  • proprietary-files.txt records input paths and provenance.
  • The firmware DSC and FDF embed UniXNU, UniXNUDxe, DarwinBoot, UniXNURamDiskDxe, DiskIoDxe and FAT support.

Procedure ​

  • Run ./unixnu build firmware -D ../UniXNU-sheng --uefi ../uefi-sheng.
  • Record the firmware commit, output FD and handoff memory map before a boot attempt.
  • Build the payload, then run ./unixnu bootimg with the firmware DTB. Inspect boot.json ramdisk_bytes and the required firmware modules.

Development findings ​

  • The firmware DTB is an input to boot-image assembly. XNU consumes the separately generated ADT.
  • The sheng preflight component belongs with board integration and its firmware requirements.
  • The shared UniXNURamDiskDxe reads the Mu-Silicium entry-argument HOB and FDT initrd range to publish the payload block device. ShengBootMemoryDxe owns memory expansion.
  • Configured menu entries require a payload FAT filesystem containing EFI/UniXNU/unixnu.toml. Check the UNIXNURAMDISK initrd block-device status when entries are absent.

Completion criteria ​

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

Current limits ​

  • Boot-image assembly requires the selected firmware DTB and proprietary input files.

Next action ​

  • Capture firmware revision and memory reservations with the next image verification.

Evidence ​

CPU and interrupts ​

implemented

Components: ArmCpu, ArmDTPlatform.

Hardware and dependencies ​

  • SM8550 CPU affinities, GIC distributor at 0x17100000, redistributors at 0x17180000, 0x40000 stride and 19.2 MHz timer.
  • PSCI uses SMC. The board disables cpu1 and cpu2 in its DTS.

Configuration ​

  • dts/sheng.dts includes sm8550.dtsi; shared CPU and interrupt definitions come from the SoC source.
  • Kernel arguments select sheng-smp=1 and armcpu-spi-ipi=1.

Procedure ​

  • Compile the board DTS and inspect enabled CPUs, GIC ranges and timer properties in the ADT.
  • Record per-CPU entry, timer interrupts and inter-processor interrupt delivery.

Development findings ​

  • CPU affinity values are hardware identifiers. Enabled CPU count and MPIDR affinities must be checked together.
  • GIC register ranges must use translated physical addresses from the hardware tree.
  • XNU accepts work interval operations 6, 7 and 8 (interval start, update and finish) through patches/xnu/native-work-interval-instance.patch in UniXNU; without a performance controller they only succeed.

Completion criteria ​

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

Current limits ​

  • CPU selection and frequency policy are board inputs; SoC topology describes all cores.

Next action ​

  • Attach per-CPU and interrupt observations for the selected firmware and image.

Evidence ​

Memory and DMA ​

implemented

Hardware and dependencies ​

  • Handoff DRAM at 0x80000000 with size 0x80000000; splash reservation at 0xb8000000 with size 0x2b00000.
  • Payload owned-memory request is 0x130000000. Device DMA requires controller stream IDs, address widths and ownership.

Configuration ​

  • device_tree.source = device:dts/sheng.dts; include_dirs = [soc:dts].
  • payload.adt.owned_memory_size and firmware reservations describe separate allocations.

Procedure ​

  • Compare firmware RAM ranges, reserved regions, DTS ranges and ADT memory-map entries.
  • Check DMA buffers against controller address width, cache policy and SMMU mapping before submitting work.

Development findings ​

  • Physical register translation and CPU virtual mappings have different purposes. Preserve physical resource ranges in hardware descriptions.
  • GPU and UFS use different SMMU instances and stream assignments.

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 DTS declares the current handoff window and splash region; memory sizing requires the selected firmware map.

Next action ​

  • Record the firmware memory map and each DMA consumer when changing reserved memory.

Evidence ​

Storage and root ​

implemented

Components: ShengUfs, VirtioMmioBlock, RamBlock, VerifiedRoot.

Hardware and dependencies ​

  • UFS host 0x01d84000/0x3000; PHY 0x01d80000/0x2000; GCC base 0x00100000.
  • GCC AXI, AHB, UniPro, symbol and PHY auxiliary branches; power domains and firmware link state.
  • Apps SMMU at 0x15000000, UFS stream 0x60, context-bank ownership, DMA width and cache maintenance.
  • LUN 0 uses 4096-byte blocks; userdata spans LBAs 3094592 through 64007162.

Configuration ​

  • Select ShengUfs and CONFIG_XNU_NATIVE_UFS=y; native-ufs-root=1 enables the root path.
  • userdata defines OS and SystemOS windows. payload.adt.root_match_volume_uuid = 04769D26-2CA0-4825-B443-E2E5F88300F2.

Procedure ​

  • Read https://unixnu.com/porting/ufs with this storage record.
  • Inspect clock enables, power state, HCE/HCS, link state, request-list base and SMMU mappings before changing controller ownership.
  • Validate SCSI capacity and GPT reads, then publish root windows and mount the configured root UUID.
  • Verify persistent Data writes on the documented Data allocation with a recovery image available.

Development findings ​

  • An idle AHB branch may report CLK_OFF with hardware gating enabled. Check enable and gating bits together.
  • SMMU bypass still has address-width constraints. Validate every DMA range and context-bank assignment.
  • ShengUfs contains controller access, GPT/window parsing and sheng Data/log policy. Reuse each layer according to its inputs.

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 ​

  • The SoC DTSI exports host and PHY ranges. GCC and UFS SMMU handling currently use constants and operations in ShengUfs.
  • The root transport uses a polled request slot. Its firmware adoption path requires a usable existing request list.

Next action ​

  • Record clock/PHY/reset initialization ownership and the SMMU stream before adapting this driver to another board.

Evidence ​

Display ​

implemented

Components: GopFramebuffer.

Hardware and dependencies ​

  • UEFI GOP framebuffer, stride, pixel format, splash reservation and board panel/backlight controls.

Configuration ​

  • Select GopFramebuffer; CONFIG_XNU_NATIVE_LEGACY_DISPLAY=y; artwork-display-gamut = sRGB.
  • sheng-vsync=120 requests board display timing.

Procedure ​

  • Verify GOP address, dimensions, stride and pixel layout before enabling presentation.
  • Build the late display archive with the selected OS ABI records, then check display publication and frame presentation.

Development findings ​

  • The display source and ABI binding are selected independently from the physical panel configuration.
  • The board configuration declares sRGB for the current 8-bit framebuffer path.
  • scripts/build-gop-legacy-display.py also builds the board driver objects in the display archive, including the ADSP, IPC router, FAT reader and battery manager.
  • The GENI I2C core also moves 1 to 8 byte writes and 1 to 4 byte reads (the audio amplifiers use 32-bit registers); the backlight keeps its 8-bit transfers.

Completion criteria ​

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

Current limits ​

  • The late display builder needs qualified prelink candidates and ABI records. A timing request requires a measured presentation result.

Next action ​

  • Record frame timing, pixel format and presentation evidence for each image used to qualify display.

Evidence ​

Input ​

implemented

Components: ShengHidInput, ShengNovatekTouch, QcomGeniSpi.

Hardware and dependencies ​

  • Novatek NT36532 sensor, GENI SPI controller, pin configuration, reset/interrupt lines, firmware and touch coordinate geometry.

Configuration ​

  • Select ShengHidInput, ShengNovatekTouch and QcomGeniSpi; sheng-touch=4 and sheng-touch-hid=1 select board integration.

Procedure ​

  • Read TouchBoard.h and verify the SPI clock and mode against the controller setup.
  • Validate protocol reports, contact tracking and coordinate orientation before publishing HID events.

Development findings ​

  • Controller transfer logic, sensor protocol and board sensor geometry are separate inputs.
  • Track contact IDs across movement and lift events; a register read alone covers only transport access.
  • sheng_buttons_press() holds a button mask for a given time through the HID sink, for unattended tests (the audio lock sound test uses it).

Completion criteria ​

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

Current limits ​

  • Sensor firmware and board dimensions remain sheng inputs.

Next action ​

  • Attach contact and orientation observations when firmware or geometry changes.

Evidence ​

GPU ​

implemented

Components: Adreno740, AdrenoMetal, AirNir, Sm8550Platform, AdrenoPM4, AdrenoFirmware, ArmSmmu4K.

Hardware and dependencies ​

  • A740 GPU/GMU registers, GPU SMMU streams 0/1 and GMU stream 5, signed ZAP firmware and board power votes.
  • Turnip, metal2vulkan, AIR translation and the selected OS GPU/Metal ABI.

Configuration ​

  • Select Adreno740, AdrenoMetal and AirNir; shared SM8550 operations arrive through component dependencies.
  • Board scripts combine shared GMU code with package/ShengGmuVotes.c.

Procedure ​

  • Qualify power, firmware, SMMU and GMU startup before command submission.
  • Check memory mapping, command completion and a known rendered image before staging the Metal plugin.

Development findings ​

  • GPU generation and the frontend ABI define component scope. Firmware, votes and display integration remain board inputs.
  • Shared platform code and board votes require separate include paths during archive assembly.
  • A frame is one submission of up to 128 IBs (24 at most observed). WPTR writes check the GMU AHB fence status; none were dropped. Jobs take about 5 ms against the client's 1 ms waits, so the stall handler's write-pointer and TLB recovery runs on ordinary jobs: mapping-time TLB invalidation did not change it.
  • The render server primes all 162 Metal libraries of the OS image while the desktop is idle (the PR log row). The payload carries the library list and a copy of the cryptex QuartzCore library. The idle desktop submits 6 command buffers per 250 ms at 120 Hz, so priming waits only above 8.

Completion criteria ​

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

Current limits ​

  • A740 coverage depends on the selected firmware and OS ABI; board qualification requires its own memory and power evidence.

Next action ​

  • Record the exact firmware, compiler inputs, driver revision and rendered output for the next qualification.

Evidence ​

Network ​

implemented

Components: Ath12kWifi.

Hardware and dependencies ​

  • Ath12k device on PCIe, BAR windows, MSI routing, DMA callbacks, firmware, MHI and QRTR services.

Configuration ​

  • Select Ath12kWifi. build-gop-legacy-display.py compiles its objects through build-ath12k-wifi.py.
  • board.toml sets sheng-wifi=5 in the kernel arguments; WifiProbe and the UFS driver read it.

Procedure ​

  • Verify PCIe enumeration and MSI delivery before MHI startup.
  • Record firmware startup, scan, association, address configuration and bidirectional packet delivery separately.

Development findings ​

  • The reusable Wi-Fi stack consumes board callbacks; PCIe and the OS network interface are owned by the device integration.
  • MHI startup and network traffic are separate completion points.

Completion criteria ​

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

Current limits ​

  • The source implements the station path through WifiNet.cpp and board PCIe integration. Device evidence must identify the firmware and access point.

Next action ​

  • Attach association and receive/transmit observations for the current firmware and image.

Evidence ​

Audio ​

implemented

Hardware and dependencies ​

  • ADSP firmware from modem_a, SMEM, SMP2P, GLINK, the GPR channel adsp_apps.
  • Speakers: six CS35L43 amplifiers on QUP1 SE5 and QUP2 SE0 (I2C 0x40 to 0x42), shared reset gpio90, secondary MI2S (gpio121 to 124).
  • Microphones: WCD938x codec on the TX SoundWire master (0x6d30000), reset gpio108, supply ldob15; TX and VA macros.

Configuration ​

  • sheng-audio takes bits (sheng-adsp=2 is required): any nonzero value serves the audio service, 2 plays a 1.5 s 750 Hz test tone at boot, 4 brings up the microphone path and reads two seconds of capture, 8 runs the lock sound test.
  • sheng-audio-pa moves the DSP period buffer (default 0xd0000000); sheng-audio-tone-ms and sheng-audio-atten set the tone.
  • The payload addon carries hal/ShengAudio.driver under audio/; patches/xnu/zzyd-sheng-audio-addon-mount.patch mounts it over /System/Library/Audio/Plug-Ins/HAL. Its CDHash joins the owner trust cache.

Procedure ​

  • Read the [audio], [amps], [audio-glink], [audio-buffer], [mic], [mic regs] and [mic capture] log lines with scripts/read-sheng-log.py.
  • Read [audio-props], [audio-service], [audio-io], [audio-thread], [audio-clock], [audio-requests] and [audio-sync] for the iOS path: the plug-in's volume and peak, late and silent periods, write-ahead and read-behind, IO cycle intervals, clock skew, the audio server's IO thread scheduling and host clock, and the plug-in's last start and stop requests.
  • Run scripts/check-audioreach-host.py, scripts/check-cs35l43-host.py and scripts/check-geni-i2c-host.py after changing the codecs.

Development findings ​

  • The ADSP image loads in place from the split adsp and adsp_dtb files in /image of the modem_a FAT volume.
  • The DSP offers 24 intents of 128 bytes on adsp_apps and grants a 4 KiB one on request; the GLINK remote intent table keeps it.
  • The amplifiers play ASP RX1 directly (DSP bypassed, no amplifier firmware): top three slot 0, bottom three slot 1, gain 18 dB, 16-bit I2S at 48 kHz from the SoC as clock master.
  • The DSP takes buffers as a 32-bit address with the stream index (0x1001 & 0xf) in the upper word. The period buffer is low DRAM outside the kernel's window, mapped write-combined; the audio streams stay in SMMU pass-through.
  • Programming a translating SMMU context for the audio streams resets the board; the hypervisor keeps those context banks.
  • PRM commands go from the PRM port (2) and use PRM clock ids: the TX core clock is 0x30c. The macro and digital codec votes make the LPASS registers accessible.
  • The VA macro gates the TX SoundWire master's clock on SM8550; with its gate and the TX macro's on, the link comes up and the codec enumerates as device 1.
  • The primary microphone is AMIC3 on micbias 3 into ADC2, codec data port 1 channel 2, master port 2, TX decimator 0 from SWR_MIC1 and codec DMA TX3, mono 48 kHz.
  • iOS sees the plug-in device only with the Thunderbolt transport type: VirtualAudio makes it a driver device with one output and one input port. Built-in devices need Apple port descriptions, and a USB device needs a location the audio server does not take from a plug-in.
  • The plug-in and the service share one timeline anchored at boot on the 19.2 MHz host timer (400 ticks per frame, computed in 128-bit). Playback and capture rings hold 65536 frames; the service takes 480-frame periods and keeps four in flight.
  • The DSP answers a playback buffer once it has copied it, so the steady lead is measured per run (about 1600 to 2000 frames) and the published lead is at least 300 ms.
  • Capture answers carry a byte count and an offset; only those bytes are taken, and a short period is normal.
  • CoreAudio takes the host clock to be 24 MHz (one constant behind AudioGetHostClockFrequency). The plug-in finds that constant and the service sets it to 19.2 MHz on its shared page; without it the audio server's IO cycles ran 25 percent long and playback and recording stuttered.
  • The zero time stamps start at the frame IO starts on, every 65536 frames, with the raw clock algorithm. A period under the safety offset stops the audio server's IO.
  • The audio server's IO thread runs with a time constraint (priority 97, period 409600 ticks, computation 204800).

Completion criteria ​

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

Current limits ​

  • Playback sounds harsh in places; no speaker equalization or protection runs.

Next action ​

  • Qualify iOS playback and capture across apps and routes, then add speaker equalization and protection.

Evidence ​

Power ​

implemented

Components: AppleKeyStoreState.

Hardware and dependencies ​

  • Board PMGR integration, clocks/regulators and per-peripheral power requirements.
  • ADSP battery manager: PMIC GLINK owner 32778 on PMIC_RTR_ADSP_APPS; board properties use opcode 0x50; fuel gauges 0x8a/0x8b and 0xa6/0xa7.

Configuration ​

  • CONFIG_XNU_SHENG_PMGR=y; sheng-pmgr=2 selects the board integration.
  • AppleKeyStoreState is selected with the OS event integration.
  • sheng-adsp=2 publishes the battery as an IOPMPowerSource; sheng-battery=0 leaves it off.
  • sheng-usb-sdp-ma sets the input limit on a standard computer port (default 900; 0 keeps the firmware limit).
  • sheng-cpufreq=4 scales the CPU domains with load (sheng-cpufreq-min sets a floor in MHz); sheng-cpufreq=3 fixes the highest non-turbo level.
  • sheng-gpu-dcvs=1 scales the GPU clock with its busy time (sheng-gpu-dcvs-min sets the floor level, default 3); sheng-gpu-perf fixes a level instead.

Procedure ​

  • Document each clock, regulator and firmware-owned state before enabling power transitions.
  • Check battery units and update behavior separately from suspend/resume and peripheral power.
  • Read the [battery], [battery-raw] and [charger] log lines with scripts/read-sheng-log.py.

Development findings ​

  • The ADSP firmware runs charging and PD/PPS negotiation without host requests.
  • Battery properties after 11 are shifted by one: charge current 12, temperature 13, charge counter 15, cycles 16, design 17, full 18, time to full 20, time to empty 21.
  • Charge is the sum of both fuel gauges' remaining over full capacity. Battery current is reported discharge-positive.
  • USB property 6 reads SDP on every port. Property 7 carries the adapter type (6 PD, 8 PD PPS).
  • A PPS adapter gets a 3 A input limit at about 8.7 V; the battery charges at the 2000 mA charge current with the charge pump off.
  • Both cells and the PD adapter read unauthenticated.
  • A Mac USB-C port negotiates PD 5 V with a 1.2 A input limit: about 1.1 A in, and the battery gains 0.25 to 0.4 A on the desktop.
  • Power policy belongs to the board even when controller operations are shared.
  • The GPU power probe hands the ring its register window without a GMU fence callback: only the GPU service checks fenced WPTR writes.
  • The CPU governor reads each CPU idle time through patches/xnu/zzye-sheng-cpu-idle.patch. Domain 0 holds the parked boot core and stays at its top level.
  • The GPU governor reads the GMU XO busy counter and votes over HFI with the level bandwidth.

Completion criteria ​

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

Current limits ​

  • Adapter details shown to iOS come from USB property 6, so every adapter reads as a computer port.
  • Charge current stays at 2 A without fuel gauge and adapter authentication.
  • A low-battery shutdown panics in vnode_rele_ext during unmount.
  • Per-peripheral controls and battery publication have separate coverage from system suspend.
  • The GPU governor changes level several times a second and spends most busy time at 680 MHz; its effect on frame times is not measured.

Next action ​

  • Take adapter details from property 7.
  • Authenticate both fuel gauges, then qualify PPS charge pump charging; Xiaomi adapter authentication follows.

Evidence ​

Image assembly ​

implemented

Components: DarwinBoot, XnuPrelink, SoftwareAES.

Hardware and dependencies ​

  • Prelinked kernel, hardware DTB, generated ADT, trust cache, Data seed, platform identity and firmware DTB.

Configuration ​

  • Payload volume is 208 MiB. kernel.patch_series selects ARM64, SoC, OS and device series in order.

Procedure ​

  • Build kernel and package, then payload with --unique-chip-id and the selected trust-cache/Data inputs.
  • Run ./unixnu bootimg -D ../UniXNU-sheng --uefi ../uefi-sheng --dtb <firmware.dtb> and inspect the assembly report.

Development findings ​

  • The OS boot-progress integration follows the SoC hooks in patch order.
  • The payload carries kernel.macho.adt; the boot image carries the firmware FDT. Keep the two inputs named explicitly.
  • The device patch series adds zzyd-sheng-audio-addon-mount.patch: the payload addon's audio directory is union-mounted over /System/Library/Audio/Plug-Ins/HAL (mount4 in the A log line).

Completion criteria ​

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

Current limits ​

  • Image output depends on the selected ABI audits, firmware and volume policy inputs.

Next action ​

  • Attach artifact paths and exact source revisions to the next image build record.

Evidence ​

Diagnostics ​

implemented

Hardware and dependencies ​

  • Serial or framebuffer diagnostics, panic region, boot checkpoints and a recovery path.

Configuration ​

  • boot-progress=2 enables checkpoints; source and image revisions accompany every log.

Procedure ​

  • Run the existing check for the changed area and keep its command, output and input revision.
  • Record the last completed checkpoint and the first failing operation; link the captured output.

Development findings ​

  • A source implementation, a host check and a device observation establish different completion levels.
  • Keep an unresolved cause explicit and record the next measurement that can distinguish it.
  • The UFS log carries [adsp], [qrtr], [battery], [battery-raw] and [charger] lines for the DSP, the IPC router and the charger.
  • BatteryProbe starts the battery with sheng-adsp=2, so the [battery] and [charger] lines appear on every DSP image; a missing [battery] line on such an image means sheng-battery=0 or a failed start.
  • Host checks for the ADSP path: check-adsp-host.py, check-modem-fw-host.py, check-qrtr-host.py and check-battery-host.py.
  • The log carries [audio], [amps], [audio-glink], [audio-buffer], [mic] and [mic regs] for the audio path, and [gpu wptr] for fenced GPU write pointer writes.

Completion criteria ​

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

Current limits ​

  • Source references in this record describe implemented behavior. Host and device status require their respective evidence entries.

Next action ​

  • Add captured host or device evidence when repeating a checkpoint on a known image.

Evidence ​

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

Copyright 2026 UniXNU contributors