UniXNU

English

简体中文

English

简体中文

Appearance

Samsung Galaxy Tab S7+ Wi-Fi (SM-T970, gts7xlwifi), single-core platform bootstrap ​

CakeAL/UniXNU-sm-t970

SM-T970: eight-core BOOT3da265b4 reaches launchd main1 and67 processes, SpringBoard27/runningboardd26; all cores show timer/SGI.512MiB owned window and RAM Data policy verified. Sustained SMP, controlled workload, persistent Data and GUI remain unverified; display ABI host audit passed, backend still disabled.

Source record: porting.toml, 37b439d75ded02edf01c0ed7f357ba0f746a811d.

This page is generated from the device record.

AreaStatus
Configurationhost-verified
Firmware and boothost-verified
CPU and interruptsimplemented
Memory and DMAimplemented
Storage and rootimplemented
Displayplanned
Inputplanned
GPUplanned
Networkplanned
Audioplanned
Powerplanned
Image assemblyplanned
Diagnosticsimplemented

Configuration ​

host-verified

Components: ArmDTPlatform.

Hardware and dependencies ​

  • ADB reports SM-T970, gts7xlwifi, SM8250, board platform kona and hardware qcom.
  • The target OS is iPadOS 17.7.11, build 21H461, matching the local IPSW BuildManifest.plist.
  • SoC feed: FFT-infra/UniXNU-sm8250-common at 166235ec2480ff0992627b7aafa15c65ce6b4efa; reviewed with UniXNU 04b4e558bcded5213c2d802984862dc062f28257.

Configuration ​

  • board.toml uses schema_version=2, name/kit=sm-t970, soc=SM8250, soc_source=sm8250 and os_profile=ipados-17.7.11-21H461.
  • Complete component selection: ArmDTPlatform, ArmCpu, SoftwareAES, XnuPrelink and DarwinBoot. The inherited archive list is preserved.
  • Config fragments are ARM64 common, SM8250 and iPadOS in that order, followed by sm-t970_defconfig. Patch series are arch, soc, os, device; arrays replace inherited arrays.
  • feeds.toml explicitly pins the five selected components in addition to the SoC source. The selection snapshot fixes the reviewed UniXNU revision and ARM64/OS profile hashes.

Procedure ​

  • From the sibling UniXNU checkout run python3.14 ./unixnu defconfig sm-t970_defconfig -D ../UniXNU-sm-t970, fetch the six selected SoC/component sources, then run status --json and tree.
  • Run python3.14 ../UniXNU-sm-t970/scripts/check-platform.py --unixnu . to compare DT/ADT bindings with the captured hardware.

Development findings ​

  • BOOT5385b6ce owner photo03:00:42 shows three pending queues drained, MG done134, BB161, SB75->78, display open6/fail0/swap0. No constrained head means Q cap zero is absent data, not a measured cached limit. v22 reuses exact v21 kernel with existing stack mode1 to locate current BB/SB main waits; host image checks pass, hardware stack result pending.
  • v21 BCM2837 EDGE width fallback uses registered SMP CPU/cluster counts only when E/P counts are both zero. Previous BOOT705d4160 has all eight ADT CPU cluster-type absent (SMP), cached constrained cap0 and callback progress. Actual prepared-function ASan/UBSan tests cover SMP1/8, E/P precedence and non-BCM guard; kernel/prelink/FAT checks pass. BOOT5385b6ce hardware result pending; this is not validated heterogeneous scheduling or desktop. See evidence/display/edge-smp-v21.
  • BOOT cfbd84ba photo confirms stage4: ID/VALID/S2CR accepted, direct FAULT restore200ff succeeded without fallback, allRestored/mappingsUnchanged=1 and GFSR=0. Six context states captured; CB0..4 already configured with FSR400 of unknown age, CB73 SCTLR3ab3a706 is not a verified free bank. No context writes, DMA or UFS commands occurred.
  • Combined field diagnostic BOOT cfbd84ba34fc03b50661b46c9e22fe59c43ba651bca6967da49f1df1ec373e75 prepared from source7ee2918/kernel53e9e68c. Thirteen host tests, input-stable kernel build, independent FAT/arguments/FD checks and DT/ADT check passed. BOOT-only upload exited0; actual VALID/S2CR/restoration/context observations remain pending.
  • Prepared a combined single-slot field qualification after ee45890a: test VALID only under unchanged FAULT policy; test S2CR only with SMR invalid; restore with a bounded Qualcomm-aware fallback if necessary; compare all protected mappings; only then read six context states. No UFS commands, DMA route grants, queue/context/global/clock/SCM writes. Field results and restore flags still require exact-image device observation.
  • BOOT ee45890a device photo confirms stage5, inactive SMR56 ID a5 accepted and restored to zero; S2CR remains200ff, restoreOK and mappingsUnchanged are1, GFSR before/after zero and display04 unchanged. This qualifies only inactive ID-field writes, not VALID/S2CR/context/DMA, and contradicts blanket read-only claims for this measured field.
  • Single-slot SMR ID test BOOT ee45890ab4875987b0e3376b095a64a5d58f1b23177c96b9ea4a996cd8ba9031 prepared from source 41d99e6 and kernel d455be28. Twelve host tests pass; compiled code has exactly two writes to offset958 with DSB after each. Packed FAT/arguments/FD, capacity and DT/ADT checks pass. BOOT-only patched Heimdall upload exited 0; device field acceptance/restoration observation is pending.
  • Prepared a single-slot inactive SMR ID-field test, based on the complete 933a5d77 handoff observation. Requires exact measured geometry, clean GFSR, controller prerequisites, sole display mapping unchanged and slot 56 equal to zero/200ff. Rechecks mappings, writes only invalid ID a5 at offset958, restores zero and compares protected state; both writes fenced. No VALID/S2CR/CB/GCC/HCI/SCM/DMA changes. Outcome is not yet observed.
  • BOOT 933a5d77 device screen is confirmed through END slots=87. Corrected SM8250 GCC gate passes; HCE=1 HCS=10f IS=400, both queue run-stop bits set and both doorbells zero, UTRLBA=9b296000. The sole valid SMR 84020820/S2CR 4 exactly matches the captured display SID 0820 mask 0402; preserve slot 04 and CB4. Candidate residues in invalid slots 02/03 are not active routes. No DMA, SCSI or root read was attempted.
  • Prepared and independently verified BOOT 933a5d776edb2500be5c268b93e64f2cfec53fee6e12cebbb39869a8d7050deb from source 58bdac8 and kernel 147f8d3b; DT/ADT checks passed. Patched Heimdall uploaded BOOT only with exit 0. The new handoff screen and full-table END marker await device observation; no UFS DMA/root success claimed.
  • Prepared t970-ufs-handoff=1: corrected board-local SM8250 clock diagnostics from Samsung gcc-kona.c, removed SM8550-only memory-PHY GDSC reads, capture all bounded raw SMR/S2CR slots and guarded read-only HCI/queue state. No clock, PHY, SCM, SMMU, DMA or queue writes; use the exact tested baseline FD. Host and device results remain separate.
  • User confirmed and photographed the expected T970 SMMUv2 RO stop for BOOT 7f729c2a: sCR0=002d0406 ID0=4c017e57 ID1=6000004a ID2=00005111 GFSR=0; 87 groups scanned, 74 context banks, no candidate match for 0060/00e0/04e0. MMIO observation is confirmed; SMR writability, actual UFS routing, DMA and root reads are not.
  • Resumed at 47b113f. New default diagnostic t970-smmu-report=1 reads the measured SMMUv2 window before any controller/queue/DMA/root setup and stops on a labeled panic. It retires the unflashed all-slot write scan, separates sCR0 from ID0/1/2, honors EXIDS, and does not treat ignored writes or prior SCM markers as proof that secure-world routes are exhausted.
  • Uploaded deliberate after-MMU BRK control 150ed5ff9d73d81b17d3f6d32e609b9a9e42fdfe0397da7c5eea7d62f7ce7b4d, using patched Heimdall, exit 0. The device reset at about 50 seconds, matching the reviewed BRK path; original BOOT restoration is still pending. C startup and console behavior are not exercised.
  • After-MMU BRK control image prepared and extracted from FAT: BRK word, unchanged PE_create_console call, guard bytes, vector branches and preserved IRQ/FIQ slots verified. Eight host tests passed; hardware BRK delivery and the ~50-second timed reset were observed.
  • Added explicit after-MMU BRK control mode to qualify diagnostic execution before C startup. It preserves PE_create_console call bytes, uses the same reviewed fault handlers, and expects the distinct 50-second BRK path. Device execution and fault routing remain unverified until observed.
  • Guarded image e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29 did not reset within 60 seconds. Neither PE_create_console return nor a fault terminal is established. Next is a deliberate after-MMU BRK control to qualify the diagnostic path independently of C startup; no spin-loop diagnosis is claimed.
  • Uploaded guarded PE_create_console return probe e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29, using patched Heimdall, exit 0. Measured outcome and original BOOT restoration remain pending. Fault outcomes classify early paths and do not by themselves identify the failing function.
  • Host checks for guarded PE_create_console return passed: eight tests, verified 112-byte guard code and all modified vector/panic branches inside the actual FAT kernel, with IRQ/FIQ/reserved slots unchanged. Runtime outcome and device BRK control remain unverified.
  • Added an opt-in early-fault diagnostic restricted to PE_create_console return in arm_init on repaired kernel bfb50a1a. It verifies the compiled active-vector selection, preserves IRQ/FIQ/reserved slots, and terminates sync/SError/panic/BRK paths at 20/30/40/50 seconds. This is not a normal kernel, text/register log or device fault result.
  • Repaired PE_init_printf(TRUE) return checkpoint was not observed (f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7). User photo shows retained firmware/loader text and entry bars, not a confirmed XNU text log. Restored PE_create_console may stop earlier; old-kernel gc_enable localization cannot be assumed for this new kernel.
  • Uploaded repaired-console PE_init_printf(TRUE) after-return probe, image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7, using patched Heimdall, exit 0. Device return result, text rendering and original BOOT restoration are pending; transfer alone does not verify the repair.
  • Repaired kernel bfb50a1a009f4dd08d54cb94d6187d768c7a5ef976427abd235756874f38473c compiled, linked and prelinked successfully. Mach-O checks verify PE_init_printf(FALSE) immediately precedes unconditional PE_create_console. Build configuration checks passed for 61 patches and 19 pinned modules; device return probe is pending.
  • check-build-config.py now excludes .DS_Store from script-content comparison, matching its existing source-cleanliness policy. Host metadata from framework and device can share that filename; real script bytes remain checked.
  • Replaced the experimental skip-console patch with t970-console-bootstrap.patch: arm_init now always installs PE_init_printf(FALSE) before PE_create_console, restoring callback and console/lock setup rather than continuing with uninitialized console state. Kernel rebuild and prelink passed; the final Mach-O has adjacent unconditional PE_init_printf(FALSE) and PE_create_console calls. Device return checkpoint remains pending.
  • Committed-source isolated probe build passed at 6a3ae24fba8bc4cb44dcdb0898b92582751a36b9; board defaults and source kernel hashes are unchanged.
  • Step 7 continuation preserves the handed-off minimal boot configuration and removes persistent entry-probe settings from board.toml. scripts/build-entry-probe.py supplies one in-memory probe override and writes a new ignored artifact directory per experiment.
  • All seven local Step 3 repository requirements passed at 18d3a77cd98f47ee42aa1f95d6584d22c3a13a18; source pins and template files are complete and the example marker is removed. Runtime milestones remain separate.
  • The final reviewed framework commit is 194aae294c1107e791f4f74b2be371a391ac6bc4; in addition to v2/raw packing it normalizes the upstream shim image_size to include the 112-byte shim while preserving the firmware copy size. Eight regression cases pass.
  • Step 3 completion replaces the initial staging audit: real T970 firmware config/DSC/FDF/FD inputs now exist; stock asset hashes, disabled peripheral descriptions and exact firmware source pins are recorded. board.example is removed to enable host builds; hardware boot remains unverified.
  • The framework pin advances to 7ebc585543fd1a89e1d47d17442899ab61978f9a for tested raw-kernel/Android-v2 separate-DTB packing. The component catalog, ARM64/OS profile hashes, SoC and all five component pins are unchanged.
  • The official examples/device structure is present, retaining the existing hardware inventory and scripts. Board-specific names replace the template identity.
  • The resolved bootstrap contains five canonical components, three configuration fragments and 61 ordered patches, including both SM8250 CPU patches.
  • Kernel archive recipes remain inherited from ARM64. Component choice is configuration work, not evidence that any XNU driver has executed.
  • Host check passed against committed platform inputs at 5cab8f372a491af149ce27df02d918f6ac8cddba; configuration resolution, five component pins and all 61 patch paths are recorded in evidence/platform-bootstrap.
  • Step 2 review reuses the existing ARM64, SM8250 and iPadOS 17.7.11 support. The five selected components declare no catalog dependencies; no new OS profile is created.
  • The SM8250 soc.toml at the chosen revision contains only SoC metadata, despite its README saying it selects ArmCpu/ArmDTPlatform. This board therefore retains the complete explicit component selection.
  • The platform checker now rejects framework/profile drift and disagreement among reviewed component pins, device feeds, catalog ABI scope and actual clean source checkouts.
  • Step 2 verification passed against 25f9797275c93b227585ab4403923da34c4fec19 with explicit six-source feeds and frozen framework/profile inputs. The selected minimal support and pending hardware/ABI work meet the source-selection deliverable.
  • Step 3 seven-item audit at device configuration 6d3012ab3fbbbb3d4517d1a4ed4ccb87b795a028: all 13 template files are present and tracked; identities, renamed entry paths, three config fragments, four series and eight inherited archive recipes agree. Firmware config/DSC/FD and real handoff inputs remain incomplete.
  • At the original audit, the 13-area check passed while Step 3 inputs remained incomplete and example was true. The completion update above supersedes that configuration.
  • board.toml [payload] tools is now true, so the generated boot menu carries Tools, and the platform checker verifies the firmware log-exporter wiring that backs it. Host builds, not a menu image, confirm this configuration change; the device remains unbooted.
  • Step 4 ran defconfig/fetch/status/tree. unixnu fetch rewrote unixnu.lock with all nine resolved sources (eight Apple/EDK references plus sm8250 at 166235ec...), and status resolves arch arm64/4KiB, the pinned SM8250 feed, the iPadOS profile and this board.toml in that order; 19 modules and 61 patches (56 arch, 2 SoC, 3 OS, 0 board) agree with the declared series, and build_config is empty because no unixnu.local.toml exists yet.
  • Step 7 local inputs are configured outside version control: the IPSW lives at ../ipsw per the requirements rule, kernelcache.decompressed matches the profile pin f18b4df8..., the accepted trust-cache bundle 7416ca4f... is referenced from the framework build directory, and the platform seed is the local test value 0x534d543937303031.
  • board.toml now points the OS layer of patch_series at device:patches/xnu/os-series so the two required XnuPrelink ABI patches still apply while zzz-boot-progress.patch, which requires sheng's XNU_SHENG_PMGR hook, is omitted. The applied set is 60 patches.
  • The measured boot partition is 71303168 bytes, so board.toml [payload] size_mib dropped from 192 to 56; the 192 MiB payload could never be flashed. 56 MiB holds the 51.9 MB prelinked kernel plus ADT and trust cache with about 8 MB margin.
  • board.toml [payload] now passes t970-novc and enables panic_screen for the bring-up images; both are diagnostic defaults that must be revisited once a real console exists.
  • The diagnostic tree at commit 66abd1f carries the t970-novc boot argument, panic_screen and the three console-bypass patches; the checkpoint evidence revisions name that commit in full.
  • The diagnostic kernel still boots with t970-novc and panic_screen. The next config change is the PMGR bridge: CONFIG_XNU_SHENG_PMGR=y, a build-platform-power.py archive entry and a sheng-pmgr=2 boot argument, following the marble-milacy reference that targets the same 21H461 kernelcache.
  • Enabled CONFIG_XNU_SHENG_PMGR=y in sm-t970_defconfig, added the PMGR archive and sheng-pmgr=2 boot argument, and regenerated .config before the kernel build.
  • feeds.toml now pins the SM8250 UFS fork and unixnu.lock records it, but no component selects it; board.toml and sm-t970_defconfig remain in their buildable pre-UFS state.
  • board.toml now carries the measured T970 [userdata] geometry and the root-volume UUID for the ADT; the UFS component selection, storage archives and native-ufs boot arguments used for the size measurement were reverted so the default build stays inside the BOOT partition.
  • board.toml selects ShengUfs and VirtioMmioBlock, adds the empty-policy VerifiedRoot archive entry, and boots with sheng-pmgr=2, native-ufs-root=1 and no stream override (default 0x60); sm-t970_defconfig enables CONFIG_XNU_NATIVE_UFS and CONFIG_XNU_VERIFIED_ROOT_PROBE. The temporary MassStorage boot-option firmware patch was reverted.
  • board.toml now passes t970-smmu-dump=1 together with native-ufs-root=1 for the SMMU table diagnostic; the flag only triggers the arm_init dump and must be removed once the UFS stream is resolved.
  • board.toml keeps native-ufs-root=1 with the default stream (no override) and selects component:ShengUfs only; the temporary MassStorage, smmu-dump and local-archive experiments are not part of the default boot path.
  • The build currently selects the board-local ShengUfs archive (component removed, zz-build-shengufs-local.py), enables CONFIG_XNU_NATIVE_UFS/VERIFIED_ROOT_PROBE and boots with native-ufs-root=1 plus t970-ufs-auto-stream=1. The kernel links and produces a 62.7 MB boot image.
  • board.toml passes t970-ufs-no-smmu=1 for the last experiment; it is a diagnostic switch alongside native-ufs-root=1 and does not enable any storage publication.
  • board.toml adds {uefi}/Silicon/Samsung to [firmware] packages so SamsungPkg resolves; the boot image continues to use the RELEASE firmware target.
  • board.toml currently boots with t970-ufs-image=1 (the read-only survey image) and panic_screen; the survey BOOT is c404ce26 and the image source revision is 09bff63.

Completion criteria ​

  • A board.toml with matching device identity resolves the selected SoC and OS profiles and pinned sources.

Current limits ​

  • Repository completion and removal of the example marker permit host builds; they do not certify a UEFI launch or an iPadOS boot.
  • Apple kernelcache/private ABI, trust-cache, Data seed and XNU image compilation remain separate later-stage work.

Next action ​

  • Continue with audited SM8250 storage inputs and isolated images; retain exact source/image hashes and hardware observations.

Evidence ​

Firmware and boot ​

host-verified

Components: DarwinBoot.

Hardware and dependencies ​

  • Stock bootloader property: T970ZCU2CVK1.
  • Stock build fingerprint: samsung/gts7xlwifizc/gts7xlwifi:12/SP2A.220305.013/T970ZCU2CVK1:user/release-keys.
  • Boot properties report ro.boot.flash.locked=0, ro.boot.verifiedbootstate=orange and ro.boot.warranty_bit=1.
  • Live DT /psci declares arm,psci-1.0 with method smc; CPUs declare enable-method psci.
  • Read-only inspection of boot and recovery headers reports ANDROID! magic, header version 2 and page size 4096 bytes.

Configuration ​

  • board firmware.config=gts7xlwifi, dsc=gts7xlwifiPkg/gts7xlwifi.dsc and fd=Build/gts7xlwifiPkg/{target}_CLANGPDB/FV/SILICIUM_UEFI.fd point to the prepared pinned Mu-Silicium tree.
  • prepare-uefi.py validates each pinned submodule and stock input hash, then stages the committed overlay; build-uefi-candidate.py exercises the official firmware builder without booting.

Procedure ​

  • The existing Android shell transcript records getprop ro.bootloader and getprop ro.build.fingerprint.
  • Collect selected boot properties, the live DT and the first 4096 bytes of boot/recovery with the inventory script; only parsed header fields are saved.

