UniXNU

English

简体中文

English

简体中文

Appearance

Xiaomi Mi 11 M2011K2C: single-CPU platform bring-up ​

Sulee7z/UniXNU-venus

The WSL zeta XNU12377.121.6 build now passes real QEMU UEFI/DarwinBoot handoff and arm_vm_init return with a256-byte random seed, EL1/MMU and4KiB pages. Root/Data/userspace for this kernel remain unqualified; see ZETA-WSL-ENTRY.md. Earlier XNU10063 phone baseline:039 touch normal, Metal apparently inactive;040 diagnostic absent;041 prepared. iPhone11,8 iOS17.7 inputs/root are prepared but its MH_FILESET arm64e conversion remains incomplete; see README.md.

Source record: porting.toml, 9b1402a99d9ee37d8aa4a980eceff18a4c993e02.

This page is generated from the device record.

AreaStatus
Configurationhost-verified
Firmware and boothost-verified
CPU and interruptshost-verified
Memory and DMAdevice-verified
Storage and rootdevice-verified
Displayhost-verified
Inputdevice-verified
GPUdevice-verified
Networkplanned
Audioplanned
Powerhost-verified
Image assemblyhost-verified
Diagnosticsimplemented

Configuration ​

host-verified

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

Hardware and dependencies ​

  • UniXNU 16e592abee8a550dec8154ed1f38b5ebc4f16213 and its component catalog
  • Unpublished local SM8350 source selected by local.toml

Configuration ​

  • Format 2; ARM64 -> SM8350 -> ipados-17.7.11-21H461 -> venus
  • The venus_ufs_root_defconfig adds the real owner-policy, Virtio and RAM providers through the audited board archive recipe
  • Ordered source patches; missing compile objects trigger bootstrap recovery before archive symbol audits

Procedure ​

  • Run unixnu defconfig venus_ufs_root_defconfig, status --json, check-stage-foundation.py and the official porting-record checker
  • Resolve source pins and apply the recorded host ADT converter patch before generating new stage inputs

Development findings ​

  • The former device directory contained diagnostic notes rather than a standard board.toml
  • The guide's SM8550 peripherals do not describe SM8350; only generic compatible components are selected
  • The prerequisite series supplies the PMGR call site; the current profile now links the audited original-nub publication archive and enables XNU_SHENG_PMGR.
  • After a changed series recreates xnu-work, retained compile records skip the bootstrap pass. Archive compilation then missed TrustCache/API.h; explicitly restoring the matching Apple headers before archives fixes the dependency order.

Completion criteria ​

  • Profiles and component revisions resolve; complete archive/patch plan is reproducible; source overrides are explicit

Current limits ​

  • Local SoC/device changes and the shared converter correction are unpublished; evidence records upstream base plus local input hashes

Next action ​

  • Use the current full-root board with explicit chosen display-scale2/rotation0; the lockscreen candidate explicitly requests6GiB
  • Current generator comparison is recorded in LOCKSCREEN-SCALE.md; preserve historical exact-input checks for their original board revisions

Evidence ​

Firmware and boot ​

host-verified

Hardware and dependencies ​

  • Venus stock boot v3, matching vendor_boot/dtbo, FD 0x9fd00000/2MiB
  • Mu_Basecore cfb93724a06ff86ff5ba971413368a7809ee42a5 with local Venus integration

Configuration ​

  • Existing venusPkg paths and Mu patch list in board.toml
  • Stock header v3 uses vendor_boot DTB rather than an appended foreign DTB

Procedure ​

  • Compare shared UniXNURamDiskDxe with the existing combined-initrd VenusPayloadDxe handling
  • Integrate AdvancedLogDxe and required libraries; rebuild and round-trip-check the boot container

