Porting overview
A device port has two repositories and one board configuration.
| Repository | Contents |
|---|---|
UniXNU-<device> | board.toml, kernel defconfig, device scripts, drivers, kits, patches and device package |
uefi-<device> | Mu-Silicium UEFI port: device configuration, DSC/FDF, preflight and vendor inputs |
UniXNU supplies the build driver, the UEFI boot manager, DarwinBoot and the generic drivers. A device repository overrides any module with the same name.
Porting checklist
- Port the UEFI firmware so the device reaches a menu, a framebuffer and a payload volume.
- Create the device repository with
board.toml, a defconfig and the package directory. - Select the target IPSW and its identity.
- Generate the ADT with the nodes and properties XNU consumes.
- Build the payload and the boot image.
- Bring up in stages: firmware, menu, payload, kernel entry, platform expert, storage, root, userland.
- Add device drivers and kits for display, storage, input and power.
- Build the userdata image and flash it.
What stays generic
These parts come from UniXNU and usually need no device copy:
- The build driver and module resolution.
- UniXNU and its configuration schema.
- DarwinBoot and the loader protocol.
- NativePrelink.
- The 4 KiB XNU patches.
- The generic platform expert, CPU, VirtIO and block drivers.
What is device specific
- The UEFI firmware port and its vendor binaries.
- The firmware base and size.
- The device tree and the ADT generator.
- The kernel defconfig and the archives it selects.
- The board power, display, touch and GPU drivers.
- The IPSW identity and the trust caches.
- The userdata partition geometry.
Device pages
The Devices section lists device repositories. Each page records the values for that device. The porting guide uses placeholders and links to the device pages for concrete values.