UniXNU

English

简体中文

English

简体中文

Appearance

Samsung Galaxy Tab A7 10.4 (2020) (gta4lunix) ​

gta4lunix/UniXNU-gta4l

Samsung Galaxy Tab A7 10.4 (2020) Format 2 migration; PMGR-linked host kernel, tablet RAM-root/EL0 fixture success and bounded QEMU checkpoints, eMMC bring-up pending.

Source record: porting.toml, bc3e47c0cd516dda23296a1e235e6a6125885f05.

This page is generated from the device record.

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

Configuration ​

planned

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

Hardware and dependencies ​

  • Format 2 architecture, SM6115 SoC, iPadOS 17.7.11 21H461 and device profiles; board.toml and configs/gta4l_defconfig; the shared SM6115 DTSI.

Configuration ​

  • board.toml schema_version=2, soc_source=sm6115 and os_profile=ipados-17.7.11-21H461; CONFIG_XNU_NATIVE_PAN=n; CONFIG_XNU_ARMCPU=y and CONFIG_XNU_NATIVE_ARCH_TIMER=y; output out/gta4l/ipados-17.7.11-21H461/gta4l.

Procedure ​

  • ./unixnu defconfig gta4l_defconfig -D ../UniXNU-gta4l; ./unixnu fetch -D ../UniXNU-gta4l; ./unixnu status --json -D ../UniXNU-gta4l; ./unixnu build kernel -D ../UniXNU-gta4l.

Development findings ​

  • The SM6115 Cortex-A73/A53 cores are ARMv8.0 and do not implement PAN; the shared ARM64 profile enables PAN, so the board overrides CONFIG_XNU_NATIVE_PAN=n. TB128FU records the same undefined-instruction failure and the same override.
  • The Format 2 resolver selects the expected arch/SM6115/OS/device layers and the output path above; the PT_LOAD/ADT records are built from dts/gta4l.dts and the shared SM6115 DTSI.
  • The TB128FU device repository (xVanTuring/UniXNU-tb128fu) is the pinned reference for the timer, IPI and PMGR questions; docs/tb128fu-comparison.md records its credit, revisions and the limits on reuse.
  • The .circleci workflow credential patch is scoped to trusted HTTPS GitHub hosts and strips the token headers on cross-host redirects; the porting record owns the removed gemini-code helper path so the gate accepts its deletion.
  • The SM6115 SoC feed now points at gta4lunix/UniXNU-sm6115-common; the pinned commit is unchanged.

Completion criteria ​

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

Current limits ​

  • The host kernel build and prelink pass. The successful tablet RAM-root image uses a test-scoped ad-hoc signed fixture and owner trust bundle; it is not an authenticated-root or production security result.

Next action ​

  • Use the explicit diagnostic payload builder and the mandatory payload/ADT contract for raw RAM-root images; keep the pinned v5 baseline and the byte-identical v2 reproduction. The next packaging change is required only for a new documented baseline or payload format.

Evidence ​

Firmware and boot ​

planned

Hardware and dependencies ​

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

Configuration ​

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

Procedure ​

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

Development findings ​

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

Completion criteria ​

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

Current limits ​

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

Next action ​

  • Inventory the required firmware and boot inputs before implementation.

Evidence ​

Collect evidence using the next action.

CPU and interrupts ​

planned

Components: ArmCpu.

Hardware and dependencies ​

  • SM6115: four Cortex-A53 and four Cortex-A73 cores, PSCI 1.0 SMC, GICv3 distributor 0xf200000 and redistributor 0xf300000 with 0x20000 stride, 19.2 MHz timebase, timer PPIs 1/2/3/0.

Configuration ​

  • CONFIG_XNU_ARMCPU=y, CONFIG_XNU_NATIVE_ARCH_TIMER=y, CONFIG_XNU_NATIVE_PAN=n; dts/sm6115.dtsi timer interrupts <1 1>, <1 2>, <1 3>, <1 0>; candidate boot argument armcpu-timer-intid=19.

Procedure ​

  • Boot the boot CPU first with the timer diagnostic counters; compare INTID 27 and INTID 19; test SGI delivery before enabling any SPI-IPI workaround.

Development findings ​

  • The live timer specifiers match TB128FU: PPI 3 is the EL1 virtual timer, so INTID 19 is the gta4l candidate. The current ArmCpu default is 27 and INTID 27 may be another asserted source on this SoC; this is not yet measured on gta4l.
  • TB128FU found SGIs undelivered and used software-pended SPIs 504..511 (INTIDs 536..543). Its GIC capacity and unused-line inventory do not transfer to gta4l; do not enable SPI IPIs before measuring ours.
  • The TB128FU ArmCpu fork does not retain GICv2. Port only its timer/IPI mechanisms with per-device defaults so the shared GICv2 path stays intact.

Completion criteria ​

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

Current limits ​

  • The kernel links on the host and the boot CPU ran the bounded fs/timer fixture on the tablet; that fixture's single blocking poll does not establish sustained timer stability. Secondary-CPU bring-up and IPI delivery are untested.

Next action ​

  • Port the timer selection with the 27 default, test INTID 19 on the boot CPU, and record the interrupt counters before starting secondary CPUs.

Evidence ​

Collect evidence using the next action.

Memory and DMA ​

planned

Hardware and dependencies ​

  • Captured SM-T505N FDT memory map; DarwinBoot/firmware reservations; 3 GiB dram_info; ADT generator's one-range requirement.

Configuration ​

  • dts/gta4l.dts memory@40000000 reg = <0 0x40000000 0 0xc0000000>; board.toml payload dram_size=0xC0000000 and payload.adt owned_memory_size=0x80000000.

Procedure ​

  • Compare the three live banks, the ADT span and the firmware reserved-memory map; confirm the free window before any hardware test.

Development findings ​

  • The live FDT reports three banks: 0x40000000+0x3e580000, 0x80000000+0x20000000 and 0xa0000000+0x60000000, with a hole at 0x7e580000..0x80000000. The ADT generator requires one range, so 0x40000000+0xc0000000 is a physical span that includes the hole, not a contiguous free map.
  • After the live no-map regions and the Mu-Silicium DDR reservations, the largest contiguous free run is 0x80000000..0x100000000 (2 GiB). DarwinBoot requests that window; the previous 3 GiB request had no qualifying run and would stop at NO WINDOW.
  • The captured unit reports 3 GiB; TB128FU's 0x180000000 span and 0x100000000 owned window describe a different memory population and must not be copied.

