UniXNU

English

简体中文

English

简体中文

Appearance

Lenovo Xiaoxin Pad 12.1 (2025), Lenovo TB365FC (board cava_prc_consumer_wifi) ​

LittleStar-OuO/UniXNU-tb365fc

Lenovo Xiaoxin Pad 12.1 (2025), Lenovo TB365FC, board cava_prc_consumer_wifi. The stock ZUXOS 1.1.10.122 package is unpacked and the unit itself has been inventoried over rooted adb (8 GB DRAM, 128 GB UFS, BOE HX83122B 1600x2560 @90 Hz, MT6631 combo). The UEFI firmware from uefi-tb365fc boots on the unit and shows the UniXNU menu with the Advanced Logger viewer; no XNU image has been built or booted yet.

Source record: porting.toml, b13016b5088c91819dd4350f733a938e109723ad.

This page is generated from the device record.

AreaStatus
Configurationimplemented
Firmware and bootimplemented
CPU and interruptsplanned
Memory and DMAplanned
Storage and rootplanned
Displayimplemented
Inputimplemented
GPUplanned
Networkplanned
Audioplanned
Powerplanned
Image assemblyimplemented
Diagnosticsimplemented

Configuration ​

implemented

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

Hardware and dependencies ​

  • MT6835 platform identity, Lenovo TB365FC (cava_prc_consumer_wifi) board identity, iPad7,1 / iPadOS 17.7.11 build 21H461 target identity and the TB365FC bootstrap defconfig.
  • Stock package ZUXOS 1.1.10.122 (Android 15, build TB365FC_CN_OPEN_USER_M1317.3_V_ZUXOS_1.1.10.122_ST_250828), hashed in proprietary-files.txt.

Configuration ​

  • board.soc = MT6835; board.soc_source = mt6835; board.os_profile = ipados-17.7.11-21H461; schema_version = 2.
  • tb365fc_defconfig enables the shared ARM DT platform, ARMCPU, architected timer, panic and prelinked crypto paths.
  • feeds.toml pins the published UniXNU-mt6835-common commit; the workstation override lives in the git-ignored local.toml.

Procedure ​

  • Run ./unixnu defconfig tb365fc_defconfig -D ../UniXNU-tb365fc from a UniXNU checkout.
  • Run ./unixnu status --json -D ../UniXNU-tb365fc and inspect the effective SoC layer and source pins.

Development findings ​

  • The device identifies as MT6835 with stock board name cava_prc_consumer_wifi, Android 15, build TB365FC_CN_OPEN_USER_M1317.3_V_ZUXOS_1.1.10.122_ST_250828.
  • The stock SP Flash Tool package provides boot, init_boot, vendor_boot, dtbo, lk and preloader images; their hashes and the values derived from them are recorded across the firmware, cpu, memory, storage, display, input, gpu, network, audio, power and packaging areas.
  • No public Lenovo kernel source or DTS for this board was found; every hardware value so far comes from the stock firmware and the live device inventory.
  • The unit reports ro.product.device TB365FC, ro.product.name TB365FC_PRC, ro.board.platform mt6835 and ro.boot.hardware mt8755 on Android 15 build AP3A.240905.015.A2/250828_122 (kernel 5.15.170), with ro.boot.verifiedbootstate orange and ro.boot.flash.locked 0.

Completion criteria ​

  • Source pins resolve, the effective configuration contains the intended TB365FC overrides and every selected component has an owning area.

Current limits ​

  • The APFS Data volume UUID and the unique chip ID are payload inputs and still unmeasured; the panel variant, the self-built boot image and the FD base are settled on hardware (see firmware and display). example stays true until the payload inputs are measured.

Next action ​

  • Measure the APFS Data volume UUID and the unique chip ID once XNU is installed, then clear example = true.

Evidence ​

Firmware and boot ​

implemented

Hardware and dependencies ​

  • Stock TB365FC firmware package (Android 15, build TB365FC_CN_OPEN_USER_M1317.3_V_ZUXOS_1.1.10.122_ST_250828), unlocked bootloader state, fastboot mode, the stock boot/vendor_boot/dtbo partitions and the UEFI firmware from uefi-tb365fc.
  • Measured boot geometry: boot.img header v4 (4096-byte pages); vendor_boot header v4 with kernel_addr 0x40000000, ramdisk_addr 0x66F00000, tags_addr/dtb_addr 0x47C80000 and cmdline "bootopt=64S3,32N2,64N2".