Development findings ​

  • ABL initrd overlapped the old DXE heap; the heap moved to 0xc6200000/256MiB
  • PrePi AllocatePool rejects the 776555-byte FDT; page allocation fixed the earlier stall
  • Shared UniXNURamDiskDxe assumes an integral-sector complete FAT initrd; Venus vendor concatenation requires retaining the bounded board adapter
  • VENUS_GUIDE_LOGGING compiles DxeCore memory logging, framebuffer forwarding and AdvancedLogDxe QR export; buffer is 128 pages and locator-variable publication is disabled

Completion criteria ​

  • New profile builds firmware, discovers the RAM FAT and exports readable firmware logs

Current limits ​

  • The current package uses the external Mu build wrapper for board patch handling; new logger protocol/menu/QR runtime remains untested on phone

Next action ​

  • Obtain approval for the candidate RAM boot and observe Tools/Advanced Logger and the new kernel handoff

Evidence ​

CPU and interrupts ​

host-verified

Hardware and dependencies ​

  • Affinities 0,0x100..0x700; initial boot CPU affinity zero
  • GICD 0x17a00000/0x10000, GICR 0x17a60000/0x100000, stride 0x20000; timer 19.2MHz; PSCI SMC

Configuration ​

  • Default remains the device-proven boot core. Independent038 selects four affinities0/400/500/700 with cpus4/sheng-smp1
  • Retained native BCM2837 arrays support only MAX_CPUS4; eight-node037 is blocked
  • The non-Apple reset entry now preserves Affinity1 and initializes PSCI reset state before debug access

Procedure ​

  • Compare shared DTSI with live FDT; boot matching profile; verify platform/CPU registration and first timer interrupt
  • Enable secondary cores only after individual entry and IPI checks

Development findings ​

  • Legacy phone probes proved entry/MMU/arm_vm_init return only
  • New prelinked kernel and its panic-screen payload copy both reached a real QEMU rtclock_intr return with GIC ready, one running CPU and one timer IRQ
  • First prelinked phone run panicked at PC fffffff00741a378, opcode d51be228: fiq_context_init wrote CNTP_CTL_EL0 after enabling CNTV_CTL_EL0. The SM8350 series now removes that inaccessible physical-timer write while retaining virtual timer operation.

Completion criteria ​

  • Boot CPU receives timer interrupts; every subsequently enabled CPU reaches entry and receives IPI

Current limits ​

  • 038 compiled-reset and QEMU startup checks observe four available CPUs; not a Venus hardware qualification
  • The bounded timer sample does not cover every core and IPI delivered count is0; delivery remains unqualified
  • CPU frequency and E/P scheduling are not yet implemented; no complete Apple CPU compatibility claim

Next action ​

  • See CPU-038-AND-IPHONE.md; complete per-core timer/IPI and device qualification for038
  • A full eight-core configuration needs all MAX_CPUS-dependent kernel objects rebuilt, not a boot-argument change

Evidence ​

Memory and DMA ​

device-verified

Hardware and dependencies ​

  • Hash-pinned live FDT contains two DRAM banks and 21 nonempty reservations
  • Second bank is 0xc0000000 + 0x1c0000000; firmware remains responsible for allocatable regions

Configuration ​

  • Hardware DTS describes the measured upper DRAM bank; the independent default owned window is now the phone-tested 1GiB
  • All 21 fixed live reservations retain their no-map attributes; venus.dsc enables the qualified high-memory region

Procedure ​

  • Compile DTS and compare CPU/GIC/timer/PSCI, bank and reservation values to live.dtb
  • Generate ADT using the selected OS profile and audit each DMA engine before enabling it

Development findings ​

  • Adding bank lengths across the physical DRAM hole is unsuitable as a single contiguous DTS range
  • The new phone run reached IODTGetICellCounts with a null interrupt parent because the shared converter emitted phandle without AAPL,phandle
  • The QEMU shared-generator fixture reproduced the exact phone PC/LR/FAR/ESR. Emitting the Apple alias fixed platform discovery and timer return with the same kernel.
  • The user-provided 2026-10-28 23:40 photograph reports MEM totalMiB=6144, root=1, 124 processes and OS t=172s; this is physical evidence of a reported 6GiB window at capture time. The photo does not show the full image SHA or prove execution after capture.
  • At the same capture, SWAP/COPY are zero and three retained SpringBoard rows show SIGTRAP; UI remains unavailable. UFS read and integrity failure counters are zero.