Completion criteria ​

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

Current limits ​

  • The 2 GiB window is a static derivation from the live FDT and Mu-Silicium map; the runtime UEFI map has not been observed on the tablet. The first boot must validate DarwinBoot's allocation.

Next action ​

  • Boot the diagnostic image with the 2 GiB request and capture DarwinBoot's BIG RUN/FREE rows if it fails; do not change the window without those rows.

Evidence ​

Collect evidence using the next action.

Storage and root ​

planned

Hardware and dependencies ​

  • Identify the storage and root hardware, resources and existing component interfaces for this board. Reference-only inputs: limonabisi/linux-gta4l gta4l-7.2 at cf5f763f0ef8a5b4d8bb4163833cba1160c51894 (board DTS credits V6lhost; SoC DTSI credits Iskren Chernev) and itsChris122/UniXNU-guamp at 6be83ac10b4eee84d504266bb8d12ef64a083acc and Dracen-W/NativeEmmc at 4980f1070b0c822dedb9eb350df710a57df28590 (maintainer Dracen; catalog community-native-emmc; static audit in docs/native-emmc-reference-audit.md). No reference code is imported.

Configuration ​

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

Procedure ​

  • Read the live FDT, primary/backup GPT and recovery sysfs read-only; validate GPT CRCs and array equality with scripts/verify-gpt.py; resolve controller resources from the stock FDT before implementation.