Configuration ​

  • Plan A implemented: the FD is packed as the gzip kernel of an Android boot v4 image, LK decompresses it to kernel_addr 0x40000000 and jumps into the SEC entry; no shim is needed.
  • Resources/Configs/tb365fc.toml keeps header_version = 4, the FD window 0x40000000/0x400000 and the 1 MiB FAT12 UNIXNU ramdisk; the stock init_boot and vendor_boot ramdisks and DTB stay in place.
  • Firmware paths in board.toml [firmware] point at Platforms/Lenovo/tb365fcPkg; the five Mu base-core fixes are applied from uefi-tb365fc Resources/MuPatches at build time over the upstream Mu_Basecore pin.

Procedure ​

  • Extract the stock boot, vendor_boot and dtbo partitions and read them with tools/unpack_boot_image.py and tools/extract_fdt.py.
  • Build the UEFI FD, flash the boot image, and record the first screen, last confirmed stage and log source.

Development findings ​

  • init_boot.img is header v4 with a 2,066,170-byte ramdisk; vendor_boot.img is header v4 with vendor_ramdisk_size 27,731,435 and dtb_size 190,500.
  • dtbo.img holds one 240,233-byte DTBO with 208 fragments; the vendor_boot DTB is the MT6835 base tree (model "MT6835") and the overlay targets use unresolved 0xffffffff phandles until LK merges them.
  • lk.img (2,897,568 bytes) carries kernel_load_addr and dtb_addr as runtime variables rather than text-form constants; the few 32-bit words equal to 0x40080000 have no established role, so the FD base stays the Plan A convention proven on merlinx and camellia until a hardware log confirms it.
  • The stock boot images are padded to their partition sizes (boot and vendor_boot 64 MiB, init_boot and dtbo 8 MiB); the hashes in proprietary-files.txt cover the padded files.
  • On the tablet the boot, vendor_boot and dtbo images match the pinned stock hashes, and /proc/iomem reserves the header addresses: dtb at 0x47c80000 and the ramdisk at 0x66f00000-0x68be2fff.
  • init_boot_a does not match the pinned stock hash: the unit runs SukiSU Ultra in LKM mode (a kernelsu module is loaded and the stock kernel carries no KernelSU strings), so the pin still describes the package, not this unit's rooted boot partition.
  • The stock cmdline carries fastboot_enable=1 and bootopt=64S3,32N2,64N2; neither demonstrates fastboot boot support.
  • The first bring-up image booted on the unit: LK accepted the self-built v4 image, SEC cleared the LK scanout, the Project Silicium logo appeared and the UniXNU menu followed at 1600x2560; the 1.7 MiB image is far below the 64 MiB boot_a limit.
  • The FD base is 0x40000000 (the stock vendor_boot kernel_addr), not the earlier 0x40080000 plan; the primary stack sits at 0x40400000 and the LK reservations (DTB 0x47C80000, ramdisk 0x66F00000) survive the handoff.
  • In the booted firmware Volume Up/Down move the menu selection, Power and Enter activate entries, and Tools opens the Advanced Logger viewer with QR pages, five speed gears and Power/Enter to exit.

Completion criteria ​

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

Current limits ​

  • The XNU/DarwinBoot handoff and the ADT payload are not implemented; the image was flashed to this unit's boot_a only, boot_b stays stock as the recovery path.

Next action ​

  • Build the XNU payload and boot image, then record the DarwinBoot handoff and the first XNU checkpoint.

Evidence ​

CPU and interrupts ​

planned

Hardware and dependencies ​

  • Measured from the stock vendor_boot DTB: 6x Cortex-A55 at MPIDR affinities 0x0-0x500, 2x Cortex-A76 at 0x600-0x700, GIC distributor 0x0C000000 (256 KiB), redistributors 0x0C040000 (2 MiB) and a 13 MHz architected timer.