Completion criteria ​

  • Handoff ownership matches UEFI; every enabled DMA engine reaches only its assigned memory

Current limits ​

  • The 6GiB photo has no embedded image SHA or associated RAM-boot log; association to candidate66f5314a follows the user-provided handoff context
  • A single photograph cannot establish continued execution after capture or whether memory pressure caused SpringBoard SIGTRAP
  • UFS private contiguous DMA and SIDe0 routing are verified by bounded phone reads; other peripheral DMA paths remain unqualified

Next action ​

  • Continue host-side analysis of the retained SpringBoard display-mode/service failure; do not infer a memory-related fix from the 6144MiB report
  • Any further phone observation requires separate confirmation of the exact image and operation
  • The new6GiB firmware branch reaches the measured DT bank end0x280000000; source/QEMU results do not replace device evidence

Evidence ​

Storage and root ​

device-verified

Hardware and dependencies ​

  • Live UFS controller 0x01d84000/0x3000; Lahaina PHY 0x01d87000/0xe10
  • Actual LUN/GPT, block size, clocks, resets, regulators and SMMU handoff must be reconciled

Configuration ​

  • Separate register-only, block-read and verified-root configurations retain their own evidence
  • Root mode uses the real signed disk policies, persistent Data provider and exact existing 64GiB unixnu selection in GPT slot35
  • The existing 1GiB tail reservation is explicitly fixed; 8GiB Data store placement and original seed identity remain stable

Procedure ​

  • Inventory target UFS/PHY/clock/SMMU ownership; implement bounded read commands
  • Verify capacity and known blocks before root publication; derive root UUID from selected IPSW volume

Development findings ​

  • The user supplied the official dual-system guide for renewed evaluation; the pinned-file design stays deferred
  • Android read-only inspection confirms matching primary/backup GPT, a tail userdata partition, spare GPT entries, and matching single-segment-section F2FS superblocks. Recovery/resize support is not yet verified.
  • The pinned zeta SM8350 transport matches target resources and compiles against current XNU10063 headers
  • Sheng's original IOBlockStorageDevice ABI was checked against actual compiled public metadata and live QEMU class state: 190 slots, sizes 0x90/0x88
  • Both probe archives bind 190 concrete slots, 23 overrides and 11 original imports; remaining kernel imports resolve against native link inputs. Exact unixnu/userdata selection and no cross-target/prefix fallback passed ASan/UBSan.
  • The initial survey returned err=0, ready UFSHCI3.0 and exact SIDe0/CB2. Unused banks had M clear but nonzero reset bits; restoring the successful reference's initialize-then-readback order fixed the extra pre-zero refusal.
  • Approved 20537e4e image then completed 9 commands and 5 GPT reads through bank74. Capacity, both header CRCs, array CRC and primary-header SHA256 match retained Android blocks; final queues/doorbells/GFSR are zero. Evidence: ufs-read-device-verified.json.

Completion criteria ​

  • Known block reads match; correct root volume mounts; launchd starts; Data writes survive the defined reboot sequence

Current limits ​

  • The latest exact-image photo (28051b5a) demonstrates owner-root acceptance, userspace and zero reported UFS failures/integrity failures; it is not a complete readback or proof of Data persistence across reboot.
  • GPT/reset/post-reset geometry and all 67 root sparse fragments completed earlier. The latest full-baseline RAM boot used the existing deployment; no additional root flash is required.

Next action ​

  • Controlled Data002 write/restart/readback now passes; preserve the kernel/seed/store/marker and exact evidence
  • Advance to CPU display mode/known-frame/swap checks using current board-generated inputs without the opt-in Data qualification stop
  • Keep broader UFS endurance/error recovery and old-marker cause separate from this one-file persistence result