Development findings ​

  • RAM-backed mockfs root and a signed static EL0 fixture succeeded on the tablet without the AMFI bypass arguments: PID 1 and 4096-byte page-size syscall observed. The fs/timer fixture then passed with reads of distinct 4 KiB pages, seek/reopen/EOF and one blocking poll() timeout. These are bounded fixture results, not an eMMC or authenticated-root result.
  • Recovery inventory: eMMC is mmcblk0 at /sys/firmware/devicetree/base/soc/sdhci@4744000, compatible qcom,sdhci-msm-v5/qcom,sdhci-msm-cqe; registers are 0x4744000+0x1000, 0x4745000+0x1000 and 0x4748000+0x8000; clocks are iface_clk, core_clk and ice_core_clk; reset is core_reset; supplies are vdd and vdd-io. Recovery reports HS400 Enhanced Strobe, CQHCI and 64-bit ADMA.
  • The eMMC is a 29.1 GiB DX68MB (Samsung CID 150100445836384d42009005f4661900, CSD d02701320f5903fff6dbffef8e404000, 61,071,360 logical 512-byte sectors). The live FDT matches the pinned stock FDT and the CRC-valid primary/backup GPTs agree on 80 partitions. These are recovery observations, not an XNU driver result.
  • The corrected v5 observation-only snapshot ran on the tablet and reported v=10000072 (major 1, minor 0x72), sv=7202, c=742dc8b2, c1=0000808f, ps=01f800f0, clk=0003, pwr=00, hc=00, hc2=0000, is=00000000 and ie=00000000. This establishes the v5 version offset and the gated map/read/panic path, not card protocol or storage access.
  • A separate read-only XNU handoff audit now observes the SM6115 GCC SDCC1 reset/branch/RCG state and the v5 vendor power status/mask, capability and DLL state without writing or acknowledging power requests. Its first boot image was withdrawn after a BOOT-only packaging failure (minimal DTB instead of the working v5 boot DTB); the pre-flash BOOT partition was restored and confirmed, and a corrected image preserving the v5 boot header, firmware, boot DTB and boot kernel section exactly then booted and completed the read-only audit. It reports bcr=00000000, ac=00004221, ahb=00000001, ice=00004229, cmd=00000000, cfg=00000401, m=00000001, n=000000fe, d=000000fd, clk=0003, pwr=00, pst=00000000, pm=00000000 and dll=00000000. This is register-level handoff evidence, not card or storage access.
  • The bounded host-local init probe is implemented in package/Gta4lSdhciHostInit.c/.h and compiled into the diagnostic archive (archive sha256 3cccb9e9d25a7e93b470c718e50b53edf50b975956259b37c851538f9c730b0f; host-init object sha256 2dac8c6e09d510e2d2c052aa599f630eec7950cc932547dd71657de793c7f2b9). It writes only SDHCI interrupt enable/signal enable (0x34/0x38), standard software reset (0x2F) and clock control (0x2C); disassembly shows no other MMIO stores. scripts/test-gta4l-sdhci-host-init.py passes its allowlist, write-contract, conflict and bounded-wait self-test; the audit hardened its MMIO check to reject reordered volatile qualifiers, typedef-hidden stores, whitespace-split stores, pointer-index stores and non-volatile pointer casts and added matching self-test cases; those source patterns are guardrails, not a proof of absence. scripts/test-gta4l-sdhci-host-init-sim.py replaces the production MMIO helpers with logging hooks, asserts the exact write sequence, records every read and write so a same-value transient write is rejected, and disassembles the run function to confirm a pointer-index mutation adds memory stores the event trace would not see. and covers conflicting arguments, an absent boot argument, an SDHCI map failure, a GCC-only map failure, bus power, reset timeout, unstable clock, interrupt suppression with nonzero enable registers, an ignored interrupt-clear failure, a pending vendor power request, a device-side vendor change, GCC reset/branch/RCG preconditions, delayed reset/clock completion, post-reset state changes and a stuck clock counter. The completion line is now HOST INIT REPORT with an explicit "vendor state reported, not enforced" qualifier; the historical tablet transcript keeps its earlier HOST INIT OK wording. The kernel relink succeeded (kernel sha256 ba52b6500ec3d064d173fa06fba23cb42aa4850c0bddd0df9a4178666c084646) and bsd_init calls preflight/audit/snapshot/host-init in order. The first 80 MiB payload inherited packed_data_ramdisk=true, so its ADT reserved PackedRAMDisk while the raw N4KROOT scratch-data.img reports RamdiskPacked=FALSE; DarwinBoot returned EFI_COMPROMISED_DATA at the UniXNU picker. BOOT was rolled back byte-for-byte (pre-flash backup 55d80d52a7246acec8277a8aeb40e38b2b2aac1eadef1e5d439579d86a7cd701; failed readback 73b7a586ee2498277dc77adc7b81714afa0662d36c8dfc48b8c0a2ec456e01b6; rollback readback 55d80d52a7246acec8277a8aeb40e38b2b2aac1eadef1e5d439579d86a7cd701). The corrected payload sets packed_data_ramdisk=false; its ADT reserves RAMDisk, payload sha256 0afaae8d66251d61c74d80427289da5e79551e52652e5236adaac55c6c8ac8b1, boot image sha256 d4aee57a9d1874d23dc010b7de43384ace6ab29241f5ee18cb10f0a561bab133, and both the 18-check boot-image gate and scripts/check-gta4l-payload.py pass. Corrected v2 was then flashed to BOOT; the image-byte readback matches d4aee57a9d1874d23dc010b7de43384ace6ab29241f5ee18cb10f0a561bab133, the full partition readback is 7ff725aacfbd5e205f98c6c71229e59908e432491cda91d2257f566d2925874a, and the readback gate is 18/18 with the extracted payload contract passing. The owner's manual boot then completed the host-local probe: reset=00, clk=0003, pwr=00, ie=00000000, se=00000000, and unchanged vendor values g=00f04003, pst=00000000, pm=00000000, vs=00300a0c, ddr=80040873, dll=00000000. The GCC row is the pre-write capture. No card command, data transfer, DMA, storage write, bus-power enable or card-clock enable was issued. This is controller-local evidence, not PM6125 L24/L11 rail state. Evidence: out/gta4l/ram-root-sdhci-host-init-evidence/host-init-success.txt and host-init-success-photo.jpg (photo sha256 672ecf61d0cb3e5675c5f511e88f3250a3f507afaf0acad84ee3153d97acc967).
  • The pinned mainline gta4l port at cf5f763f0ef8a5b4d8bb4163833cba1160c51894 enables sdhc_1 without vmmc-supply or vqmmc-supply; pm6125_l24a and pm6125_l11a are defined but unreferenced, while only sdhc_2 uses L22/L5. Its RPM path is GLINK over sram@45f0000 (qcom,glink-smd-rpm), not the live FDT's legacy qcom,rpm-smd node. This is a retained-rail design, not proof of the XNU-time rail state.
  • The mainline qcom_smd-regulator driver exposes cached is_enabled and uV only; it has no RPM query or PMIC register read. qcom_glink_rpm_probe writes zero to the TX head and RX tail and sends a GLINK version command, and opening rpm_requests requires an open/intent handshake. A read-only XNU audit can inspect the RPM message-RAM TOC and FIFO pointers but cannot derive L24/L11 voltage or enable state, and must not reset the FIFOs or ring the mailbox.
  • Step 4 records the board-level electrical-contract assessment in docs/sdhc-electrical-contract.md. It selects a bus-power-only candidate and finds all nine safety-critical areas (E1–E9) blocking: supply voltage/absmax, IO compatibility, current/loading, transients, sequencing, back-powering, retention, fault handling and recovery. DT ranges and current levels are operating intent, not measurements. Step 5 adds a versioned access trace, 33 deterministic scenarios, ten negative-control mutations and a separate-implementation oracle (same author) for the existing controller-local probe only; the oracle derives its rules from the header and write contract rather than the harness arrays. All host tests pass, but they do not cover bus-power or card-clock activation.
  • Step 6 records a dated NO-GO decision in docs/sdhc-decision-memo.md for sdhc-bus-power-activation. The gate table fails electrical contract, starting state, access policy, software behavior for that candidate, independent assessment, recovery and authorization. No bus-power-only implementation, image, access policy or measurement exists; the host-local diagnostic approval does not transfer.
  • The Dracen-W/NativeEmmc audit (commit 4980f1070b0c822dedb9eb350df710a57df28590, maintainer Dracen) is a host-only static review of a MediaTek MT6768 MSDC driver, not a Qualcomm SDHCI v5 port: its register map, command encoding, FIFO path and hardcoded userdata LBA are not transferable. Its staged boot arguments, IOBlockStorageDevice shape, write rejection, global controller lock, fail-closed manifest checks and exact-one-match IOMedia lookup are useful design references. The audit also records a completion gap (success after draining bytes without XFER_COMPL), an unconfirmed stop-on-error path, no R1 card-status check, no window content-hash verification, and a source/license mismatch (BSD-2-Clause-Patent versus BSD-2-Clause LICENSE). No code was imported, built or run, and the repository documents no hardware result.
  • The consolidated power/pad dependency report (docs/sdhc-power-pad-dependency-report.md) corrects the SdccDxe controller-local handshake: it sets the SDHCI bus-power bit, resets the controller, and writes the IO_SUCCESS (4) or BUS_SUCCESS (1) result bit to CORE_PWRCTL_CTL after bounded status/clear polls (up to 10,001 reads each) and a 10,000-read reset self-clear poll, with no PMIC/LDO/RPM action; CORE_PWRCTL_CTL carries success/fail results, not the BUS_OFF/IO_LOW request bits, which live in CORE_PWRCTL_STATUS. It is not a bus-power-on regulator sequence. The pinned pinctrl driver and sm6115.dtsi map the UEFI 0x9fe4 write at 0x575000 to the SDC1 QDSD group at west+0x75000, and the value matches the vendor sdc1_*_on drive/pull fields, closing only the write-to-pad mapping part of E2. L24/L11 physical state, the SDC1 pad domain and actual levels, PM6125 fault semantics, electrical sequencing and recovery, and the CX/ICC/SMMU state remain unmeasured. No electrical E/S gate closes and the bus-power decision remains NO-GO; the next step is a measurement-only baseline or the missing datasheets, schematic, safe test points and recovery procedure. A host-only regression test, scripts/test-gta4l-sdccdxe-decode.py, pins the SdccDxe hash and the handshake instruction words and checks the captured-status selection, the three non-aborting timeout paths, the loop bounds and the TLMM pad decode; it does not execute firmware.
  • The 2026-10-31 porting-approach reassessment records the owner-directed decision that software porting may proceed with the mainline Linux, vendor/LineageOS and captured-firmware stack as the reference, that electrical characterization is not a porting prerequisite, and that the NO-GO applies only to the on-device bus-power activation operation. It lists the dependencies to reproduce and keeps the residual electrical, RPM-retention, UEFI-volume and boot-medium risks open; no E1-E9 or S1-S4 gate is marked closed.

