Samsung Galaxy Tab S7 FE Wi-Fi (SM-T733)

RigoLigoRLC/unixnu-sm-t733

Samsung SM-T733 format 2 baseline48f records eight CPUs, UFS, CPU display and touch. A642L driver and Turnip tooling compiled and deployed as49h with verbose diagnostics; GPU hardware execution remains pending. The49g IODT interrupt-parent panic is addressed by emitting AAPL,phandle in the shared converter.

Source record: porting.toml, 7ec704db1f60d99ea8606aabada919ed2dcbae1b.

This page is generated from the device record.

Area	Status
Configuration	implemented
Firmware and boot	implemented
CPU and interrupts	implemented
Memory and DMA	implemented
Storage and root	implemented
Display	implemented
Input	implemented
GPU	implemented
Network	implemented
Audio	planned
Power	implemented
Image assembly	implemented
Diagnostics	implemented

Configuration

implemented

Components: ArmDTPlatform, device.

Hardware and dependencies

• SM-T733 uses the SM7325 profile and the iPad7,1 21H461 restore inputs.
• The device's 14 driver and kit submodules retain their community repositories and adaptation revisions.

Configuration

• Both boards select schema_version 2, sm7325 and ipados-17.7.11-21H461.
• The component list and archive list are complete arrays; device components.toml supplies community identities and board-specific recipes.
• Public payload.adt.chip_id is hexadecimal 733; private local.toml hardware.unique_chip_id enters the official UNIXNU_UNIQUE_CHIP_ID environment variable.

Procedure

• Run bash scripts/build.sh TAG for the system configuration or add --platform for the platform configuration.
• The official driver resolves output paths from the selected OS profile and defconfig.

Development findings

• Format 2 arrays replace inherited arrays, so every selected component, configuration fragment, patch series and archive remains explicit.
• The SM7325 profile owns common CPU, interrupt, timer, PSCI and UFS facts; the device owns memory span, identity and board policies.
• system-format2-48f completed configure, resolve, kernel, menu, wallpaper, debug-tools and payload with exit code 0.

Completion criteria

• The selected components and source revisions resolve and the unified build produces the requested payload.

Current limits

• The format 2 observations cover the recorded eight-core, UFS, display and touch boot activity; other hardware observations retain their earlier build TAGs.

Next action

• Record subsequent system operations under the current build TAG.

Evidence

• source: The system board selects all four configuration layers and the complete component and archive lists.
• source: The delivery record names the seven successful stages, FAT deployment and specific USB boot observations for 48f.

Firmware and boot

implemented

Components: DarwinBoot, EarlyEntry.

Hardware and dependencies

• Samsung bootloader is unlocked; BOOT/recovery use memory-input-display-46.
• DarwinBoot receives the actual UEFI memory map, framebuffer and loaded sidecar addresses.

Configuration

• gts7fewifi.dsc supplies the Samsung firmware package and userdata payload driver.
• The normal system menu entry is Boot UniXNU.

Procedure

• Use the device build entry with --firmware when firmware source changes require a matching image.
• Ordinary system updates write only the userdata FAT and restart the firmware.

Development findings

• The 47a runtime reaches the Apple logo, lock screen and USB with the existing 46 firmware.
• 48f also booted with the existing 46 firmware and produced its own USB record.
• The firmware's actual conventional-memory allocations define BootArgs memory ownership.

Completion criteria

• Firmware enters the menu, loads the payload and publishes the inherited framebuffer and UEFI reservations.

Current limits

• Samsung recovery and PARAM handling remain device-specific.

Next action

• Retain the existing firmware and record any new firmware-dependent behavior with its build TAG.

Evidence

• source: DarwinBoot implements the UEFI allocation and XNU handoff used by the current device build.

CPU and interrupts

implemented

Components: ArmCpu, NativeQcomTsens.

Hardware and dependencies

• CPU affinities are 0 through 0x700 in 0x100 steps.
• GIC distributor is 0x17a00000; redistributors begin at 0x17a60000 with 0x20000 stride; the architectural counter is 19.2 MHz.

Configuration