Evidence ​

Display ​

host-verified

Components: GopFramebuffer, AppleKeyStoreState.

Hardware and dependencies ​

  • Phone panel 1440x3200; retain actual GOP base, stride, format and reservation
  • Target MobileFramebuffer/IOSurface ABI and panel brightness protocol

Configuration ​

  • The full defconfig links NativeLegacyDisplay with the audited original ABI and CPU presentation enabled
  • AppleKeyStoreState is linked; per-candidate offline-key-events/sheng-aks gates select the offline state service

Procedure ​

  • Validate kernel console first; then bind GopFramebuffer using audited profile ABI and board initialization
  • Test known-frame presentation and brightness separately

Development findings ​

  • Visible UEFI and entry bands establish scanout, not a functioning iOS graphics service
  • The complete baseline now displays BootProgress and runs userspace, but SpringBoard retains signal-5 failures. The photograph does not identify a specific display/GPU dependency as their cause.
  • The current full Venus kernel's original IOMobileGraphicsFamily text matches the sheng reference (2e044ee6...). Its 358-slot Legacy dispatch, constructor chain, nine pure slots, generic override set and newUserClient ABI pass the static audit; no runtime instance, display publication or scanout is claimed.
  • The display archive is now linked into the full kernel. QEMU still reaches _native_owner_root_accepted_checkpoint (1 GiB owned, no timeout) while NativeLegacyDisplay reports stage10, init/start success, probe/parent match, surface_found and an 800x600 GOP mapping. NativeGOPPresenter.ready remains 0; no client, transfer, swap or frame is observed. Some display data-field reads remain unavailable (E22) in the probe.
  • The exact display-enabled image was RAM booted on the phone once. It stopped on a BootProgress page with only top/bottom content; no SpringBoard or desktop appeared, and the panel did not show a presented frame. The image was not retried.
  • The lock screen does not require Metal: the iPadOS 17 qemu and tb128fu records reach CPU-rendered UI (others also do), and both require the offline AppleKeyStore state service. Without it MKBEventsRegister fails, liveactivitiesd crashes at every start, chronod waits on it and SpringBoard on chronod, so the render server never takes the display. Venus showed exactly liveactivitiesd/SpringBoard SIGTRAP, DISPLAY stage10 and SWAP=0.
  • The AppleKeyStoreState component and KeyStoreProbe.cpp are now linked into the display late archive with a deferred initializer; the final kernel's late probe calls the real native_keystore_probe. The service answers offline state queries only and provides no key storage. The 068e4ad1 kernel / 998bc56e boot candidate adds offline-key-events=1 sheng-aks=1 with all other inputs unchanged; phone result pending.
  • Recorded before this repository was published (local evidence artifact): AKS symbols, the real late-probe call, deferred initializer, archive members and sources verified; kernel 068e4ad1 / boot 998bc56e reach the QEMU owner-root and start NativeLegacyDisplay. The offline state service adds offline-key-events=1 sheng-aks=1; no phone result yet.

Completion criteria ​

  • OS display service presents known frames and completes swaps; brightness controls match visible output

Current limits ​

  • iOS composition, display swaps and a frame are still unverified
  • The AKS-only phone run at 150 s still shows SpringBoard SIGTRAP and SWAP=0. The recent-exit tail does not prove liveactivitiesd/watchdogd recovered; earlier pending-result and causal statements are superseded by HID-OS-SERVICES.md.
  • QEMU in the HID candidate verifies AKS/HID initialization before root acceptance, not userspace health or a Venus panel
  • AKS is an offline state/notification service and provides no key storage, keybag or data protection

Next action ​

  • After exact012 image/protected directory/3fixed cache backups/journal scope confirmation, measure invalidation and regenerated scale/UI
  • 012 only accepts unowned UID-2/mode0 for exact shared MG path on Data; preserve original ownership checks for preferences and all backup/error evidence
  • Keep010 normal original chain/IPS and separate actual APFS rename from QEMU medium absence or device UI success