Completion criteria ​

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

Current limits ​

  • No XNU eMMC driver or XNU block-device result exists yet. Recovery inventory is read-only evidence and does not establish register, clock, DMA, power-domain or SMMU behavior under XNU. Recovery regulator state is not the XNU handoff state; the L24 reading was internally inconsistent (state=disabled with num_users=1 and microvolts=2960000), so it does not prove the eMMC VDD rail is on at the audit point in bsd_init.
  • The v5 snapshot and handoff audit are register-level diagnostics. They do not establish the PMIC L24/L11 state, VDDCX power domain, interconnect bandwidth, SMMU stream ID or card protocol state.
  • The pinned mainline port is source evidence only. Its no-supply sdhc_1 design does not measure L24/L11 at XNU handoff and is not an XNU regulator control or readback path; the separate SPMI map in docs/pm6125-register-map.md is a register map, not an implemented readback.
  • The NativeEmmc audit is static source review only. It does not establish that the reviewed driver builds, probes or reads on any device, and its MediaTek MSDC target does not exercise the gta4l SDHCI v5/CQE/ICE path, clock/reset/power sequencing, interconnect or SMMU. Its firmware-left-controller assumption is not satisfied by the gta4l handoff, and its hardcoded LBA and UUIDs are image-specific.

Next action ​

  • The host-local milestone is complete and the mainline RPM/regulator source trace is recorded in docs/rpm-power-interface.md. The pinned port has no L24/L11 consumer and no RPM readback; it relies on retained firmware rails. A separate SPMI readback map is recorded in docs/pm6125-register-map.md. Keep bus power and card clock off and issue no card commands, DMA or storage writes. Do not implement an RPM vote, SPMI regulator write or bus-power acknowledgement to learn the state. Next decision: accept a retained-rail contract only with the written board-level electrical contract and a direct rail measurement; a PMIC readback reports commanded state, not measured voltage, and substitutes for neither; the Mu-Silicium exit trace in docs/firmware-handoff.md shows the handoff writes no LDO control register but does not measure the rails, so it does not unblock the power stage. Keep the working RAM root throughout. Step 4 records the electrical-contract gap assessment in docs/sdhc-electrical-contract.md and Step 6 records NO-GO in docs/sdhc-decision-memo.md; do not treat the passing host-local tests or the oracle as permission for bus-power or card-clock activation. The next legitimate work is host-only evidence acquisition (datasheets, schematic, firmware/RPM analysis) and, only under a separately approved measurement procedure, direct rail/pad measurement. A bounded RPM/XBL static trace is recorded in docs/power-retention-evidence.md §7: it identifies the RPM LDOA resource tables for L11/L24, finds no referenced static table or stored pointer/resolvable PC-relative literal that selects either rail in the bounded scan, and finds no direct L11/L24 voltage, mode or enable write in the traced paths; the setter's class object and per-id array are built at runtime, and the runtime policy, PBS semantics and retention remain unresolved, so E7 stays blocking. The NativeEmmc audit in docs/native-emmc-reference-audit.md is a design reference for a future read-only XNU block device; it does not authorize controller commands, bus power or card clock, and it does not change the E7 or storage gates.

Evidence ​

Display ​

planned

Hardware and dependencies ​

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

Configuration ​

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

Procedure ​

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

Development findings ​

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

Completion criteria ​

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

Current limits ​

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

Next action ​

  • Inventory the required display inputs before implementation.

Evidence ​

Collect evidence using the next action.

Input ​

planned

Hardware and dependencies ​

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

Configuration ​

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

Procedure ​

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

Development findings ​

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

Completion criteria ​

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

Current limits ​

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

Next action ​

  • Inventory the required input inputs before implementation.

Evidence ​

Collect evidence using the next action.

GPU ​

planned

Hardware and dependencies ​

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

Configuration ​

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

Procedure ​

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

Development findings ​

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

Completion criteria ​

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

Current limits ​

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

Next action ​

  • Inventory the required gpu inputs before implementation.

Evidence ​

Collect evidence using the next action.

Network ​

planned

Hardware and dependencies ​

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

Configuration ​

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

Procedure ​

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

Development findings ​

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

Completion criteria ​

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

Current limits ​

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

Next action ​

  • Inventory the required network inputs before implementation.

Evidence ​

Collect evidence using the next action.

Audio ​

planned

Hardware and dependencies ​

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

Configuration ​

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

Procedure ​

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

Development findings ​

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

Completion criteria ​

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

Current limits ​

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

Next action ​

  • Inventory the required audio inputs before implementation.

Evidence ​

Collect evidence using the next action.

Power ​

planned

Hardware and dependencies ​

  • Original ApplePMGR consumer in the prelinked kernel; TB128FU original-PMGR bridge reference; gta4l PMIC, RPMh/RPM and clock resources are not yet inventoried.

Configuration ​

  • CONFIG_XNU_SHENG_PMGR=y; board.toml archives append build-platform-power.py; device series applies patches/xnu/sheng-platform-power.patch; package/ShengPlatformPower.cpp and scripts/build-platform-power.py are adapted with credit from TB128FU a9c3863.

Procedure ​

  • Run the bridge audit against the original kernelcache and prelinked kernel, then boot with sheng-pmgr=2 and no AMFI bypass for the first bounded test.