Development findings ​

  • BOOT 933a5d77 device screen is confirmed through END slots=87. Corrected SM8250 GCC gate passes; HCE=1 HCS=10f IS=400, both queue run-stop bits set and both doorbells zero, UTRLBA=9b296000. The sole valid SMR 84020820/S2CR 4 exactly matches the captured display SID 0820 mask 0402; preserve slot 04 and CB4. Candidate residues in invalid slots 02/03 are not active routes. No DMA, SCSI or root read was attempted.
  • Prepared and independently verified BOOT 933a5d776edb2500be5c268b93e64f2cfec53fee6e12cebbb39869a8d7050deb from source 58bdac8 and kernel 147f8d3b; DT/ADT checks passed. Patched Heimdall uploaded BOOT only with exit 0. The new handoff screen and full-table END marker await device observation; no UFS DMA/root success claimed.
  • Prepared t970-ufs-handoff=1: corrected board-local SM8250 clock diagnostics from Samsung gcc-kona.c, removed SM8550-only memory-PHY GDSC reads, capture all bounded raw SMR/S2CR slots and guarded read-only HCI/queue state. No clock, PHY, SCM, SMMU, DMA or queue writes; use the exact tested baseline FD. Host and device results remain separate.
  • User confirmed and photographed the expected T970 SMMUv2 RO stop for BOOT 7f729c2a: sCR0=002d0406 ID0=4c017e57 ID1=6000004a ID2=00005111 GFSR=0; 87 groups scanned, 74 context banks, no candidate match for 0060/00e0/04e0. MMIO observation is confirmed; SMR writability, actual UFS routing, DMA and root reads are not.
  • Prepared BOOT 7f729c2a6ee8ee11b6eb5d4ff7ec23171b261854151578e36737d866a62391e2 from source 23d54b9 and kernel cca9bbb8. Independent FAT/kernel/arguments and packed FD checks passed, as did nine host tests and CPU0 DT/ADT checks. Patched Heimdall uploaded BOOT only with exit 0; device screen/register observation is pending. This is not a UFS/DMA/root-volume success.
  • Resumed at 47b113f. New default diagnostic t970-smmu-report=1 reads the measured SMMUv2 window before any controller/queue/DMA/root setup and stops on a labeled panic. It retires the unflashed all-slot write scan, separates sCR0 from ID0/1/2, honors EXIDS, and does not treat ignored writes or prior SCM markers as proof that secure-world routes are exhausted.
  • The prepared SEC patch rebuild passed; built FV inspection confirms TzDxe/PILDxe/PILProxyDxe absent and AdvancedLogDxe present.
  • The handed-off runtime workaround excludes TzDxe, PILDxe and PILProxyDxe from DSC/FDF dispatch: the handoff reports TEE and missing-UFS partition assertions before the menu. The SEC x0 HOB patch is now hash-checked and automatically prepared. These reports do not certify TEE/PIL functionality.
  • Handoff follow-up: prepare-uefi.py now applies or recognizes the SEC x0-to-HOB patch using its exact patch hash and four pre/postimage hashes; clean upstream application and a second idempotent run passed. The cached Mu source modifications are therefore reproducible rather than implicit workspace state.
  • The normal unixnu build firmware command passed on committed sources; the 3 MiB FD contains all four UniXNU/DarwinBoot modules plus DiskIo, FAT and Unicode collation (7 checked modules among 91 FV files).
  • A T970-specific overlay selects the pinned Kona support, original numeric configuration and a nonoverlapping 44-region map derived from the stock 45-region map; Android SEC LOG scratch is omitted because it overlaps FV/FD/stack and Mu would halt on it.
  • 44 vendor modules use 84 exact PE32/DEPEX/RAW inputs from this T970 XBL. Vendor UFS/USB DMA dispatch is omitted from the CPU0/initrd candidate.
  • DSC and FDF include UniXNU, UniXNUDxe, DarwinBoot and UniXNURamDiskDxe; DiskIo, FAT and Unicode collation are present. The actual EDK build produced a 3145728-byte FD before this implementation commit; a committed-source build report is the next check.
  • Read-only XBL extraction validates FV/FFS header checksums and decompresses its gzip-guided volume. The snapshot has 121 FFS records, 94 PE32 assets and 45 platform regions. Stock FD is 0x9fc00000+0x300000; stack is 0x9ff90000+0x40000. These constants do not verify a new UEFI launch.
  • The follow-up read-only inventory hashes 43 stock assets (6 GPU, 8 Wi-Fi, 2 Bluetooth, 27 audio). This expands the original two-file inventory; none is selected by the CPU0 bootstrap.
  • The archived properties identify an Android 12 stock build and bootloader T970ZCU2CVK1.
  • The running Android environment has Magisk root and reports an unlocked/orange boot state; this does not verify a UEFI launch method.
  • The template firmware integration slots are retained as a table with only known package roots; board.example=true prevents treating the staging configuration as boot-ready.
  • Reviewed Project-Silicium/Mu-Silicium commit 4bd8ae83bf37de41777f19e0777db70f59383a6d: KonaPkg and Samsung r8qPkg exist, but no T970/gts7xlwifi platform/config was found in the inspected upstream directories.
  • The r8q reference declares Android header v1 and 1080x2400 display geometry, while the T970 inventory reports header v2 and 2800x1752 modes. No reference-board boot parameters or firmware path were adopted.
  • Step 3 audit confirms firmware.config, firmware.dsc and firmware.fd are absent. Only package search roots are configured; the known GPU manifest entries are inventory, not a complete enabled-firmware integration.
  • The firmware log exporter is now wired: AdvancedLogDxe (FFS 8D4E7F50-3A2C-4C9A-9E1B-50C4C8472D41) is in the DSC Components and FDF, AdvancedLoggerAccessLib and QrEncoderLib come from Common/Mu, PcdUniXNUDeviceModel is gts7xlwifi, and board [payload] tools adds the Tools entry.
  • AdvancedLoggerLib is mapped for SEC (PeilessArm), DXE_CORE, DXE_DRIVER, DXE_RUNTIME_DRIVER, UEFI_DRIVER and UEFI_APPLICATION, with AdvancedLoggerHdwPortLib over SerialPortLib and BaseDebugLibAdvancedLogger only in DEBUG. PcdAdvancedLoggerBase stays 0, so the DXE Core library reserves the 4 MiB buffer instead of a fabricated fixed address; SEC and DEBUG screen output still reach FrameBufferSerialPortLib.
  • A DEBUG rebuild with the exporter produced a 3145728-byte FD containing 92 FV files, including the exporter GUID, and FVMAIN.inf lists it. The earlier 91-file, 6108b542... FD is superseded.
  • Committed-source rebuild with the exporter produced a 3145728-byte FD (sha256 94709bbe5b7ecc1a78cb6041889258d9c537b096ae04bce41252ad57f4d8d30a) whose FV holds 92 files and the exporter FFS.
  • Step 5 records the two tree inputs as distinct artifacts. The bootloader FDT captured read-only from /sys/firmware/fdt is 837154 bytes (86c14aa3...) with 4533 nodes, 43 reserved-memory entries and a /chosen carrying bootargs, kaslr-seed and initrd range; two captures are byte-identical. The blob stays in ignored storage because /chosen holds identity and boot state; only hashes, structure, memory ranges and property names are archived.
  • scripts/check-hardware-description.py rebuilds the board DTS and ADT with artificial identity 1, checks dram-base/size, CPU0 affinity and 19.2 MHz timebase, GIC registers and stride, rejects a firmware DTB equal to the board build or a board DTS carrying /chosen, and checks the firmware DSC/FDF plus the pinned base configuration for DiskIo, FAT and Unicode collation.
  • The payload command was probed at the Step 5 commit: it reaches the payload step and stops only at the missing kernel/kernel.macho, so the board DTS/ADT and OS-profile side is not the blocker; the XNU kernel build is the next required input.
  • The board package now carries Sm8250UfsPhyTables.h, the extracted SM8250 QMP UFS PHY register sequences, but the platform DSC still does not build any UFS DXE; no firmware image has been rebuilt or booted with it.
  • The T970 firmware now builds Samsung UfsDxe plus a board PlatformUfsLib: the SM8250 QMP UFS PHY sequences are replayed after mapping GCC, PHY, controller and ICE windows into the UEFI page tables. On hardware the stage markers reach the final green pair (PHY replay and PCS ready), then the device falls back to the Samsung bootloader warning screen before XNU starts.
  • GCC block writes hang the non-secure bus, so the board library skips them and relies on ABL's existing UFS power; the workspace marker sequence (magenta/orange/cyan/teal/yellow/orange/purple/blue/deep blue/green/green) is the reproducible evidence path for this bring-up.
  • The board PlatformUfsLib now also issues QCOM_SCM_SVC_MP / MP_RESTORE_SEC_CFG over SMC (0x02000000 | (svc<<8) | cmd, arginfo 2) after the PHY succeeds. On hardware the first call (device_id 0) returns non-zero (red marker) and the second does not complete, so the secure monitor does not restore the UFS SMMU configuration through this interface.

Completion criteria ​

  • A board-specific UEFI image starts reproducibly and produces an accessible boot log.

Current limits ​

  • UEFI launch, actual GOP/stride/pixel format, initrd discovery, runtime memory allocations and boot-services exit are untested. The running boot image is Magisk-modified.
  • A host-built T970-specific candidate is now selected; it is not an upstream-certified or device-verified T970 port.

Next action ​

  • Audit T970 handoff against the public T733 vendor integration and umi inherited-state path using T970-owned inputs; old experimental SCM/PHY conclusions are not qualified.

Evidence ​

CPU and interrupts ​

implemented

Components: ArmCpu.

Hardware and dependencies ​

  • Android exposes CPUs 0-7. Live DT affinity values are 0x000, 0x100, 0x200, 0x300, 0x400, 0x500, 0x600 and 0x700.
  • CPU frequency policies group CPUs 0-3, 4-6 and 7, with reported maxima 1804800, 2419200 and 3091200 kHz respectively.
  • GICv3 distributor is 0x17a00000 + 0x10000; redistributor region is 0x17a60000 + 0x100000 with stride 0x20000.
  • The arm,armv8-timer DT node declares clock-frequency 19200000 Hz.

Configuration ​

  • The board DTS includes pinned sm8250.dtsi, enables cpu0 and explicitly disables cpu1-cpu7. payload.kernel_args includes cpus=1.
  • ArmCpu and ArmDTPlatform are selected with their inherited archive recipes; timebase 19200000 and GIC resources come from the reviewed SoC DTSI.

Procedure ​

  • Collect /proc/cpuinfo, online/present CPU lists, cpufreq policies, /proc/interrupts and the live DT using the inventory script.

Development findings ​

  • BOOT5385b6ce owner photo03:00:42 shows three pending queues drained, MG done134, BB161, SB75->78, display open6/fail0/swap0. No constrained head means Q cap zero is absent data, not a measured cached limit. v22 reuses exact v21 kernel with existing stack mode1 to locate current BB/SB main waits; host image checks pass, hardware stack result pending.
  • v21 BCM2837 EDGE width fallback uses registered SMP CPU/cluster counts only when E/P counts are both zero. Previous BOOT705d4160 has all eight ADT CPU cluster-type absent (SMP), cached constrained cap0 and callback progress. Actual prepared-function ASan/UBSan tests cover SMP1/8, E/P precedence and non-BCM guard; kernel/prelink/FAT checks pass. BOOT5385b6ce hardware result pending; this is not validated heterogeneous scheduling or desktop. See evidence/display/edge-smp-v21.
  • UI-job-v8 kernel049897a9/BOOT1939b59d adds PID1 namei basename lookup counts and latest matching open error for BB/SB plists using existing kernel path copies only. Actual helper ASan tests cover filters/relative paths/errors/ring/bounds. Job lookup is not parsed/imported job proof; path/return association is best effort. Same eight-core60-second display diagnostics and policy. Hardware outcome pending; see evidence/display/ui-job-v8.
  • BOOT3da265b4 target60 owner photo confirms main1/n67/cpu8/sec7, SpringBoard27/runningboardd26, Data0/policy0/stage4 and all-core positive timer/SGI snapshots. Backboardd not observed; free0x183 excludes reclaimable memory, not sole OOM proof. Sustained runtime, controlled CPU workload and desktop remain unverified. See runtime-cache60/device-result.json.
  • Target45 BOOTbe219c43 owner photo confirms cpu8/sec7/main0/n2, blocks729210 and108 completed cache calls. Latest openat successfully opens final numbered subcache52.dyldlinkedit; recent open/fcntl errors0. Last signature-registration return and shared mapping not yet observed. Same-kernel target60 BOOT3da265b4 prepared, independently checked and uploaded BOOT-only with exit0; see runtime-cache45/device-result and runtime-cache60. No authorization changes or completed-main claim.
  • Target30 BOOT79a949b6 shows cpu8/sec7/main0/n2, blocks546747 and82 completed cache syscalls, latest openat subcache39 with error0; recent fcntl97 signature registration also succeeds. Host SystemOS inventory has52 numbered subcaches;40..52 logical bytes989839360. Same-kernel target45 be219c43 prepared to observe mapping/main progress; no authorization or signature behavior changes.
  • Same-kernel eight-core target20 image0dba26bc reproduces cpu8/sec7/secondary phase7/C4 and main0/n2. Verified blocks371515 versus189168 at target10 suggests continued reading across comparable boots. CPU5 timer2 observed; CPU4/6/7 timer0. Added optional compact runtime view of existing completed PID1 cache syscalls at target30 to localize startup without changing authorization or syscall behavior.
  • BOOTd95c45d9 owner photo confirms8 available CPUs/sec7, every secondary phase7/PSCI0/fail0/C4, and positive SGI counts on all8 cores (54/62/59/26/6/24/2/1,total234). At target10, timers onCPU4/5/7 are0 and main0/n2. Eight-core startup and per-core SGI reception observed; all-core timer workload, sustained SMP, isolated bidirectional IPI and userspace remain unverified.
  • BOOT1c778e4b owner photo confirms actual SGI reception on both CPUs:44/102,total146, CPU1 check99->102 after inline asm separator repair. Fixed-sender bidirectional isolation and sustained userspace remain unverified. Owner explicitly requested skipping4-core: same-kernel8-core BOOTd95c45d9 prepared, independently checked and uploaded; device result pending. Non-atomic sec aggregate is not sole core-online evidence.
  • Actual old ArmCpu object/kernel lacked ICC_SGI1R_EL1 writes: semicolon-separated multi-instruction inline asm emitted only initial instruction under reviewed Apple arm64 assembler. Independent componentb5f9775 uses explicit newlines in17 strings. Old kernel negative control rejects; new object/kernel/payload checks confirm SGI writes/barriers, GIC/timer ISBs, DAIF and counter reads. BOOT1c778e4b uploaded with explicit local component override; default catalog/feed9066 unchanged. Hardware delivery pending; unused redistributor experiment not flashed.
  • BOOT7e60f7c9 after owner reboot reproduces two CPUs/phase7/timers and matching TTBR1. Explicit SGI0 test observed attempt1/sent2/test1/recv0/cpu1=0>0 and target redistributor found1. Standard SGI delivery remains unqualified; sender thread is not pinned, so a future single receive would not independently prove bidirectional IPI. Do not promote8-core yet.
  • BOOT6fe3e519 owner photo confirms cpu2/sec1, secondary phase7/C4, per-core timers22925/22334 and matching TTBR1=c4325000. This qualifies two-core startup/timers after reset publication; both SGI counts remain0. Added optional one-SGI0/100ms-yield plus existing read-only GIC snapshot before expanding core count. Actual IPI and8-core unverified.
  • BOOT36c2f602 device records CPU1 pre-branch TTBR1=0 versus primary c4325000. T733 ArmCpu55cc0617 explicitly cleans cpu_ttep and sysreg_restore; previous comparison missed these ranges. Added an opt-in board qualification clean of these exact live objects in cpu_start before platform wake, preserving values/default behavior. Runtime fix remains to be verified.
  • BOOTb44e4108 owner photo observes CPU1 milestone9 after MMU enable, with main0/n2 at target10. Added pre-branch register capture and first high-entry store through the already-used physical record alias to distinguish fetch from diagnostic-address failures. Actual transition and hardware page tables remain unverified.
  • BOOT95accf53 owner photo confirms CPU1 entry3 (matched CPU data and reached common_start boundary); C marker4 not seen. Target10 snapshot main0/n2 is earlier than old120 samples. Added secondary-only common/TCR/table/SCTLR/trampoline markers without changing CPU setup values. See entry-trace/device-result.json and MMU trace records.
  • Two-core BOOT9d4dc888 observed main1 and106 processes but one CPU available; CPU1 phase4/PSCI0/timer0/SGI0. Reset table, CPU1 affinity and reset handler match. Entry execution remains unconfirmed. Added four diagnostic entry milestones and shortened future target wait to10 seconds; default CPU0 unchanged,8-core not uploaded. See evidence/cpu and docs/smp-bringup.md; source/build checks are not hardware SMP qualification.
  • Uploaded deliberate after-MMU BRK control 150ed5ff9d73d81b17d3f6d32e609b9a9e42fdfe0397da7c5eea7d62f7ce7b4d, using patched Heimdall, exit 0. The device reset at about 50 seconds, matching the reviewed BRK path; original BOOT restoration is still pending. C startup and console behavior are not exercised.
  • After-MMU BRK control image prepared and extracted from FAT: BRK word, unchanged PE_create_console call, guard bytes, vector branches and preserved IRQ/FIQ slots verified. Eight host tests passed; hardware BRK delivery and the ~50-second timed reset were observed.
  • Prepared isolated BRK #0 after-MMU-control image 150ed5ff9d73d81b17d3f6d32e609b9a9e42fdfe0397da7c5eea7d62f7ce7b4d; the FAT kernel was independently extracted and the probe instruction at 0xfffffff0073f3370 matches the intended probe. The device reset at about 50 seconds, confirming the deliberate BRK reached the bounded fault terminal.
  • Added explicit after-MMU BRK control mode to qualify diagnostic execution before C startup. It preserves PE_create_console call bytes, uses the same reviewed fault handlers, and expects the distinct 50-second BRK path. Device execution and fault routing remain unverified until observed.
  • Guarded image e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29 did not reset within 60 seconds. Neither PE_create_console return nor a fault terminal is established. Next is a deliberate after-MMU BRK control to qualify the diagnostic path independently of C startup; no spin-loop diagnosis is claimed.
  • Uploaded guarded PE_create_console return probe e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29, using patched Heimdall, exit 0. Measured outcome and original BOOT restoration remain pending. Fault outcomes classify early paths and do not by themselves identify the failing function.
  • Host checks for guarded PE_create_console return passed: eight tests, verified 112-byte guard code and all modified vector/panic branches inside the actual FAT kernel, with IRQ/FIQ/reserved slots unchanged. Runtime outcome and device BRK control remain unverified.
  • Prepared isolated _PE_create_console after-return image e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29; the FAT kernel was independently extracted and its branch at 0xfffffff0079b619c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Added an opt-in early-fault diagnostic restricted to PE_create_console return in arm_init on repaired kernel bfb50a1a. It verifies the compiled active-vector selection, preserves IRQ/FIQ/reserved slots, and terminates sync/SError/panic/BRK paths at 20/30/40/50 seconds. This is not a normal kernel, text/register log or device fault result.
  • Repaired PE_init_printf(TRUE) return checkpoint was not observed (f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7). User photo shows retained firmware/loader text and entry bars, not a confirmed XNU text log. Restored PE_create_console may stop earlier; old-kernel gc_enable localization cannot be assumed for this new kernel.
  • User observation for _PE_init_printf after-return image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7: no automatic reset observed; checkpoint not established.
  • Uploaded repaired-console PE_init_printf(TRUE) after-return probe, image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7, using patched Heimdall, exit 0. Device return result, text rendering and original BOOT restoration are pending; transfer alone does not verify the repair.
  • Repaired kernel bfb50a1a009f4dd08d54cb94d6187d768c7a5ef976427abd235756874f38473c compiled, linked and prelinked successfully. Mach-O checks verify PE_init_printf(FALSE) immediately precedes unconditional PE_create_console. Build configuration checks passed for 61 patches and 19 pinned modules; device return probe is pending.
  • Prepared isolated _PE_init_printf after-return image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7; the FAT kernel was independently extracted and its branch at 0xfffffff00794a01c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Human timing of about four seconds for console-state image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341 supports gc_initialized low bit 0 and PE_putc NULL before gc_enable. This supports missing console initialization under the experimental skip patch, but does not identify the exact faulting instruction.
  • Replaced the experimental skip-console patch with t970-console-bootstrap.patch: arm_init now always installs PE_init_printf(FALSE) before PE_create_console, restoring callback and console/lock setup rather than continuing with uninitialized console state. Kernel rebuild and prelink passed; the final Mach-O has adjacent unconditional PE_init_printf(FALSE) and PE_create_console calls. Device return checkpoint remains pending.
  • Uploaded console-state BOOT image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341, using patched Heimdall, exit 0. Measured reset timing and original BOOT restoration are pending. Upload and host tests do not establish runtime gc_initialized or PE_putc values.
  • The console-state FAT kernel was independently extracted; the complete 112-byte state code SHA256 matches its generator report. All six host tests passed, including ARM64 execution of the four timing codes and read-only checks. This does not establish tablet state or timing.
  • Prepared isolated _gc_enable before-call image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Added an opt-in, hash-pinned console-state diagnostic copy at the confirmed gc_enable call site. It reads gc_initialized and PE_putc without invoking gc_enable, encodes their combination as 4/14/24/34-second terminal waits, and rejects unknown input kernels. This is not text logging or a device state result.
  • The user confirmed the gc_enable before-call reset (59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9), whereas its after-return probe did not reset. The unconfirmed path is inside gc_enable. Next diagnostic reads gc_initialized and PE_putc at that known reachable call site; no runtime NULL value is claimed yet.
  • User observation for _gc_enable before-call image 59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9: automatic reset observed; checkpoint reached.
  • Uploaded the isolated gc_enable before-call probe inside vcattach, image 59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _gc_enable before-call image 59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The gc_enable after-return probe in vcattach did not reset (a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737). Earlier vcattach lock initialization return is confirmed. Next test is immediately before the same gc_enable call to distinguish an internal failure from its preceding path; neither a NULL callback nor a specific exception is established.
  • User observation for _gc_enable after-return image a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737: no automatic reset observed; checkpoint not established.
  • Uploaded the isolated gc_enable after-return probe inside vcattach, image a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _gc_enable after-return image a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The user observed automatic reset after arm_usimple_lock_init in vcattach with image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561. This establishes vcattach entry and lock initialization return, but not screen acquisition or message replay. The next checkpoint is after gc_enable inside vcattach.
  • User observation for _arm_usimple_lock_init after-return image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561: automatic reset observed; checkpoint reached.
  • Uploaded the isolated arm_usimple_lock_init after-return probe inside vcattach, image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _arm_usimple_lock_init after-return image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4894 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • PE_init_printf after-return checkpoint inside PE_init_iokit was not observed with image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4. The next unconditional internal checkpoint is after arm_usimple_lock_init in vcattach, before its graphics-state checks. Failure type and exact instruction remain unknown.
  • User observation for _PE_init_printf after-return image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4: no automatic reset observed; checkpoint not established.
  • Uploaded the isolated PE_init_printf after-return probe inside PE_init_iokit, image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _PE_init_printf after-return image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4; the FAT kernel was independently extracted and its branch at 0xfffffff00794a01c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The InitIOKit before-call probe inside PE_init_iokit did not reset (977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270). PE_init_iokit entry is confirmed by the earlier probe, so the next boundary is its first call PE_init_printf(TRUE), which tail-calls vcattach in this exact binary. No crypto-provider failure is established.
  • User observation for _InitIOKit before-call image 977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270: no automatic reset observed; checkpoint not established.
  • Uploaded the isolated InitIOKit before-call probe inside PE_init_iokit, image 977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _InitIOKit before-call image 977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270; the FAT kernel was independently extracted and its branch at 0xfffffff00794a390 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The user confirmed automatic reset before PE_init_iokit with image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421, while the after-return image did not reset. This brackets the unconfirmed path inside PE_init_iokit; the exact failing instruction and fault type remain unknown.
  • User observation for _PE_init_iokit before-call image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421: automatic reset observed; checkpoint reached.
  • Uploaded the isolated PE_init_iokit before-call BOOT image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421 using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _PE_init_iokit before-call image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421; the FAT kernel was independently extracted and its branch at 0xfffffff00798ca8c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • External zeta/SM8350 records describe a PE_init_iokit failure caused by a NULL crypto provider and a version-specific fix; T970 uses prelinked crypto and has no runtime pointer result. See docs/related-bring-up.md; no root cause is inferred from similarity.
  • User observation for _PE_init_iokit after-return image 9b0f8f683db2802cefc30287b206ac33f7c0d3acf480457b9447c53afdf947dd: no automatic reset observed; checkpoint not established.
  • Prepared isolated _PE_init_iokit after-return image 9b0f8f683db2802cefc30287b206ac33f7c0d3acf480457b9447c53afdf947dd; the FAT kernel was independently extracted and its branch at 0xfffffff00798ca8c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • User observation for _sched_startup after-return image 4a5e423389efb142c3c5b8b5afedf98dcc59c7b0db1a29782805c95d8a298721: automatic reset observed; checkpoint reached.
  • Prepared isolated _sched_startup after-return image 4a5e423389efb142c3c5b8b5afedf98dcc59c7b0db1a29782805c95d8a298721; the FAT kernel was independently extracted and its branch at 0xfffffff00798c8f0 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The user observed automatic reset with the exact idle-return image 55b7c0354446888e80d0ed77258e4f29c236fdd9df6e65bfafbfab2cb72ab5ed. This confirms idle_thread_create returned; the next checkpoint is sched_startup return, not initialize_screen internals.
  • The next image targets idle_thread_create return at 0xfffffff00798c8c4. Its modified kernel was independently extracted from the FAT payload and matched to the patch site. No result for this image has yet been observed.
  • The user confirms the handed-off reset-before initialize_screen probe did not reset. That probe resets immediately at the call site, so the next test isolates whether idle_thread_create returns; no conclusion about initialize_screen internals is drawn.
  • The first-boot DRAM window now excludes the entire observed camera CMA allocation window; CPU0-only topology and the disabled peripheral policy are unchanged.
  • The board now includes disabled measured peripheral declarations alongside the unchanged CPU0-only topology; the checker compares their GIC interrupt cell translation without enabling peripheral drivers.
  • Core identity differs in Affinity1 (0x100 steps); retaining only the lowest MPIDR byte would lose the recorded core distinction.
  • Android's three frequency policies are not automatically the cluster layout required by the selected XNU profile.
  • GICv3 arch_timer and IPI counters are visible in Android; they do not demonstrate XNU secondary-core startup.
  • Single-core board wiring is implemented before SMP. Shared secondary-core and cluster patches remain in their declared SoC series; no E/P tags or SMP execution are claimed.
  • Host check compared every shared CPU affinity with the captured Android tree and decoded the ADT to confirm exactly one enabled CPU, affinity 0 and timebase 19200000 in little endian. This is not an interrupt/startup test.