Evidence ​

Input ​

device-verified

Components: ShengHidInput, ShengNovatekTouch, QcomGeniSpi.

Hardware and dependencies ​

  • Venus touch chip/firmware, transport, reset/IRQ pins and physical orientation
  • Selected IOHIDFamily ABI

Configuration ​

  • Format-2 defaults keep phone touch disabled; separately prepared 035 selects STM FTS SPI producer and the retained mainline HID consumer
  • 035 enables sheng-touch-hid=1 and venus-st-custom-hid=0, replaces native_touch stubs, and verifies unique producer symbols at link time

Procedure ​

  • Identify target sensor and bus from vendor DTS/source; implement bounded chip-ID and frame reads
  • Publish consistent coordinates and contact IDs through matching HID ABI

Development findings ​

  • Sheng NT36532 matrix and wiring cannot be inferred from the Mi 11 panel size
  • Actual original IOHIDFamily text, 207-slot IOHIDDevice dispatch, constructors and report ABI match the selected iOS17 kernel
  • 035 vendor audit confirms STMicroelectronics fts_spi, not FocalTech; motion 0x23 and lift 0x33 were reversed in the old codec and its tests
  • 035 fixes reset OUT bit1 clearing, removes writes to the sampled GPIO input level, restores STM ready/scan-echo sequencing and corrects CS hold placement
  • User confirms touch succeeds after the single035 boot, image db727796ae044c84feaf27fcc745357ddaee4ca064e60b7541b655ebac5fb98a; see TOUCH-035-AUDIT.md

Completion criteria ​

  • Correct press/move/release, stable multitouch IDs and physical-button HID events

Current limits ​

  • The user's confirmation does not enumerate every multitouch/edge gesture or physical button
  • 035 does not reuse the old custom-HID QEMU qualification; host OS/SystemOS raw images are absent
  • Prelaunchd counters do not observe later user input

Next action ​

  • Retain the exact035 producer/consumer in GPU candidates;036 link checks both binary hashes
  • Keep historical phone artifacts and the user confirmation in TOUCH-035-AUDIT.md

Evidence ​

GPU ​

device-verified

Hardware and dependencies ​

  • SM8350 Adreno 660, GMU/ZAP firmware, SMMU, power and command submission ABI

Configuration ​

  • build-venus-a660.py links the A660 backend and the separately delayed generic original-IOAcceleratorES adapter against iOS17
  • Mi 11 GMU/SQE/ZAP firmware is hash-checked and injected into the retained ADT;036 mode9/Metal1 and successful035 touch; GPU scanout handoff remains disabled
  • 036 waits for GPU initialization before launchd and sets both Metal discovery properties before service registration
  • 039 aligns the plugin entry with zeta's framebuffer/IOSurface constraints, persistent cache preference and failure reporting; its trust is one static module preserving all2554 original entries
  • 040 adds a bounded plugin-written postlaunch JSONL diagnostic at /private/var/db/venus-metal-040/native.jsonl with root/mobile cache and tmp fallbacks

Procedure ​

  • Audit A660 generation requirements and implement matching platform/backend
  • Verify bounded submissions, fences and known pixels before Metal/UI workloads

Development findings ​

  • Official Adreno740 implements A740/SM8550; Venus uses the SM8350/A660 reference with the Mi 11 ZAP image and the unit's measured fuse value (0 here, not the previously assumed 4)
  • The old stage0/calls0 photographs used pulse-reserved row47 and are stale pixels, not runtime zero evidence. The new diagnostic uses rows24-29 and41 with real repaint regression.
  • Cold-start trace retained a Duo 2 physical address; it now occupies an audited 8192-byte kernel BSS buffer, independent of the Venus ZAP region.
  • The one authorized a660-live phone run reached GMU context Ready, parsed the command DB and built votes, completed the firmware cold start with HFI ready, powered GX, started the GPU context/SQE/ring/CP, ran the ZAP shader to stage 9, returned the expected CP_MEM_WRITE word (05e9a660), published the accelerator and completed two user-client submission rounds (4/4 matches each).
  • The still-retained SpringBoard/watchdogd SIGTRAP exits have no timestamp, so their ordering relative to the successful GPU publish is unknown; publication did not by itself produce a frame, desktop or render server.