Development findings ​

  • TB128FU's ShengPlatformPower bridge publishes the original ApplePMGRNub through an ABI-audited provider, reads and writes no hardware, and fails unsupported power operations explicitly.
  • The audit passes against our original kernelcache f18b4df865405f2a287b84977d7aca745e056d656d9fc9df1662970ce2969de7 and prelinked kernel. The PMGR-linked kernel sha256 is dc8184da757b5323d2f4fb6c7ac1d588790b3d44d583c6d6fd24897cdbbcfe60; bsd_init.o has XNU_SHENG_PMGR=1 and the kernel contains ShengPlatformPower and sheng_pmgr_run.
  • QEMU TCG with sheng-pmgr=2 and no AMFI bypass reaches _bsd_init, _sheng_pmgr_run and _IOKitBSDInit with no AMFI 'No PMGR' panic and no _panic checkpoint; it stalls at _ml_get_timebase before _vfs_mountroot. Publication was not read back independently.
  • The live FDT resolves /soc/sdhci@4744000 vdd-supply to phandle 0x1f7 (/soc/qcom,rpm-smd/rpm-regulator-ldoa24/regulator-l24, pm6125_l24) and vdd-io-supply to 0x1f0 (/soc/qcom,rpm-smd/rpm-regulator-ldoa11/regulator-l11, pm6125_l11). It reports L24 2,704,000-3,600,000 uV with init 2,704,000, L11 1,704,000-1,952,000 uV with init 1,704,000, SDHCI vdd level 2,960,000 uV, vdd-io level 1,800,000 uV, and qcom,vdd-io-always-on/lpm-sup booleans. No XNU RPM/RPMh/SPMI/regulator component exists; ShengPlatformPower is the Apple PMGR bridge, not a Qualcomm regulator driver. There is no supported XNU path to enable or set L24/L11, so the first host-local SDHCI probe keeps bus power and card clock off and reports the power stage blocked.
  • The Mu-Silicium SDCC DXE ExitBootServices handler at SdccDxe.efi 0x81a8 configures the SDC1/SDC2 TLMM pads (0x00575000/0x00973000), sets SDHCI bus power, runs the v5 reset/power handshake (0x240/0x248/0x24c) and writes vendor registers; the reset clears the standard power and clock registers and the handler does not re-enable bus power, but has no PMIC/SPMI/LDO/RPM-request path. PmicDxeLa.efi 0x4220 locates the PMIC protocol GUID cea4489f-da0d-43d9-a3b2-766977a109f7 and calls the interface entry at 0x41ec, which issues SPMI writes at register bytes 0x14, 0x16 and 0xd1 only. Those addresses cannot reach the PM6125 LDO control registers 0x40/0x41/0x45/0x46/0x48/0x4c/0x61, so the two traced callees cannot directly write the L11/L24 enable or voltage registers. That is a direct-address exclusion, not proof that the callback leaves the rails unchanged: the 0x28 entry performs a read/modify/write of the arbiter IRQ clear register (v5 interpretation) over bitmap-selected APIDs (instruction sequence resolved; runtime bitmap unresolved), and for peripherals with the PMIC interrupt layout 0x14/0x16 are QPNPINT_REG_LATCHED_CLR and QPNPINT_REG_EN_CLR, so the writes clear latched interrupts and mask interrupt delivery. The 0xd1 value is u16>>14, so it can be 0-3, not necessarily zero. uefiplat.cfg has no LDO entries. During initialization the same IRQ status/clear routine runs via 0x266c -> 0x2d90, and 0x2d90 then calls 0x2ec8 with w3=0, which clears access-enable bit 0 for entries that pass its checks. The recovery path (0x27bc -> 0x3904) writes arbiter owner/APID registers at base+apid*4+0xa700 and base+apid*4+0x40900 when its conditions permit, though it is not proven to have run during the recorded boot. A null configuration pointer in the 0x120a8 exit callee reaches a non-returning self-loop, so the callback can hang instead of returning an error. See docs/firmware-handoff.md.
  • qcom_spmi-regulator.c carries a PM6125 regulator table giving L11 peripheral 0x4a and L24 peripheral 0x57, with the common layout VOLTAGE_RANGE 0x40, VOLTAGE_SET 0x41, MODE 0x45 and ENABLE 0x46, so L11 enable is address 0x4a46 and L24 enable is 0x5746. The board DTS uses qcom,rpm-pm6125-regulators rather than qcom,pm6125-regulators, so the proven path is RPM-owned regulation, not AP-side SPMI access. Three limits keep this from being a ready probe: the vendor live.dts bounds the LDO USID to 0 or 1 but has no regulator subnode, so no pinned source chooses between them; voltage encoding is ops-dependent, with ldo/smps on the range/selector getter and ftsmps426/hfs430/hfsmps on the two-byte millivolt getter, and both getters return a software selector rather than microvolts; and pmic_arb_read_cmd issues the command with writel_relaxed into the observer window, where the 1000 us bound covers only the transaction poll, not the APID mapping walks. The audit in docs/pmic-audit.md blocks the probe: identity, the runtime callback state and the board-level electrical contract are all unresolved.
  • docs/linux-regulator-lifecycle.md reconstructs the pinned board's power path with each statement tagged source-established, conditional or unknown. Only the board file has a regulators node; sdhc_1 has no vmmc-supply or vqmmc-supply; L11/L24 have DT min/max and regulator-allow-set-load but no regulator-boot-on, no regulator-always-on and no consumer, and their vdd_l9_l11/vdd_l23_l24 parent supply has no matching regulator, so regulator_resolve_supply may substitute the dummy regulator under full constraints, but registration does not depend on that substitution. Registration sets apply_uV and calls set_voltage, but rpm_reg_write_active includes uv only when the cached is_enabled is set, so no RPM packet is sent; always_on/boot_on are false, so registration does not enable either rail; the 30 s regulator_late_cleanup then reads the cached is_enabled of 0 and skips the disable. mmc_regulator_get_supply keeps -ENODEV error pointers, sdhci_msm_set_regulator_caps therefore writes no core_vendor_spec pad switch, sdhci_msm_set_pincfg calls pinctrl which returns 0 without applying a state, and the power IRQ acknowledges CORE_PWRCTL_BUS_SUCCESS after set_vmmc/set_vqmmc return 0. The probe does reset core_vendor_spec to 0xa9c and later paths rewrite other bits of it. Linux attempts RPM votes for VDDCX corners and interconnect bandwidth through rpmpd, OPP and icc-rpm, but none for L11/L24; a failed OPP call at probe is only warned about. The AP therefore never learns the rail state.
  • Host-only dependency tracing corrects the sdhc_1 prerequisite record: the probe requests VDDCX SVS_PLUS and the genpd attach enters the rpmpd send path, but genpd aggregates across attached devices and subdomains and the provider caches that aggregate, which may be higher than SVS_PLUS, and a pre-sync aggregate may emit max_state and physical voltage is unmeasured; PIO does not use the SDHC DMA master; SMMU stream 0xc0 state is unknown; the TLMM SDC2 write target is 0x00973000; and the L11/L24 handoff state remains unmeasured. Pinned-revision MMC/SDHCI/genpd/ICC sources establish the power-request chain through sdhci_set_power_noreg, genpd power-on at attach, and that both SDHC interconnect paths attempt RPM master/slave and bus-clock votes (the cpu-sdhc path is not local-only). PIO uses CPU MMIO rather than the SDHC DMA master. Physical rail/CX voltage and SMMU state remain unmeasured. The power stage stays blocked.
  • Step 4 records the candidate-specific electrical-contract assessment in docs/sdhc-electrical-contract.md. For sdhc-bus-power-activation every safety-critical area is blocking: supply voltage/absmax, IO compatibility, current/loading, transients, sequencing, back-powering, retention, fault handling and recovery. The document also records the evidence-acquisition requirements and proposed measurement requirements without executing them; PMIC readback is explicitly not a substitute for physical voltage or power-good evidence.
  • Step 5 verifies only the existing controller-local probe: 33 deterministic scenarios pass, ten negative-control mutations are rejected by the simulator, and the separate-implementation oracle (same author) validates all 33 traces, rejects the same ten mutations plus forty-one synthetic trace controls, and accepts the valid initially-zero interrupt baseline. The oracle derives its policy from the header and write contract, not the harness allowlists. The policy still prohibits bus-power enable, card-clock enable, power-status acknowledgement and PMIC/RPM/SPMI activity.
  • Step 6 records the dated NO-GO decision in docs/sdhc-decision-memo.md. The gate table fails electrical contract, starting state, access policy, software behavior for the bus-power-only candidate, independent assessment, recovery and authorization. Blockers use canonical E1-E9 (electrical-contract areas) and S1-S4 (software, provenance, independent assessment, authorization) identifiers. No approval request is made because the technical prerequisites are not met.
  • The stock-firmware analysis archive supplied by https://github.com/NoNameBuilder was audited in docs/stock-firmware-analysis-audit.md. All 214 manifest-listed files match their hashes, but the supplied XBL executable bytes and device-tree overlays differ from the captured image and live FDT, so its code-level conclusions do not transfer automatically. Its XBL program-header layout prompted correction of our missing 0x5fc00000 LOAD range; its LCDB voltage, PMIC interrupt-specifier, XBL address and disassembly-coverage claims were corrected. It adds no rail, pad or power measurement and closes no gate.
  • A bounded, reproducible host-only scan of the captured rpm.img (scripts/analyze-gta4l-rpm-ldoa.py; image sha256 272bebd3ddd7ef223d6e95e9b4cd30385a3df0eb4fa7beae6b622f457b4937c6) finds exactly one stored pointer to the L11 name record (0x46966a8, the dead selector slot), none to L24, one to the selector array (from the unreferenced group table at 0x46966fc), one to the voltage table (the descriptor at 0x4696c40), one to the descriptor (0x4697f10 inside the 0x4697e20 boundary table), and none to 0x4697f10 or the group table. The class table at 0x4695774 is zero in the linked image and the setter's class object is built at runtime by 0x46996c4, so the runtime count and id bounds are conditional. This is a stored-word scan, not a control-flow reachability result.

