Platform overview¶

This page describes the Zune HD (Pavo, firmware 4.5). It covers the SoC, the operating system, the processes that make up the running system, and the memory and storage layout that the rest of this reference is described against.

Hardware¶

The Zune HD is built on an NVIDIA Tegra APX 2600: an ARM11 application core, a GeForce ULP GPU, and a separate audio and video coprocessor, the AVP, that runs the media codecs. The chip-ID register (APB_MISC GP_HIDREV, 0x70000804) reads 0x00031617, chip 0x16, which is the AP16 part in that family. This is first-generation Tegra, and its SDMMC controller uses a non-standard register layout rather than the standard SDHCI block of the later Tegra 2. The firmware carries the matching NVIDIA driver stack, the libnvrm*, libnvmm*, and libnvddk* DLLs. The AVP's own code ships as .axf images in the same region: nvrm_avp.axf for the coprocessor runtime, and codec blobs including nvmm_h264dec.axf, nvmm_adtsdec.axf, nvmm_mpeg4dec.axf, and nvmm_jpegdec.axf. The rest of the configuration is the published Zune HD specification: 256 MB of RAM, a 480x272 capacitive OLED, and 802.11 b/g Wi-Fi with no cellular radio.

The panel is 480x272. The surface compositor.exe scans out is a separate 272x480 A8R8G8B8 carveout. The scanout path is covered in the display reference.

Operating system¶

The device runs Windows CE 6.0. User-mode drivers run under udevice.exe, the reflector-based host that CE 6 introduced, where the CE 5 Zune Classic devices use device.exe instead. That host and the per-process memory layout described below are both particular to CE 6 rather than the CE 5 line.

The \Windows\ directory holds the OS image, stored read-only in the eMMC OS-image partition (Part00, mounted with zbinfs). At runtime it is a RAM-backed shadow of that image. Files there can be written within a boot but revert on the next one, which is the root of the persistence rules further down. The storage section covers the partition layout.

Processes¶

These are the processes on a running device, walked live from the kernel process list.

Process	Base	Role
`NK.EXE`	`0x80014000`	The CE 6 kernel.
`udevice.exe` (x2)	`0x00010000`	User-mode driver hosts (CE 6 reflector).
`servicesd.exe`	`0x00010000`	Background services, and the host that renders the HUD scene graph through `xuidll`.
`compositor.exe`	`0x00010000`	Composites the final framebuffer through OpenGL ES. Owns the scanout surface and runs no XUI itself.
`gemstone.exe`	`0x00010000`	The main UI runtime: the home screen, now-playing, settings, and the C++ scene classes behind them.
`zie.exe`	`0x00010000`	The Trident-based web browser. Present only while browsing, so it is absent from an idle snapshot.

gemstone.exe and servicesd.exe carry most of the UI. gemstone owns the main shell and its scenes. servicesd renders the HUD, the overlay with the media controls and the lock screen, through xuidll in the same way. compositor.exe sits below both and only composites the result. It does not load xuidll at all.

Not all device state lives inside gemstone. The media library and playback state are exposed by the ZDKMedia_* API in zdksystem.dll, which talks to a set of service brokers. Any user-mode process that loads that DLL can read them, and a standalone daemon has done exactly that on the device to read the now-playing track without injecting into gemstone. The scene tree and the C++ scene-class instances are the part that stays inside gemstone and needs in-process work to reach.

On a modded device this list is longer. Lyra adds nativeapp.exe, its daemon, and one process for each running mod daemon. Those are part of the Lyra runtime, not the retail platform, which is the set in the table above.

Memory model¶

Windows CE 6 gives every process its own private virtual address space, a change from the fixed 32 MB slots of the CE 5 devices in the Zune Classic line. The kernel occupies the top of the address space, at 0x80000000 and above. NK.EXE bases at 0x80014000. Everything below belongs to the process that is currently running.

Executable base. Each process image loads at 0x00010000. The live process list reports that base for every user process, and it matches the on-disk ImageBase of the executables: gemstone.exe, compositor.exe, and zie.exe all link at 0x00010000. Because the space is per-process, the same address is different memory in a different process.
Shared ROM DLLs. The execute-in-place UI and graphics DLLs map at fixed high addresses that are identical in every process: xuidll.dll at 0x41800000, zd3d.dll at 0x41910000, zdksystem.dll at 0x41970000. An address inside one of these is quoted without naming a process because it resolves to the same place everywhere.

Because each process has its own address space, reading another process's memory means working within that process's context rather than the caller's. Lyra provides a cross-process primitive for this. The mechanism it uses is described in the Lyra runtime reference and is not part of the retail platform.

Resources¶

The UI is data-driven from XUIZ container files (.gem) in \Windows\, holding compiled scenes (.xur), skins, and localized string tables. On a v4.5 device the containers group by which process consumes them:

Containers	Consumer
`scenes_standard.gem`, `skin_default.gem`, `strings.gem`	The main `gemstone` shell
`HudScenes.gem`, `HudStrings.gem`, `HudScenes_Tv.gem`	The HUD in `servicesd`
`ZIE_Scenes.gem`, `ZIE_Skins.gem`, `ZIE_Strings.gem`	The `zie` browser
`scenes_tv.gem`	The TV-out UI variant
`xnascenes.gem`, `xnastrings.gem`	The XNA game launcher

Scenes are opened by name through a family of URI transports (gem://, gemskin://, gemstring://). The transport registration and the container format are covered in the XUI engine reference.

Storage ¶

Internal storage is a single eMMC device, presented to CE's storage manager as DSK1:. It is split into three partitions: the OS image (surfaced as the \Windows\ shadow), a small \Flash\ partition, and the large \Flash2\ partition that holds user content and, on a modded device, the platform's boot-staged files. The eMMC has no separate boot or RPMB partitions, so these three are the partitions CE exposes. The storage reference covers the partition layout, the filesystem drivers, and what lies outside the partition table.

Persistence¶

Two rules cover what survives a reboot.

\Windows\ is the XIP shadow and resets on every boot. A change to a file there has to be re-applied on the next boot to stick.
\Flash2\ is real flash and keeps its contents.

The registry does not persist either. RegFlushKey is a stub on this firmware, so a registry write lives only until reboot. Anything that has to survive a power cycle is a file under \Flash2\, and the platform's persistence is built on that. The runtime reference covers how.

Address convention¶

Unless a page says otherwise, an address in this reference is an absolute virtual address in the gemstone.exe v4.5 image as loaded at 0x00010000, so it is the image base plus the file RVA. Instructions are ARM, four bytes each. Addresses are specific to firmware 4.5. The same code on another firmware version sits elsewhere, and each page notes the version it was verified against.