The iPhone appears to use a PL080 (or similar) chip for its two DMA controllers. (We can verify whether it is the exact chip by dumping the PrimeCell identification registers later). The reason we believe so is because the S3C6400X uses that chip and reversed iBoot seems to correspond with that chip. iBoot accesses the DMA controller in a limited manner. In iBoot 1.1.4, cross-references to it only appear only from the NAND FTL driver (in the the low-level FTL functions). Apple's implementation is also very "light", an assumption is made that no error ever occurs.
The iPhone uses NOR to store its bootloaders and other boot related information and configuration details. What we know as NVRAM is also (currently) stored on the same NOR device. Access to the NOR will allow OpenIBoot to bootstrap itself by writing itself to NOR (alternative Apple independent pwner!). This will also enable it to read an existing copy of iBoot that we can store there and chainload it, giving us dual-boot capability.
The iPhone uses an AES device to both accelerate AES encryption and to secure data with two keys: One is a gid key (unique across all iPhones) and one is a uid key (unique to each iPhone). These keys secure data in the NOR (among other tasks), and we must be able to use these in order to be able to modify the contents of NOR (because they are encrypted with these keys).
SPI is used to communicate with at least the LCD and multitouch device. The device controlling the SPI appears to be unique to the s5l8900xrb.
GPIO is used as at least a secondary communications channel for many devices, including the baseband, lcd, buttons, camera, uarts, battery charger, tv-out, etc. The device controlling the GPIO bears a passing similarity to the one on S3C6400X. In addition, it appears that many of Samsung's GPIO interfaces are designed similarly. However, there appears to be a "master" output register at 0x320, just past the ones for individual ports. GPXCON, GPXDAT appear to match in format (though it's impossible to tell the details because so much depends on the specific device, its peripherals, etc. that we'd need the s5l8900xrb data sheet to find out [and we're most likely never getting that]), but only one bit per port is used for the pull-up configuration.
I2C is used in some communications with the LCD panel, so it must be implemented before LCD work can proceed. It is also used to communicate with the accelerometer and PMU (important if we ever want to charge the batteries!)
Code for the LCD driver appears to use a generic LCD controller to communicate with a wide variety of LCD panels. We will obviously need to be able to display stuff on the screen. This allows us to have feedback independent of a hooked up computer, which is important if we want to release things to a mass audience.
The PMU controls power to many components of the iPhone including the backlight. It also contains a few registers of nonvolatile memory that keep track of boot failure counts and so on. It also contains the on-off-control and is responsible for controlling if, when and how the iPhone recharges itself. The chip used is PCF50633.
The physical buttons on the iPhone. They work via GPIO. Would be nice if we could get input from them.
This is the block of memory on which the filesystem data, operating system is stored. We will need it eventually for persistent storage of the Linux filesystem. iBoot implements the NAND in a series of layers. The lowest layer touches the hardware and is called FIL (flash interface layer?). If we reverse engineer that, we can implement the wear-leveling layer from specs (hopefully the wear-leveling technique is the same as some documented Samsung spec) or else just look at the physical format and reverse engineer the specs. This should give us a block device emulator on top of which we can stick filesystem code. The filesystem used is HFS+, so there's already plenty of existing code for that.