UniXNU

English

简体中文

English

简体中文

Appearance

Lenovo Legion Y700 Gen 4 (elden) ​

jerry-2009/UNIXNU_elden

Lenovo Legion Y700 Gen 4 format 2 migration. Phase 1 UEFI is device-verified; XNU, storage, display and touch remain bring-up work.

Source record: porting.toml, 57e68be133c407ef9fa7dc6b4f10f1bd4cd3aedd.

This page is generated from the device record.

AreaStatus
Configurationhost-verified
Firmware and bootdevice-verified
CPU and interruptsimplemented
Memory and DMAimplemented
Storage and rootplanned
Displayplanned
Inputplanned
GPUplanned
Networknot-applicable
Audionot-applicable
Powerplanned
Image assemblyhost-verified
Diagnosticsdevice-verified

Configuration ​

host-verified

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

Hardware and dependencies ​

  • Use the ARM64 and iPadOS 17.7.11 profiles supplied by UniXNU.
  • Select the shared platform, CPU and DarwinBoot components.
  • Provide an SM8750 profile until an official shared SoC repository exists.

Configuration ​

  • board.toml declares schema_version = 2, soc_source = sm8750 and os_profile = ipados-17.7.11-21H461.
  • The complete component list is explicit because profile arrays replace inherited arrays.
  • Configuration and patch roots are ordered as ARM64, SoC, OS and device.
  • soc/sm8750 supplies the transition profile and is referenced from feeds.toml.

Procedure ​

  • Run defconfig from a current UniXNU checkout.
  • Inspect status JSON for profile order, component dependencies, patch order and output path.
  • Replace the local SoC source with a reviewed UniXNU-sm8750-common commit before release.

Development findings ​

  • The repository was format 1 and did not select shared SoC or OS profiles.
  • A public UniXNU-sm8750-common repository was not available during migration.
  • Keeping a separate local SoC profile preserves parser validation without mislabelling unqualified hardware support as shared.
  • Phase 2.0 resolved ARM64, local SM8750, iPadOS and device layers; the selected component order, 56 patches, 4 KiB page setting and separate format 2 output were checked with current UniXNU.
  • Phase 2.1 keeps the XNU handoff and firmware memory description separate from the phase 1 dummy firmware DTB.
  • Phase 2.2 resolved 57 patches after adding compile-time-disabled PMGR context required by the shared boot-progress patch. CONFIG_XNU_BOOT_PROGRESS is disabled for the minimum kernel because that diagnostic layer currently requires UFS, owner-root and Virtio.

Completion criteria ​

  • board.toml resolves four ordered configuration layers.
  • All selected components come from the UniXNU catalog and include their dependencies.
  • No array field depends accidentally on inheritance.
  • The SoC source is a reviewed remote commit and unixnu.lock records it.

Current limits ​

  • soc/sm8750 is local and is not yet a release-quality shared source.
  • The first resolution pass selects only platform, CPU, AES, prelink and DarwinBoot components.

Next action ​

  • Phase 2.3: validate the near-final-size Android v3 ramdisk, FDT/initrd and HOB path in an isolated candidate. Replace the local SM8750 source with a reviewed shared commit before release.

Evidence ​

Firmware and boot ​

device-verified

Components: DarwinBoot.

Hardware and dependencies ​

  • mu_wide_platforms lenovo-y700g4 UEFI source and patched PMIC binaries.
  • UniXNU, UniXNUDxe, DarwinBoot and EldenRamDiskDxe firmware modules.
  • A 4 MiB FAT16 payload containing package/unixnu.toml.

Configuration ​

  • firmware.dsc points to PakalaPkg/PakalaNoSb.dsc.
  • firmware.fd points to the DEBUG CLANGPDB SM8750_EFI.fd.
  • payload volume is ELDENRAM and loader is firmware.
  • panic_screen remains false because the phase 2 panic renderer is not integrated.

Procedure ​

  • Build the phase 1 image with scripts/build_phase1.py.
  • Run scripts/verify_artifact.py against the FD and Android v3 image.
  • Owner performs two RAM cold boots with fastboot boot.

Development findings ​

  • The vendor UFSDxe crashed before the menu, so it was removed from the phase 1 APRIORI, DSC and FDF.
  • The embedded FAT payload avoids persistent storage and makes the menu independent of UFS.
  • The same image reached the visible menu twice and returned to stock Android after reset.