Configuration ​

  • CONFIG_XNU_ARMCPU=y and CONFIG_XNU_ARM_DT_PLATFORM=y.
  • dts/mt6835.dtsi carries the measured cluster layout, the PSCI conduit and the GIC ranges; tb365fc.dts enables the CPUs.

Procedure ​

  • Compare dts/mt6835.dtsi with the stock FDT /cpus, interrupt-controller and timer nodes.
  • After the first boot, check the PSCI conduit and per-CPU bring-up against /proc/cpuinfo and the stock dmesg.

Development findings ​

  • The stock topology is one GICv3 domain: A55 at affinity 0x0 and 0x100-0x500 (cluster type E), A76 at 0x600/0x700 (cluster type P). The earlier MT6833-style 0x0-0x1 / 0x100-0x105 guess was wrong.
  • The architected timer runs at 13 MHz (clock-frequency 0xc65d40), and GICD spans 0x40000 bytes rather than 64 KiB.
  • The stock tree has a /psci node (compatible arm,psci-1.0, method smc) and every CPU uses enable-method = "psci"; the dtsi conduit matches it.
  • The stock tree uses four-cell interrupt specifiers whose trailing cell is a MediaTek wakeup flag; the ADT keeps the standard three-cell GIC form.
  • The on-device /proc/cpuinfo lists 8 CPUs: six 0xd05 (Cortex-A55) and two 0xd0b (Cortex-A76), matching the DTB affinities.

Completion criteria ​

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

Current limits ​

  • SMP is not enabled in UniXNU; the PSCI conduit and cluster types are untested there, although Android already runs all eight cores.

Next action ​

  • Boot the first CPU on hardware, confirm the PSCI conduit, then enable the remaining cores one cluster at a time.

Evidence ​

Memory and DMA ​

planned

Hardware and dependencies ​

  • DRAM base and size, reserved-memory carveouts and the IOMMU/SMMU stream inventory.
  • The stock tree declares CMA pools (ssmr and ssheap, 256 MiB each, 16 MiB/2 MiB alignment) and dynamic carveouts whose final addresses are assigned by LK.

Configuration ​

  • tb365fc.dts must expose exactly one enabled memory node with one contiguous range; the shared ADT generator rejects anything else.
  • Reserved regions stay outside the contiguous DRAM range reported to XNU.

Procedure ​

  • Read the stock DTB memory and reserved-memory nodes and reconcile them with /proc/iomem and /proc/meminfo on the rooted device.
  • Regenerate the ADT and confirm chosen/dram-base and dram-size match the extracted values.

Development findings ​

  • The stock DTB memory node is a 1 GiB stub at 0x40000000 (0x0 0x40000000 0x0 0x40000000) that LK replaces at boot, so the DRAM size cannot be read from the DTB.
  • Measured on the tablet: MemTotal is 7,991,068 kB, CmaTotal 737,280 kB, and /proc/iomem maps DRAM from 0x40000000 to 0x23fffffff, confirming the 8 GiB range in tb365fc.dts.
  • The live map reserves 0x47c80000-0x47ce6fff (DTB), 0x66f00000-0x68be2fff (vendor ramdisk) and a large block from 0x20888f000 to 0x23e5fffff; the ADT must keep such ranges out of the region handed to XNU.

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 reserved ranges are LK-assigned and this is Android's post-LK view, not a UniXNU handoff contract; the final carveouts remain unknown.

Next action ​

  • Regenerate the ADT once the UEFI FD runs and diff its memory map against this inventory.

Evidence ​

Storage and root ​

planned

Hardware and dependencies ​

  • Storage host candidates in the stock DTB: ufshci@112b0000 ("mediatek,mt8183-ufshci", reg 0x112b0000/0x2300, IRQ 0x189) is enabled, while mmc@11230000 ("mediatek,mt6835-mmc", reg 0x11230000/0x10000 + 0x11e70000/0x1000, IRQ 0x183) and mmc@11240000 are explicitly disabled.
  • Stock scatter: boot_a 0x28F00000, vendor_boot_a 0x2CF00000, init_boot_a 0x30F00000, dtbo_a 0x31700000, super 0x4B000000 (0x2C0000000 bytes), userdata at byte 0x34C800000 in both the EMMC and UFS layout.
  • The userdata partition geometry and the Data volume UUID.

