UniXNU

English

简体中文

English

简体中文

Appearance

Lenovo Xiaoxin Pad Pro 2021 (j716f) ​

Denis0x00/UniXNU-j716f

Lenovo TB-J716F migration record for the UniXNU iPadOS 17.7.11 bring-up.

Source record: porting.toml, f7f9f4a315e2f467d5a9dfe7fdf70c34c917fc87.

This page is generated from the device record.

AreaStatus
Configurationhost-verified
Firmware and bootdevice-verified
CPU and interruptsplanned
Memory and DMAdevice-verified
Storage and rootplanned
Displaydevice-verified
Inputdevice-verified
GPUplanned
Networkplanned
Audioplanned
Powerplanned
Image assemblyhost-verified
Diagnosticsdevice-verified

Configuration ​

host-verified

Components: XnuPrelink, DarwinBoot.

Hardware and dependencies ​

  • SM8250/Kona identity, iPadOS 17.7.11 profile candidate, source defconfig, and the local SoC evidence snapshot.

Configuration ​

  • board.toml uses schema_version 2, soc_source sm8250, os_profile ipados-17.7.11-21H461, and device:dts/j716f.dts.
  • The source qualification defconfig remains the reproducible kernel configuration; it does not claim a bootable XNU.

Procedure ​

  • Run the latest UniXNU defconfig, status, tree, and porting-record checks from the UniXNU checkout.

Development findings ​

  • No reviewed public UniXNU-sm8250-common repository was available, so the board-local source is explicitly marked as a transition snapshot.
  • The macOS source workflow is pinned to UniXNU 42bffe8 and keeps its J716F compatibility fixes in the device repository.
  • The source qualification defconfig disables the profile's MOCKFS fixture because that fixture requires ArmCpu, while this board intentionally keeps ArmCpu disabled.
  • The source-output sealing step discovers the migration-qualified report and tree instead of assuming the legacy out/j716f root.

Completion criteria ​

  • The format 2 identity, source paths, defconfig, and patch order resolve without ambiguous board fields.

Current limits ​

  • The SoC source is local and not yet a reusable fixed public commit; component ABI inputs remain incomplete.

Next action ​

  • Extract the shared SM8250 resources into a reviewed UniXNU-sm8250-common repository and pin its 40-character commit.

Evidence ​

Firmware and boot ​

device-verified

Hardware and dependencies ​

  • Mu-Silicium J716F platform, inherited GOP, fixed ZUI memory map, and the board UEFI DSC/FDF.

Configuration ​

  • The device board points to the j716f DSC/FD and keeps vendor inputs outside the public repository.

Procedure ​

  • Build the diagnostic FD with the local UEFI checkout, audit its inputs, then boot only through boot_b for hardware checks.

Development findings ​

  • V14 reached the UniXNU menu and exercised the documented button and DarwinBoot protocol paths.
  • V16 on boot_b displayed the green ExitBootServices bar, the blue MMU-off XNU entry probe and the magenta pre-MMU-enable probe; the screen also showed the normal CapsuleRuntimeDxe LockCapsuleInterface callback.
  • V17 on boot_b waited through the post-MMU probe, executed PSCI reset, and returned to the UniXNU menu with the same three entry bars.
  • V18 displayed the same three bars but later reset back to UniXNU despite replacing stage 3 with a WFE loop; the external reset/watchdog source is unresolved.
  • V19/V20 added read-only reset diagnostics. V20 photographs showed the DarwinBoot pre-ExitBootServices message and a later menu, but no readable PMIC value.
  • V21 was built and host-audited, flashed only to boot_b and rebooted. A photograph confirms its large-text V21 menu and PMIC RESET: 0x02000001; the V21 XNU attempt remains unobserved.

Completion criteria ​

  • The FD enters UniXNU, preserves the documented memory reservations, and exposes the framebuffer for the menu.

Current limits ​

  • MMU-on persistence, ArmCpu/ArmDTPlatform initialization, UFS/root, userspace and iPadOS remain unverified; TzDxe is out of scope.

Next action ​

  • Record a V21 XNU attempt, final text/color bars and any Lenovo logo reappearance; use the PMIC sample as historical baseline without assigning a reset cause.

Evidence ​

CPU and interrupts ​

planned

Hardware and dependencies ​

  • CPU0 MPIDR affinity 0, PSCI SMC, and a 19.2 MHz timer from the firmware device-tree evidence.

Configuration ​

  • The DTS describes one enabled CPU and the measured timer frequency; the source qualification defconfig keeps ArmCpu disabled.

Procedure ​

  • Compile the DTS, enable the reviewed ArmCpu implementation, and verify CPU entry, timer and IPI checkpoints.

Development findings ​

  • Only the single boot CPU and shared resource addresses are currently audited; no multi-core XNU entry has been established.
  • The source qualification keeps ArmCpu disabled, so the profile's MOCKFS executable-root fixture is disabled rather than claiming CPU component support.

Completion criteria ​

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

Current limits ​

  • No public SM8250 ArmCpu source or device-side CPU entry evidence is pinned yet.