Completion criteria ​

  • Firmware contains UniXNU, UniXNUDxe, DarwinBoot and the RAM payload driver.
  • The payload config is readable and the menu accepts volume-key input.
  • Two RAM boots produce the same visible checkpoint and do not modify persistent partitions.

Current limits ​

  • The verified firmware is phase 1 and does not contain a bootable XNU payload.
  • The new format 2 firmware command is not yet switched from the project build script.

Next action ​

  • Use the current phase 1 image as the accepted baseline. Phase 2.3: validate Android ramdisk/FDT/HOB handoff and the RAM disk driver only in a separately isolated candidate; measure inner/outer FV capacity before integrating kernel inputs.

Evidence ​

CPU and interrupts ​

implemented

Components: ArmCpu.

Hardware and dependencies ​

  • SM8750 MPIDRs 0x0, 0x100, 0x200, 0x300, 0x400, 0x500, 0x10000 and 0x10100.
  • GICv3 distributor 0x16000000, redistributor base 0x16080000 and stride 0x40000.
  • 19.2 MHz architectural timer and PSCI SMC conduit.

Configuration ​

  • The SoC DTSI declares eight CPU nodes, timebase-frequency = 19200000 and psci method = smc.
  • The GIC node exports unixnu,adt-name = intc.
  • The device defconfig enables ARM DT platform, ArmCpu, native timer and PAN.

Procedure ​

  • Compile dts/elden.dts with the SoC include path.
  • Generate an ADT from the DTB and inspect /cpus, /psci and /arm-io/intc.
  • Boot the smallest XNU payload and record the first CPU, GIC or timer failure.

Development findings ​

  • The board evidence documents the same eight MPIDR layout used by other SM8750 ports.
  • The shared ADT generator emitted cpu0 as running and all other cores as waiting; ArmCpu does not probe secondary nubs unless sheng-smp is enabled.
  • ArmCpu reads the GIC through /arm-io/intc and requires a complete two-range reg property.
  • The old kernel argument set enabled armcpu-spi-ipi before elden had evidence that SGIs fail or that per-core SPI routing works. Phase 2.1 removed it from the single-boot-CPU milestone.
  • Secondary CPU startup and both SGI and SPI IPI delivery are not device-verified for elden.

Completion criteria ​

  • The boot CPU reaches the ArmCpu checkpoint.
  • GIC distributor and its own redistributor frame map successfully.
  • Timer handling works before secondary cores or IPI transport are qualified.

Current limits ​

  • No elden XNU CPU, GIC or timer log exists yet.
  • The eight-core topology is described, but SMP bring-up is not claimed.

Next action ​

  • Phase 2.5: prove ArmDTPlatform and the boot CPU ArmCpu/GIC/timer checkpoints using the audited CPU order and argument set. Defer SPI IPI, SGI delivery, secondary startup and SMP qualification to separate device checks.

Evidence ​

Memory and DMA ​

implemented

Components: ArmDTPlatform.

Hardware and dependencies ​

  • The owner-captured live elden FDT, including the 12 GiB RAM map, initrd and reserved-memory nodes.
  • The pinned Linux 16 GiB variant and the elden UEFI static memory map.
  • A conservative 256 MiB XNU handoff window in UEFI DXE conventional memory.

Configuration ​

  • dts/elden.dts declares one 256 MiB XNU handoff node at 0xC2400000.
  • payload.dram_size and payload.adt.owned_memory_size both request 0x10000000.
  • dts/elden-firmware-memory.dts records the sanitised live 12 GiB RAM map, reserved-memory ranges and expected GOP framebuffer.
  • The format 2 generator creates a 64-byte seed, CHRP NVRAM proxy and optional-input memory-map placeholders.

Procedure ​

  • Compile the hardware and firmware memory descriptions.
  • Generate an ADT with the shared generator and decode it independently.
  • Cross-check the XNU window against firmware RAM, reserved-memory and the pinned UEFI memory map.

Development findings ​

  • The previous [0x80000000, 0x100000000) candidate overlapped 44 recorded no-map reservations and was removed.
  • The live FDT is 885,861 bytes with SHA-256 8a653a3e790f29bf2b0f3545135f06fe771360f31da3d37c04f648c26b95e26e and describes the current 12 GiB RAM map.
  • The former A8000000+10000000 UEFI Kernel carveout overlaps the live initrd B74AC000-B7FFEE30 and is unsuitable for RAM-boot phase 2.
  • C2400000+10000000 is covered by live RAM, avoids all live reservations and the initrd, and lies in UEFI DXE conventional memory.
  • The flashed vendor FDT uses generic qcom,sun-qrd compatible strings but retains the elden 3K panel marker, 1904x3040 display and UFS path.
  • The ADT has no optional RAMDisk, TrustCache or GPU addon placeholders because phase 2.1 has no matching inputs.
  • The unique chip ID remains a local input and is not stored in the repository.