Configuration ​

  • [userdata] first_lba = 0x34C800, last_lba = 0x1DC8FF7 and lba_bytes = 4096 come from the on-device GPT; the APFS Data volume UUID is still REQUIRED.
  • A storage component is selected only after the host-controller inventory; no storage gate is enabled in tb365fc_defconfig yet.

Procedure ​

  • Read /proc/partitions, the GPT (sgdisk -p on the boot LUN: /dev/block/sda* for UFS or /dev/block/mmcblk0* for eMMC) and the queue/logical_block_size on the rooted device.
  • Record the userdata entry LBA range and the APFS volume UUID used for root matching.

Development findings ​

  • The stock DTB enables a UFS host (ufshci@112b0000) and disables both MSDC hosts; the dtbo also carries the mt6377_vufs rail. The earlier "eMMC on MSDC_0" reading came from the scatter's first layout section and is not established.
  • The scatter is a download map, not the GPT: its pgpt entry is NONE and the userdata size 0xC0000000 is the factory image, so the real partition may extend further.
  • Measured on the tablet: the UFS host 112b0000.ufshci drives a Samsung KLUDG2R1JF-B0F1 LUN with 4096-byte logical sectors; /dev/block/sdc reports 249,921,536 512-byte sectors (127.96 GB) and a 71-entry GPT.
  • GPT entries: userdata 0x34C800-0x1DC8FF7 (111,091,680 KiB), boot_a 0x28F00 and vendor_boot_a 0x2CF00 (64 MiB each), init_boot_a 0x30F00 and dtbo_a 0x31700 (8 MiB each), super 0x4B000 (11 GiB); the init_boot_b entry is 11,776 KiB, an asymmetry in the factory table.
  • The LK log reports the UFS link as "HS-G3-2, 1 lane".

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 ​

  • UniXNU's firmware has no UFS driver (MsdcDxe is the only storage path) and the SMMU stream wiring is unknown; the Data volume UUID cannot be set until APFS is installed.

Next action ​

  • Port a UFS host path into the firmware, then record the GPT and the Data volume UUID once APFS is installed.

Evidence ​

Display ​

implemented

Hardware and dependencies ​

  • DSI panel variant from the stock overlay: panel1@0 "boe,hx83122b,vdo" or panel2@1 "tm,nt36532,vdo", both video-mode with TE.
  • Panel rails and GPIOs: power enable GPIO 0x22, backlight enables 0x15/0x19, reset GPIO 0x56 (86), bias GPIOs 0x7c (124) and 0x97 (151).
  • Backlight controllers ST7758 and AW99706 at I2C addresses 0x2e and 0x76 on two panel channels.
  • Panel resolution, refresh rate and init sequence from the vendor LCM driver; the device tree carries no timings.

Configuration ​

  • Bootstrap relies on the firmware GOP framebuffer only; no XNU display provider is selected yet.

Procedure ​

  • Record the active panel compatible, wm size and wm density on the tablet and match them with the stock LCM driver name from the LK/kernel log.
  • Record the GOP mode from the UEFI boot log when the first firmware image runs.

Development findings ​

  • The board ships with either a BOE HX83122B or a Tianma NT36532 video-mode panel using the same rails, reset and TE wiring.
  • Measured on the tablet: 1600x2560 at 90.00 Hz with a physical density of 249.46 dpi (ro.sf.lcd_density 320), so the panel is portrait 1600x2560.
  • Both panel1@0 and panel2@1 stay enabled in the live merged FDT; LK picks the variant at runtime from the panel ID.
  • The LK log (/proc/pl_lk) names the active driver: lcm_compare_id matches "hx83122b_boe AF" and LK uses "cava_hx83122b_boe_vdo_cphy_dsc_90hz_lcm_drv" (BOE HX83122B, video mode, CPHY, DSC, 90 Hz) with fps=9009.
  • The same log reads the backlight ids: AW99706 answers on I2C 0x76 with id 0x7 while ST7758 returns 0, so this unit uses the AW99706 controller on both channels.
  • The UEFI firmware reuses the stock LK scanout 1600x2560x32 at 0xFCF2B000 (0xFA0000 bytes) through SimpleFbDxe; the boot logo and the UniXNU menu render with correct geometry and colors on the unit, so the GOP mode is 1600x2560x32.

