The reports¶
The recovered detail lives in reports/ in the repository, one file per subsystem. These are
working notes, not polished documentation -- they carry hypotheses that died, retractions, and
corrections to earlier entries in the same file, because that record is the useful part.
Two conventions to know before reading one:
- Read the whole file before appending to it. The head very often already answers the question the tail is about to dig into. A tail read is not reading the notes.
- Superseded sections are kept, marked superseded, rather than deleted. Several conclusions in this project were reversed by later measurement, and the reversal is worth more than a clean file.
Where to start¶
| File | What it is |
|---|---|
session_state.md |
where the last session stopped and what is next -- read this first |
fs_worklist.md |
every filesystem function, with its state |
ui_menu_worklist.md |
every menu target: registered, generic, unserved, unresolved |
qemu_vs_unicorn.md |
the device-by-device diff between the two emulators |
address_space_hygiene.md |
the address conversions, at length |
By subsystem¶
Filesystem and data
fs_layer.md, hfs_driver_worklist.md, itunesdb_reader.md, itunesdb_signature.md,
artwork_reader.md, media_model.md, genius_re_report.md, genius_constraints.md,
photos_re.md
UI -- the largest group, and the one to read before touching a screen
ui_view_base.md, ui_view_records.md, ui_menu_wiring.md, ui_split_view.md,
ui_media_lists.md, ui_text_views.md, ui_image_views.md, ui_progress_view.md,
ui_battery_statusbar.md, ui_battery_preview.md, ui_preview_panes.md, ui_pane_ownership.md,
ui_property_context.md, ui_transitions.md, ui_transform.md, ui_archive_survey.md,
ui_nowplaying_content.md, ui_settings_actions.md, wheel_scroll_rows.md
Audio and video
sm1_spec.md (the specification), sm1_audio_engine.md (the investigation log),
audio_hardware.md, audio_path.md, playback_path.md, m4a_decoder.md, video_path.md,
video_player_re.md
Platform
memory_map_rework.md, mmu_map.md, power_idle_state_machine.md, i2c_async_design.md,
input_hold_gate.md, piezo_clicker.md, accessories.md, accessory_board.md,
usb_disk_mode.md, retailos_panel_path.md, emu_display_and_time.md
Graphics stack
gl_vincent.md, gl_binary_shaders.md, gl_port_plan.md, third_party_versions.md
Boot, security and protected content
bootrom_crypto.md, ipod_debug_access.md, and the FairPlay series
Unsorted
unknown_blocks.md -- regions not yet attributed to anything, kept explicitly rather than ignored
Third-party components¶
third_party_versions.md records which parts of the image are somebody else's published work and at
what version, because that decides what gets recovered and what gets vendored.
The OpenGL ES implementation is the worked example. The strings identify it as Vincent, and the
advertised extension list is the stock fixed-point set -- except for GL_APPLE_binary_shader, with
its glRegisterBinaryShaderAPPLE and glUnregisterBinaryShaderAPPLE. So Vincent comes from upstream
at the advertised version, and the Apple extension is recovered, because Apple wrote it and it
could have been different.
Vendoring a library does not vendor the parts Apple grew onto it, and a file that takes one has to say which half it is.
Debug facilities on a real device¶
ipod_debug_access.md decodes about 37 firmware options, gated behind two empty files in
iPod_Control/Device/ -- a master gate and a per-feature flag. With logging enabled the firmware
writes an event log and a usage report to the device. Others include memory, FPS and voltage
displays. This is Apple's own instrumentation, present in shipped firmware, and it needs no
modification to switch on.