Completion criteria ​

  • DMA mappings and fences work; known rendering and OS presentation pass

Current limits ​

  • Historical GMU/GX/CP device results do not establish Metal rendering
  • 039 was booted: touch normal, no performance change and Metal apparently inactive
  • 040 was booted and read back; no plugin diagnostic file was present. This does not distinguish plugin-not-reached from filesystem denial
  • 041 is host-verified but not booted; its prelaunch file is the next actual observation
  • CPU scanout does not by itself imply CPU composition; hardware rendering and display tearing require distinct observations
  • The current boot still uses the iPadOS17 root; iPhone11,8 iOS17.7 root/profile/inputs are prepared but arm64e prelink and matching Data seed are not

Next action ​

  • Boot041 only with separate authorization, then extract /private/var/db/venus-metal-041/startup.json and the040 plugin JSONL
  • Continue zeta ordinary-pointer/arm64e prelink work for the checked iPhone11,8 iOS17.7 kernelcache and build its matching Data seed

Evidence ​

Network ​

planned

Hardware and dependencies ​

  • Venus WLAN endpoint identity, bus, board-data, firmware and interrupt/DMA ownership

Configuration ​

  • Ath12kWifi is not selected without checking the actual endpoint generation

Procedure ​

  • Identify endpoint and firmware family; validate bus/DMA/interrupts; then port protocol and OS network interface

Development findings ​

  • Sheng WCN7850 support is not evidence for the Mi 11 endpoint

Completion criteria ​

  • Scan, association, address configuration and sustained TX/RX pass

Current limits ​

  • WLAN transport and OS service not implemented

Next action ​

  • Identify enabled WLAN/PCIe resources from target inputs

Evidence ​

Collect evidence using the next action.

Audio ​

planned

Hardware and dependencies ​

  • Target ADSP firmware, PAS/GLINK/APR or GPR protocol, codec/amplifier wiring and OS audio ABI

Configuration ​

  • No DSP or audio service selected

Procedure ​

  • Identify firmware protocol and one real route; establish bounded requests and DSP-visible buffers before OS publication

Development findings ​

  • Guide AudioReach/GPR examples require checking the firmware generation and route on Lahaina

Completion criteria ​

  • Known PCM playback/capture, correct format, buffer progression and repeatable stop/start

Current limits ​

  • DSP transport and codec route audit pending

Next action ​

  • Document target DSP protocol and codec topology after root/display bring-up

Evidence ​

Collect evidence using the next action.

Power ​

host-verified

Hardware and dependencies ​

  • Target RPMh/PMIC/clock ownership, battery protocol/units and CPU OPPs

Configuration ​

  • sleep-disabled=1; firmware-inherited resource state for initial single-core boot
  • XNU_SHENG_PMGR=y with the audited original service publication archive; sheng-pmgr=2

Procedure ​

  • Identify resource owners and read-only battery/clock facts; implement measured transitions for dependent drivers

Development findings ​

  • After the timer and ADT fixes, original AMFI panicked with No PMGR at ConfigurationSettings.cpp:235
  • Reused the 21H461 original-PMGR publisher from the pinned sheng source, preserving its exact ABI gates and original nub/methods
  • Real QEMU lifecycle/release, publication/lookup, unsupported-operation and original AMFI call tests passed. Both kernel and final payload reached IOFindBSDRoot.

Completion criteria ​

  • Declared power transitions and battery readings match observations and preserve dependent devices

Current limits ​

  • Phone now passes the previous AMFI stop and reaches root-device discovery. Verification remains limited to logical original-PMGR compatibility; physical clocks, suspend/resume, battery and DVFS are not implemented.