• The SM7325 DTSI records four efficiency cores, three performance cores and one highest-performance core across three scheduler clusters.
• The current CPU power code reads the three hardware EPSS LUTs and the 27 TSENS channels.

Procedure

• The kernel build applies the SM7325 startup and scheduler patches before generating compiler records.
• build-cpu-power.py compiles the scheduler adapter, EPSS policy and TSENS reader from those records.

Development findings

• The 45f runtime started all eight CPUs, used three Edge scheduler clusters and registered perfcontrol.
• The 48f USB record confirms all eight CPUs online=1 with fail=0.
• Thermal policy uses the actual stock sensor groups and EPSS rows.

Completion criteria

• All enabled CPUs start, timer/IPI delivery works and policy chooses hardware LUT rows for each frequency domain.

Current limits

• Format 2 must preserve the cluster-type, die-cluster-id and cluster-core-id properties consumed by XNU.

Next action

• Record further scheduler and thermal observations under the current build TAG.

Evidence

• source: The board implementation reads EPSS frequency domains and applies scheduler demand to hardware rows.

Memory and DMA

implemented

Hardware and dependencies

• The device DRAM address span is 0x80000000 through 0x200000000 and contains reserved holes.
• UEFI conventional-memory ranges exclude firmware, TZ, framebuffer and DMA reservations.

Configuration

• payload.adt.owned_memory_size remains auto.
• The shared converter emits darwinboot-memory-range with a 1 GiB minimum and the existing 2 MiB-aligned maximum.

Procedure

• DarwinBoot chooses a real contiguous UEFI allocation, then reports the successful base and size in BootArgs.

Development findings

• The 46b runtime reported 4548722688 bytes of XNU-managed memory, approximately 4.236 GiB; 48f has no separate LLDB memory probe.
• The 6 GiB physical capacity is a DRAM span input; reservations and contiguous allocation still determine XNU ownership.

Completion criteria

• The owned window fits one successful UEFI allocation and preserves every reserved range.

Current limits

• Available contiguous memory depends on the live UEFI memory map.

Next action

• Record the actual allocated range during the format 2 boot.

Evidence

• source: The board supplies the physical span while retaining automatic conventional-memory allocation.

Storage and root

implemented

Components: NativeUfs, NativeRamBlock, SoftwareAES, VirtioMmioBlock, VerifiedRoot.

Hardware and dependencies

• SM7325 UFS MMIO is 0x01d84000, SMMU MMIO is 0x15000000, stream ID is 0x80 and GIC INTID is 297.
• USERDATA LBAs are 2320896 through 31099898 with 4096-byte sectors.

Configuration

• The NativeUfs community component retains its native-ufs-smmu-reg, native-ufs-stream-id and native-ufs-interrupt ABI.
• The Data UUID remains 09A342FC-CB72-44DE-A10E-B89F14508869; its logical size remains 103079215104 bytes.
• VirtioMmioBlock supplies storage ABI declarations to the existing archive builder.

Procedure

• The ordered archive plan builds verified-root policies, original AES bindings, NativeUfs and NativeRamBlock before final kernel linking.
• Ordinary deployment replaces the 512 MiB FAT at userdata offset 9382658048 and preserves the existing Data location and seed.

Development findings

• The 45f runtime completed 1213669 UFS requests with zero failures or timeouts and peak queue depth 16.
• The 48f USB record shows 300788 completed UFS requests, failed=0, both timeout counts 0 and peak queue depth 14.
• The existing Data implementation persists changes across ordinary FAT updates.

Completion criteria

• UFS publishes the signed OS/SystemOS windows, root mounts, launchd starts and Data writes survive reboot at the fixed offset.

Current limits

• Install / erase Data intentionally initializes the fixed Data region and requires the explicit menu action.

Next action

• Retain the layout and associate further storage activity with its build TAG.

Evidence

• source: The committed layout fixes the 512 MiB FAT and 96 GiB Data positions and UUID.

Display

implemented

Components: NativeMobileDisplay, NativeGeniI2c, NativeQcomDsi.

Hardware and dependencies

• UEFI leaves the panel, DSI PHY and video scanout running.
• The original 21H461 AppleARMBacklight and MobileFramebuffer classes supply the runtime ABI.