Completion criteria ​

  • The ADT contains exactly one continuous memory range.
  • The range is covered by live firmware RAM and avoids recorded reservations, initrd, GOP and UEFI FD.
  • DarwinBoot and the UEFI exit map confirm that same range is conventional memory before XNU entry.

Current limits ​

  • The raw live FDT remains local-only because it can contain device identifiers.
  • Actual DarwinBoot ADT, boot_args and allocated-window addresses remain runtime evidence.
  • The live vendor tree and pinned 16 GiB source differ in RAM size and generic compatible strings; both are tracked separately.
  • SMMU and cache policy are not complete.

Next action ​

  • Phase 2.3: preserve .cache/device/elden-live.fdt locally and rerun the live audit if firmware or boot mode changes; never commit the raw tree. Keep the phase 2 hardware ADT separate from the firmware FDT.

Evidence ​

Storage and root ​

planned

Hardware and dependencies ​

  • SM8750 UFS host at 0x1d84000 and PHY at 0x1d80000.
  • 4 KiB logical-sector partition geometry and a root-volume UUID.
  • Clock, regulator, power-domain and SMMU stream ownership.

Configuration ​

  • The phase 1 defconfig disables Native UFS.
  • The format 2 component list does not select a storage transport.

Procedure ​

  • Inventory GPT and logical block size without modifying the device.
  • Bring up UFS in read-only mode and validate known blocks.
  • Add an SM8750 storage component and root-window input before mounting.

Development findings ​

  • UFSDxe crashed in phase 1 and was removed from the menu path.
  • There is no elden XNU UFS probe result yet.
  • The phase 1 FAT payload intentionally bypasses persistent storage.

Completion criteria ​

  • Controller and PHY initialize.
  • Read-only capacity, GPT and known-block checks match the device.
  • The configured OS volume mounts and launchd starts.

Current limits ​

  • Storage is not selected or implemented.
  • No owner-authored userdata image or root UUID exists.

Next action ​

  • Capture a read-only GPT and memory-resource audit, then implement an SM8750 UFS component.

Evidence ​

Display ​

planned

Hardware and dependencies ​

  • 1904x3040 bonded dual-DSI panel with DSC.
  • UEFI GOP framebuffer and splash reservation.
  • SM8750 DPU/DSI/PHY and backlight sequencing.

Configuration ​

  • The phase 1 menu renders through UEFI GOP.
  • XNU display and IOMobileFramebuffer components remain disabled.

Procedure ​

  • Keep display handoff on GOP for the first kernel milestone.
  • Record a visible checkpoint after DarwinBoot.
  • Add DPU/DSI only after kernel entry is stable.

Development findings ​

  • GOP display is device-verified in the UniXNU menu.
  • No XNU display provider has been validated.
  • The panel path remains a known high-risk cold-boot area.

Completion criteria ​

  • XNU paints a known pattern through a declared framebuffer handoff.
  • Userland presentation and backlight transitions work.

Current limits ​

  • No DPU, DSI, DSC or panel node is present in the hardware DTS.
  • GOP success is not counted as XNU display support.

Next action ​

  • Carry GOP framebuffer properties into DarwinBoot and record the first kernel-visible screen checkpoint.

Evidence ​

Input ​

planned

Hardware and dependencies ​

  • Novatek SPI touch on SPI4 and GPIO 162 interrupt.
  • Volume and power keys used by the UEFI menu.

Configuration ​

  • The phase 1 menu accepts volume-key input through UEFI.
  • No XNU HID or Novatek transport is selected.

Procedure ​

  • Preserve UEFI key navigation as the bring-up input path.
  • Inventory the touch firmware and protocol from read-only sources.
  • Add QCOM GENI SPI, touch protocol and HID input after XNU boots.

Development findings ​

  • Volume-key menu input is device-verified.
  • Touch has not been initialized by XNU.
  • The panel and touch controller share board state that must be validated together.

Completion criteria ​

  • Touch coordinates map to the display.
  • Contact IDs, releases and multi-touch remain stable.
  • Buttons produce expected HID events in XNU.