Completion criteria ​

  • Each enabled XNU CPU reaches its checkpoint and handles timers and IPIs with the measured affinity and timer rate.

Current limits ​

  • Human-observed reset checkpoints establish idle_thread_create and sched_startup return only; timer IRQs, IPI routing and secondary CPU startup remain unverified.
  • CPU0 diagnostic execution is observed; full platform matching and runtime interrupt handling are not verified.

Next action ​

  • Qualify the bounded exception path with a deliberate BRK immediately after MMU enable, before C startup, then reassess the repaired kernel checkpoint.

Evidence ​

Memory and DMA ​

implemented

Hardware and dependencies ​

  • Stock /proc/meminfo reports MemTotal: 7806144 kB and CmaTotal: 458752 kB.
  • Live /memory reg tuples (base + size): 0x80000000 + 0x3bb00000, 0x180000000 + 0x100000000, 0xc0000000 + 0xc0000000.
  • The live DT includes firmware reservations, display splash at 0x9c000000 + 0x2300000 and ramoops at 0x9fa00000 + 0x100000.
  • Applications SMMU: 0x15000000 + 0x100000; GPU SMMU: 0x03da0000 + 0x10000. Both declare qcom,qsmmu-v500.

Configuration ​

  • DTS describes the measured-bank subrange 0x200000000+0x80000000 (2 GiB), excluding the complete camera CMA allocation window, and all 30 static reservations. Other DRAM remains in stock evidence.
  • The firmware overlay supplies the original low-memory configuration/stack/FD map. No XNU DMA device or dynamic Android CMA allocator is enabled.

Procedure ​

  • The existing Android shell transcript records cat /proc/meminfo.
  • Capture root-readable /proc/iomem and the live DT, then compare physical memory and reserved-memory reg values.

Development findings ​

  • The original 3 GiB and 4 GiB banks are adjacent, with a separate lower bank. Even before exclusions the maximum contiguous range is 7 GiB. The current loader requires one EFI conventional memory allocation. The largest actually available run is unmeasured.
  • The 768 MiB v60 BOOT was repacked as v62 with a structurally verified 2 GiB DarwinBoot request. v57 through v59 still encode 768 MiB and fail full ADT decoding. v62 preserves the base kernel, arguments, trust cache, Data seed, firmware and DTB. At target120 XNU reports 0x79e30 managed pages, about 1950 MiB. This verifies the larger managed-memory window on the tested image.
  • Isolated BOOTf6fd6636 changes only darwinboot-memory-size512->768MiB; final FAT round-trip, unchanged kernel/arguments/trust/seed/DTS/reservations pass. Device target60 main1/cpu8 and pages0x2b187 confirm about689.5MiB managed RAM. Free0x13b alone is not OOM evidence. Default remains512MiB and no high-memory map is enabled.
  • BOOT3da265b4 target60 owner photo confirms main1/n67/cpu8/sec7, SpringBoard27/runningboardd26, Data0/policy0/stage4 and all-core positive timer/SGI snapshots. Backboardd not observed; free0x183 excludes reclaimable memory, not sole OOM proof. Sustained runtime, controlled CPU workload and desktop remain unverified. See runtime-cache60/device-result.json.
  • After corrected carriers were backed up/updated and fully readback-verified under explicit authorization, BOOT097c4f8c owner photo shows memorystatus no-victim (available3060pages), rather than prior cache EACCES. This is not proof of full mapping/launchd main. Source retains73293824bytes of carrier plus another73293824bytes of duplicated manifest tables. Borrow only exact authenticated driver-owned boot-lifetime allocations, protect them readonly, retain separate private readonly key pages and reauthenticate; fallback sources still copy. Teardown never frees borrowed carrier. Actual configure/free host ASan/UBSan+mprotect lifecycle/failure tests pass; Normal BOOT12766f5f stalls with persistent bars over3minutes. Isolated BOOTef97eb6a resets about10seconds after magenta per owner, confirming at least one shared-policy vr_open return but not success status. BOOTc544bae1 before-init-exec checkpoint immediately resets per owner, confirming the exec call boundary only; exec and launchd success remain unverified. Session stopped at owner request. EFI owned window remains256MiB.
  • BOOT cfbd84ba photo confirms stage4: ID/VALID/S2CR accepted, direct FAULT restore200ff succeeded without fallback, allRestored/mappingsUnchanged=1 and GFSR=0. Six context states captured; CB0..4 already configured with FSR400 of unknown age, CB73 SCTLR3ab3a706 is not a verified free bank. No context writes, DMA or UFS commands occurred.
  • Combined field diagnostic BOOT cfbd84ba34fc03b50661b46c9e22fe59c43ba651bca6967da49f1df1ec373e75 prepared from source7ee2918/kernel53e9e68c. Thirteen host tests, input-stable kernel build, independent FAT/arguments/FD checks and DT/ADT check passed. BOOT-only upload exited0; actual VALID/S2CR/restoration/context observations remain pending.
  • Prepared a combined single-slot field qualification after ee45890a: test VALID only under unchanged FAULT policy; test S2CR only with SMR invalid; restore with a bounded Qualcomm-aware fallback if necessary; compare all protected mappings; only then read six context states. No UFS commands, DMA route grants, queue/context/global/clock/SCM writes. Field results and restore flags still require exact-image device observation.
  • BOOT ee45890a device photo confirms stage5, inactive SMR56 ID a5 accepted and restored to zero; S2CR remains200ff, restoreOK and mappingsUnchanged are1, GFSR before/after zero and display04 unchanged. This qualifies only inactive ID-field writes, not VALID/S2CR/context/DMA, and contradicts blanket read-only claims for this measured field.
  • Single-slot SMR ID test BOOT ee45890ab4875987b0e3376b095a64a5d58f1b23177c96b9ea4a996cd8ba9031 prepared from source 41d99e6 and kernel d455be28. Twelve host tests pass; compiled code has exactly two writes to offset958 with DSB after each. Packed FAT/arguments/FD, capacity and DT/ADT checks pass. BOOT-only patched Heimdall upload exited 0; device field acceptance/restoration observation is pending.
  • Prepared a single-slot inactive SMR ID-field test, based on the complete 933a5d77 handoff observation. Requires exact measured geometry, clean GFSR, controller prerequisites, sole display mapping unchanged and slot 56 equal to zero/200ff. Rechecks mappings, writes only invalid ID a5 at offset958, restores zero and compares protected state; both writes fenced. No VALID/S2CR/CB/GCC/HCI/SCM/DMA changes. Outcome is not yet observed.
  • BOOT 933a5d77 device screen is confirmed through END slots=87. Corrected SM8250 GCC gate passes; HCE=1 HCS=10f IS=400, both queue run-stop bits set and both doorbells zero, UTRLBA=9b296000. The sole valid SMR 84020820/S2CR 4 exactly matches the captured display SID 0820 mask 0402; preserve slot 04 and CB4. Candidate residues in invalid slots 02/03 are not active routes. No DMA, SCSI or root read was attempted.
  • Prepared t970-ufs-handoff=1: corrected board-local SM8250 clock diagnostics from Samsung gcc-kona.c, removed SM8550-only memory-PHY GDSC reads, capture all bounded raw SMR/S2CR slots and guarded read-only HCI/queue state. No clock, PHY, SCM, SMMU, DMA or queue writes; use the exact tested baseline FD. Host and device results remain separate.
  • User confirmed and photographed the expected T970 SMMUv2 RO stop for BOOT 7f729c2a: sCR0=002d0406 ID0=4c017e57 ID1=6000004a ID2=00005111 GFSR=0; 87 groups scanned, 74 context banks, no candidate match for 0060/00e0/04e0. MMIO observation is confirmed; SMR writability, actual UFS routing, DMA and root reads are not.
  • Resumed at 47b113f. New default diagnostic t970-smmu-report=1 reads the measured SMMUv2 window before any controller/queue/DMA/root setup and stops on a labeled panic. It retires the unflashed all-slot write scan, separates sCR0 from ID0/1/2, honors EXIDS, and does not treat ignored writes or prior SCM markers as proof that secure-world routes are exhausted.
  • Current platform checks passed in explicit firmware-envelope mode with the 256 MiB ADT owned-window request. Reserved holes are reported, not reclaimed; per-boot allocation-map capture is still pending.
  • The handed-off diagnostic DTS uses the 0x80000000+0x80000000 ADT envelope to include the reported DarwinBoot window at 0xc0000000. It is explicitly tagged as firmware-envelope in the board checker, with a 256 MiB owned-window request matching the pinned loader default. Reserved holes are retained and not declared free.
  • The pinned DarwinBoot AllocateWindow uses only EfiConventionalMemory and AllocatePages; boot_args.MemorySize and MemorySizeActual describe that allocation, not all 2 GiB of the envelope. The checker retains strict bank/non-overlap checks for physical-bank mode and reports the envelope overlaps separately; actual per-boot EFI allocation remains a runtime measurement.
  • The committed-source platform check passed with a 2 GiB measured-bank subrange, 30 static reservations, all 13 stock dynamic-pool windows, 45 stock XBL regions and seven disabled peripheral ranges.
  • Committed-source checking found camera_mem_region allows allocations in 0x180000000+0x80000000. The first-boot DRAM window is therefore narrowed to the remaining measured subrange 0x200000000+0x80000000 (2 GiB), outside all 13 original dynamic-pool allocation windows. The checker verifies containment in a real bank rather than demanding the entire bank.
  • The completed repository supplies the candidate bank and static reservations, and checks every original dynamic-pool allocation window and all 45 XBL platform regions against that bank. The firmware overlay owns its low-memory heap/FD/stack; real UEFI allocation still needs runtime evidence.
  • The stock XBL describes 45 platform regions, including low-memory firmware heaps/FD/stack. Its DDR descriptors do not intersect the candidate high handoff bank. This is a static source comparison, not a GetMemoryMap result.
  • MemTotal describes memory exposed to the running Android kernel; it does not establish installed DRAM capacity, physical banks or firmware reservations.
  • CmaTotal describes the stock kernel's CMA pool; it is not a complete reserved-memory map for the XNU handoff.
  • Several reserved-memory node unit addresses differ from their reg values, and some display ranges overlap; consume actual reg properties and reconcile their ownership before reuse.
  • The shared ADT generator accepts exactly one contiguous memory range, so the three-bank Android memory node cannot be passed through unchanged.
  • The candidate high bank does not intersect the captured static reservations. Dynamic size-only reservations and future firmware allocations are not thereby proven safe.
  • Three dtc naming warnings are retained from the copied static reservations; the actual reg values and original names are preserved.
  • Host check compared all 30 static reservation reg values, confirmed their non-overlap with the selected measured bank, and decoded the ADT DRAM base/size. Runtime allocations and DMA remain unverified.
  • Step 3 audit records the candidate contiguous bank and 30 static reservations as partial DTS input completion. Dynamic reservations, UEFI allocation and full peripheral ownership are still not established.
  • The UFS survey DMA buffer is allocated from the DarwinBoot owned window (args->physBase/memSize); the preflight refuses any allocation outside it, so the verified reads also confirm the owned-memory window arithmetic on hardware.

Completion criteria ​

  • The board memory description accounts for physical DRAM banks, firmware reservations and the UEFI-to-XNU handoff regions.

Current limits ​

  • The saved DT, XBL and iomem describe original software. New UEFI allocations, secure-world ownership, DMA widths and XNU cache/SMMU behavior require separate runtime checks.
  • Removing board.example completes the concrete input configuration; it does not make the candidate RAM bank device-verified.

Next action ​

  • Capture the actual owned-window physical base/size and EFI memory map on the next observable boot; do not reclaim the rest of the ADT envelope.

Evidence ​

Storage and root ​

implemented

Components: ShengUfs, VirtioMmioBlock, RamBlock, VerifiedRoot.

Hardware and dependencies ​

  • UFS controller: 0x01d84000 + 0x3000; UFS ICE: 0x01d90000 + 0x8000. Controller interrupt cells are <0 0x109 4>.
  • UFS PHY: qcom,ufs-phy-qmp-v4 at 0x01d87000 + 0xe00; two lanes per direction. Clock, reset and supply references are preserved in the live DT.
  • SAMSUNG KLUEG8UHDB-C2D1 revision 0090; logical and physical block size 4096 bytes. sda/sdb/sdc/sdd map to SCSI LUNs 0/1/2/3.
  • boot=sda22 (71303168 bytes), recovery=sda23 (86888448 bytes), dtbo=sda21 (10485760 bytes), super=sda28 (9961472000 bytes), userdata=sda36 (243668070400 bytes).

Configuration ​

  • The Android by-name mapping and GPT provide measured partition inputs; no UniXNU root volume or writable Data region has been allocated.

Procedure ​

  • Read block sysfs and by-name links; read each LUN's primary GPT header and entry array and validate their CRC32 values without writing any block device.