Configuration

• Software rendering and CPU framebuffer copies remain enabled.
• The current payload retains the CoreGraphics and CoreUI text fixups, framebuffer write-combine and display binding arguments.

Procedure

• build-software-display.py emits original ABI bindings and the software display archive.
• The board display coordinator sends DSI commands and controls panel power through the existing I2C resources.

Development findings

• The 46l runtime's backlight control and normal shutdown were confirmed by the user.
• The 47a runtime reaches the graphical lock screen with CPU rendering.
• The 48f USB record reports display ready=1 and awake=1 with continuing CPU display frames.

Completion criteria

• Frames have correct geometry and colors, userland presentation advances and brightness/shutdown controls work.

Current limits

• GPU acceleration is a separate hardware implementation stage.

Next action

• Record subsequent brightness and presentation operations with the current build TAG.

Evidence

• source: The board coordinates current panel power, brightness and DSI command operations.

Input

implemented

Components: NativeFocaltechTouch, NativeGeniSpi, NativeQcomSpmi, NativePmicKeys.

Hardware and dependencies

• The touch controller is FT8203 on GENI SPI and uses GPIO81.
• PM7325 supplies the power, volume-down and volume-up inputs through SPMI arbiter v5.

Configuration

• The board touch HID descriptor retains multitouch IDs and grouped digitizer dispatch.
• The original button ADT names remain hold, voldown and volup.

Procedure

• The touch archive compiles the FT8203 protocol, GENI SPI transport and original IOHIDDevice subclass.
• The PMIC archive compiles the SPMI controller, key protocol and board Consumer Control subclass.

Development findings

• Earlier runtime records contain complete power/volume DOWN and UP events.
• The 48f USB record contains continuing touch DOWN/UP events.
• The TLMM owner services registered GPIO sources and the PMIC transport preserves inherited hardware reset policy.

Completion criteria

• Touch coordinates and contact releases arrive, and all three physical buttons produce press/release HID reports.

Current limits

• Firmware and board electrical routing remain SM-T733 inputs.

Next action

• Associate further touch and physical-button operations with the current build TAG.

Evidence

• source: The board binds the PMIC resources to the existing key and HID drivers.

GPU

implemented

Components: Adreno6xx, ArmSmmu4K, AdrenoPM4, AdrenoFirmware.

Hardware and dependencies

• SM7325 A642L chip ID 0x06030500, 512 KiB GMEM and A660 GMU/SQE/ZAP inputs.

Configuration

• The independent Adreno6xx archive is force-loaded with native-adreno-a6xx=1.
• GPU classes register after IOBSD; screen and early diagnostics are enabled.

Procedure

• Initialize live command-db votes, clocks, GPU/GMU SMMU and HFI, then require CP fence and GPU memory readback before publication.
• Run the raw ABI command followed by Turnip fill, compute and triangle readback.

Development findings

• 49h completed eight build stages and its FAT was written and synced; GPU runtime results are pending.
• 49g panicked in IODTGetICellCounts because interrupt-parent resolution requires AAPL,phandle;49h includes the shared converter correction.

Completion criteria

• Actual A642L submissions and rendering succeed before enabling system Metal composition and direct DPU scanout.

Current limits

• No successful A642L GPU hardware execution has been recorded.
• Final display presentation uses GPU-rendered surfaces directly; framebuffer copies remain a diagnostic fallback.

Next action

• Collect 49h screen and USB initialization results.

Evidence

• source: The component is compiled into a dedicated archive with deferred IOKit constructors; hardware execution remains pending.

Network

implemented

Components: NativeUsbNetwork.

Hardware and dependencies

• The DWC3 device transport supplies the current USB ECM link.

Configuration

• The system archive plan includes NativeUsbNetwork and retains native-usb-debug=1.

Procedure

• The existing USB implementation exposes ECM and the XNU ifnet adapter exchanges frames with the host.
• Pairing and RSD setup use the native iOS diagnostics tool when required.

Development findings

• The current ECM connection supports native debugserver capture and detach.

Completion criteria

• The host connects through ECM and completes the requested native diagnostics session.