Current limits ​

  • No touch component is selected.
  • The NT36536 firmware and ABI inputs are not yet integrated.

Next action ​

  • Read the touch controller model and firmware version without modifying flash, then define the board transport.

Evidence ​

GPU ​

planned

Hardware and dependencies ​

  • Adreno 830 / gen80000.
  • GPU firmware, power votes, SMMU and display integration.

Configuration ​

  • GPU and Metal components are not selected.
  • The first XNU milestone targets CPU/console progress only.

Procedure ​

  • Reach the XNU platform expert without GPU dependencies.
  • Collect the GPU identity and firmware hashes.
  • Select and implement a GPU component only after a display provider exists.

Development findings ​

  • The board has no validated XNU GPU path.
  • Selecting SM8550 Adreno740 would misrepresent the Adreno 830 implementation scope.

Completion criteria ​

  • GPU submissions, fences and mapping work.
  • A known image renders and Metal presentation is visible.

Current limits ​

  • GPU and Metal are explicitly out of the first milestone.

Next action ​

  • Keep GPU unselected until an SM8750-compatible component and firmware inputs exist.

Evidence ​

Network ​

not-applicable

Hardware and dependencies ​

  • Wi-Fi is outside the current bring-up milestone.

Configuration ​

  • No Wi-Fi or MHI component is selected.

Procedure ​

  • Revisit after the USB or PCIe transport and firmware ownership are established.

Development findings ​

  • There is no verified Wi-Fi source or firmware path for elden.

Completion criteria ​

  • Not required for this milestone.

Current limits ​

  • Wi-Fi, Bluetooth and cellular are not implemented or claimed.

Next action ​

  • Open a separate network bring-up task when the base kernel and root volume are stable.

Evidence ​

Collect evidence using the next action.

Audio ​

not-applicable

Hardware and dependencies ​

  • Audio is outside the current bring-up milestone.

Configuration ​

  • No ADSP, GLink, codec or audio component is selected.

Procedure ​

  • Revisit after platform, storage and display are stable.

Development findings ​

  • There is no elden audio log or firmware inventory.

Completion criteria ​

  • Not required for this milestone.

Current limits ​

  • Speakers, microphone and DSP routing are not implemented or claimed.

Next action ​

  • Open a separate audio bring-up task with DSP and codec inputs.

Evidence ​

Collect evidence using the next action.

Power ​

planned

Hardware and dependencies ​

  • PM8550-class PMIC, RPMh resources and device power domains.
  • Volume and power key behavior.

Configuration ​

  • The first DTS selects only CPU and GIC resources.
  • No platform power component is selected.

Procedure ​

  • Keep suspend and CPU power management disabled during first XNU entry.
  • Record regulator and clock ownership.
  • Add platform power only after the boot CPU reaches a stable checkpoint.

Development findings ​

  • UEFI power and key handling are verified only at the firmware layer.
  • The selected OS profile does not supply sleep-disabled, so board.toml now adds it under [adt.defaults.u32].
  • The final Phase 2.1 ADT was decoded with sleep-disabled=1.
  • The XNU power topology is not complete.

Completion criteria ​

  • Declared power controls match readings.
  • Sleep/resume or shutdown transitions restore dependent peripherals.

Current limits ​

  • Battery, charging, thermal and sleep are not implemented.

Next action ​

  • Phase 2.5: use armcpu-diagnostics=1 to observe boot-CPU quiesce/halt behavior. Audit RPMh ownership and keep suspend/secondary CPU power management out of initial qualification.

Evidence ​

Image assembly ​

host-verified

Hardware and dependencies ​

  • iPad7,1 iPadOS 17.7.11 build 21H461 restore inputs.
  • Target kernelcache, XNU 10063.141.1, DriverKit and TrustCache ABI inputs.
  • Android v3 RAM-boot image, a 4 MiB phase 1 embedded FAT payload and a measured 56 MiB phase 2 candidate.

Configuration ​

  • The phase 1 image is produced by the project build script and verified against recorded hashes.
  • Format 2 output is out/elden/ipados-17.7.11-21H461/elden/.
  • The 2.2 prelink output is kernel/kernel.macho and its ADT sidecar; no phase 2 boot image is generated.

Procedure ​

  • Run scripts/build_phase1.py for the accepted firmware path.
  • Fetch the target IPSW components and build the patched 4 KiB XNU.
  • Prelink against the pinned kernelcache and audit Mach-O, ABI, symbols and ADT.
  • Package an isolated near-final-size payload only in Phase 2.3.