Next action ​

  • Review the SM8250 CPU topology and ArmCpu ABI before enabling the component.

Evidence ​

Collect evidence using the next action.

Memory and DMA ​

device-verified

Hardware and dependencies ​

  • Two firmware RAM banks, a 5 GiB primary contiguous bank, reserved ranges, and the qualified 256 MiB DarwinBoot window.

Configuration ​

  • The board DTS records the primary 0xc0000000/0x140000000 bank; the diagnostic payload separately requests 0x10000000 owned bytes.

Procedure ​

  • Audit the memory map on the host, then allocate, cache-maintain, read back and release the V14 window on boot_b.

Development findings ​

  • The V14 256 MiB physical window passed seven checks, including two complete write/read rounds with cache maintenance and release; this does not validate full DRAM ownership.
  • V21 host audit confirms the same embedded FAT payload and module GUID set as V20; this does not add a new RAM qualification result.

Completion criteria ​

  • Handoff regions do not overlap and the requested DarwinBoot window is allocated, coherently accessed and released.

Current limits ​

  • The V15 larger FAT payload and runtime initrd allocation still need a device observation.

Next action ​

  • Repeat the memory check with V15 while recording the initrd range and final owned-memory result.

Evidence ​

Storage and root ​

planned

Hardware and dependencies ​

  • UFS controller, PHY, LUN and userdata geometry are not yet represented by a reviewed J716F component source.

Configuration ​

  • No UFS node, root volume UUID, GPT window or Data seed is declared in the public board configuration.

Procedure ​

  • Capture the UFS controller and GPT facts from recovery/TWRP, then select a compatible storage component and root policy.

Development findings ​

  • The current V15 payload is a diagnostic FAT volume and does not prove physical UFS access or root mounting.

Completion criteria ​

  • Controller reads, GPT windows, OS/SystemOS ranges and root persistence pass on the device.

Current limits ​

  • No storage ABI, trust cache or userdata seed is public or verified.

Next action ​

  • Record UFS register, LUN and userdata geometry before adding a storage component.

Evidence ​

Collect evidence using the next action.

Display ​

device-verified

Hardware and dependencies ​

  • Inherited GOP at 2560x1600 with 10240 bytes per row and 32-bit pixels.

Configuration ​

  • The UEFI platform keeps the inherited framebuffer and the board DTS does not invent a panel controller.

Procedure ​

  • Enter the menu through boot_b, observe the framebuffer geometry, and preserve the last screen on a returned diagnostic path.

Development findings ​

  • The menu and diagnostic screens rendered on the device; panel, backlight and native display driver adaptation are not complete.
  • V21 device photography confirms the scale-4 menu with hidden logo and readable PMIC summary. The active framebuffer log font was changed from scale 3 to 5, but its device effect has not yet been observed.

Completion criteria ​

  • A known frame has the measured geometry and format, followed by a native display provider and backlight result.

Current limits ​

  • Only GOP/menu output is verified; native display and backlight remain pending.

Next action ​

  • Capture the V21 DarwinBoot/entry screen and then identify panel/backlight resources from the vendor DT.

Evidence ​

Input ​

device-verified

Hardware and dependencies ​

  • Volume and power key paths provided by the Mu-Silicium platform and J716F key DXE.

Configuration ​

  • The menu remains interactive only where the platform reports an input device; no touch component is selected yet.

Procedure ​

  • Use volume keys to select and the power key to confirm, then record whether the selected entry returns or advances.

Development findings ​

  • Volume and power keys were observed in the diagnostic menu; touch coordinates and HID reports are not yet adapted.

Completion criteria ​

  • Touches map to the display and buttons produce stable reports through the selected input component.

Current limits ​

  • Only the hardware keys are verified; touch controller and HID ABI are pending.

Next action ​

  • Collect touch controller bus, interrupt and coordinate mapping from the vendor DT and recovery logs.

Evidence ​

GPU ​

planned

Hardware and dependencies ​

  • Adreno/GMU registers, firmware, SMMU streams and Metal ABI inputs are not public for this board.

Configuration ​

  • No GPU component is selected; the source defconfig keeps native Adreno disabled.

Procedure ​

  • Audit the SM8250 GPU resources, obtain matching firmware and ABI records, then add a component and package service.

Development findings ​

  • The current screen result comes from inherited GOP and does not establish GPU submission or Metal presentation.

Completion criteria ​

  • GPU submissions, mapping, fences, known rendering and the selected Metal client all pass.

Current limits ​

  • No GPU firmware or device-side submission evidence is available.

Next action ​

  • Inventory Adreno 650/SM8250 resources and firmware ownership before selecting a component.

Evidence ​

Collect evidence using the next action.

Network ​

planned

Hardware and dependencies ​

  • Wireless chipset, bus, firmware and DMA ownership are not identified in the public port.

Configuration ​

  • No Wi-Fi component or network package is selected.

Procedure ​

  • Identify the wireless controller and firmware, then follow the network adaptation guide and record association/traffic tests.