Completion criteria ​

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

Current limits ​

  • No power backend (clocks, sleep, reset) is implemented. The bridge is runtime-unqualified and the QEMU stall is unresolved. The RAM-root fixture booted through the PMGR-linked kernel without AMFI bypass arguments; PMGR publication and power operations remain unqualified.
  • The firmware trace shows the Mu-Silicium PMIC exit path reaches only the SPMI write and the 0x28 entry and writes register bytes 0x14, 0x16 and 0xd1, which cannot directly reach the LDO control registers 0x40/0x41/0x45/0x46/0x48/0x4c/0x61; it does not measure the rails, does not resolve the runtime 0x28 bitmap or the clear-register read-back, and can clear latched PMIC interrupts and mask interrupt delivery on peripherals using the QPNPINT layout. The SPMI map reports commanded state only, supplies no power-good bit, leaves the LDO USID unresolved, and depends on a subtype read for voltage decoding. An SPMI read is a transport bring-up: it needs arbiter version detection, an APID owner-table parse and one observer command write per transaction, and the 1000 us bound covers only the transaction poll. The board-level electrical contract, including absolute maximums, consumer topology and safe sequencing, is not established, so docs/pmic-audit.md blocks live PMIC access. The LDOA reference analysis is a stored-word scan: it does not exclude computed addresses, runtime relocation or aliasing, and the class object is runtime-built.

Next action ​

  • Capture a separate PMGR publication/power result on the tablet; do not claim power support from the bridge or from the RAM-root fixture. Keep bus power and the SDHCI card clock off until the retained-rail electrical contract and a direct rail measurement are established; a new RPM/SPMI/regulator path is not required merely to match the pinned design. See docs/sdhci-host-init.md. The Mu-Silicium exit trace is recorded in docs/firmware-handoff.md and does not unblock the power stage. Live PMIC/SPMI access is blocked by docs/pmic-audit.md: the L11/L24 slave assignment is unresolved between USID 0 and 1 (bounded to that pair and not selected by any pinned source in docs/pm6125-usid-research.md), the runtime 0x28 bitmap, the clear-register read-back value and the indirect callback paths remain unresolved, the voltage getters return software selectors rather than microvolts, and the board-level electrical contract is absent. Do not scan candidate slaves or substitute a USID. The next legitimate step is host-side: try to reconstruct the working RPM-owned Linux path and its assumptions from pinned sources rather than inventing AP-side SPMI access. That reconstruction is recorded in docs/linux-regulator-lifecycle.md and shows the AP never enables, disables or reads L11/L24. Remaining host-side questions are what the RPM firmware does across suspend and shutdown, whether the handoff rail state is guaranteed or incidental, which other consumers share the two supplies, and what the board-level electrical contract requires. docs/power-path-decision.md inventories that contract gap and selects the retained-rail RPM-owned path over AP-side SPMI; it does not authorize a live test. docs/sdhc-dependency-trace.md records the corrected remaining prerequisites and lists the fetched pinned-revision sources with hashes; passing the controller-local gate does not establish power, card-command, DMA or tuning readiness. Step 4 records the candidate-specific contract assessment in docs/sdhc-electrical-contract.md and Step 6 records NO-GO in docs/sdhc-decision-memo.md. The passing host-local scenarios, mutations and oracle are software evidence only; they do not authorize bus-power or card-clock activation. The next legitimate work is host-only evidence acquisition and, separately, an owner-approved measurement-only procedure that does not activate SDHC; approval of that measurement does not approve a controlled activation or the bus-power capability (docs/sdhc-decision-memo.md §6.2-§6.4). The current-tree evidence baseline is in docs/evidence-baseline.md. The stock-firmware analysis supplied by https://github.com/NoNameBuilder and its audit are recorded in docs/stock-firmware-analysis-audit.md; they are cross-check material and do not authorize live access.