Development findings ​

  • The matched v68 display comparison runs disposable RAM Data from copies of the existing 512 MiB seed. Both retain the Data UUID and disable the persistent backend to avoid reinitializing the existing UFS store. A direct v67 comparison therefore mixes Data history and policy.
  • The v62 owner report shows Data mounted with 15402 free 4 KiB blocks (about 60.2 MiB) and 1115551 verified UFS blocks. There is no ENOSPC measurement. Data contents change across boots.
  • The verified 512 MiB APFS seed reports 534294528 free bytes when attached read-only on the host, before any device writes. This is not runtime free space. BOOTe0a2d858 adds an opt-in bounded worker that checks the actual RAM Data device and requests APFS block counts, while preserving display counters in the 125-second terminal report. Host helper, BSD compile, kernel/prelink and packing checks pass; owner photo after successful BOOT upload shows rc0/phase1/support1d0 and 78135 available blocks of 4096 bytes (320040960 bytes). At the target125 snapshot the mounted RAM Data APFS has free capacity. See evidence/storage/data-space-v31.
  • BOOT705d4160 mode6 owner photo02:38:12 captures all three processes/end marker unclipped. Constrained cap/active/busy=0/0/0; MG done35->37 while BB25/SB53 unchanged across 500ms deadlines. Runtime callback continues; investigate EDGE E/P counts versus current SMP topology before any scheduling change. See evidence/display/ui-queue-progress-v20/device-result.json.
  • First boot of7e60f7c9 refused UFS handoff NOP at stage0, before NOP submission; CB0=100ff/1/e0, GFSR0 and historical FSR400. Owner rebooted the same image and root reads recovered. Exact stage0 predicate remains unknown; no storage gate or mappings were relaxed. Both photos are retained in evidence/cpu/smp-bringup/ipi-check/device-result.json.
  • BOOTeeeba83b owner photo19:36:40 shows requested120-second runtime report: genuine main1,109 processes, watchdogd absent, SpringBoard27/backboardd56/runningboardd26, Data0/policy0/stage4,964876 verified blocks. Kernel deadline-wait/report executed; rate accuracy unmeasured. Interface-service process presence is not proof of rendering or functional services. Display backend remains disabled; next phase is display handoff/provider and independent staged SMP qualification.
  • BOOTeeeba83b uses explicit t970-runtime-report=120 to start one diagnostic kernel thread after Data/policy install. Deadline wait yields CPU; bounded512 non-zombie callbacks, first18 names in512bytes and named service PIDs are displayed in intentional panic. Readonly genuine-main accessor and original process refs/exit policies retained. Actual helper sanitizer/API-substitute bounds/wait/range/once/thread-failure tests plus policy regression and independent symbol/FAT/ADT/boot/argument verification pass; implicit sampler configuration refused. BOOT-only upload exit0; physical timer/snapshot and later services pending.
  • BOOT28268af5 owner photo19:10 confirms genuine main1/error0/Data0/policy0/stage4. Kernel installer actually completed root-owned RAM policy and migration marker writes/metadata/fsync/close before launchd main. Probe is readonly, preserves original sysctl semantics and caller frame;27 Unicorn state/result combinations plus unknown-input refusal pass, actual pinned binary/FAT/geometry checks pass. Normal BOOT2387e904 restored via BOOT-only upload exit0 after observation. Original launchd override acceptance, subsequent services and desktop remain unverified.
  • BOOT2387e904 installs an explicit temporary original-launchd watchdog-only override after successful volatile Data mount when t970-disable-watchdogd=1. Refuse non-RAM/persistent/readonly/unready/nonroot conditions and existing policy/marker; exclusive nofollow creation, root metadata and full write/fsync/close before migration marker. Actual helper ASan/UBSan15 API failure points plus guard/preservation/cleanup cases pass; original launchd/watchdogd unchanged. Source39d7cfe1/real PMGR and independent FAT/ADT/boot/argument checks pass. BOOT-only upload exit0, runtime policy acceptance/services pending.
  • BOOT97271e99 photo18:22 confirms launchd main1/err0 and managed pages0x1b709 (~439MiB):512MiB EFI-owned request works. BOOT911a462a new Data build failed AMFI No PMGR because isolated output silently used FirstPassStub. Remove implicit stub, require a reference, audit real PMGR340 slots and reject missing registration symbols/archive members in independent pack checks. Repaired6b83f4e6 uploaded exit0; photo18:42 shows watchdogd PID102 SIGTRAP. Enforced exact-device/writable/APFS mount success gate precedes exec, so Data mount success is inferred, not a Data write/persistence test. Original watchdogd host branch and launchd root-owned watchdog-only policy checks pass with explicit OS API substitutions; policy not applied.
  • 2026-11-02: normal release BOOT867efc59 requests512MiB via the chosen ADT property only; fixed normal kernel/FD/DTB/config/tail preserved, Heimdall upload exit0. Owner reports retained bars, which does not localize execution or verify allocation. Terminal main checkpoint BOOT97271e99 uploaded exit0 to measure actual pages; runtime result pending; Data APFS32MiB seed packed losslessly to1007696bytes on host, not integrated/flashed or persistence-qualified. Physical8GiB is not the EFI-owned256MiB diagnostic allocation.
  • After corrected carriers were backed up/updated and fully readback-verified under explicit authorization, BOOT097c4f8c owner photo shows memorystatus no-victim (available3060pages), rather than prior cache EACCES. This is not proof of full mapping/launchd main. Source retains73293824bytes of carrier plus another73293824bytes of duplicated manifest tables. Borrow only exact authenticated driver-owned boot-lifetime allocations, protect them readonly, retain separate private readonly key pages and reauthenticate; fallback sources still copy. Teardown never frees borrowed carrier. Actual configure/free host ASan/UBSan+mprotect lifecycle/failure tests pass; Normal BOOT12766f5f stalls with persistent bars over3minutes. Isolated BOOTef97eb6a resets about10seconds after magenta per owner, confirming at least one shared-policy vr_open return but not success status. BOOTc544bae1 before-init-exec checkpoint immediately resets per owner, confirming the exec call boundary only; exec and launchd success remain unverified. Session stopped at owner request. EFI owned window remains256MiB.
  • Root cause identified on host: deployed/readback raw root fd43ee70 contains original OS e5634d04/SystemOS b4908cde, but current owner envelopes signed stale sparse windows47c1e4b0/ee18c5c2. Prior userdata-write-audit already recorded the stale segment seek bug. SystemOS block43008 in stale segment/policy is SHNGROOT, whereas raw/original data match; host APFS mapping for .03 read offset34MiB covers this block. Signer read SHA at wrong entry offset80 instead of56 and never compared it. Fix both, validate full window digests before signing, and prepare envelopes from exact raw source. Five generator and five writer-order/error tests pass; real C verifier authenticates all2290185blocks. Corrected carrier write plan is prepared but not executed; do not infer new device success. Diagnostic BOOT097c4f8c remains host-prepared/unflashed.
  • BOOT 6b04878c owner photo: stage171, .03 read offset0x2200000, expected original CDHash. AMFI and earlier signature setup passed; actual native4k vn_rdwr returns EACCES. Add read-mediation201 versus filesystem202 observations and first actual UFS integrity-rejected block index/LUN0-LBA/length/hash prefixes. No additional I/O or retry/grant; original rejection is preserved. Nine existing state tests and actual-helper ASan/UBSan bounds/retention checks pass. New build/runtime observations pending; storage corruption is not yet established.
  • Owner photo for BOOT dd007d58 shows .02 openat and F_ADDFILESIGS_RETURN97 succeed, then .03 openat returns fd4 and fcntl97 returns EACCES13. Host original cache/.01-.04 CodeDirectory pages all verify and CDHashes are present in the unchanged original System trust module; .03 cdhash is 55b4a307efbf08234c98c81f09f1d17e5efc0d0a. This does not establish device-runtime integrity or identify the rejecting stage. Add first-PID1-EACCES pipeline-stage/offset/known-kernel-CDHash observations without changing signature/trust behavior; host helper filtering/latching/encoding cases pass, runtime stage pending.
  • After BOOT 49f3b166 actual dyld cache failure, add PID1-only bounded numeric results for open/openat, fcntl and shared-region calls plus the existing kernel-owned copied namei path. No extra user-memory reads, argument/result changes or policy bypass. Keep 24 entries and show the last 12 only at initproc fatal exit. Actual-helper host checks cover PID/null filtering, scalar errno/command, path truncation, wraparound and output bounds. Kernel 170cc979 and BOOT dd007d58 build with stable inputs and pass FAT/FD/geometry checks; BOOT-only upload at 22:47 exits 0 and requests reboot. A last-copied path is not a per-thread causal trace; actual startup trace is pending.
  • BOOT dc42838f owner photo: mount=2 stage=3 auth=0 mstatus=2 and all three cache lookups ENOENT. Read-only original OS inspection shows System/Cryptexes/OS is a symlink to ../../private/preboot/Cryptexes/OS, whose target is absent; private/preboot is empty. T733 3bb0d6f and SM8250 umi 3eb7257 both use the authenticated readonly SystemOS root union for initial cache startup. Restore that configuration and check its actual /System cache path. Also import the T733 shared kernproc-cwd/rootvnode reference correction: extracted actual XNU checkdirs fails the ownership test before the correction and passes five cases after it. This independent reference bug is not inferred from the mount ENOENT photo; Kernel 1d83105e/BOOT 49f3b166 passed actual compiler-branch checks and five reference cases, then BOOT-only upload exited 0 at 22:35. Owner photo confirms preparation/cache vnode guard passed and actual dyld still exits namespace 6/code 1 (no dyld cache), carrier acc/rej 0/0. Union same-mount behavior means these counters do not identify the failed stage. Next observe real syscall returns without extra user-pointer reads.
  • dsh handoff photo attributed by the owner to BOOT a41b5c11/kernel d66b832b shows mount=0 stage=6 auth=1 mstatus=0 sys=0 cryptex=2 preboot=2. Preserved host kernel matches d66b832b, but resolved .config and actual kern_exec compile record still enable OWNER_UNION_SYSTEMOS=1; defconfig edits were not regenerated. The unconditional three-path panic also stops before launchd. Explicitly disable union, regenerate config and panic only for mount or cryptex-lookup failure; BOOT dc42838f/kernel 8262854b builds with stable tracked inputs; real compiler preprocessing confirms union=0 and consistent mount/environment/carrier paths. Independent FAT/FD/geometry and DT/ADT checks pass; check-platform.py fails its historical five-component assertion. The owner explicitly authorized flashing; Heimdall uploaded BOOT dc42838f and requested reboot at 22:23 Asia/Shanghai with exit 0. Startup/cache mapping/launchd observations remain pending.
  • BOOT cfbd84ba photo confirms stage4: ID/VALID/S2CR accepted, direct FAULT restore200ff succeeded without fallback, allRestored/mappingsUnchanged=1 and GFSR=0. Six context states captured; CB0..4 already configured with FSR400 of unknown age, CB73 SCTLR3ab3a706 is not a verified free bank. No context writes, DMA or UFS commands occurred.
  • Combined field diagnostic BOOT cfbd84ba34fc03b50661b46c9e22fe59c43ba651bca6967da49f1df1ec373e75 prepared from source7ee2918/kernel53e9e68c. Thirteen host tests, input-stable kernel build, independent FAT/arguments/FD checks and DT/ADT check passed. BOOT-only upload exited0; actual VALID/S2CR/restoration/context observations remain pending.
  • Prepared a combined single-slot field qualification after ee45890a: test VALID only under unchanged FAULT policy; test S2CR only with SMR invalid; restore with a bounded Qualcomm-aware fallback if necessary; compare all protected mappings; only then read six context states. No UFS commands, DMA route grants, queue/context/global/clock/SCM writes. Field results and restore flags still require exact-image device observation.
  • BOOT ee45890a device photo confirms stage5, inactive SMR56 ID a5 accepted and restored to zero; S2CR remains200ff, restoreOK and mappingsUnchanged are1, GFSR before/after zero and display04 unchanged. This qualifies only inactive ID-field writes, not VALID/S2CR/context/DMA, and contradicts blanket read-only claims for this measured field.
  • Single-slot SMR ID test BOOT ee45890ab4875987b0e3376b095a64a5d58f1b23177c96b9ea4a996cd8ba9031 prepared from source 41d99e6 and kernel d455be28. Twelve host tests pass; compiled code has exactly two writes to offset958 with DSB after each. Packed FAT/arguments/FD, capacity and DT/ADT checks pass. BOOT-only patched Heimdall upload exited 0; device field acceptance/restoration observation is pending.
  • Prepared a single-slot inactive SMR ID-field test, based on the complete 933a5d77 handoff observation. Requires exact measured geometry, clean GFSR, controller prerequisites, sole display mapping unchanged and slot 56 equal to zero/200ff. Rechecks mappings, writes only invalid ID a5 at offset958, restores zero and compares protected state; both writes fenced. No VALID/S2CR/CB/GCC/HCI/SCM/DMA changes. Outcome is not yet observed.
  • BOOT 933a5d77 device screen is confirmed through END slots=87. Corrected SM8250 GCC gate passes; HCE=1 HCS=10f IS=400, both queue run-stop bits set and both doorbells zero, UTRLBA=9b296000. The sole valid SMR 84020820/S2CR 4 exactly matches the captured display SID 0820 mask 0402; preserve slot 04 and CB4. Candidate residues in invalid slots 02/03 are not active routes. No DMA, SCSI or root read was attempted.
  • Prepared and independently verified BOOT 933a5d776edb2500be5c268b93e64f2cfec53fee6e12cebbb39869a8d7050deb from source 58bdac8 and kernel 147f8d3b; DT/ADT checks passed. Patched Heimdall uploaded BOOT only with exit 0. The new handoff screen and full-table END marker await device observation; no UFS DMA/root success claimed.
  • Prepared t970-ufs-handoff=1: corrected board-local SM8250 clock diagnostics from Samsung gcc-kona.c, removed SM8550-only memory-PHY GDSC reads, capture all bounded raw SMR/S2CR slots and guarded read-only HCI/queue state. No clock, PHY, SCM, SMMU, DMA or queue writes; use the exact tested baseline FD. Host and device results remain separate.
  • Compared current T733 (SM7325) and umi (SM8250) public sources and maintainer-reported hardware results. T970 still inherits SM8550 clock diagnostic offsets; Samsung gcc-kona.c and umi agree on different SM8250 offsets. Current BoardInit skips GCC writes, so this is not proof of a reset cause. Public T733 firmware integration exists; no foreign SID or firmware was applied.
  • User confirmed and photographed the expected T970 SMMUv2 RO stop for BOOT 7f729c2a: sCR0=002d0406 ID0=4c017e57 ID1=6000004a ID2=00005111 GFSR=0; 87 groups scanned, 74 context banks, no candidate match for 0060/00e0/04e0. MMIO observation is confirmed; SMR writability, actual UFS routing, DMA and root reads are not.
  • Prepared BOOT 7f729c2a6ee8ee11b6eb5d4ff7ec23171b261854151578e36737d866a62391e2 from source 23d54b9 and kernel cca9bbb8. Independent FAT/kernel/arguments and packed FD checks passed, as did nine host tests and CPU0 DT/ADT checks. Patched Heimdall uploaded BOOT only with exit 0; device screen/register observation is pending. This is not a UFS/DMA/root-volume success.
  • Resumed at 47b113f. New default diagnostic t970-smmu-report=1 reads the measured SMMUv2 window before any controller/queue/DMA/root setup and stops on a labeled panic. It retires the unflashed all-slot write scan, separates sCR0 from ID0/1/2, honors EXIDS, and does not treat ignored writes or prior SCM markers as proof that secure-world routes are exhausted.
  • Disabled board UFS/PHY reg and interrupt overrides now preserve the exact stock ranges, including ICE. No root/Data policy or XNU storage driver is enabled.
  • Primary GPT headers and entry-array CRCs passed for all four inspected LUNs; their entries and byte offsets are saved in gpt.json.
  • Linux block sysfs start/size values use 512-byte units, while this device's GPT LBAs use 4096-byte logical blocks; convert explicitly when comparing them.
  • Step 2 catalog review found ShengUfs declares SM8550/sheng clock, SMMU and userdata-layout dependencies. It and RamBlock/VirtIO/VerifiedRoot remain unselected until a T970 storage/root policy and interfaces are established.
  • Step 6 storage inventory resolves the UFS controller (0x1d84000+0x3000 and ICE 0x1d90000+0x8000), QMP PHY v4 (0x1d87000+0xe000), all nine clock names to kona IDs (UFS_PHY_AXI 167, AGGRE_UFS_PHY_AXI 6, UFS_PHY_AHB 166, UNIPRO 179, ICE 170, TX/RX symbol clocks, RPMH_CXO 0), reset core_reset=GCC_UFS_PHY_BCR(33) and every regulator phandle; the stock UFS node has no iommus property.
  • ShengUfs is not selected: it is scoped to the SM8550 controller with a 0x1d80000/0x2000 PHY, SM8550 clock policy, a fixed apps-SMMU stream 0x60 and sheng userdata LBAs. The T970 controller base matches but the PHY window, ICE block, SMMU ownership and userdata geometry do not.
  • No SM8250/kona UFS implementation exists in the reviewed repositories: the shared SoC DTSI only declares disabled ufs/ufsphy nodes, and the SM8250 pipa port carries only package/SmmuBypass.h. UFS therefore stays disabled; storage remains planned pending a real driver port.
  • Reviewed the SM8250 ports on unixnu.com/zh/devices: umi (Mi 10) has Native UFS, both root volumes and writable Data with launchd running; alioth (Redmi K40) marks storage device-verified using a device fork FFT-infra/NativeUfs-alioth pinned through feeds.toml; kebab reaches an HFS root; pipa is still stuck at root mount.
  • The shared technique is firmware state takeover, not cold init: NativeUfs reads GCC gating and link state without writing clocks/reset/PHY, plans the two SM8250 UFS streams 0x0e0 and 0x4e0 from SMR/S2CR readback, and publishes a per-device userdata window. T970 uses the same controller 0x1d84000 and PHY 0x1d87000, so the umi/alioth driver is the concrete base for this port instead of ShengUfs SM8550 constants.
  • Started the SM8250 UFS port by pinning feeds.toml ShengUfs to FFT-infra/NativeUfs-alioth@ab54059 (device-verified storage fork, streams 0x0e0/0x4e0). The component compiled; the kernel link then required the original IOStorageFamily absolute bindings (scripts/build-storage-bindings.py plus scripts/data/native-storage-original-bindings.S, both stored here) and the VerifiedRoot vr_* archive.
  • Enabling the driver is blocked on two inputs that do not exist yet: the signed VerifiedRoot policy archive (build-verified-root-probe.py needs the OS-volume verification bundle, not just the IPSW) and a sheng userdata manifest that findRootLayout accepts; the T970 GPT is an Android layout. The integration is therefore prepared but disabled; CONFIG_XNU_NATIVE_UFS stays off and board components/archives are unchanged.
  • Built the T970 userdata-root image from the 21H461 IPSW with the board GPT geometry (LBA 2969600..62458874, 4096-byte blocks): OS e5634d04 at 0x100000 and SystemOS b4908cde at 0x16a600000, image fd43ee70, 9382658048 bytes. Added [userdata] and payload.adt root_match_volume_uuid 04769D26-2CA0-4825-B443-E2E5F88300F2.
  • The VerifiedRoot path cannot fit this board: the OS+SystemOS policy bundle embeds a 47 MiB block-hash table in the kernel (kernel.macho 125374464 bytes) and the packed boot image measured 138211328 bytes against the 71303168-byte BOOT partition. CONFIG_XNU_NATIVE_UFS and CONFIG_XNU_VERIFIED_ROOT_PROBE are therefore left off; the next storage step is a T970 device-side UFS publication path that does not embed the verified-root hash table.
  • Provisioned the T970 userdata partition without Odin: scripts/encode-userdata-sparse.py encodes one contiguous segment of userdata-root.img as an Android sparse image whose DONT_CARE chunks leave the rest of the partition untouched, so three segments of ~2.8-3.1 GB each fit Heimdall's 4 GiB single-file protocol limit. All three uploads reported USERDATA upload successful.
  • Enabled ShengUfs on the alioth fork with the empty-policy VerifiedRoot archive (19 KB, native policy count zero) and single default stream sid 0x0060. The kernel links and boots (kernel a981a22d, boot image c38d09f7). The driver reaches the SMMU setup but the SMR write for bank 73 slot 86 reads back zero, so UFS publication still fails at NativeUfs.cpp:455; the firmware-configured stream id or SMMU ownership is not yet identified.
  • A t970-smmu-dump boot-argument diagnostic in arm_init (patches/xnu/t970-smmu-dump.patch) dumps the firmware-configured apps_smmu table before IOKit starts: IDR0 0x002d0405 and 26 valid SMR entries, none with SID 0x0060. The alioth driver then plans bank 73 slot 86 and its SMR write reads back zero, which points at SMMU power/clock or secure ownership rather than a missing stream id.
  • The firmware DSC still states 'no UFS driver yet', and the ShengUfs hostBringUp only maps the controller: it assumes the boot firmware already powered UFS, the PHY and apps_smmu. On T970 the SMMU stream writes do not stick (SMR reads back zero) and the IDR reads vary between boots, so the driver cannot create the bypass context it needs. The vendored board copy in package/ShengUfs (IDR at 0x0/0x4/0x8 and a 0x820 attempt) is kept for the next step but is not selected in the archive list.
  • NativeUfs/ShengUfs reuse is not enough for T970 on its own: slot 4 is a wildcard SID mapping (mask 0x402) that the driver refuses, and the firmware-configured UFS stream has not been identified among the 26 entries.
  • The vendored ShengUfs copy with IDR at 0x0/0x4/0x8 and an auto-reuse scan of every exact stream still fails: the planner rejects the block with 'SMMU AArch64 stage 1 unsupported' because IDR0 bit 30 is clear on T970. The alioth/SM8550 SMMU register model therefore does not describe SM8250 apps_smmu; a correct SM8250 SMMU implementation (or firmware-side stream setup) is required before UFS can publish the partition.
  • Restoring the Linux-validated SMMU model (IDR at 0x20/0x24/0x28, NUMSMRG/NUMCB geometry) showed the vendored driver's original offsets were correct; the failure is that no firmware stream is reusable and an SMR write for a new bypass context reads back zero. This is consistent with the secure world owning the stream registers on T970.
  • Kernel-side SMMU programming is therefore not a viable path on this board: the storage driver needs the firmware to leave a bypass stream for UFS, which is what the alioth/T733 firmware does and what the Mu-Silicium T970 build does not.
  • Keeping the SMMU map but disabling SMMU programming (t970-ufs-no-smmu=1) moves the failure past the SMMU panics and into an unexplained self-reset before console output. That is consistent with the driver's unbounded UFS completion loops waiting on DMA that the firmware stream mapping does not cover; kernel-side SMMU bypass alone is not sufficient.
  • Route B started: scripts/gen-ufs-phy-tables.py extracts the SM8250 QMP UFS PHY sequences from the Linux driver into package/firmware/.../PlatformUfsLib/Sm8250UfsPhyTables.h (SM8150 base tables plus the SM8250 HS-G4 overlays, 24/6/34/7 and 1/21/2 entries). Wiring PlatformUfsLib and the Samsung UfsDxe is the next step and no firmware behaviour has changed yet.
  • Both non-secure routes to a usable UFS SMMU context are now exhausted: kernel writes to the SMR are ignored, UEFI firmware PHY bring-up succeeds but UFS DMA still resets the board, and QCOM_SCM restore_sec_cfg is not provided by this platform's secure monitor.
  • The UEFI image survey (t970-ufs-image=1) completed on hardware after the full userdata rewrite: 14 UFS reads, healthy=1, poisoned=0, and all seven manifest/OS/SystemOS samples matched (matchMask=0x7f). It reuses the firmware SMMU handoff context (CB0 0x100ff, SCTLR 0xe0, existing SMR entries) and stops with noPublication=1, so no block device or root is published.
  • The working UFS reads reuse the firmware handoff state rather than a driver-created SMMU context: CB0 with cbar=0x100ff, cba2r=1, sctlr=0xe0 and the firmware SMR entries for SID 0x0e0/0x4e0 in slots 55/56, with the DMA buffer inside the owned window. This is the configuration the root publication must reuse.
  • Connected that handoff to the production publication path (t970-ufs-publish=1): hostBringUpHandoff maps the controller and SMMU, takes DMA inside the DarwinBoot owned window, requires the exact reviewed firmware state (CB0 0x100ff/0x1/0xe0, 0x810 0x84020820, 0xc10 4, 0x954 0x800000e0, 0x958 0x800004e0, zero tails, GFSR/FSR zero) and then runs the survey's NOP/power/TUR sequence without writing the SMMU, the queue registers or storage. startRoot keeps every window fail-closed, so a rejected window publishes nothing.
  • The kernel still links the empty policy table, and the policy bundle cannot be moved into it: the OS window needs about 46.4 MB of block hashes and SystemOS about 25.2 MB (32 bytes per 4096-byte block), so the packed boot image would exceed the 71303168-byte BOOT partition. The carrier therefore has to move out of the kernel; the planned shape is both manifests in a fixed userdata region after the image, read at boot through the same handoff transport and verified by the compiled-in owner key before the policy table is filled.
  • The first publication image (BOOT 3b0d7d73) was refused on hardware by its own precondition: CB0 was still active (0x100ff/0x1/0xe0), GFSR 0, but the two parked SID entries 0x954/0x958 read zero and CB0 FSR read 0x400. The survey's healthy() snapshot was a state the survey itself had written (its NOP test parks SID 0x0e0/0x4e0 there) and FSR400 predates the kernel, so the snapshot was the wrong premise. The gate now checks fault drift around its own commands instead of a boot-specific snapshot, and the state words are reported without deciding.
  • Its successor (BOOT 11a1d635) hung at the magenta loader bar with no panic text, which under t970-novc means a stall: the handoff path proved the transport without taking over the request list, so UTRLBA still addressed the firmware buffer and the first doorbell made the controller fetch foreign descriptors. The survey never hit this because its own NOP test halts the queue, writes UTRLBA/UTRLBAU to the owned DMA and restarts it. hostBringUpHandoff now performs that takeover and still writes no SMMU register.
  • BOOT ca021c28 (handoff bring-up reusing the survey's t970_nop::run admission and NOP) reached the owner policy on hardware: the production reader validated the SHNGROOT manifest (status 0), planned both windows with the exact host geometry (OS 0x100000/6077580800, SystemOS 0x16a600000/3303014400) and published nothing because the linked policy table is empty (prepared=0 published=0, stage policy count invalid). The survey sequence is what makes this board work; the two hand-written bring-up variants before it either refused a state the survey itself had created or stalled the machine.
  • The policy carrier therefore has exact inputs: 1483785 OS blocks and 806400 SystemOS blocks, 73285920 bytes of block hashes plus two manifests, against a 71303168-byte BOOT partition. The root image ends at LBA 5260288, so a fixed region from LBA 5505024 (about 18000 blocks) after the image is the candidate carrier, read at boot through the same handoff transport and authenticated by the compiled-in owner key before the policy table is filled.
  • Implemented the carrier on both sides. Host: scripts/build-owner-root-manifests.py streams each window out of the sparse segments (no 9.4 GB file), signs it with the owner key through kits/VerifiedRoot/tools/manifest.py, and authenticates the result with the real C code (vr_host_open plus six sampled blocks). OS is 1483785 blocks / 47481664 bytes at LBA 5505024 and SystemOS 806400 blocks / 25805344 bytes at LBA 5516624, total 73287008 bytes; the OS UUID is the ADT root match 04769D26-2CA0-4825-B443-E2E5F88300F2 and the SystemOS UUID 8846FE78-2910-4297-AF97-D59BB6F8FC16 is the mounted cryptex volume UUID, which equals the kernel's XNU_OWNER_CACHE_VOLUME_UUID. Kernel: the linked table and count moved to .data and the real 395-byte owner key anchor is linked instead of zeros; installOwnerPolicyCarrier reads each envelope through hostRead4k, authenticates it with vr_open, and only then fills verified_root_policies, so a bad envelope still publishes nothing.
  • Wrote both envelopes into the carrier region through the qualified recovery ADB channel (BOOT e67fe744): dd conv=fsync at LBA 5505024 and 5516624, block cache dropped, and the exact envelope bytes read back with matching SHA-256 (45a69e42 and 869da36d). Nothing outside the two ranges was written. The first readback compared whole 4096-byte blocks and failed only on the partial last block, so verification now hashes the exact envelope length.

Completion criteria ​

  • UFS reads return correct capacity, GPT and known blocks under XNU; the chosen root mounts and writes persist only inside the allocated Data region.

Current limits ​

  • Root image and corrected carrier writes were explicitly authorized, completed and readback-verified in their respective receipts. Readonly root and SystemOS preparation reached before-init-exec; writable Data, persistence and sustained XNU storage operation remain unverified.
  • Current corrected runtime carriers authenticate the published OS/SystemOS windows; prior empty-policy publication reports are historical. Latest repeat has bootloader-only output, without a usable exec-return observation.

Next action ​

  • Track persistent Data separately from the v31 RAM Data result. Reopen the capacity hypothesis if a write operation reports ENOSPC or a later sample shows exhaustion.

Evidence ​

Display ​

planned

Hardware and dependencies ​

  • DRM controller is ae00000.qcom,mdss_mdp; DSI-1 advertises 2800x1752 modes at 120 and 60 Hz. Android wm reports physical size 1752x2800 and density 340.
  • Panel sysfs reports SDC_801417. The selected boot argument is msm_drm.dsi_display0=ss_dsi_panel_S6TUUM3_AMSA24VU01_WQXGA:.
  • The selected S6TUUM3 DT panel declares dsi_cmd_mode, DCS brightness control, max level 355, four data lanes and 24 bits per pixel.

Configuration ​

  • The unbooted UEFI overlay uses the measured 2800x1752 panel geometry and original Display Reserved base; SimpleFb stride/pixel format and actual GOP service require hardware validation. No XNU display component is selected.

Procedure ​

  • Collect DRM modes, panel type and brightness limits; read only display-selection tokens from /proc/cmdline and match the selected S6TUUM3 node in the live DT.

Development findings ​

  • v68 compares matched RAM-Data BOOT images with and without the three SpringBoard idle/dim preferences used by Sirius. The 21H461 cache has direct references from SBIdleTimerDefaults and SBPowerDefaults. The BOOTs share kernel, ADT, trust cache, arguments and firmware. The owner reports that the treatment did not go black. At target360 there are 253 successful CPU copies and retirements with blank/dark=0/0; the last copy was at 379990 ms. The paired RAM control is still unbooted, so the effect cannot yet be attributed solely to the preferences. v69 removes only the terminal report. The owner confirms Hello remains visible; swipe and power press do not respond.
  • v67 adds an opt-in root-domain watchdog panic detail with PM machine state, wait reason, current and requested power states, pending count and first pending service class. It also retains a 240-second frame report if no watchdog fires. Kernel prelink and final BOOT FAT checks pass. The device reaches target240 with a completed blank GOP fill 28 ms after the last normal CPU copy. No PM watchdog panic occurred before the report.
  • v65 with noidle=1 still shows Hello and then turns black after about ten seconds. The owner photo shows no panic text. v66 uses the sleep-disabled ADT default also used on T733 and dada; it retains noidle and adds only that property to the tested payload.
  • v64 owner photo confirms Sleep/Wake hang detected at IOPMrootDomain.cpp:12812. The linked stack reaches IOService::watchdog_timer_expired; this timer belongs to the PM root domain. The original triggering request and blocked child are unknown. v65 changes only noidle=1 on the continuous v63 image and preserves the power watchdog.
  • v64 changes the board observation callbacks only in the reviewed display archive, then relinks and repacks the v63 layout with a 240-second runtime report. The new fields track the latest completed CPU copy, explicit blank fill and sampled black source. The source scan is bounded and occurs before copying.
  • The owner target120 reference shows GOP published, three swaps/copies/retirements, first copy at 114.231 seconds and software vsync start1/arm0. SpringBoard and BackBoard are active, with no desktop observation. The photo has no matching upload receipt. v62 reaches 220 processes with four copies and SpringBoard S1 in a CFRunLoop Mach receive. Publish to first copy remains about 94 seconds. v63 removes the terminal report and reaches visible Hello setup per the owner. Animation stutters and the screen goes black about four seconds later. A short power press did not restore it. v64 adds last copy, blank-fill and dark-source timing in a 240-second diagnostic. The home screen remains unverified.
  • V37 mode9 limits the report to two processes and one line per sampled thread. It records the current CPU scanout writer thread ID. Host row/line budget and final FAT checks pass. BOOTea3e7c10 owner photo shows both processes and clipped0. Hold0/writer0, two frame retirements. BackBoard samples setGrayscale and SwapEnd. SpringBoard samples the recurring LaunchServices lock and a synchronous Mach wait.
  • V34 adds an opt-in terminal scanout hold synchronized with the Legacy work loop, and reports display publication and first CPU surface copy times. Host compile, prelink and final FAT checks passed. BOOTc9c49879 uploaded and reboot requested. Owner photo shows hold1 after bounded retries, publication at 18527 ms and first CPU copy at 143217 ms, with five retirements. BackBoard accessibility bundle code executes. Home screen remains unverified.
  • V32 adds board-side counters for the existing GopFramebuffer software vsync events. BOOT6b692880 rebuilt and passed prelink and final FAT verification against v31, retaining the same arguments and non-kernel inputs. Owner photo shows timer start1/arm0/notify0, open7 and three successful frame retirements. At 60 Hz refresh0 matches the component gate.
  • BOOTc96f86d7 is a 125-second comparison to BOOTbb4d8474 adding only a synthetic Wi-Fi address. Owner photo shows the same open7/swap2/copy2/retire2 as baseline; SB sample is in the Control Center default module-list property-list path versus a LaunchServices lookup in baseline. Independent live snapshots do not establish relative progress or causality. No confirmed UI improvement; stop repeating address comparisons. See evidence/display/wifi-address-125-v30.
  • Original 21H461 MobileGestalt static control-flow audit confirms a conditional chosen Wi-Fi property path, sdio/wlan/marconi-wifi fallbacks and an IONetworkController-related fallback. An earlier branch can bypass it. This is not proof of runtime invocation, property acceptance, timeout, or the T970 seeding cause. See evidence/display/mobilegestalt-wifi-audit.
  • BOOTfec656ec adds only a synthetic local Wi-Fi address property to observed BOOTaeb13ffc. At target90 owner photo still shows open5/swap0, lsd journal-recovery and XPC database-seeding waits, and SB BackBoard screen-info wait matching the baseline caller chains. Single independent samples occur before first frame, and runtime property consumption is unmeasured; no immediate improvement or definitive cause established. See evidence/display/wifi-address-control-v29.
  • Mode8 BOOTf69965a7 target90 photo captures lsd threads5-7: thread5 handles an XPC request waiting for database seeding, threads6/7 are in workqueue entry; report end marker unclipped. The seeding worker and Wi-Fi lookup were not observed, and thread order can change across boots. See evidence/display/lsd-later-mode8-v28.
  • Poco F1 iOS16 port reports the same Control Center/LaunchServices/unfair-lock caller chain and traced its stall through lsd seeding and a Wi-Fi address wait. Original 21H461 MobileGestalt contains relevant address and IONetworkController strings; actual T970 v24 ADT lacks both address properties. BOOTaeb13ffc target90 photo shows lsd7 threads, first4 sampled: install journal recovery/dispatch queue, inactive installs/dispatch group, and an XPC call waiting for database seeding. SB still waits for BackBoard screen info, swap0. lsd5-7, seeding owner and cause are unobserved; strings do not prove Wi-Fi lookup. See docs/ui-reference-comparison.md and evidence/display/springboard-mode7-v27.
  • BOOTe82eec17 target300 owner photo shows main1, CPU8, open7, swap7/0, copy7 and retire7; upload was successful but not read back. SB waits on an unfair lock under the same LaunchServices/Control Center caller chain sampled in the independent target125 boot. BB first thread is in CFRunLoop Mach receive. These two snapshots neither prove continuous refresh nor establish a permanent deadlock. Owner requests shorter future waits. See evidence/display/display-late-v26.
  • Host prepared BOOTb6e55159 from observed BOOTbb4d8474, removing only the terminal 125-second runtime report argument. FAT roundtrip passes. After two failed pre-upload attempts the authorized BOOT upload succeeded without readback. Owner observed unchanged Apple logo for over three minutes following reboot, without other screen or reboot; background progress, frame updates and desktop remain unverified. check-platform stops before DT/ADT because the sibling framework HEAD differs from the reviewed pin. See evidence/display/display-continuous-v25.
  • BOOTbb4d8474 owner observed Apple logo; photo14:40:13 shows swap2/0, transfer2, copies2, retire2. BOOT08b90255 previously panicked on uninitialized vc_progress_lock via first swap console handoff. Guard now matches t970-novc bootstrap. SpringBoard sample reaches LaunchServices database context from Control Center module discovery; sustained desktop pending. See evidence/display/display-novc-v24.
  • BOOTe44011cb photo03:08:38 links BB wait to QuartzCore CAMetalContextCreate polling IOAcceleratorES, at most 300 sleeps of 100ms; SB waits for main screen info, open6/swap0. T733 48f documents CPU frames through NativeLegacyDisplay. BOOT08b90255 keeps kernel and changes report target to 125s; FAT comparison passes, ADT differs only in random-seed. See evidence/display/ui-cpu-fallback-v23.
  • BOOT5385b6ce owner photo03:00:42 shows three pending queues drained, MG done134, BB161, SB75->78, display open6/fail0/swap0. No constrained head means Q cap zero is absent data, not a measured cached limit. v22 reuses exact v21 kernel with existing stack mode1 to locate current BB/SB main waits; host image checks pass, hardware stack result pending.
  • v21 BCM2837 EDGE width fallback uses registered SMP CPU/cluster counts only when E/P counts are both zero. Previous BOOT705d4160 has all eight ADT CPU cluster-type absent (SMP), cached constrained cap0 and callback progress. Actual prepared-function ASan/UBSan tests cover SMP1/8, E/P precedence and non-BCM guard; kernel/prelink/FAT checks pass. BOOT5385b6ce hardware result pending; this is not validated heterogeneous scheduling or desktop. See evidence/display/edge-smp-v21.
  • BOOT705d4160 mode6 owner photo02:38:12 captures all three processes/end marker unclipped. Constrained cap/active/busy=0/0/0; MG done35->37 while BB25/SB53 unchanged across 500ms deadlines. Runtime callback continues; investigate EDGE E/P counts versus current SMP topology before any scheduling change. See evidence/display/ui-queue-progress-v20/device-result.json.
  • BOOT6ef0db8c photo01:42:52 shows MG/BB/SB req4/6/4 idle2/1/2 creator0 and open2/swap0; flags14=death+delayed scheduled,10=delayed. Single snapshots do not prove lost wakeups; SB tail remains offscreen. v20 mode6 takes two read-only queue/admission snapshots per process 500ms deadlines apart, converts absolute time with kernel API, and performs no user VM reads or scheduling mutations. Host helper/kernel/pack checks pass; device result pending, see evidence/display/ui-queue-progress-v20.
  • BOOT10dbedd8 photo01:27:03 batch captures MG/BB/SB headers: MG wq7/0/6 and no limit flags, BB2/0/1, SB2/0/0; display open2/swap0. SB tail/end marker offscreen, clipping status unverified. Shared semaphore wait-event value does not prove same semaphore. v19 adds read-only workqueue req/flags/idle/creator/last-call timing snapshot and compact batch output; host helper/ABI checks pass, hardware pending.
  • BOOT6da8d322 photo01:17:48 target90/main1/n109 shows MG threads5-7 same16-frame chain, ending at MG global lock call; thread8 start_wqthread, display open2/swap0. Owner/callback execution unresolved. User requested batch capture: mode5 samples BB/SB/MG first8 threads each with16 frames, wait events/priorities/tids and try-lock workqueue info, deduplicates identical sampled stacks. Host helper/ABI checks pass; hardware pending. See gestalt-workers-v17 and ui-batch-v18.
  • 2026-11-04 original MG review identifies global-queue semaphore helper using MobileGestaltRunLoopMode, with syscfg fallback matching AppleDiagnosticDataAccessReadOnly. Original kext requires Apple NOR/NAND config provider absent on this board, but timeout semantics mean absence alone is not proof of permanent stall. Mode4 samples helper threads5-8 previously outside visited4. Host tests/ABI compile pass; hardware pending. See gestalt-workers-v17.
  • BOOT91025540 photo01:09:00 target90/main1/n107 confirms MobileGestaltHelper95 threads8/visited4/busy0, FP9/16 frames error0. Helper handles NSXPC request through _MGServerCopyAnswerWithError then waits in semaphore inside MobileGestalt; precise internal provider unresolved. Display open2/swap0.90 seconds sufficient for this target snapshot. See gestalt-stack-v16/device-result/symbols.
  • BOOT93bd51e8 photo01:03:24 BB thread2 sixteen frames/error0 reaches RemoteHID AACP activate -> BTSessionAttachWithQueue -> MGGetBoolAnswer -> MobileGestaltExtensions synchronous XPC. Original BT call queries bluetooth; original com.apple.mobilegestalt.xpc job runs MobileGestaltHelper. Mode3 samples helper first2 threads,16 frames; next target90 per owner timing request. Host mode3 tests/ABI compile pass; hardware pending. See ui-stack-deep-v15 and gestalt-stack-v16.
  • 2026-11-04 ui-stack-deep-v15 expands only mode2 selected BB FP chains to16 frames to find caller above NSXPC synchronous send; mode1 remains8. Actual ASan/UBSan16-frame cap test and Mach-private compile pass. Hardware pending; evidence/display/ui-stack-deep-v15.
  • BOOTdbb7921a photo00:58:17 confirms BB thread2 eight frames/error0 in synchronous NSXPC reply wait through _sendSelector:withProxy:arg1:arg2:, thread3 one frame/error0 at start_wqthread; open2/swap0. Slide0xe784000 cross-checked against original mach_msg2 PC; XPC caller/peer remains unresolved. See ui-stack-other-v14/device-result.json.
  • 2026-11-04 ui-stack-other-v14 adds diagnostic mode2 for BB queued threads2-4, each bounded to8 frames, preserving mode1 and no-stack default. Host ASan/UBSan selection/reference checks and Mach-private compile pass. Hardware pending; see evidence/display/ui-stack-other-v14.
  • BOOTa708fadf owner photo00:46:53 confirms main1/n147/cpu8/sec7, BB57/SB27 each8 FP frames/error0, display open2/swap0. UUID-matched symbols place BB in IOHIDSessionOpen semaphore wait after dispatch_async initialization submission and SB in BKSDisplayGetMainScreenInfo Mach message. Does not identify a missing touch driver. See ui-stack-v13 device-result/symbols; next sample BB other threads.
  • 2026-11-04 ui-stack-v13: opt-in isolated worker reads at most8 FP frames for each UI process first queued thread after releasing locks; reporter uses20 scheduler deadlines and hides partial buffers. Actual ASan/UBSan helper and current Mach-private compile pass. Live stacks are not coherent snapshots; VM worker is not cancelled on timeout. New image hardware results pending; see evidence/display/ui-stack-v13.
  • BOOTd80a3773 target120 owner photo confirms main1/n148/cpu8/sec7, BB57/SB27, display opens2 but no swap/frame, KeyStore opens49/calls194. Saved PC/LR of3 threads per target and slide10914000 captured with busy0. Original cache/symbol UUIDs match; BB queue-first PC maps semaphore_wait_trap+8 and LR libdispatch semaphore-wait variant+24; other rows map mach_msg2/workq. Current sampler has no scheduler-state or user stack, so an upstream dependency is not yet established. Next capture bounded caller frames in a separate worker.
  • UI runtime follow-up: BOOTdb0121c9 target120 confirms BB57 and display client2/open2/fail0, all swap/frame counters0. Catalog AppleKeyStoreState42ff83e is now linked behind explicit RAM-only gates: BOOTb9cc7afb target60 confirms stage4/ready1/open1/call1/selector0 success, no frame. BOOTf6fd6636 confirms768MiB request manages pages0x2b187, no earlier display by60. Continuous BOOTec912b09 owner observation remains color bars only. See ui-call-v9, key-state-v10 and memory768-v11.
  • V9 owner photo target60 confirms main1/n69/cpu8/sec7, SB27 spawn return1/e0, BB0/e-1, path-copy-errors0, both job-lookups0/e-1, display stage8/mapped1/published1 and all client/frame counters0. Associated with latest prepared/uploaded BOOT45531047 by sequence and unique v9 field, without screen image ID or device hash readback. Host original plist/cache contains automatic backboardd job; runtime import not proven. Fixed T733/umi/sheng code review identifies missing KeyStore state registration and much smaller managed RAM as concrete audit targets, not established causes. Same-kernel target120 BOOTdb0121c9 packed/round-trip verified, not uploaded. ASan/UBSan helper tests pass after updating report API stand-ins; platform checker refuses stale reviewed framework revision.
  • UI-job-v8 kernel049897a9/BOOT1939b59d adds PID1 namei basename lookup counts and latest matching open error for BB/SB plists using existing kernel path copies only. Actual helper ASan tests cover filters/relative paths/errors/ring/bounds. Job lookup is not parsed/imported job proof; path/return association is best effort. Same eight-core60-second display diagnostics and policy. Hardware outcome pending; see evidence/display/ui-job-v8.
  • Client-v4 confirms zero display clients/swaps. Native UI nonzero-exit trap v5 did not trigger. V6 saved-path sampling was too late (exec_activate_image already frees strings), so its zero target counts are invalid absence evidence. Corrected v7 BOOT535c53e9 observes SB1/27/0/activated1, BB0, total89 activations at60; positive SB control validates path capture. Does not rule out pre-activation failure, alternate path or later BB launch. Actual helper ASan checks and pre-free placement check pass. Next inspect launchd job import/early spawn.
  • Client-v4 adds relaxed diagnostic counters for client enter/open/fail, swap accept/reject, transfer/status, copies, retirement and vsync notifications. Actual formatter/counter block passes ASan bounds/null/state checks. Kernelb81e0783 builds/prelinks; independent payload/BOOT/eight-core preparation passes. No rendering decisions changed; counters are best-effort snapshots. Hardware client/frame outcome pending; see client-v4.
  • BOOT0854aff6 owner photo18:12:19 confirms display stage8/meta0/surface0/mapped1/published1, main1/n69/cpu8/sec7. Actual display class/init, IOSurface readiness, GOP mapping, original start and publication succeeded. Client opens, swaps, CPU copies and rendered desktop remain unverified; backboardd not observed in snapshot. See status-v3/device-result.json. Umi uses the same real IOBSD/IOSurface lifecycle boundary; do not copy its board geometry.
  • Owner requested full continuous boot: same-kernel BOOTc39efc0f prepared with8 CPUs, runtime sampler absent, CPU transfer/validation/retirement and software vsync60 enabled. Independent packing checks pass; rendering and physical refresh unverified. Abstract backend guards remain. See evidence/display/continuous-v1 upload and pending hardware observation.
  • BOOT5e318d75 target60 owner photo17:09:08 confirms main1/n69/cpu8/sec7, SpringBoard27/runningboardd26 and IOMFB_bics_daemon86; backboardd not observed. No dedicated display counters yet, so publication/mapping/presentation not qualified. BOOT-only upload exit0; next add direct stage/status sampling.
  • Display late archive linked after removing duplicated board-owned early frame counters. Kernel0adf72f3 prelink and independent BOOT5e318d75 packing checks pass; isolated work .config enables Legacy only, defaults unchanged. Eight-core target60 explicit GOP/PM integration probe; CPU presentation off. Runtime report lacks dedicated publication counters, so main1 alone will not verify display. Hardware observation pending; see evidence/display/integration-v2.
  • T970 display registration/mapping/observation callbacks implemented behind explicit t970-display-start=1. Current XNU compile and actual GOP board callback-symbol checks pass; nine native_legacy original-family aliases plus original class/kernel bindings still require final linking. Geometry helper passes17 rejected and2 accepted assertions. No archive/BOOT or device publication/rendering result; failure cleanup not API-injection tested. See evidence/display/registration-v1.
  • GopFramebuffer cf3b429 NativeLegacyDisplay compiled with current T970 XNU recipe and Wall/Wextra/Werror. Actual Mach-O relocation audit confirms358 virtual entries and24 expected owned methods/abstract leaves. Original/candidate ABI audit checks native-symbol rebound slots, nine abstract leaves, seven IOSurface getters and unchanged graphics text. Object only: registration callbacks, linked archive, runtime mapping/publication/presentation remain pending. See evidence/display/abi21h461.
  • BOOT3da265b4 target60 owner photo confirms main1/n67/cpu8/sec7, SpringBoard27/runningboardd26, Data0/policy0/stage4 and all-core positive timer/SGI snapshots. Backboardd not observed; free0x183 excludes reclaimable memory, not sole OOM proof. Sustained runtime, controlled CPU workload and desktop remain unverified. See runtime-cache60/device-result.json.
  • BOOTeeeba83b owner photo19:36:40 shows requested120-second runtime report: genuine main1,109 processes, watchdogd absent, SpringBoard27/backboardd56/runningboardd26, Data0/policy0/stage4,964876 verified blocks. Kernel deadline-wait/report executed; rate accuracy unmeasured. Interface-service process presence is not proof of rendering or functional services. Display backend remains disabled; next phase is display handoff/provider and independent staged SMP qualification.
  • BOOT 933a5d77 device screen is confirmed through END slots=87. Corrected SM8250 GCC gate passes; HCE=1 HCS=10f IS=400, both queue run-stop bits set and both doorbells zero, UTRLBA=9b296000. The sole valid SMR 84020820/S2CR 4 exactly matches the captured display SID 0820 mask 0402; preserve slot 04 and CB4. Candidate residues in invalid slots 02/03 are not active routes. No DMA, SCSI or root read was attempted.
  • Uploaded deliberate after-MMU BRK control 150ed5ff9d73d81b17d3f6d32e609b9a9e42fdfe0397da7c5eea7d62f7ce7b4d, using patched Heimdall, exit 0. The device reset at about 50 seconds, matching the reviewed BRK path; original BOOT restoration is still pending. C startup and console behavior are not exercised.
  • After-MMU BRK control image prepared and extracted from FAT: BRK word, unchanged PE_create_console call, guard bytes, vector branches and preserved IRQ/FIQ slots verified. Eight host tests passed; hardware BRK delivery and the ~50-second timed reset were observed.
  • Added explicit after-MMU BRK control mode to qualify diagnostic execution before C startup. It preserves PE_create_console call bytes, uses the same reviewed fault handlers, and expects the distinct 50-second BRK path. Device execution and fault routing remain unverified until observed.
  • Guarded image e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29 did not reset within 60 seconds. Neither PE_create_console return nor a fault terminal is established. Next is a deliberate after-MMU BRK control to qualify the diagnostic path independently of C startup; no spin-loop diagnosis is claimed.
  • Uploaded guarded PE_create_console return probe e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29, using patched Heimdall, exit 0. Measured outcome and original BOOT restoration remain pending. Fault outcomes classify early paths and do not by themselves identify the failing function.
  • Host checks for guarded PE_create_console return passed: eight tests, verified 112-byte guard code and all modified vector/panic branches inside the actual FAT kernel, with IRQ/FIQ/reserved slots unchanged. Runtime outcome and device BRK control remain unverified.
  • Added an opt-in early-fault diagnostic restricted to PE_create_console return in arm_init on repaired kernel bfb50a1a. It verifies the compiled active-vector selection, preserves IRQ/FIQ/reserved slots, and terminates sync/SError/panic/BRK paths at 20/30/40/50 seconds. This is not a normal kernel, text/register log or device fault result.
  • Repaired PE_init_printf(TRUE) return checkpoint was not observed (f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7). User photo shows retained firmware/loader text and entry bars, not a confirmed XNU text log. Restored PE_create_console may stop earlier; old-kernel gc_enable localization cannot be assumed for this new kernel.
  • Uploaded repaired-console PE_init_printf(TRUE) after-return probe, image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7, using patched Heimdall, exit 0. Device return result, text rendering and original BOOT restoration are pending; transfer alone does not verify the repair.
  • Repaired kernel bfb50a1a009f4dd08d54cb94d6187d768c7a5ef976427abd235756874f38473c compiled, linked and prelinked successfully. Mach-O checks verify PE_init_printf(FALSE) immediately precedes unconditional PE_create_console. Build configuration checks passed for 61 patches and 19 pinned modules; device return probe is pending.
  • Human timing of about four seconds for console-state image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341 supports gc_initialized low bit 0 and PE_putc NULL before gc_enable. This supports missing console initialization under the experimental skip patch, but does not identify the exact faulting instruction.
  • Replaced the experimental skip-console patch with t970-console-bootstrap.patch: arm_init now always installs PE_init_printf(FALSE) before PE_create_console, restoring callback and console/lock setup rather than continuing with uninitialized console state. Kernel rebuild and prelink passed; the final Mach-O has adjacent unconditional PE_init_printf(FALSE) and PE_create_console calls. Device return checkpoint remains pending.
  • The handed-off t970-skip-early-console.patch keeps PE_create_console/PE_init_printf opt-in via t970-console as an experimental workaround. It does not prove an Apple-console hang; the latest user result places the unobserved checkpoint before initialize_screen.
  • The live DT contains many alternative panels; the boot selector identifies S6TUUM3 rather than the S6TUUM2 candidate.
  • DRM mode geometry is landscape while wm and touch coordinates are portrait; display/input orientation must be mapped explicitly.
  • At capture time DPMS was Off and brightness was zero; this records Android runtime state, not a display failure.
  • GopFramebuffer is deferred at Step 2 because the T970 UEFI GOP handoff and display power callbacks have not been established.
  • The bring-up console patch populates vinfo and maps the UEFI framebuffer only so the panic screen can draw text; no display driver, panel init or XNU framebuffer integration is implemented and display remains planned.

Completion criteria ​

  • A known image has correct geometry and colors, followed by working userland presentation and brightness control.

Current limits ​

  • Framebuffer physical address, stride, pixel format and UEFI GOP handoff are not verified by the mode list.

Next action ​

  • Keep v69 as the visible Setup baseline. Implement and verify touch and Setup completion separately. The v68 matched RAM-Data control is retained for attribution.
  • V31 confirmed spare RAM Data capacity at target125. V35 reports hold0 and reproduces the v34 BB QuartzCore mutex and SB LaunchServices context waits. V36 shows SwapEnd and dispatch group wait in BackBoard, but screen clips before SpringBoard. V37 fits both processes on screen. Capture the resolved SpringBoard unfair-lock owner, then map that ID to the peer stacks. Compare source extent with a straight-on photo only if both show the same frame.

Evidence ​

Input ​

planned

Hardware and dependencies ​

  • Touch binds to fts_touch (stm,fts_touch), I2C bus 4 address 0x49 on controller 0x994000. DT IRQ GPIO is 15, with irq_type 0x2008.
  • Touch DT supplies are pm8150_l14 and pm8150_l13; firmware path is tsp_stm/fts1ba90a_gts7xl.bin. Android touch axes span X 0-1751 and Y 0-2799.
  • S Pen binds to wacom_w90xx (wacom,w90xx), I2C bus 9 address 0x56 on controller 0x88c000. DT IRQ GPIO is 136 and firmware path is epen/w9021_gts7xl.bin.
  • Wacom DT max_coords=<0x5880 0x3750>, max_pressure=4095 and invert=<0 1 1>; GPIO keys, power-key and hall inputs are also enumerated.

Configuration ​

  • The live DT records GENI I2C resources, supplies, IRQs and coordinate transforms; no XNU HID or touch component has been selected.

Procedure ​

  • Read /proc/bus/input/devices, getevent -lp and bound I2C driver links; correlate them with the exact touch and Wacom DT nodes.

Development findings ​

  • The stock fts1ba90a family uses command 0x22 followed by a five-byte identity read, expected bytes 39 36, and 16-byte FIFO records. The T970 firmware name and stock board wiring match this reference. v70 first samples GCC branch state and GPIO12/13/15 without transactions. It skips the GENI engine if any required clock reports off.
  • v69 owner reports swipe and power-key presses do not affect the visible Hello screen. No XNU touch or key service has been wired for this image. Stock Android enumerates KEY_POWER on PM8150 PON separately from touch.
  • SM-T733 uses Focaltech over GENI SPI and separate PMIC-key and HID bridges. Its 21H461 touch HID descriptor and original IOHIDEventDriver dispatch bindings are ABI references; its Focaltech transactions, hardware geometry and key wiring need a separate board match.
  • T970 touch I2C uses QUP SE5 at 0x994000 and GPIO12/13, with the stock GPI0 controller at 0x900000 and SMMU SID 0x5b6. The hardware-tested umi ST FTM5 path uses SE at 0xa94000 and a different GPI wrapper. Compare the exact T970 chip identity and event format before reusing the transport or HID path.
  • The actual boot kernel contains all three named input firmware blobs. A unique common image base and 24-byte builtin_fw layout are reconstructed through AArch64 RELATIVE relocations; source offsets, lengths and SHA256 are recorded in builtin-firmware.json.
  • The disabled board I2C nodes describe measured controller/IRQ resources and input firmware names/coordinate properties; clock/regulator/HID implementations remain planned.
  • The filesystem-only capture did not find the three input assets; the subsequent builtin-kernel inspection above resolves their source and hashes.
  • The bound touch driver is STM FTS; the template's Novatek implementation is not established as compatible. Wacom reports a separate input device and requires its own protocol handling.
  • Step 2 keeps ShengNovatekTouch, QcomGeniSpi and ShengHidInput unselected: their Novatek/SPI/sheng dependencies do not match the measured STM FTS/I2C and independent Wacom input paths.

Completion criteria ​

  • Touch contacts preserve stable IDs and releases, coordinates map correctly to the display, and keys/pen produce the expected HID reports.

Current limits ​

  • Firmware hashes and static I2C/IRQ inputs are established. Protocol transactions, sequencing and XNU event delivery remain untested; no input events were injected.

Next action ​

  • Temporarily vote SE5 and qualify the inherited GENI image with the known wrapper AHB votes. Restore the original clocks before proceeding to pins, rails, 0x49 identity and FIFO. Map PM8150 PON keys separately.

Evidence ​

GPU ​

planned

Hardware and dependencies ​

  • KGSL reports Adreno650v3, seven power levels and a maximum clock of 670000000 Hz; the GPU DT chipid is 0x06050002.
  • GPU register window: 0x03d00000 + 0x40000. GMU register window: 0x03d6a000 + 0x30000; PDC windows are also present in the DT.
  • a650_gmu.bin is 41548 bytes with SHA256 df79fa8482fcc7587bb239b9c9e2b24bce4729893b990fe3f82b30da8175b01c.
  • a650_sqe.fw is 31632 bytes with SHA256 b4c27420fd6a5c6b511b254cc0fad8cdd40eea38ceb3418f895a1084f4460487.

Configuration ​

  • The live DT records GPU/GMU interrupts, clocks, supplies and SMMU resources; no UniXNU GPU backend or Metal ABI has been selected.

Procedure ​

  • Read KGSL identity and frequency nodes, list GPU firmware files and calculate the GMU/SQE hashes without executing GPU commands.

Development findings ​

  • Disabled GPU/GMU overrides now preserve the stock named register windows and interrupts. Unverified shared iommus references are removed; no GPU DMA mapping is invented.
  • Six A650 files include GMU/SQE and the split signed ZAP image.
  • The measured GPU is A650, so A740 register sequences and firmware cannot be assumed compatible. Presence of a615_zap files alone does not establish which secure firmware the running driver loads.
  • Known GMU/SQE files and hashes are listed in proprietary-files.txt as inventory only; no GPU component or consumption recipe is enabled.
  • Step 2 retains the SoC A650Gmu operations as a future reference only. Adreno740 is scoped to A740/SM8550 and AdrenoMetal depends on that backend; neither is selected for T970.

Completion criteria ​

  • GMU boots, bounded GPU submissions and fences complete, memory mappings remain valid, and a known rendered image reaches a Metal client and display.

Current limits ​

  • No GMU bring-up, command submission, DMA/SMMU ownership or Metal rendering was tested under UniXNU.

Next action ​

  • Compare the measured A650 resources and firmware hashes with the candidate SM8250 GMU implementation and document the loaded secure-firmware path.

Evidence ​

Network ​

planned

Hardware and dependencies ​

  • wlan0 maps to PCIe endpoint 0000:01:00.0, vendor/device 17cb:1101, subsystem 17cb:0108, bound to cnss_pci behind controller 0x01c00000.
  • The endpoint firmware directory /vendor/firmware/qca6390 contains amss20.bin, m3.bin, bdwlan variants and regdb.bin.
  • The live DT WLAN node is named qcom,cnss-qca6490@b0000000 and declares compatible qcom,cnss-qca6490; the naming difference is retained as an unresolved input.

Configuration ​

  • The PCIe DT records clocks, supplies, resets and iommu-map inputs; no UniXNU network component or OS network interface has been selected.

Procedure ​

  • Read PCI IDs, driver links, wlan0's device path and firmware directory names; do not collect SSIDs, MAC addresses or network traffic.

Development findings ​

  • Eight Wi-Fi files and two Bluetooth files are hashed. The Wi-Fi board-data variant is not selected.
  • The bound PCI endpoint and firmware-directory name are more specific observations than a generic SoC Wi-Fi assumption; exact chipset/revision must be reconciled with the driver source.
  • The network collection exits 1 because optional firmware_mnt globs do not match; PCI and qca6390 directory output was still captured.
  • Ath12kWifi is not selected at Step 2: its catalog hardware inputs do not establish compatibility with PCI 17cb:1101 and the unresolved QCA6390/QCA6490 naming on this board.

Completion criteria ​

  • Scanning, association, address configuration and sustained RX/TX traffic pass using the selected firmware and XNU network interface.

Current limits ​

  • No Wi-Fi scans, reconnects, traffic tests or firmware loading were initiated; the DT/firmware naming difference is unresolved.

Next action ​

  • Resolve PCI 17cb:1101 and the board firmware selection in the matching Android driver before choosing a UniXNU network implementation.

Evidence ​

Audio ​

planned

Hardware and dependencies ​

  • ALSA card 0 is kona-mtp-snd-card with playback/capture PCM endpoints. LPASS is exposed at 0x17300000 and an ADSP loader is present.
  • Four devices at I2C bus 6 addresses 0x40-0x43 bind to the cs35l41 driver behind controller 0xa8c000.
  • ADSP firmware segments exist under /vendor/firmware_mnt/image/adsp.*; /vendor/firmware contains cs35l40-spk-dsp1-spk-prot firmware files.

Configuration ​

  • The DT sound node declares qcom,kona-asoc-snd and bolero_codec among its codec names; no XNU audio route or DSP service is configured.

Procedure ​

  • Collect ALSA card/PCM lists, bound amplifier links and firmware file names, then inspect the sound and ADSP DT nodes.

Development findings ​

  • 27 ADSP/amp firmware and service-description files are hashed; loaded DSP routes are not inferred.
  • The bound amplifier driver is cs35l41 while available DSP firmware filenames use cs35l40; file names alone do not prove the loaded amplifier firmware or route.

Completion criteria ​

  • Each declared route plays or records the selected audio format and handles start/stop through the required DSP and codec services.

Current limits ​

  • No playback, recording, mixer writes or DSP restart was performed; loaded firmware, codec wiring and actual routes are not verified.

Next action ​

  • Trace the bound amplifier driver and Android audio configuration to determine firmware selection, MI2S wiring and the first playback route.

Evidence ​

Power ​

planned

Hardware and dependencies ​

  • Power-supply devices include max77705-charger, max77705-fuelgauge, pca9468-charger and sec-direct-charger.
  • MAX77705 is at I2C bus 2 address 0x66 and PCA9468 at 0x57, behind controller 0x980000.
  • The battery snapshot reports Li-ion, capacity=100, voltage_now=4252000, temp=289 and charge_full_design=10090000; raw vendor values are preserved without assuming units.
  • Android exposes power states freeze/mem and mem_sleep choices s2idle/[deep]; CPU/GPU/DDR/WLAN thermal-zone names are recorded.

Configuration ​

  • Board regulator, RPMh and power-supply declarations are preserved in the live DT; no XNU power policy is configured.

Procedure ​

  • Read selected power-supply attributes, available sleep states and thermal-zone names; do not write charging, regulator or suspend controls.

Development findings ​

  • v67 adds an opt-in root-domain watchdog panic detail with PM machine state, wait reason, current and requested power states, pending count and first pending service class. It also retains a 240-second frame report if no watchdog fires. Kernel prelink and final BOOT FAT checks pass. The device reaches target240 with a completed blank GOP fill 28 ms after the last normal CPU copy. No PM watchdog panic occurred before the report.
  • v65 with noidle=1 still shows Hello and then turns black after about ten seconds. The owner photo shows no panic text. v66 uses the sleep-disabled ADT default also used on T733 and dada; it retains noidle and adds only that property to the tested payload.
  • v64 owner photo confirms Sleep/Wake hang detected at IOPMrootDomain.cpp:12812. The linked stack reaches IOService::watchdog_timer_expired; this timer belongs to the PM root domain. The original triggering request and blocked child are unknown. v65 changes only noidle=1 on the continuous v63 image and preserves the power watchdog.
  • Advertised Android sleep states and power-supply entries do not establish UniXNU suspend, charging support or physical presence of every listed supply type.

Completion criteria ​

  • Battery units match measurements, charging and thermal controls operate correctly, and each supported sleep/resume transition restores dependent peripherals.

Current limits ​

  • Vendor battery units, firmware ownership and state transitions remain unverified; The v64 panic identifies a PM timeout but does not establish suspend or resume functionality.

Next action ​

  • Read the matching battery/charger driver sources to establish units and ownership, then map required regulators and clocks for the first boot path.

Evidence ​

Image assembly ​

planned

Components: SoftwareAES, XnuPrelink.

Hardware and dependencies ​

  • Local archive: ipsw/iPad_Pro_HFR_17.7.11_21H461_Restore.ipsw.
  • BuildManifest.plist reports ProductVersion 17.7.11 and ProductBuildVersion 21H461.
  • BuildManifest.plist lists SupportedProductTypes iPad7,1, iPad7,2, iPad7,3 and iPad7,4.

Configuration ​

  • OS profile ipados-17.7.11-21H461 retains the reviewed XNU/Apple identity/prelink settings and archive recipes.
  • package/firmware provides the concrete firmware overlay. Boot packing selects header v2, raw kernel, separate DTB at base+0x1f00000, kernel at base+0x8000 and ramdisk at base+0x2000000.

Procedure ​

  • Read BuildManifest.plist from the local IPSW using Python zipfile and plistlib to identify its OS version, build and product types.

Development findings ​

  • BOOTbb4d8474 owner observed Apple logo; photo14:40:13 shows swap2/0, transfer2, copies2, retire2. BOOT08b90255 previously panicked on uninitialized vc_progress_lock via first swap console handoff. Guard now matches t970-novc bootstrap. SpringBoard sample reaches LaunchServices database context from Control Center module discovery; sustained desktop pending. See evidence/display/display-novc-v24.
  • BOOTe44011cb photo03:08:38 links BB wait to QuartzCore CAMetalContextCreate polling IOAcceleratorES, at most 300 sleeps of 100ms; SB waits for main screen info, open6/swap0. T733 48f documents CPU frames through NativeLegacyDisplay. BOOT08b90255 keeps kernel and changes report target to 125s; FAT comparison passes, ADT differs only in random-seed. See evidence/display/ui-cpu-fallback-v23.
  • BOOT5385b6ce owner photo03:00:42 shows three pending queues drained, MG done134, BB161, SB75->78, display open6/fail0/swap0. No constrained head means Q cap zero is absent data, not a measured cached limit. v22 reuses exact v21 kernel with existing stack mode1 to locate current BB/SB main waits; host image checks pass, hardware stack result pending.
  • v21 BCM2837 EDGE width fallback uses registered SMP CPU/cluster counts only when E/P counts are both zero. Previous BOOT705d4160 has all eight ADT CPU cluster-type absent (SMP), cached constrained cap0 and callback progress. Actual prepared-function ASan/UBSan tests cover SMP1/8, E/P precedence and non-BCM guard; kernel/prelink/FAT checks pass. BOOT5385b6ce hardware result pending; this is not validated heterogeneous scheduling or desktop. See evidence/display/edge-smp-v21.
  • BOOT705d4160 mode6 owner photo02:38:12 captures all three processes/end marker unclipped. Constrained cap/active/busy=0/0/0; MG done35->37 while BB25/SB53 unchanged across 500ms deadlines. Runtime callback continues; investigate EDGE E/P counts versus current SMP topology before any scheduling change. See evidence/display/ui-queue-progress-v20/device-result.json.
  • BOOTdb0121c9, b9cc7afb, f6fd6636 and continuous ec912b09 were independently packed and BOOT-only uploaded, with receipts and owner observations kept together. Header v2, exact existing FD/firmware DTB, trust and RAM seed are preserved. New key-state and register diagnostics use opt-in runtime inputs; defaults and partition geometry remain unchanged.
  • BOOT95accf53 owner photo confirms CPU1 entry3 (matched CPU data and reached common_start boundary); C marker4 not seen. Target10 snapshot main0/n2 is earlier than old120 samples. Added secondary-only common/TCR/table/SCTLR/trampoline markers without changing CPU setup values. See entry-trace/device-result.json and MMU trace records.
  • Two-core BOOT9d4dc888 observed main1 and106 processes but one CPU available; CPU1 phase4/PSCI0/timer0/SGI0. Reset table, CPU1 affinity and reset handler match. Entry execution remains unconfirmed. Added four diagnostic entry milestones and shortened future target wait to10 seconds; default CPU0 unchanged,8-core not uploaded. See evidence/cpu and docs/smp-bringup.md; source/build checks are not hardware SMP qualification.
  • BOOT97271e99 photo18:22 confirms launchd main1/err0 and managed pages0x1b709 (~439MiB):512MiB EFI-owned request works. BOOT911a462a new Data build failed AMFI No PMGR because isolated output silently used FirstPassStub. Remove implicit stub, require a reference, audit real PMGR340 slots and reject missing registration symbols/archive members in independent pack checks. Repaired6b83f4e6 uploaded exit0; photo18:42 shows watchdogd PID102 SIGTRAP. Enforced exact-device/writable/APFS mount success gate precedes exec, so Data mount success is inferred, not a Data write/persistence test. Original watchdogd host branch and launchd root-owned watchdog-only policy checks pass with explicit OS API substitutions; policy not applied.
  • BOOT cfbd84ba photo confirms stage4: ID/VALID/S2CR accepted, direct FAULT restore200ff succeeded without fallback, allRestored/mappingsUnchanged=1 and GFSR=0. Six context states captured; CB0..4 already configured with FSR400 of unknown age, CB73 SCTLR3ab3a706 is not a verified free bank. No context writes, DMA or UFS commands occurred.
  • Combined field diagnostic BOOT cfbd84ba34fc03b50661b46c9e22fe59c43ba651bca6967da49f1df1ec373e75 prepared from source7ee2918/kernel53e9e68c. Thirteen host tests, input-stable kernel build, independent FAT/arguments/FD checks and DT/ADT check passed. BOOT-only upload exited0; actual VALID/S2CR/restoration/context observations remain pending.
  • Prepared a combined single-slot field qualification after ee45890a: test VALID only under unchanged FAULT policy; test S2CR only with SMR invalid; restore with a bounded Qualcomm-aware fallback if necessary; compare all protected mappings; only then read six context states. No UFS commands, DMA route grants, queue/context/global/clock/SCM writes. Field results and restore flags still require exact-image device observation.
  • BOOT ee45890a device photo confirms stage5, inactive SMR56 ID a5 accepted and restored to zero; S2CR remains200ff, restoreOK and mappingsUnchanged are1, GFSR before/after zero and display04 unchanged. This qualifies only inactive ID-field writes, not VALID/S2CR/context/DMA, and contradicts blanket read-only claims for this measured field.
  • Single-slot SMR ID test BOOT ee45890ab4875987b0e3376b095a64a5d58f1b23177c96b9ea4a996cd8ba9031 prepared from source 41d99e6 and kernel d455be28. Twelve host tests pass; compiled code has exactly two writes to offset958 with DSB after each. Packed FAT/arguments/FD, capacity and DT/ADT checks pass. BOOT-only patched Heimdall upload exited 0; device field acceptance/restoration observation is pending.
  • Prepared a single-slot inactive SMR ID-field test, based on the complete 933a5d77 handoff observation. Requires exact measured geometry, clean GFSR, controller prerequisites, sole display mapping unchanged and slot 56 equal to zero/200ff. Rechecks mappings, writes only invalid ID a5 at offset958, restores zero and compares protected state; both writes fenced. No VALID/S2CR/CB/GCC/HCI/SCM/DMA changes. Outcome is not yet observed.
  • BOOT 933a5d77 device screen is confirmed through END slots=87. Corrected SM8250 GCC gate passes; HCE=1 HCS=10f IS=400, both queue run-stop bits set and both doorbells zero, UTRLBA=9b296000. The sole valid SMR 84020820/S2CR 4 exactly matches the captured display SID 0820 mask 0402; preserve slot 04 and CB4. Candidate residues in invalid slots 02/03 are not active routes. No DMA, SCSI or root read was attempted.
  • Prepared and independently verified BOOT 933a5d776edb2500be5c268b93e64f2cfec53fee6e12cebbb39869a8d7050deb from source 58bdac8 and kernel 147f8d3b; DT/ADT checks passed. Patched Heimdall uploaded BOOT only with exit 0. The new handoff screen and full-table END marker await device observation; no UFS DMA/root success claimed.
  • Prepared t970-ufs-handoff=1: corrected board-local SM8250 clock diagnostics from Samsung gcc-kona.c, removed SM8550-only memory-PHY GDSC reads, capture all bounded raw SMR/S2CR slots and guarded read-only HCI/queue state. No clock, PHY, SCM, SMMU, DMA or queue writes; use the exact tested baseline FD. Host and device results remain separate.
  • User confirmed and photographed the expected T970 SMMUv2 RO stop for BOOT 7f729c2a: sCR0=002d0406 ID0=4c017e57 ID1=6000004a ID2=00005111 GFSR=0; 87 groups scanned, 74 context banks, no candidate match for 0060/00e0/04e0. MMIO observation is confirmed; SMR writability, actual UFS routing, DMA and root reads are not.
  • Prepared BOOT 7f729c2a6ee8ee11b6eb5d4ff7ec23171b261854151578e36737d866a62391e2 from source 23d54b9 and kernel cca9bbb8. Independent FAT/kernel/arguments and packed FD checks passed, as did nine host tests and CPU0 DT/ADT checks. Patched Heimdall uploaded BOOT only with exit 0; device screen/register observation is pending. This is not a UFS/DMA/root-volume success.
  • Resumed at 47b113f. New default diagnostic t970-smmu-report=1 reads the measured SMMUv2 window before any controller/queue/DMA/root setup and stops on a labeled panic. It retires the unflashed all-slot write scan, separates sCR0 from ID0/1/2, honors EXIDS, and does not treat ignored writes or prior SCM markers as proof that secure-world routes are exhausted.
  • Uploaded deliberate after-MMU BRK control 150ed5ff9d73d81b17d3f6d32e609b9a9e42fdfe0397da7c5eea7d62f7ce7b4d, using patched Heimdall, exit 0. The device reset at about 50 seconds, matching the reviewed BRK path; original BOOT restoration is still pending. C startup and console behavior are not exercised.
  • After-MMU BRK control image prepared and extracted from FAT: BRK word, unchanged PE_create_console call, guard bytes, vector branches and preserved IRQ/FIQ slots verified. Eight host tests passed; hardware BRK delivery and the ~50-second timed reset were observed.
  • Prepared isolated BRK #0 after-MMU-control image 150ed5ff9d73d81b17d3f6d32e609b9a9e42fdfe0397da7c5eea7d62f7ce7b4d; the FAT kernel was independently extracted and the probe instruction at 0xfffffff0073f3370 matches the intended probe. The device reset at about 50 seconds, confirming the deliberate BRK reached the bounded fault terminal.
  • Added explicit after-MMU BRK control mode to qualify diagnostic execution before C startup. It preserves PE_create_console call bytes, uses the same reviewed fault handlers, and expects the distinct 50-second BRK path. Device execution and fault routing remain unverified until observed.
  • Guarded image e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29 did not reset within 60 seconds. Neither PE_create_console return nor a fault terminal is established. Next is a deliberate after-MMU BRK control to qualify the diagnostic path independently of C startup; no spin-loop diagnosis is claimed.
  • Uploaded guarded PE_create_console return probe e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29, using patched Heimdall, exit 0. Measured outcome and original BOOT restoration remain pending. Fault outcomes classify early paths and do not by themselves identify the failing function.
  • Host checks for guarded PE_create_console return passed: eight tests, verified 112-byte guard code and all modified vector/panic branches inside the actual FAT kernel, with IRQ/FIQ/reserved slots unchanged. Runtime outcome and device BRK control remain unverified.
  • Prepared isolated _PE_create_console after-return image e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29; the FAT kernel was independently extracted and its branch at 0xfffffff0079b619c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Added an opt-in early-fault diagnostic restricted to PE_create_console return in arm_init on repaired kernel bfb50a1a. It verifies the compiled active-vector selection, preserves IRQ/FIQ/reserved slots, and terminates sync/SError/panic/BRK paths at 20/30/40/50 seconds. This is not a normal kernel, text/register log or device fault result.
  • Repaired PE_init_printf(TRUE) return checkpoint was not observed (f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7). User photo shows retained firmware/loader text and entry bars, not a confirmed XNU text log. Restored PE_create_console may stop earlier; old-kernel gc_enable localization cannot be assumed for this new kernel.
  • Uploaded repaired-console PE_init_printf(TRUE) after-return probe, image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7, using patched Heimdall, exit 0. Device return result, text rendering and original BOOT restoration are pending; transfer alone does not verify the repair.
  • Repaired kernel bfb50a1a009f4dd08d54cb94d6187d768c7a5ef976427abd235756874f38473c compiled, linked and prelinked successfully. Mach-O checks verify PE_init_printf(FALSE) immediately precedes unconditional PE_create_console. Build configuration checks passed for 61 patches and 19 pinned modules; device return probe is pending.
  • Prepared isolated _PE_init_printf after-return image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7; the FAT kernel was independently extracted and its branch at 0xfffffff00794a01c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Human timing of about four seconds for console-state image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341 supports gc_initialized low bit 0 and PE_putc NULL before gc_enable. This supports missing console initialization under the experimental skip patch, but does not identify the exact faulting instruction.
  • Replaced the experimental skip-console patch with t970-console-bootstrap.patch: arm_init now always installs PE_init_printf(FALSE) before PE_create_console, restoring callback and console/lock setup rather than continuing with uninitialized console state. Kernel rebuild and prelink passed; the final Mach-O has adjacent unconditional PE_init_printf(FALSE) and PE_create_console calls. Device return checkpoint remains pending.
  • Uploaded console-state BOOT image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341, using patched Heimdall, exit 0. Measured reset timing and original BOOT restoration are pending. Upload and host tests do not establish runtime gc_initialized or PE_putc values.
  • The console-state FAT kernel was independently extracted; the complete 112-byte state code SHA256 matches its generator report. All six host tests passed, including ARM64 execution of the four timing codes and read-only checks. This does not establish tablet state or timing.
  • Prepared isolated _gc_enable before-call image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Added an opt-in, hash-pinned console-state diagnostic copy at the confirmed gc_enable call site. It reads gc_initialized and PE_putc without invoking gc_enable, encodes their combination as 4/14/24/34-second terminal waits, and rejects unknown input kernels. This is not text logging or a device state result.
  • The user confirmed the gc_enable before-call reset (59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9), whereas its after-return probe did not reset. The unconfirmed path is inside gc_enable. Next diagnostic reads gc_initialized and PE_putc at that known reachable call site; no runtime NULL value is claimed yet.
  • Uploaded the isolated gc_enable before-call probe inside vcattach, image 59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _gc_enable before-call image 59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The gc_enable after-return probe in vcattach did not reset (a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737). Earlier vcattach lock initialization return is confirmed. Next test is immediately before the same gc_enable call to distinguish an internal failure from its preceding path; neither a NULL callback nor a specific exception is established.
  • Uploaded the isolated gc_enable after-return probe inside vcattach, image a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _gc_enable after-return image a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The user observed automatic reset after arm_usimple_lock_init in vcattach with image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561. This establishes vcattach entry and lock initialization return, but not screen acquisition or message replay. The next checkpoint is after gc_enable inside vcattach.
  • Uploaded the isolated arm_usimple_lock_init after-return probe inside vcattach, image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _arm_usimple_lock_init after-return image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4894 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • PE_init_printf after-return checkpoint inside PE_init_iokit was not observed with image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4. The next unconditional internal checkpoint is after arm_usimple_lock_init in vcattach, before its graphics-state checks. Failure type and exact instruction remain unknown.
  • Uploaded the isolated PE_init_printf after-return probe inside PE_init_iokit, image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _PE_init_printf after-return image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4; the FAT kernel was independently extracted and its branch at 0xfffffff00794a01c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The InitIOKit before-call probe inside PE_init_iokit did not reset (977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270). PE_init_iokit entry is confirmed by the earlier probe, so the next boundary is its first call PE_init_printf(TRUE), which tail-calls vcattach in this exact binary. No crypto-provider failure is established.
  • Uploaded the isolated InitIOKit before-call probe inside PE_init_iokit, image 977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _InitIOKit before-call image 977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270; the FAT kernel was independently extracted and its branch at 0xfffffff00794a390 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The user confirmed automatic reset before PE_init_iokit with image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421, while the after-return image did not reset. This brackets the unconfirmed path inside PE_init_iokit; the exact failing instruction and fault type remain unknown.
  • Uploaded the isolated PE_init_iokit before-call BOOT image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421 using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _PE_init_iokit before-call image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421; the FAT kernel was independently extracted and its branch at 0xfffffff00798ca8c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The iokit-return BOOT image uploaded successfully; the user observed no automatic reset. Upload verifies transfer only, not IOKit completion or userland readiness. Original BOOT restoration remains pending.
  • Prepared isolated _PE_init_iokit after-return image 9b0f8f683db2802cefc30287b206ac33f7c0d3acf480457b9447c53afdf947dd; the FAT kernel was independently extracted and its branch at 0xfffffff00798ca8c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Prepared isolated _sched_startup after-return image 4a5e423389efb142c3c5b8b5afedf98dcc59c7b0db1a29782805c95d8a298721; the FAT kernel was independently extracted and its branch at 0xfffffff00798c8f0 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The isolated probe boot image is 62713856 bytes, within the measured 71303168-byte BOOT limit. Its header/payload sections round-trip; no Data image is included.
  • The previously uncommitted board console patch is now part of the declared series, for 61 total patches (56 arch, 2 SoC, 2 OS, 1 board). Isolated probe generation reuses the built source kernel and firmware, patches only a payload copy, checks the measured BOOT size limit and leaves board defaults untouched.
  • The required Mu SEC entry-argument HOB integration is now versioned in package/firmware/patches and inputs.json, independently of the currently retained runtime probe.
  • The normal bootimg command produced a 3993600-byte header-v2/raw-kernel/separate-DTB firmware-only check image and verified its sections and load addresses. Ramdisk is empty; no XNU kernel/payload or device boot is claimed.
  • Actual bootimg invocation exposed the pinned upstream BootShim declaring only FD_SIZE in ARM64 image_size. The shared packer now normalizes the header with strict base/size checks; a real header-v2 raw-kernel/separate-DTB firmware-only image packs and unpacks successfully.
  • The board package now contains a real T970 firmware overlay and build integration; its vendor assets stay local. Kernel board patch series remains empty.
  • The shared packer now supports observed raw kernel/header-v2/separate-DTB layout, validates DTB/ramdisk addresses and byte content, and has seven passing regression cases. XNU payload inputs are still a later stage.
  • A second boot-header capture confirms header v2, header_size=1660, page_size=4096, DTB address=0x1f00000, boot DTB bytes=1580275, and separate recovery DTBO geometry. Source boot is Magisk-modified.
  • The local archive's manifest matches the intended iPadOS 17.7.11 / 21H461 target.
  • The manifest's product types describe the Apple restore targets; they do not establish SM-T970 compatibility.
  • The initial format-2 staging layout blocked builds; the completed device input configuration now removes the example flag without claiming a hardware boot.
  • Step 2 reuses XNU 10063.141.1 / Darwin 23.6.0 and the existing profile kernelcache hash, DriverKit and TrustCache header tags. Source-level ABI scope was reviewed; private ABI and actual prelink remain unverified.
  • Step 3 example-gate check invoked build kernel and bootimg against the existing configuration; both returned exit 1 with EXAMPLE device repository before building or packaging. No missing input was replaced with a fabricated path.
  • tools=true only changes the generated menu; the payload/initrd image was not built because XNU kernel and Apple payload inputs are still absent, so the Tools entry and QR export remain unverified on an image.
  • The full host build chain now completes at this commit: kernel.macho 51908608 bytes b3f9ab34..., payload.img 201326592 bytes a4a0bac8..., boot.img 205320192 bytes 28f3bb9f... and the 3145728-byte FD 4691d86c.... boot.json reports header v2 with ramdisk_bytes 201326592, the captured firmware DTB hash and the built FD hash; payload.json reports the kernel, generated ADT and accepted trust cache.
  • The build required a two-pass kernel flow (bootstrap compile records, archives, final link/prelink) and a python3 with tomllib on PATH for the archive scripts. No device write or boot was attempted; restore dumps stay in ignored storage.
  • With the 56 MiB payload the rebuilt boot.img is 62713856 bytes (payload.img 58720256, sha256 a87d42da...; boot.img sha256 d61f416a...) and fits the 68 MiB boot partition. Odin AP tars for the test image and the Magisk restore image were generated in ignored storage; no flash has been performed.
  • Added t970-skip-video.patch (initialize_screen guarded by t970-novc) and t970-skip-vcattach.patch (PE_init_printf TRUE path uses a null output callback under t970-novc), and changed t970-console-bootstrap.patch to skip PE_create_console under t970-novc. These are diagnostic bypasses, not a replacement console.
  • Ported the marble-milacy PMGR placeholder: package/ShengPlatformPower.cpp and scripts/build-platform-power.py build the 340-slot original ApplePMGR ABI bridge from the shared 21H461 kernelcache; the framework sheng-platform-power.patch is in the device series and board archives now include build-platform-power.py. The builder's audit passed unchanged-AMFI read/OR/write and original provider dispatch.
  • Final console diagnostic patch set for this revision: t970-console-bootstrap calls PE_initialize_console under t970-novc so vinfo and the framebuffer mapping exist for the panic screen, and the t970-skip-video patch (which skipped gc_initialize and left VCPUTC's ticket lock uninitialized) is removed. t970-skip-vcattach keeps PE_putc a null writer.
  • scripts/build-owner-systemos-policy.py signs and fully verifies the raw Cryptex1,SystemOS member (806400 blocks, b4908cde) against the same owner anchor; it is the missing SystemOS half the framework's --include-systemos bundle needs.
  • Added scripts/build-verified-root-empty.py (real VerifiedRoot crypto with a zero-length policy table, 19 KB archive, fixed at link time) and scripts/build-ufs-stubs.py with package/UfsStubs.c. The VerifiedRoot probe archive with the 47 MiB hash table stays out of the kernel because it does not fit the 68 MiB BOOT partition.
  • patches/xnu/t970-smmu-dump.patch is appended to the device series after the console and vcattach patches; it targets the end of arm_init (before machine_startup) so it stays clear of the console hunks.
  • package/ShengUfs/ keeps the vendored alioth driver next to the board package; scripts/zz-build-shengufs-local.py compiles it against the kernel ABI and would replace the component archive when enabled. Both are deliberately not selected in the current archive list.
  • package/ShengUfs is now the active driver copy: SmmuTakeover.h reads IDR0/1/2 at 0x0/0x4/0x8 with log2 geometry and NativeUfs.cpp adds the t970-ufs-auto-stream reuse scan; scripts/zz-build-shengufs-local.py builds the archive and must run after any component build to avoid duplicate objects.
  • patches/xnu/t970-smmu-dump.patch now carries the t970-smmu-write probe (IDR stability read plus a GFSR write-1-to-clear readback) instead of the stream table dump; it is a guarded arm_init diagnostic only.
  • package/ShengUfs now follows the Linux-validated SMMU layout again (IDR 0x20/0x24/0x28, NUMSMRG/NUMCB) and carries the 128-slot auto-stream scan; the local archive remains the active build input.
  • package/ShengUfs/NativeUfs.cpp adds t970-ufs-no-smmu=1, which still maps the SMMU window (the caller dereferences it) but skips every SMMU write; the earlier early-return variant crashed in hostBringUp and is not kept.
  • The generated PHY table header and its generator live under package/firmware/Platforms/Samsung/gts7xlwifiPkg/Library/PlatformUfsLib/ with a GPL-2.0 provenance comment; docs/firmware-ufs-plan.md records the remaining work.
  • package/firmware carries PlatformUfsLib (BoardInit.c, PlatformUfsLib.inf, Sm8250UfsPhyTables.h), DSC/FDF entries for UfsDxe, and a single merged UfsDxe source patch (ChipInfo tolerance plus 0x9ff80004 stage words). The firmware staging must run scripts/prepare-uefi.py from a reset checkout because same-file patches cannot overlap.
  • patches/xnu/t970-smmu-dump.patch now carries the t970-ufs-status probe that maps 0x9ff80000 and panics with the firmware stage word; it is the kernel half of the firmware visibility path.
  • PlatformUfsLib now links ArmSmcLib, ArmMmuLib-free DxeServicesTableLib and BaseMemoryLib; the SCM prototype lives in BoardInit.c next to the PHY replay and is selected by the same DSC/FDF entries.
  • The post-survey evidence records the survey BOOT build (c404ce26 from revision 09bff63) and a zero-byte read log, with userdata_written=false and recovery_written=false for that action.

Completion criteria ​

  • The selected profile's inputs produce a kernel, payload and a boot image matching the SM-T970 boot path.

Current limits ​

  • Manifest inspection does not verify archive authenticity or integrity, driver ABI compatibility, or bootability.
  • The IPSW is a local external input; its selected manifest fields are archived, but no complete image build is recorded.
  • The selected profile kernelcache SHA256 f18b4df865405f2a287b84977d7aca745e056d656d9fc9df1662970ce2969de7 has not been checked against a locally extracted/decompressed kernelcache.

Next action ​

  • Review an exclusive bypass-context and bounded command/DMA test plan using the qualified stream fields; preserve display CB4, reject unqualified CB73 and record actual data reads separately.

Evidence ​

Diagnostics ​

implemented

Hardware and dependencies ​

  • Existing ADB and Magisk su can read the live FDT, physical iomem, input capabilities and primary GPT metadata while SELinux remains Enforcing.
  • Android pstore lists console-ramoops-0 and pmsg-ramoops-0; their contents were not collected.
  • capture.json records timestamps in Asia/Shanghai, remote commands, exit codes, boot header fields and evidence-file SHA256 values.

Configuration ​

  • The collector uses adb -d shell -T to preserve binary bytes and remote exit status. Evidence is an Android inventory snapshot, not an XNU verification run.
  • scripts/check-platform.py resolves source pins and archive/patch plans, compiles the board DTS and checks an artificial host-only ADT against archived hardware inputs.

Procedure ​

  • Run python3 scripts/collect-adb-inventory.py --root --output evidence/<new-capture>; review per-command stderr, checksums, GPT CRC results and DT sanitization before updating this record.

Development findings ​

  • BOOTbb4d8474 owner observed Apple logo; photo14:40:13 shows swap2/0, transfer2, copies2, retire2. BOOT08b90255 previously panicked on uninitialized vc_progress_lock via first swap console handoff. Guard now matches t970-novc bootstrap. SpringBoard sample reaches LaunchServices database context from Control Center module discovery; sustained desktop pending. See evidence/display/display-novc-v24.
  • BOOTe44011cb photo03:08:38 links BB wait to QuartzCore CAMetalContextCreate polling IOAcceleratorES, at most 300 sleeps of 100ms; SB waits for main screen info, open6/swap0. T733 48f documents CPU frames through NativeLegacyDisplay. BOOT08b90255 keeps kernel and changes report target to 125s; FAT comparison passes, ADT differs only in random-seed. See evidence/display/ui-cpu-fallback-v23.
  • BOOT5385b6ce owner photo03:00:42 shows three pending queues drained, MG done134, BB161, SB75->78, display open6/fail0/swap0. No constrained head means Q cap zero is absent data, not a measured cached limit. v22 reuses exact v21 kernel with existing stack mode1 to locate current BB/SB main waits; host image checks pass, hardware stack result pending.
  • v21 BCM2837 EDGE width fallback uses registered SMP CPU/cluster counts only when E/P counts are both zero. Previous BOOT705d4160 has all eight ADT CPU cluster-type absent (SMP), cached constrained cap0 and callback progress. Actual prepared-function ASan/UBSan tests cover SMP1/8, E/P precedence and non-BCM guard; kernel/prelink/FAT checks pass. BOOT5385b6ce hardware result pending; this is not validated heterogeneous scheduling or desktop. See evidence/display/edge-smp-v21.
  • BOOT705d4160 mode6 owner photo02:38:12 captures all three processes/end marker unclipped. Constrained cap/active/busy=0/0/0; MG done35->37 while BB25/SB53 unchanged across 500ms deadlines. Runtime callback continues; investigate EDGE E/P counts versus current SMP topology before any scheduling change. See evidence/display/ui-queue-progress-v20/device-result.json.
  • BOOTd80a3773 target120 owner photo confirms main1/n148/cpu8/sec7, BB57/SB27, display opens2 but no swap/frame, KeyStore opens49/calls194. Saved PC/LR of3 threads per target and slide10914000 captured with busy0. Original cache/symbol UUIDs match; BB queue-first PC maps semaphore_wait_trap+8 and LR libdispatch semaphore-wait variant+24; other rows map mach_msg2/workq. Current sampler has no scheduler-state or user stack, so an upstream dependency is not yet established. Next capture bounded caller frames in a separate worker.
  • PID1/direct executable path observers miss the late BB launch route: target120 BB57/client2 are positive evidence despite direct-path counters0. Normal BOOTec912b09 removes terminal and UI error-exit diagnostic flags; owner sees only retained bars. Added a Mach-private saved-register sampler following umi3eb7257 lock/copy pattern, with task/thread try-locks, IRQ restoration and4-thread caps; no VM reads, task suspension or Mach peer lookup. Host ASan/UBSan and exact ABI compile pass; device capture pending.
  • UI-job-v8 kernel049897a9/BOOT1939b59d adds PID1 namei basename lookup counts and latest matching open error for BB/SB plists using existing kernel path copies only. Actual helper ASan tests cover filters/relative paths/errors/ring/bounds. Job lookup is not parsed/imported job proof; path/return association is best effort. Same eight-core60-second display diagnostics and policy. Hardware outcome pending; see evidence/display/ui-job-v8.
  • BOOT3da265b4 target60 owner photo confirms main1/n67/cpu8/sec7, SpringBoard27/runningboardd26, Data0/policy0/stage4 and all-core positive timer/SGI snapshots. Backboardd not observed; free0x183 excludes reclaimable memory, not sole OOM proof. Sustained runtime, controlled CPU workload and desktop remain unverified. See runtime-cache60/device-result.json.
  • BOOT95accf53 owner photo confirms CPU1 entry3 (matched CPU data and reached common_start boundary); C marker4 not seen. Target10 snapshot main0/n2 is earlier than old120 samples. Added secondary-only common/TCR/table/SCTLR/trampoline markers without changing CPU setup values. See entry-trace/device-result.json and MMU trace records.
  • Two-core BOOT9d4dc888 observed main1 and106 processes but one CPU available; CPU1 phase4/PSCI0/timer0/SGI0. Reset table, CPU1 affinity and reset handler match. Entry execution remains unconfirmed. Added four diagnostic entry milestones and shortened future target wait to10 seconds; default CPU0 unchanged,8-core not uploaded. See evidence/cpu and docs/smp-bringup.md; source/build checks are not hardware SMP qualification.
  • BOOTeeeba83b owner photo19:36:40 shows requested120-second runtime report: genuine main1,109 processes, watchdogd absent, SpringBoard27/backboardd56/runningboardd26, Data0/policy0/stage4,964876 verified blocks. Kernel deadline-wait/report executed; rate accuracy unmeasured. Interface-service process presence is not proof of rendering or functional services. Display backend remains disabled; next phase is display handoff/provider and independent staged SMP qualification.
  • BOOTeeeba83b uses explicit t970-runtime-report=120 to start one diagnostic kernel thread after Data/policy install. Deadline wait yields CPU; bounded512 non-zombie callbacks, first18 names in512bytes and named service PIDs are displayed in intentional panic. Readonly genuine-main accessor and original process refs/exit policies retained. Actual helper sanitizer/API-substitute bounds/wait/range/once/thread-failure tests plus policy regression and independent symbol/FAT/ADT/boot/argument verification pass; implicit sampler configuration refused. BOOT-only upload exit0; physical timer/snapshot and later services pending.
  • BOOT28268af5 owner photo19:10 confirms genuine main1/error0/Data0/policy0/stage4. Kernel installer actually completed root-owned RAM policy and migration marker writes/metadata/fsync/close before launchd main. Probe is readonly, preserves original sysctl semantics and caller frame;27 Unicorn state/result combinations plus unknown-input refusal pass, actual pinned binary/FAT/geometry checks pass. Normal BOOT2387e904 restored via BOOT-only upload exit0 after observation. Original launchd override acceptance, subsequent services and desktop remain unverified.
  • BOOT2387e904 installs an explicit temporary original-launchd watchdog-only override after successful volatile Data mount when t970-disable-watchdogd=1. Refuse non-RAM/persistent/readonly/unready/nonroot conditions and existing policy/marker; exclusive nofollow creation, root metadata and full write/fsync/close before migration marker. Actual helper ASan/UBSan15 API failure points plus guard/preservation/cleanup cases pass; original launchd/watchdogd unchanged. Source39d7cfe1/real PMGR and independent FAT/ADT/boot/argument checks pass. BOOT-only upload exit0, runtime policy acceptance/services pending.
  • BOOT97271e99 photo18:22 confirms launchd main1/err0 and managed pages0x1b709 (~439MiB):512MiB EFI-owned request works. BOOT911a462a new Data build failed AMFI No PMGR because isolated output silently used FirstPassStub. Remove implicit stub, require a reference, audit real PMGR340 slots and reject missing registration symbols/archive members in independent pack checks. Repaired6b83f4e6 uploaded exit0; photo18:42 shows watchdogd PID102 SIGTRAP. Enforced exact-device/writable/APFS mount success gate precedes exec, so Data mount success is inferred, not a Data write/persistence test. Original watchdogd host branch and launchd root-owned watchdog-only policy checks pass with explicit OS API substitutions; policy not applied.
  • 2026-11-02: normal release BOOT867efc59 requests512MiB via the chosen ADT property only; fixed normal kernel/FD/DTB/config/tail preserved, Heimdall upload exit0. Owner reports retained bars, which does not localize execution or verify allocation. Terminal main checkpoint BOOT97271e99 uploaded exit0 to measure actual pages; runtime result pending; Data APFS32MiB seed packed losslessly to1007696bytes on host, not integrated/flashed or persistence-qualified. Physical8GiB is not the EFI-owned256MiB diagnostic allocation.
  • The next cache diagnostic follows umi bounded kernel-state observation: trace PID1 syscall returns and only already copied namei buffers, with fixed arrays and a last-12 panic summary; it makes no extra user-pointer read. Actual-helper host checks pass; device results remain pending and must be tied to the next exact BOOT hash.
  • BOOT cfbd84ba photo confirms stage4: ID/VALID/S2CR accepted, direct FAULT restore200ff succeeded without fallback, allRestored/mappingsUnchanged=1 and GFSR=0. Six context states captured; CB0..4 already configured with FSR400 of unknown age, CB73 SCTLR3ab3a706 is not a verified free bank. No context writes, DMA or UFS commands occurred.
  • Combined field diagnostic BOOT cfbd84ba34fc03b50661b46c9e22fe59c43ba651bca6967da49f1df1ec373e75 prepared from source7ee2918/kernel53e9e68c. Thirteen host tests, input-stable kernel build, independent FAT/arguments/FD checks and DT/ADT check passed. BOOT-only upload exited0; actual VALID/S2CR/restoration/context observations remain pending.
  • Prepared a combined single-slot field qualification after ee45890a: test VALID only under unchanged FAULT policy; test S2CR only with SMR invalid; restore with a bounded Qualcomm-aware fallback if necessary; compare all protected mappings; only then read six context states. No UFS commands, DMA route grants, queue/context/global/clock/SCM writes. Field results and restore flags still require exact-image device observation.
  • BOOT ee45890a device photo confirms stage5, inactive SMR56 ID a5 accepted and restored to zero; S2CR remains200ff, restoreOK and mappingsUnchanged are1, GFSR before/after zero and display04 unchanged. This qualifies only inactive ID-field writes, not VALID/S2CR/context/DMA, and contradicts blanket read-only claims for this measured field.
  • Single-slot SMR ID test BOOT ee45890ab4875987b0e3376b095a64a5d58f1b23177c96b9ea4a996cd8ba9031 prepared from source 41d99e6 and kernel d455be28. Twelve host tests pass; compiled code has exactly two writes to offset958 with DSB after each. Packed FAT/arguments/FD, capacity and DT/ADT checks pass. BOOT-only patched Heimdall upload exited 0; device field acceptance/restoration observation is pending.
  • Prepared a single-slot inactive SMR ID-field test, based on the complete 933a5d77 handoff observation. Requires exact measured geometry, clean GFSR, controller prerequisites, sole display mapping unchanged and slot 56 equal to zero/200ff. Rechecks mappings, writes only invalid ID a5 at offset958, restores zero and compares protected state; both writes fenced. No VALID/S2CR/CB/GCC/HCI/SCM/DMA changes. Outcome is not yet observed.
  • BOOT 933a5d77 device screen is confirmed through END slots=87. Corrected SM8250 GCC gate passes; HCE=1 HCS=10f IS=400, both queue run-stop bits set and both doorbells zero, UTRLBA=9b296000. The sole valid SMR 84020820/S2CR 4 exactly matches the captured display SID 0820 mask 0402; preserve slot 04 and CB4. Candidate residues in invalid slots 02/03 are not active routes. No DMA, SCSI or root read was attempted.
  • Prepared and independently verified BOOT 933a5d776edb2500be5c268b93e64f2cfec53fee6e12cebbb39869a8d7050deb from source 58bdac8 and kernel 147f8d3b; DT/ADT checks passed. Patched Heimdall uploaded BOOT only with exit 0. The new handoff screen and full-table END marker await device observation; no UFS DMA/root success claimed.
  • Prepared t970-ufs-handoff=1: corrected board-local SM8250 clock diagnostics from Samsung gcc-kona.c, removed SM8550-only memory-PHY GDSC reads, capture all bounded raw SMR/S2CR slots and guarded read-only HCI/queue state. No clock, PHY, SCM, SMMU, DMA or queue writes; use the exact tested baseline FD. Host and device results remain separate.
  • User confirmed and photographed the expected T970 SMMUv2 RO stop for BOOT 7f729c2a: sCR0=002d0406 ID0=4c017e57 ID1=6000004a ID2=00005111 GFSR=0; 87 groups scanned, 74 context banks, no candidate match for 0060/00e0/04e0. MMIO observation is confirmed; SMR writability, actual UFS routing, DMA and root reads are not.
  • Prepared BOOT 7f729c2a6ee8ee11b6eb5d4ff7ec23171b261854151578e36737d866a62391e2 from source 23d54b9 and kernel cca9bbb8. Independent FAT/kernel/arguments and packed FD checks passed, as did nine host tests and CPU0 DT/ADT checks. Patched Heimdall uploaded BOOT only with exit 0; device screen/register observation is pending. This is not a UFS/DMA/root-volume success.
  • Removed a copied BRK-success sentence from 33 unrelated host evidence entries and 33 unrelated findings. Their source JSON artifacts and device observations are preserved; successful 50-second BRK results remain attributed only to after-mmu-brk-control.
  • Resumed at 47b113f. New default diagnostic t970-smmu-report=1 reads the measured SMMUv2 window before any controller/queue/DMA/root setup and stops on a labeled panic. It retires the unflashed all-slot write scan, separates sCR0 from ID0/1/2, honors EXIDS, and does not treat ignored writes or prior SCM markers as proof that secure-world routes are exhausted.
  • Uploaded deliberate after-MMU BRK control 150ed5ff9d73d81b17d3f6d32e609b9a9e42fdfe0397da7c5eea7d62f7ce7b4d, using patched Heimdall, exit 0. The device reset at about 50 seconds, matching the reviewed BRK path; original BOOT restoration is still pending. C startup and console behavior are not exercised.
  • After-MMU BRK control image prepared and extracted from FAT: BRK word, unchanged PE_create_console call, guard bytes, vector branches and preserved IRQ/FIQ slots verified. Eight host tests passed; hardware BRK delivery and the ~50-second timed reset were observed.
  • Prepared isolated BRK #0 after-MMU-control image 150ed5ff9d73d81b17d3f6d32e609b9a9e42fdfe0397da7c5eea7d62f7ce7b4d; the FAT kernel was independently extracted and the probe instruction at 0xfffffff0073f3370 matches the intended probe. The device reset at about 50 seconds, confirming the deliberate BRK reached the bounded fault terminal.
  • Added explicit after-MMU BRK control mode to qualify diagnostic execution before C startup. It preserves PE_create_console call bytes, uses the same reviewed fault handlers, and expects the distinct 50-second BRK path. Device execution and fault routing remain unverified until observed.
  • Guarded image e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29 did not reset within 60 seconds. Neither PE_create_console return nor a fault terminal is established. Next is a deliberate after-MMU BRK control to qualify the diagnostic path independently of C startup; no spin-loop diagnosis is claimed.
  • Uploaded guarded PE_create_console return probe e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29, using patched Heimdall, exit 0. Measured outcome and original BOOT restoration remain pending. Fault outcomes classify early paths and do not by themselves identify the failing function.
  • Host checks for guarded PE_create_console return passed: eight tests, verified 112-byte guard code and all modified vector/panic branches inside the actual FAT kernel, with IRQ/FIQ/reserved slots unchanged. Runtime outcome and device BRK control remain unverified.
  • Prepared isolated _PE_create_console after-return image e18c6ca0e905e0e40a2283447a765bdc322bbcc85bf0cb19fe80ec857007be29; the FAT kernel was independently extracted and its branch at 0xfffffff0079b619c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Added an opt-in early-fault diagnostic restricted to PE_create_console return in arm_init on repaired kernel bfb50a1a. It verifies the compiled active-vector selection, preserves IRQ/FIQ/reserved slots, and terminates sync/SError/panic/BRK paths at 20/30/40/50 seconds. This is not a normal kernel, text/register log or device fault result.
  • Repaired PE_init_printf(TRUE) return checkpoint was not observed (f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7). User photo shows retained firmware/loader text and entry bars, not a confirmed XNU text log. Restored PE_create_console may stop earlier; old-kernel gc_enable localization cannot be assumed for this new kernel.
  • User observation for _PE_init_printf after-return image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7: no automatic reset observed; checkpoint not established.
  • Uploaded repaired-console PE_init_printf(TRUE) after-return probe, image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7, using patched Heimdall, exit 0. Device return result, text rendering and original BOOT restoration are pending; transfer alone does not verify the repair.
  • Repaired kernel bfb50a1a009f4dd08d54cb94d6187d768c7a5ef976427abd235756874f38473c compiled, linked and prelinked successfully. Mach-O checks verify PE_init_printf(FALSE) immediately precedes unconditional PE_create_console. Build configuration checks passed for 61 patches and 19 pinned modules; device return probe is pending.
  • Prepared isolated _PE_init_printf after-return image f759eb8085bb67c4a1d2ac02ea18898e6d146118fc790148638f33cfc81cd9a7; the FAT kernel was independently extracted and its branch at 0xfffffff00794a01c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • check-build-config.py now excludes .DS_Store from script-content comparison, matching its existing source-cleanliness policy. Host metadata from framework and device can share that filename; real script bytes remain checked.
  • Human timing of about four seconds for console-state image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341 supports gc_initialized low bit 0 and PE_putc NULL before gc_enable. This supports missing console initialization under the experimental skip patch, but does not identify the exact faulting instruction.
  • Replaced the experimental skip-console patch with t970-console-bootstrap.patch: arm_init now always installs PE_init_printf(FALSE) before PE_create_console, restoring callback and console/lock setup rather than continuing with uninitialized console state. Kernel rebuild and prelink passed; the final Mach-O has adjacent unconditional PE_init_printf(FALSE) and PE_create_console calls. Device return checkpoint remains pending.
  • Uploaded console-state BOOT image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341, using patched Heimdall, exit 0. Measured reset timing and original BOOT restoration are pending. Upload and host tests do not establish runtime gc_initialized or PE_putc values.
  • The console-state FAT kernel was independently extracted; the complete 112-byte state code SHA256 matches its generator report. All six host tests passed, including ARM64 execution of the four timing codes and read-only checks. This does not establish tablet state or timing.
  • Prepared isolated _gc_enable before-call image 670e78ee17a752fc297dc6537a0c98d0074d8d191c599aa065804bd9ae6cb341; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • Added an opt-in, hash-pinned console-state diagnostic copy at the confirmed gc_enable call site. It reads gc_initialized and PE_putc without invoking gc_enable, encodes their combination as 4/14/24/34-second terminal waits, and rejects unknown input kernels. This is not text logging or a device state result.
  • The user confirmed the gc_enable before-call reset (59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9), whereas its after-return probe did not reset. The unconfirmed path is inside gc_enable. Next diagnostic reads gc_initialized and PE_putc at that known reachable call site; no runtime NULL value is claimed yet.
  • User observation for _gc_enable before-call image 59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9: automatic reset observed; checkpoint reached.
  • Uploaded the isolated gc_enable before-call probe inside vcattach, image 59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _gc_enable before-call image 59dc0bb6944b0295ee20191e85d3add62439ccb21b854a7dc7e02a439ecd7ee9; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The gc_enable after-return probe in vcattach did not reset (a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737). Earlier vcattach lock initialization return is confirmed. Next test is immediately before the same gc_enable call to distinguish an internal failure from its preceding path; neither a NULL callback nor a specific exception is established.
  • User observation for _gc_enable after-return image a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737: no automatic reset observed; checkpoint not established.
  • Uploaded the isolated gc_enable after-return probe inside vcattach, image a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _gc_enable after-return image a914135de89584e944eca643528b296043bc38efa323563153e0898f74db6737; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4968 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The user observed automatic reset after arm_usimple_lock_init in vcattach with image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561. This establishes vcattach entry and lock initialization return, but not screen acquisition or message replay. The next checkpoint is after gc_enable inside vcattach.
  • User observation for _arm_usimple_lock_init after-return image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561: automatic reset observed; checkpoint reached.
  • Uploaded the isolated arm_usimple_lock_init after-return probe inside vcattach, image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _arm_usimple_lock_init after-return image 95ff2c91e26b3b125b2ae7f465fe9cfbd97d18bee1583b06e2fff17715db7561; the FAT kernel was independently extracted and its branch at 0xfffffff0073c4894 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • PE_init_printf after-return checkpoint inside PE_init_iokit was not observed with image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4. The next unconditional internal checkpoint is after arm_usimple_lock_init in vcattach, before its graphics-state checks. Failure type and exact instruction remain unknown.
  • User observation for _PE_init_printf after-return image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4: no automatic reset observed; checkpoint not established.
  • Uploaded the isolated PE_init_printf after-return probe inside PE_init_iokit, image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _PE_init_printf after-return image f89deffaac554e9569d8848852fce5cb233aedf841acb99f11fbd8b32d0a86a4; the FAT kernel was independently extracted and its branch at 0xfffffff00794a01c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The InitIOKit before-call probe inside PE_init_iokit did not reset (977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270). PE_init_iokit entry is confirmed by the earlier probe, so the next boundary is its first call PE_init_printf(TRUE), which tail-calls vcattach in this exact binary. No crypto-provider failure is established.
  • User observation for _InitIOKit before-call image 977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270: no automatic reset observed; checkpoint not established.
  • Uploaded the isolated InitIOKit before-call probe inside PE_init_iokit, image 977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270, using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _InitIOKit before-call image 977fd90de02e3643beaa01082bca713381c6449f8bccecb46fb0ca5a86aa4270; the FAT kernel was independently extracted and its branch at 0xfffffff00794a390 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The user confirmed automatic reset before PE_init_iokit with image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421, while the after-return image did not reset. This brackets the unconfirmed path inside PE_init_iokit; the exact failing instruction and fault type remain unknown.
  • User observation for _PE_init_iokit before-call image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421: automatic reset observed; checkpoint reached.
  • Uploaded the isolated PE_init_iokit before-call BOOT image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421 using patched Heimdall, exit 0. Human checkpoint feedback and original BOOT restoration are pending; transfer does not establish execution.
  • Prepared isolated _PE_init_iokit before-call image 458218bd4e846aad1408daea717d2263aa86d94ae8dac2a364f0c507a12b2421; the FAT kernel was independently extracted and its branch at 0xfffffff00798ca8c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • External zeta/SM8350 records describe a PE_init_iokit failure caused by a NULL crypto provider and a version-specific fix; T970 uses prelinked crypto and has no runtime pointer result. See docs/related-bring-up.md; no root cause is inferred from similarity.
  • User observation for _PE_init_iokit after-return image 9b0f8f683db2802cefc30287b206ac33f7c0d3acf480457b9447c53afdf947dd: no automatic reset observed; checkpoint not established.
  • Prepared isolated _PE_init_iokit after-return image 9b0f8f683db2802cefc30287b206ac33f7c0d3acf480457b9447c53afdf947dd; the FAT kernel was independently extracted and its branch at 0xfffffff00798ca8c matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • User observation for _sched_startup after-return image 4a5e423389efb142c3c5b8b5afedf98dcc59c7b0db1a29782805c95d8a298721: automatic reset observed; checkpoint reached.
  • Prepared isolated _sched_startup after-return image 4a5e423389efb142c3c5b8b5afedf98dcc59c7b0db1a29782805c95d8a298721; the FAT kernel was independently extracted and its branch at 0xfffffff00798c8f0 matches the intended probe. This preparation record does not establish a device result; see the separately recorded observation for this image hash.
  • The user observed automatic reset with the exact idle-return image 55b7c0354446888e80d0ed77258e4f29c236fdd9df6e65bfafbfab2cb72ab5ed. This confirms idle_thread_create returned; the next checkpoint is sched_startup return, not initialize_screen internals.
  • The isolated idle_thread_create after-return image (55b7c035...) was uploaded successfully to BOOT with patched Heimdall and --no-reboot. This records the write only; the new checkpoint outcome and restoration are pending the user startup/observation.
  • The isolated idle-return artifacts are archived with source hashes and the exact call site; the original Magisk BOOT backup still matches 6f49af2f77ae0e55b4f76b29b0e0491ff0228c42ae97ba0533b97631483566fc.
  • Probe control flow was checked against both the generator and the current kernel disassembly. reset-before ignores the delay and immediately issues PSCI SYSTEM_RESET. A new after-return idle_thread_create probe is the next discriminating test; physical source images and restore hashes are recorded.
  • Three source-patch preparation tests passed (apply/repeat, reject changed patch, preserve unknown local edits); an additional test used all four actual upstream SEC preimages and checked idempotence.
  • The completed Step 3 archive ties actual commands, source hashes, platform checks, normal firmware compilation and boot-image round-trip to clean committed device/framework revisions.
  • The strengthened dynamic-pool check caught an overlap with camera_mem_region that static-reservation-only checks missed. It now verifies the reduced 2 GiB window against all original pool bounds and measured-bank containment.
  • The platform checker now additionally compares seven disabled controller register/IRQ descriptions, the touch/pen addresses and firmware names, dynamic reserved-pool windows and 45 original XBL regions. None is a runtime or DMA test.
  • On this Magisk setup, exec-out through su inserted CR bytes into binary output; shell -T returned an FDT whose length matches its header. The collector verifies this before decoding.
  • The sanitized DTS omits /chosen and identifying properties; the selected display token is captured separately. It is an input reference, not a ready-to-flash board DTB.
  • The platform checker verifies CPU affinities, GIC ranges/stride, timer rate, the measured RAM-bank selection, all static reservation reg values and ADT byte order. It does not invoke ADB or produce a boot image.
  • The committed platform checker produced a PASS report tied to its exact source revision and input file hashes; sanitized resolved configuration and unchanged dtc naming warnings are archived.
  • Step 2 adds reproducible checks for reviewed framework/profile hashes, explicit device component pins, declared OS ABI scope and source file presence. These checks do not execute driver protocols or validate private ABI layouts.
  • Archived the Step 2 PASS report with input hashes and the resolved configuration; historical platform-bootstrap evidence remains bound to its earlier source revision.
  • check-platform.py now rejects a missing exporter in DSC/FDF, missing AdvancedLoggerAccessLib/QrEncoderLib/HdwPortLib/PeilessArm/DXE_CORE mappings, a fabricated PcdAdvancedLoggerBase, or board [payload] tools other than true. It also ignores untracked *.DS_Store when verifying pinned component checkouts.
  • scripts/check-build-config.py independently re-resolves the four patch series and compares them with status, re-checks every module checkout and unixnu.lock pin, and verifies the assembled tree links drivers/kits/refer to those exact sources, kits/sm-t970 to this package directory, and tree/scripts to the merged framework/SoC/device copies. Two framework behaviours are checked rather than assumed: SoC sources are deliberately not linked into tree/refer, and the feed cache may be a symlink to the same pinned checkout.
  • The Step 5 checkers share scripts/fdt.py for structural FDT parsing, so the firmware blob and the board DTB are read the same way. The checker also scans the built FV when present and requires the five UniXNU/DarwinBoot modules.
  • scripts/collect-storage-inputs.py derives the UFS inventory from the captured live DT and GPT, cross-checks every UFS clock/reset ID against the kona gcc/rpmh headers, and records the header hashes; it enables nothing and needs no device.
  • scripts/prepare-trust-cache.py reproduces the accepted trust-cache bundle from the StaticTrustCache DER payload, runs the framework's original-system-trust builder and rejects a bundle whose SHA-256 is not in the OS profile allow-list.
  • Bypassing PE_init_printf(TRUE) (which calls vcattach) with a null PE_putc under t970-novc resolved the console spin: PE_init_iokit returned (probe f32a04c0, ~6 s reset) and the bootstrap thread reached bsd_init (probe fa16c47d, immediate reset) on kernel d862c992. The same PE_init_iokit checkpoint had not reset on the earlier console-skip kernel.
  • Restoring gc_initialize fixed the invalid ticket-lock panic: with vinfo populated and the lock initialized, the panic screen renders text and the kernel reaches bsd_init. Removing the forced panic then exposed the real next blocker: unmodified AMFI panics with 'AMFI: No PMGR?' at ConfigurationSettings.cpp:235 because no ApplePMGR provider is published. Image 041fcf8c, kernel 80cc00ad.
  • With sheng-pmgr=2 and the PMGR bridge linked, unchanged AMFI passes and the kernel reaches IOKit root-device mounting: panic 'Failed to mount root device @IOKitBSDInit.cpp:984' (kernel d4914c03, image see evidence). This is the expected storage blocker, not a startup-chain failure.
  • scripts/build-storage-bindings.py and scripts/data/native-storage-original-bindings.S are kept as the audited absolute-address binding for the original IOStorageFamily symbols; they are not referenced by any enabled archive entry.
  • scripts/build-owner-systemos-policy.py is host-only qualification: it mounts the raw SystemOS member read-only, signs a manifest with the local owner anchor and verifies all 806400 blocks through the real C/RSA host dylib; no hardware or storage publication is claimed.
  • A sparse DONT_CARE segment is the working way to write a partition larger than 4 GiB through Heimdall: the bootloader expands the sparse image and skips the untouched chunks, and a 1 MiB manifest-only segment was accepted before the three full segments were attempted.
  • The SMMU dump is a guarded arm_init diagnostic (t970-smmu-dump=1) that maps 0x15000000 and reports the valid SMR/S2CR entries on the panic screen; it is a bring-up probe, not a UFS fix, and it leaves normal boots untouched.
  • scripts/zz-build-shengufs-local.py is a host-only builder for the vendored driver; it was exercised to confirm the local archive compiles and links, and it is not part of the enabled archive list.
  • The GFSR write probe (write 0xffffffff, read back unchanged) and the IDR0-bit30 rejection together classify the T970 SMMU as write-locked with a non-SM8550 register model; both are arm_init/planner diagnostics, not storage fixes.
  • The 128-slot auto-stream scan is a driver-side diagnostic: it reads every SMR, skips masked and non-exact entries, and only accepts a stream whose context already passes the bypass checks; it never writes the SMMU.
  • The no-SMMU path keeps the SMMU IO mapping because hostBringUp dereferences it after the call; an earlier version that skipped mapPhys crashed with a null-pointer data abort (FAR=0), recorded here so the distinction between our patch bug and SMMU behaviour stays clear.
  • scripts/gen-ufs-phy-tables.py is a host-only generator: it downloads the pinned Linux QMP UFS driver headers, resolves the QSERDES/PHY register defines and writes the C tables; it is reproducible from scratch and does not touch the device.
  • The firmware bring-up uses GOP colour markers at fixed x positions plus a 0x9ff80004 stage word read back by the arm_init probe; both are diagnostic-only and the current image still resets before XNU can report the stage word.
  • The SCM probe is a board-side diagnostic in PlatformUfsLib: it issues a single fast SMC with the Qualcomm SIP owner and reports the return code through GOP markers; it does not change the SMMU or UFS state itself.
  • The survey flash receipt is the device-side confirmation of the read-only UFS path; it is independent of the kernel entry probes and was captured after the full userdata rewrite.

Completion criteria ​

  • Every claimed UniXNU milestone has matching source/image revisions, a reproducible command and accessible firmware/kernel logs.

Current limits ​

  • ADB inputs and BOOT-only reset checkpoints are archived. Original BOOT restoration is pending; UART, usable UEFI log export and XNU fault capture remain unverified.

Next action ​

  • After committing this verified milestone, continue normal service/Data bring-up and measure memory use; preserve genuine main-marker evidence and256MiB owned-memory constraints. Current870a11da is terminal diagnostic, not a normal system image.

Evidence ​

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

Copyright 2026 UniXNU contributors