Completion criteria ​

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

Current limits ​

  • XNU has no display provider yet; the DSI timings and init sequence still live inside the vendor LCM driver and UniXNU does not drive the backlight.

Next action ​

  • Extract the DSI timings and init sequence for cava_hx83122b_boe_vdo_cphy_dsc_90hz_lcm_drv and write the XNU display provider; the firmware GOP path is already verified.

Evidence ​

Input ​

implemented

Hardware and dependencies ​

  • Touch over SPI at 10 MHz (0x989680) with spi-cpha: IRQ GPIO 4 (active low), reset GPIO 43 (0x2b), dual driver set himax,hxcommon and novatek,NVT-ts-spi, Novatek 40x64 node grid (mp-criteria-6096).
  • Pogo keyboard node "lenovo,lenovo_keyboard" and MT6377 PMIC keys.

Configuration ​

  • Input components are selected only after the SPI bus and GPIO inventory; no input gate is enabled yet.

Procedure ​

  • Read the stock overlay touch/keys nodes and /sys/class/input on the rooted device.
  • Record which touch firmware variant the unit actually runs and the pogo keyboard protocol.

Development findings ​

  • Touch is a Himax/Novatek SPI part on IRQ GPIO 4 with reset on GPIO 43.
  • A Lenovo pogo keyboard and MT6377 PMIC keys (power, volume) are present.
  • Measured on the tablet: /dev/input exposes himax-touchscreen (event2), lenovo-stylus (event3), mtk-kpd (event1), mtk-pmic-keys (event0), hall_irq (event5) and the MT6377 headset jack (event4); the Himax driver is the one bound on this unit.
  • In the UEFI menu Volume Up/Down move the selection and Power or Enter activate the highlighted entry, including the Tools viewer (Up/Down change the QR speed, Power/Enter exit); the KPD matrix bit 0 carries Volume Up and the MT6377 PMIC keys carry Volume Down and Power.

Completion criteria ​

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

Current limits ​

  • Touch, stylus and the pogo keyboard have no XNU driver yet; the pogo keyboard protocol and the stylus HID descriptor are not recorded.

Next action ​

  • Port the Himax touch SPI path for XNU and map the 16000x25600 range onto the panel.

Evidence ​

GPU ​

planned

Hardware and dependencies ​

  • Valhall GPU at 0x13000000 ("mediatek,mali", "arm,mali-valhall"), five interrupts 0x10D-0x111 (GPU/MMU/JOB/EVENT/PWR), OPP table and GED supply from the stock base DTB.

Configuration ​

  • No GPU component is selected; the bootstrap image does not initialize the GPU.

Procedure ​

  • Record GPU registers, power and clock inputs from the stock DTB before selecting an accelerated frontend.

Development findings ​

  • The stock tree places the GPU at 0x13000000 with GPU/MMU/JOB/EVENT/PWR interrupts and an operating-points table.
  • GPU bring-up is deferred until XNU reaches IOKit initialization.

Completion criteria ​

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

Current limits ​

  • The GPU model, firmware and IOMMU wiring are only identified by compatible string.

Next action ​

  • Inventory the GPU, IOMMU and power domain inputs after the first successful XNU boot.

Evidence ​

Collect evidence using the next action.

Network ​

planned

Hardware and dependencies ​

  • MediaTek connsys block: wifi@18000000 ("mediatek,wifi", 1 MiB register window, IRQ 0x83, 6 MiB EMI window) and consys@18002000 ("mediatek,mt6835-consys") behind the MT6377 connsys power gate.
  • Bluetooth firmware connsys_bt.img from the stock package.

Configuration ​

  • No network component is selected; the bootstrap image has no network stack input.

Procedure ​

  • Identify the combo chip and firmware variant from the vendor kernel log and /sys/kernel/debug on the tablet, then record hashes in proprietary-files.txt.