Development findings ​

  • The documented Phase 1 build was device-verified and the current procedure rebuilds and passes structural checks.
  • The same current recipe produced 94b6a6315b04fc9d276bc15e9519107be292244380fc3bf139f5af6c96a3bb0a instead of the historical accepted image hash; byte-for-byte rebuild identity is not claimed, but the new image completed two owner RAM cold boots.
  • The verified UniXNU third-party pin is intentionally retained for the accepted build.
  • Phase 2.2 produced a 21,206,040-byte native kernel and a 54,050,816-byte prelinked kernel. The 57-patch sequence selects 30 executable Apple components, 7 kernel interfaces and 30 module entrypoints.
  • A 56 MiB FAT16 host volume held the 54,063,968-byte kernel/config/ADT set with 3,734,016 bytes free and a byte-identical kernel readback.
  • The prelink report remains runtime_qualified=false, abi_qualified=false and loadable=false until device execution evidence exists.

Completion criteria ​

  • All format 2 build steps run from the resolved output directory.
  • The payload contains the kernel, ADT and declared optional inputs.
  • The boot image matches the ABL header and size limits.

Current limits ​

  • The format 2 payload and bootimg pipeline is not yet connected to a phase 2 firmware candidate.
  • The current 4 MiB board payload belongs to phase 1; the phase 2 candidate is 56 MiB and its ABL/initrd/FDT/HOB channel is unverified.
  • The 2.2 host build used Command Line Tools with an iPhone platform shim because full Xcode is absent; release rebuilding still requires the official Xcode/iPhoneOS SDK.

Next action ​

  • Phase 2.3: build a near-final-size FAT16 payload in an isolated output and verify Android v3 ramdisk, FDT/initrd and HOB delivery before executing the kernel. Keep all phase 2 outputs separate from the accepted phase 1 baseline.

Evidence ​

Diagnostics ​

device-verified

Hardware and dependencies ​

  • RAM-only owner-operated boot procedure.
  • Build and artifact SHA-256 values.
  • UEFI screen output and recovery path.

Configuration ​

  • verify_artifact.py checks the FD, Android image and embedded FAT.
  • build.json records artifact sizes and hashes.
  • The phase 1 acceptance requires two consecutive cold boots.

Procedure ​

  • Build and verify the image.
  • Owner runs fastboot boot twice and records the visible result.
  • Power off and confirm stock Android before further work.

Development findings ​

  • The original accepted image is b56ef4b7e5a71382b8c279c4ee1560764fabd126ba37ac0fd6e495c80b9ec6e1.
  • Earlier UFSDxe failure images are identified and must not be reused.
  • Phase 2 requires separate kernel and DarwinBoot evidence.
  • On 2026-10-25 a fresh phase 1 rebuild produced image SHA-256 94b6a6315b04fc9d276bc15e9519107be292244380fc3bf139f5af6c96a3bb0a and FD SHA-256 e5420517d55f4b638c07617a252d3a65c95cfb731584dcb10dd1d98bae412580. The build and prior local candidate were read-only preserved under .cache/phase2.0, and the owner then completed two RAM cold boots of the new image.
  • Phase 2.1 host auditing now checks the ADT independently and records FDT, ADT, UEFI memory and boot argument sources under .cache/phase2.1 without replacing phase 1 artifacts.
  • Phase 2.2 audits passed for 1,010 target objects, 7,730 prelink XML tags, iOS 17.0 deployment, 4 KiB TCR and the expected ArmDTPlatform/ArmCpu symbols. These are host-only checks.

Completion criteria ​

  • Every claimed checkpoint has a reproducible command, image hash and visible result.
  • Failures reach a diagnosable screen or log instead of a silent hang.

Current limits ​

  • There is no phase 2 XNU log or ADT handoff evidence yet.
  • The generated hardware ADT input is a minimal host candidate. The separate firmware memory description contains the source-derived reservation map, but neither is a live device FDT.
  • The historical accepted image bytes are absent from the workspace, so they cannot be booted or byte-compared locally.

Next action ​

  • Proceed with phase 2.3 using isolated outputs. Before any phase 2 device boot, rerun the Phase 2.1 audit against the owner-captured live firmware FDT. Record source, host and device evidence separately for every gate; loader validation, kernel entry, platform expert and boot CPU require distinct checkpoints and two final-image cold boots.

Evidence ​

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

Copyright 2026 UniXNU contributors