Evidence ​

Image assembly ​

planned

Hardware and dependencies ​

  • Format 2 kernel step, archive builders, prelink, payload and boot image; 192 MiB payload size; iPad7,1 17.7.11 21H461 kernelcache.

Configuration ​

  • board.toml payload size_mib=192, loader=firmware, panic_screen=true, dram_size=0xC0000000; CONFIG_XNU_BUILD_ARCHIVES=y; output out/gta4l/ipados-17.7.11-21H461/gta4l.

Procedure ​

  • ./unixnu build kernel -D ../UniXNU-gta4l; ./unixnu build package; ./unixnu build firmware; ./unixnu build payload; ./unixnu bootimg.
  • For a raw RAM-root diagnostic payload, use scripts/build-gta4l-diagnostic-payload.py --diagnostic host-init with the data ramdisk, owner trust cache and unique chip ID. It copies the device tree, sets payload size and packed_data_ramdisk=false, runs the payload step, and checks the ADT contract without modifying the tracked board.toml.
  • For a diagnostic image, use scripts/package-gta4l-diagnostic.py with the pinned v5 baseline and the payload; it preserves the header, firmware, boot DTB and boot kernel section, recomputes the boot-image ID, requires the payload/ADT contract, and runs scripts/check-gta4l-boot-image.py. Run scripts/test-gta4l-boot-image.py, scripts/test-gta4l-diagnostic-package.py and scripts/test-gta4l-sdhci-host-init-sim.py before flashing.
  • To replay the historical payload, run scripts/build-gta4l-diagnostic-payload.py with the audit board snapshot and --kernel; set SOURCE_DATE_EPOCH=1793180892 for the historical FAT timestamp, and use scripts/normalize-gta4l-adt-seed.py for the fail-closed seed comparison into a new output path; it refuses an existing output and candidate/reference aliases. docs/payload-build-recipe.md records the inputs, the clean hash, the seed-normalized comparison and the preserved out/gta4l/payload-testbuild-evidence directory.

Development findings ​

  • The PMGR-linked kernel/prelink pass: kernel.macho is a 49 MiB Mach-O arm64 image with SHA-256 dc8184da757b5323d2f4fb6c7ac1d588790b3d44d583c6d6fd24897cdbbcfe60; link.filelist has 1006 entries and none are missing. The earlier no-bridge hash was ef85af5417ace24e7b96f6c5a3224d2e7c40a163c1532bf2586f23fb5dd5f8bd.
  • The full ordered archive plan is required: replacing it with only build-platform-power.py dropped the NativeAES bindings and failed the final link. board.toml now keeps the architecture list and appends the PMGR builder.
  • The fresh tree first stopped in prepare-xnu-source.py while fetching omitted DriverKit headers; the retry-safe fetch restored 26 headers. The earlier Format 1 corecrypto failure was stale state, not a missing bootstrap object set.
  • The corrected v2 audit image preserved the v5 boot header, firmware, boot DTB and boot kernel section exactly but was produced by temporary board.toml substitution. scripts/build-gta4l-diagnostic-payload.py now replaces that path for raw payloads by copying the device tree and forcing the explicit size and packed-data flags; scripts/package-gta4l-diagnostic.py takes the pinned baseline and a named payload as explicit inputs.
  • scripts/package-gta4l-diagnostic.py now packages from the pinned v5 baseline and a named payload without modifying board.toml. It preserves the header page, firmware, boot kernel section and boot DTB, replaces only the ramdisk, recomputes the Android boot-image SHA-1 ID, and runs the component gate. Reproducing v2 from the v5 baseline and audit payload is byte-identical: a34519c66820eb5f1f4c4790be5e10233ffd4c8a4ece2df4768e7dca151c8546.
  • scripts/check-gta4l-boot-image.py now checks the header page excluding the deterministic ID, the recomputed ID, zero kernel padding, absence of trailing data, the appended FDT total size, the Qualcomm ID properties and an optional expected payload hash. scripts/test-gta4l-boot-image.py covers exact pass, payload-only replacement, minimal-DTB substitution, a different valid DTB, a changed header field, a wrong ID, nonzero padding, trailing data, a short ramdisk, a wrong expected payload and a malformed image.
  • An independent ABL/LinuxLoader-oriented check with bootimg_tool.py, provided by https://github.com/NoNameBuilder, confirmed the v2 header, appended FDT and Qualcomm ID properties and rejected the v1 DTB. The tool is recorded as external evidence, not vendored; its outer FV/LZMA checks also fail on the known-good v5 image and are not used as a gate.
  • scripts/check-gta4l-payload.py now checks the ADT memory-map placeholder against the actual scratch-data.img layout and checks unixnu.toml diagnostic arguments. Its self-test rejects the failed packed/raw mismatch and passes corrected v2. The failed host-init payload was packaged as PackedRAMDisk while the raw N4KROOT fixture reports RamdiskPacked=FALSE; DarwinBoot returned EFI_COMPROMISED_DATA at the UniXNU picker. Corrected v2 reserves RAMDisk and passes both the payload checker and the 18-check boot-image gate.
  • scripts/build-gta4l-diagnostic-payload.py makes the former temporary diagnostic board explicit and reproducible: it copies the device tree, forces payload.size_mib=80 and packed_data_ramdisk=false, runs the normal payload step, copies the result, and requires the payload contract before writing a manifest. The tracked board.toml remains at 192 MiB packed.
  • scripts/package-gta4l-diagnostic.py now runs scripts/check-gta4l-payload.py before publishing and records the contract result in the manifest. scripts/test-gta4l-diagnostic-package.py rejects a wrong expected diagnostic and the retained packed/raw failed payload; the valid audit payload still reproduces the v2 image byte-for-byte.
  • scripts/test-gta4l-sdhci-host-init-sim.py compiles the production host-init source against a fake MMIO window and minimal kernel-header stubs, replaces only the six MMIO helpers with logging hooks, and records every read and write. It exercises conflicting arguments, an absent boot argument, a failed mapping, bus power already on, reset timeout, unstable clock, a pending vendor power request and a device-side vendor change; it asserts the exact write sequence, rejects any access outside the allowlist, and rejects an injected same-value POWER_CONTROL write that leaves final memory unchanged.
  • The historical-host payload replay reproduces every payload byte except the 64-byte ADT random-seed: the clean payload 1d15ea68cd570382ed4ba7b426aa4fb29cf5c303124a289af16451248a8975ff differs from the historical 31b78bec7529706407f682e64dbc9c4c990e86009025174fd3f791606b29ea31 only at 0x30e3b78, and the fail-closed seed-normalized payload is byte-identical. Packaging the normalized payload against the v5 baseline reproduces the historical audit v2 image a34519c66820eb5f1f4c4790be5e10233ffd4c8a4ece2df4768e7dca151c8546 byte-for-byte; the clean payload packages to 037ba650847caa0cb32ac14a99c13736ae2ae6196700344531a224590c6694eb, differing in the derived image ID and the seed. docs/payload-build-recipe.md records the pinned inputs. A second controlled clean build (payload c697903b74279b6cadf364b94871a6125b42229cbdedf250bfcb62331b8d3d4c, boot 60ad9d056b439a2c53f82dddcefc6ac9ec0df0a5b323ff9cdcebc3d76e15e8f8) passed both gates and normalization again reproduced 31b78bec... and a34519c6... byte-for-byte. A clean bit-exact build needs a supported ADT seed pin, which the pinned UniXNU does not provide. The controlled build is preserved at out/gta4l/payload-testbuild-evidence with provenance.json and a verified SHA256SUMS.
  • The linked kernel 3103e067575d94d878485de464ee0173b07ab2f02215d3abae6fb962c1c59064 is reproduced byte-for-byte from the pinned source and patches with the historical build date, personality, object and archive-member mtimes and RC_ProjectSourceVersion=10063.141.1; the prelink outputs 452026b2d8bbfaaa5b6ebc97ce235f396a8929b50d3957eff4c655eddd30ca86 and 9f70ad6594f539f447029d5714c0cd065b14b3c5e84b54dfd7c8d5b5c22572e8 are regenerated from it (docs/kernel-build-recipe.md sections 6-7).