Next action ​

  • Retain the working PMGR path while integrating the next physical-storage dependency

Evidence ​

Image assembly ​

host-verified

Hardware and dependencies ​

  • Profile-pinned XNU 10063.141.1 and iPad7,1/J120 21H461 IPSW/kernelcache
  • Trust-cache bundle, storage ABI and Data seed

Configuration ​

  • Prelinked crypto path with inherited OS root components; 160MiB FAT leaves room in the 192MiB boot partition
  • Root UUID and userdata ranges will be filled from verified inputs, not example values

Procedure ​

  • Use unixnu ipsw info/fetch, build kernel, package, firmware, userdata dry-run, payload and bootimg in dependency order

Development findings ​

  • The previous kernel is a source-only diagnostic build; complete userland requires prelinked Apple services and root/Data volumes
  • The official build now links the generic archives and prelinks 30 executable Apple components plus codeless IOHIDEventDriver
  • Windows-checked-out XnuPrelink patches needed LF restoration; patch contents match their index. High-volume compilation completed in the G-backed WSL filesystem after /mnt/g exceeded the runner timeout.

Completion criteria ​

  • Prelink resolves the selected ABI; payload inputs and userdata geometry agree; boot container round-trips

Current limits ​

  • The latest complete baseline reaches root acceptance and userspace; a functional desktop and Data persistence across reboot remain unverified. Its reused phone-highmem-1g payload is 1 GiB, despite an incorrect pre-boot 3 GiB description.

Next action ​

  • Keep exact kernel/payload/ADT identities and memory settings with each future candidate; preserve the tested control images

Evidence ​

Diagnostics ​

implemented

Hardware and dependencies ​

  • Legacy image hashes, screen observations and RAM-boot transcripts
  • Official guide sequence and matching profile/firmware logs

Configuration ​

  • tools=true, timeout=5, panic_screen=true; no automatic reset selected in board.toml

Procedure ​

  • Save source/configuration and image hashes; observe one checkpoint at a time
  • Integrate Advanced Logger before persistent kernel logging, which depends on storage

Development findings ​

  • Historical stage and photo records are preserved; latest corrections in MG-QUERY-OBSERVATION.md
  • The cache was incorrectly read at allocation length8192; actual DSTREAM EOF7477 yields a valid plist. Cached MainScreenStaticInfo.scale0 and oldP3 artwork answers match across three captures
  • XNU parses plane prefix only with planeNULL; earlier DT0 never established an ADT root placement defect, and the later property2 is not an MG API return
  • Legacy raw tracev3 scans decoded no chunks and lacked boot UUID/PID attribution; file names/object addresses cannot prove which phone run logged a failure
  • Actual MG API helper reports default1/2/7 returns, copied static-info bytes, IOKit properties and boot UUID to one file; no repeated photo sequence required
  • User-supplied haydn pin confirms similar virtual-timer workaround and offers UART/SPI resource organization; it has no lockscreen evidence and refusal-only owner policies

Completion criteria ​

  • Each claimed stage has source/image identity and readable logs or explicit observations

Current limits ​

  • Local overlays have no published revision; QR exporter runtime and persistent XNU logging remain unverified
  • UFS survey intentionally uses the existing panic renderer to stop with read-only register results
  • The CRASH formatter's 100-character chunks can split an address across rows; the photo transcription is manual and the local-symbols LZFSE stream was not decoded.

Next action ​

  • 019 booted once; await loopback/ID and welcome-page feedback. If loop_match1 and ID0, inspect PM8350C L2/L3 vdd/avdd; if loop_match0, fix GENI/pins
  • Metal016 (82d3b33e) supersedes013; actual Metal discovery/GPU rendering unverified.012 welcome baseline retained
  • New Data capture requires manual Android return/readonly scope with explicit1GiB bound; no reset/flash/automatic device retry.

Evidence ​

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

Copyright 2026 UniXNU contributors