Development findings ​

  • No network path has been exercised by the diagnostic images.

Completion criteria ​

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

Current limits ​

  • Wireless hardware and OS ABI inputs are missing.

Next action ​

  • Extract the wireless controller identity and firmware source from the stock system.

Evidence ​

Collect evidence using the next action.

Audio ​

planned

Hardware and dependencies ​

  • DSP, codec, clocks and firmware service ownership are not yet described.

Configuration ​

  • No audio component or board package service is selected.

Procedure ​

  • Inventory the audio graph and DSP firmware, then validate playback and capture routes.

Development findings ​

  • The current bring-up stops before userspace audio and has no audio evidence.

Completion criteria ​

  • Declared routes carry the selected format through playback and capture with correct start/stop behavior.

Current limits ​

  • Audio inputs and firmware are unavailable.

Next action ​

  • Capture the codec/DSP graph and firmware interfaces from the stock device.

Evidence ​

Collect evidence using the next action.

Power ​

planned

Hardware and dependencies ​

  • Regulators, clocks, battery units and firmware ownership are not yet modeled.

Configuration ​

  • The port keeps vendor power initialization in UEFI and declares no XNU power component.

Procedure ​

  • Document regulators and power domains, then validate battery readings and a controlled sleep/resume cycle.

Development findings ​

  • No sleep/resume or battery result has been obtained from the diagnostic image.
  • The V20/V21 UEFI diagnostic provider reads PMIC history without clearing it. V21 displays 0x02000001; bit semantics and reset cause remain unclassified, and this does not validate an XNU power driver.

Completion criteria ​

  • Power readings and supported sleep/resume transitions restore dependent peripherals.

Current limits ​

  • Power resources and low-power ownership remain unknown.

Next action ​

  • Inventory PMIC and battery resources before adding a power component.

Evidence ​

Image assembly ​

host-verified

Components: XnuPrelink, DarwinBoot.

Hardware and dependencies ​

  • V15 FAT payload layout, Android boot image v2 parameters, UEFI FD and the real kernel/ADT private inputs.

Configuration ​

  • The board declares a 64 MiB diagnostic volume, firmware DarwinBoot loader, measured DRAM and boot image v2 offsets.
  • The UEFI repository now declares the shared RAM-disk DXE alongside DiskIoDxe and FAT while retaining the existing V15 embedded-FAT diagnostic path.

Procedure ​

  • Run host image audits, verify kernel/ADT hashes and inspect the boot image before any boot_b test.

Development findings ​

  • V15 host packaging and static audits passed.
  • V16 host packaging produced the source-prelinked kernel, J716F ADT and boot image used for the boot_b test.
  • The source build applies a device-local patch-series compatibility fix before the pinned UniXNU resolver, so optional Sheng PMGR context is not required for J716F.
  • V21 host checks passed FD/FV/FFS checksums, AARCH64 PE and linked-module identity, V21 markers, unchanged V20 embedded FAT, BootShim/gzip, both DTB copies and Android v2 header/SHA1/padding.
  • The byte-identical local V21 DSC is preserved in the firmware repository; it retains the V15 FDF/output path and omits the public V15 DSC additional standard-initrd declarations. Device board.toml retains historical V17 payload settings and is not the complete V21 artifact recipe.

Completion criteria ​

  • Kernel and ADT inputs are reproducible, the payload contains declared files, and the boot image matches the platform header and size constraints.

Current limits ​

  • Private payload binaries and vendor inputs are intentionally excluded; MMU-on continuation and later platform stages remain unverified.

Next action ​

  • Keep the recorded V21 image/profile identity while collecting the pending XNU attempt and reset evidence.

Evidence ​

Diagnostics ​

device-verified

Hardware and dependencies ​

  • Host audit scripts, V14 memory evidence, V15 entry preparation, V16 boot_b observation, and source-build reports.

Configuration ​

  • Diagnostic outputs are separated from private binaries and the record distinguishes host, device and planned evidence.

Procedure ​

  • Run the preflight and record checks, preserve only text metadata in CI, and use the boot_b-only recovery procedure on hardware.

Development findings ​

  • V16 device evidence confirms ExitBootServices and XNU early-entry probes on boot_b; the result is preserved in docs/V16_SOURCE_ENTRY_RESULT.md.
  • Source-build diagnostics record both device-local compatibility patches and keep patch preparation idempotent across repeated macOS runner attempts.
  • V21 was built, audited and flashed to boot_b; the observed menu has V21 labels, enlarged text and PMIC RESET: 0x02000001.
  • The current PMIC value is a boot-history baseline. Neither this sample nor the earlier exiting boot services message identifies the cause of a reset; no V21 XNU attempt has yet been observed.

Completion criteria ​

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

Current limits ​

  • No UART capture is available; MMU-on persistence, platform drivers, UFS/root and userspace remain unverified.

Next action ​

  • Record the selected XNU diagnostic attempt, final text/color bars, possible Lenovo logo and final held screen or menu before changing the next checkpoint.

Evidence ​

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

Copyright 2026 UniXNU contributors