Current limits

• Wi-Fi transport is pending; this area records the implemented USB network.

Next action

• Record the USB network connection after the format 2 boot.

Evidence

• source: The board's XNU ifnet adapter implements the existing USB network transport.

Audio

planned

Hardware and dependencies

• SM-T733 audio requires its ADSP, transport, codec and board routes.

Configuration

• The current component list selects the implemented CPU, storage, display, input, power and USB services.

Procedure

• Inventory the stock audio paths and firmware before adding an audio component.

Development findings

• The current working baseline reaches the graphical interface without an implemented audio route.

Completion criteria

• Each implemented playback or capture route carries its declared audio format and handles start/stop.

Current limits

• No audio playback or capture support is claimed.

Next action

• Implement audio after its hardware and firmware dependencies are collected.

Evidence

Collect evidence using the next action.

Power

implemented

Hardware and dependencies

• The board uses the SM5714 fuel gauge, TLMM GPIO54 notification and existing panel power resources.
• CPU demand and temperature policy use EPSS and TSENS hardware.

Configuration

• The current battery, CPU DVFS, display power and managed-memory arguments remain enabled.
• The system archive plan retains platform power, battery, thermal and display power ordering.

Procedure

• The battery worker reads the fuel gauge and publishes the original IOPMPowerSource properties.
• The platform shutdown implementation powers down the panel and invokes the existing firmware/PMIC path.

Development findings

• The 46l runtime's normal shutdown and brightness control were confirmed by the user.
• The implemented battery service reports readings from the actual device resources.

Completion criteria

• Battery readings and charging changes update, brightness control works and normal shutdown completes.

Current limits

• Suspend/resume requires separate implementation and runtime evidence.

Next action

• Record the power services after the format 2 boot.

Evidence

• source: The existing board battery service connects gauge readings and GPIO updates to IOPMPowerSource.

Image assembly

implemented

Components: NativePrelink.

Hardware and dependencies

• The system payload contains the original Apple inputs, kernel, ADT, fixed Data seed and board addon files.

Configuration

• The payload remains a 512 MiB FAT with the existing menu, binary text replacements and root UUID.
• The platform configuration retains its 64 MiB diagnostic payload.

Procedure

• The official kernel builder owns prelinking; the unified device entry owns the dependent kernel, package and payload stages.
• The coordinating agent deploys the complete resulting FAT with the existing MSC writer.

Development findings

• 48f completed all seven build stages, a full 536870912-byte FAT write and sync, followed by a USB boot record identifying its TAG.
• Format 2 output directories include the OS profile and selected defconfig; build.py reads status --json output before copying artifacts.

Completion criteria

• All stages finish and the selected output contains a complete deployable payload for its TAG.

Current limits

• Deployment only replaces the ordinary FAT window; Data is preserved.

Next action

• Keep the delivered package and associate further runtime observations with system-format2-48f.

Evidence

• source: The device entry drives the official build stages and obtains the resolved output directory.
• source: The recorded stage table, complete MSC write and USB boot observation identify the 48f delivery.

Diagnostics

implemented

Components: NativeUsbDebug.

Hardware and dependencies

• USB logging remains enabled, including the original opaque USB resource property in /chosen.
• Native debugserver provides one attach session per normal boot.

Configuration

• The selected patch list includes process, page-table and SMP diagnostics.
• Early framebuffer markers and regular screen startup logs remain disabled in the current normal configuration.

Procedure

• Collect USB logs with the existing console tools.
• Prepare symbols before a native attach, perform short reads, then continue and detach.

Development findings

• The 47a debugger entry records reason and caller before parsing the optional panic argument.
• Native debugserver capture and detach have completed on the device.
• 48f USB raw logs identify the current build and capture CPU, UFS, display and touch observations.

Completion criteria

• The build's selected patch list matches the delivered kernel and the requested logs or native capture are recorded with the build TAG.

Current limits

• A new native debugserver session requires a normal reboot after the prior session is consumed.

Next action

• Record further requested diagnostics with the current build TAG and its actual capture method.

Evidence

• source: The selected debugger patch preserves the 47a null-panic handling and entry-state records.