Development findings ​

  • Wi-Fi is a MediaTek connsys block at 0x18000000, not an SDIO/PCIe part.
  • connsys_bt.img (4,287,968 bytes) embeds the Wi-Fi PHY path phy/6631 and the "MTK SOC2_2" connectivity revision.
  • Measured on the tablet: persist.vendor.connsys.chipid is 0x6835 (the SoC) while vendor.connsys.adie.chipid is 0x6631 for Wi-Fi, BT, GPS and FM; the BT firmware names MT6631 ASIC MINIROM with patch 20250110150354, so the combo die is MT6631.
  • Android's wlan_drv_gen4m_6835 is running and carrying traffic, so the stock hardware path works.

Completion criteria ​

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

Current limits ​

  • The UniXNU side has no firmware ABI or MAC provisioning; the firmware files live on the vendor partition and are not in this repository.

Next action ​

  • When network work starts, inventory the vendor firmware names and hashes and the connsys power/EMI windows.

Evidence ​

Audio ​

planned

Hardware and dependencies ​

  • MT6377 PMIC codec ("mediatek,mt6377-sound") with accessory detection ("mediatek,mt6377-accdet").
  • Four AW883XX smart amplifiers ("awinic,aw883xx_smartpa", I2C 0x34, reset GPIOs 0x20/0x21/0x5c/0x23, sound channels 0-3) on I2S3, plus an alternative Richtek RT5512 speaker amp at I2C 0x5c.
  • The DMIC set from the stock overlay.

Configuration ​

  • No audio component is selected.

Procedure ​

  • Record the codec/amp wiring and firmware from the stock DTB and vendor files.

Development findings ​

  • The audio path is built around the MT6377 codec with four AW883XX smart amplifiers configured per speaker channel; the skeleton's MT6359 assumption was wrong.
  • The stock overlay also declares a Richtek RT5512 speaker amp at 0x5c, so two amplifier variants may exist across board revisions.
  • The stock overlay also carries the MT6377 auxadc, gauge and regulator children that feed the audio rails.

Completion criteria ​

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

Current limits ​

  • The speaker topology and firmware are not fully inventoried.

Next action ​

  • Inventory the codec, amplifiers and DMIC wiring.

Evidence ​

Power ​

planned

Hardware and dependencies ​

  • MT6377 PMIC (bucks, LDOs, charger, gauge, RTC, keys, accdet), MT6685 RTC/clock buffer, the MT6319 external buck (mt6315_3 regulator) and the RT5133 GPIO expander.
  • MM8013 fuel gauge, a PPS charger path built on the Southchip SC89890H plus an SGM charger, and the AW35615 USB-PD controller.

Configuration ​

  • The bootstrap image runs without a battery/charger driver; sleep-disabled defaults stay in place.

Procedure ​

  • Record PMIC registers, regulator rails and battery thresholds from the stock DTB before writing a power driver.

Development findings ​

  • The PMIC is MT6377, not MT6359; it also provides the MT6377-keys used for the power and volume buttons.
  • The stock overlay lists the full regulator set (vbuck1-6, vs1/vs2, vsram, va12/vaud18/vaud28, vaux18, vbif28, vcn33/vcn18, vxo22, vm18, vemc, vio18, vrf rails, vmc, vusb, vmch) and the gauge/RTC/charger children.
  • Charging is a PPS path ("mediatek,charger,pps") with a two-charger configuration: Southchip SC89890H at I2C 0x6a and an SGM charger at 0x6c, with the AW35615 PD controller at 0x22.
  • Measured on the tablet: the MM8013 gauge driver fg_mm801310c reports VBAT/VBUS, and the charger stack runs sc8989x on I2C 7-006a plus sc8541 on 5-006a under the PPS policy; MT6377 supplies the PMIC keys and the headset-jack codec path.

Completion criteria ​

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

Current limits ​

  • No power driver is written; charger, gauge and RTC register maps are unverified for UniXNU.

Next action ​

  • Record the PMIC I2C addresses and the rails the panel, touch and storage depend on.

Evidence ​

Image assembly ​

implemented

Hardware and dependencies ​

  • The payload image, the boot/vendor_boot layout accepted by the TB365FC LK, the flash method (fastboot flash boot_a) and the partition size limits.
  • Stock boot image v4 (no load addresses); stock vendor_boot addresses tags/dtb 0x47C80000 and ramdisk 0x66F00000; partition sizes boot/vendor_boot 64 MiB, dtbo/init_boot 8 MiB.