Completion criteria ​

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

Current limits ​

  • The PMGR kernel host build/prelink and one QEMU checkpoint run pass. Payload and boot images have been built from this kernel, and the RAM-root report fixture booted on the tablet; it is not an authenticated-root result.
  • The payload replay starts from the historical prelinked kernel; the kernel compile/link is replayed separately in docs/kernel-build-recipe.md, and a clean bit-exact payload build remains not established.

Next action ​

  • Use the explicit diagnostic payload builder and the mandatory payload/ADT contract for raw RAM-root images; keep the pinned v5 baseline and the byte-identical v2 reproduction. The clean payload build is not bit-exact because the ADT random-seed is fresh; use the documented seed-normalized comparison for provenance and do not present it as a clean build. A supported seed pin remains host-only work.

Evidence ​

Diagnostics ​

planned

Hardware and dependencies ​

  • Build logs for the fresh Format 2 tree; the shared prepare-xnu-source.py fetch path; the TB128FU reference revisions.

Configuration ​

  • UNIXNU_XNU_TAG=xnu-10063.141.1 and the pinned source revision; GITHUB_TOKEN can be supplied to prepare-xnu-source.py but is not required.

Procedure ​

  • Run the kernel build with a log; on a fetch failure, preserve the log and retry with the retry-safe prepare-xnu-source.py; compare failures across clean output trees.

Development findings ​

  • prepare-xnu-source.py used four threads with a 30 s TLS timeout and no retry. A GitHub raw fetch timed out during the first Format 2 kernel build, before any XNU compilation. The shared script now retries transient failures with a 60 s timeout and exponential backoff; scripts/test_prepare_xnu_source.py covers the retry and non-retry paths.
  • The clean build completed with exit 0. The PMGR kernel.macho hash dc8184da757b5323d2f4fb6c7ac1d588790b3d44d583c6d6fd24897cdbbcfe60, 1006/1006 link objects and XNU_NATIVE_PAN=0 records are in docs/build-revisions.md.
  • QEMU TCG reached _bsd_init, _sheng_pmgr_run and _IOKitBSDInit with sheng-pmgr=2 and no AMFI bypass, then timed out at _ml_get_timebase before _vfs_mountroot; the PMGR archive audit and build report are retained.
  • scripts/test-gta4l-diagnostic-payload.py checks the diagnostic payload builder with temporary stand-ins (forced size, packed_data_ramdisk=false, the contract failure path and the command line) without building a payload or touching board.toml; scripts/test-gta4l-sdccdxe-decode.py and scripts/test-gta4l-spmidxe-descriptor-base.py pin the firmware handoff and descriptor-base scan results. All are host-only and execute no firmware.

Completion criteria ​

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

Current limits ​

  • The retry test is a host unit test; the kernel/QEMU result is host-only. The QEMU serial layer has no Apple-compatible UART. The tablet result is a panic-screen report, not a serial log.

Next action ​

  • Preserve the QEMU evidence and the tablet panic-screen result; qualify the fs/timer diagnostic separately.

Evidence ​

Collect evidence using the next action.

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

Copyright 2026 UniXNU contributors