Configuration ​

  • The bring-up boot image is Android header v4 (4096-byte pages) with the gzip FD as kernel and the 1 MiB FAT12 UNIXNU ramdisk; v4 carries no load addresses, so LK places the kernel at the stock vendor_boot kernel_addr 0x40000000.
  • The future payload volume is FAT, labelled TB365FC, 192 MiB, and will ride in the same v4 image once the XNU build exists.

Procedure ​

  • Build the payload and boot image, then verify the header fields and offsets against the stock boot image before flashing.
  • Record every flash command and the exact image revision.

Development findings ​

  • The stock header is v4 while UniXNU builds v2 so that LK honours kernel_addr = 0x40080000; v2 is proven on merlinx and camellia (same MTK family) but not on this LK yet.
  • The stock images are padded to the partition sizes, so image hashes cover the padding as well.
  • The on-device GPT confirms boot_a and vendor_boot_a are 64 MiB and init_boot_a and dtbo_a 8 MiB, so a self-built boot image must stay below 64 MiB; the init_boot_b entry is 11,776 KiB.
  • The self-built v4 image (1.7 MiB) was flashed to boot_a with fastboot and accepted by the TB365FC LK; it boots to the UniXNU menu, so the v4 flash path is proven and boot_b stays stock as the recovery path.

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 payload volume has not been built; the flashed image carries only the empty UNIXNU ramdisk and the UEFI FD.

Next action ​

  • Once the XNU payload exists, extend the ramdisk or payload volume and verify the menu reads it.

Evidence ​

Diagnostics ​

implemented

Hardware and dependencies ​

  • adb/fastboot access on the rooted tablet, the stock boot/vendor_boot/dtbo images, serial or pstore log capture, and the UEFI boot log from uefi-tb365fc.

Configuration ​

  • The UEFI Advanced Logger ring mirrors to UART0 (115200 8N1) and the Tools menu exports it as 752-byte QR frames at five speed gears; Power or Enter exits the viewer.
  • tools/collect-device-info.sh writes a local, privacy-filtered inventory; tools/unpack_boot_image.py and tools/extract_fdt.py read Android boot images and extract their DTBs.
  • The scripts export MSYS_NO_PATHCONV on Git Bash so /dev/block paths reach adb unmangled, and the property filter drops psn and bootloader serial keys.

Procedure ​

  • Run the collection script over adb and archive the output outside the repository.
  • Record the last confirmed boot stage and the matching image revision for every hardware checkpoint.

Development findings ​

  • The stock package was unpacked on the host with the tools in this repository; the UEFI checkpoints (logo, fingerprint-matched menu, Advanced Logger pages) are confirmed on the unit by screen photos kept outside the repository, and no XNU checkpoint exists yet.
  • The script ran on the unit after two fixes: MSYS path conversion was rewriting /dev paths (173564d) and the property filter missed psn/bootload_sn (5ba47e6); the clean inventory stays outside the repository because the FDT embeds device-unique data.
  • Root came from SukiSU Ultra in LKM mode: adb su works only with SU compat enabled and yields u:r:ksu:s0; the stock kernel has no KernelSU strings.
  • fastboot getvar all ran in bootloader mode and reported an unlocked bootloader; the dump stays local because it carries the bootloader serial.
  • The pstore partition (sdc19) is zero-filled, but after a reboot /sys/fs/pstore exposes the previous kernel console tail (console-ramoops-0) and /proc/pl_lk exposes the preloader/LK ring; the LK ring is the reliable source for boot-stage facts because wlan traffic overruns the kernel console in about a second.

Completion criteria ​

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

Current limits ​

  • The inventory is a local snapshot; reproducing it needs the scripts at 5ba47e6 or later. Boot photos and serial captures stay local because they can carry device-identifying data, so the record has no published log yet. The kernel ring buffer keeps only about a second of logs at wlan rates, so kernel-stage evidence needs an immediate post-boot capture; pl_lk and console-ramoops are the retained sources.

Next action ​

  • Capture /proc/pl_lk and console-ramoops after every boot change and archive them locally.

Evidence ​

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

Copyright 2026 UniXNU contributors