Critical Drivers

From IPhone Linux

Contents 1 DMA (Done) 1.1 Status 1.2 Tasks 2 NOR (Done) 2.1 Status 2.2 Tasks 3 AES (Done) 3.1 Status 3.2 Tasks 4 SPI (Done) 4.1 Status 4.2 Tasks 5 GPIO (Done) 5.1 Status 5.2 Tasks 6 I²C (Done) 6.1 Status 6.2 Tasks 7 LCD (Done) 7.1 Status 7.2 Tasks 8 PMU (Partially Done) 8.1 Status 8.2 Tasks 9 Buttons (Done, Needs Improvement) 9.1 Status 9.2 Tasks 10 NAND (Partially Done) 10.1 Status 10.2 Tasks

DMA (Done)

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 access 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.

Status

The initialization and interrupt handling has been implemented. Code to actually initate an DMA transfer and to notify tasks that the DMA transfer request has been fulfilled has not yet been completed. Apple's own DMA transfer initialization code is tightly integrated with their other FTL code (upon first inspection). A blocking condition on implementation is probably also the finalization of the task switching system.

Tasks

• Write the transfer initialization code (Assigned to: planetbeing)
• Write the transfer finished notification code (Assigned to: planetbeing)

NOR (Done)

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!) and will also enable it to read an existing copy of iBoot we can store somewhere there and chainload it, giving us dual-boot capability

Status

iBoot's NOR driver can handle many different types of NOR chips, and wants to present a uniform block device interface for both NAND and NOR devices, and is thus complicated by these requirements. planetbeing's iPhone uses the SST39WF800A flash chip (http://www.sst.com/downloads/datasheet/S71258.pdf). This was determined by reading the id from the chip in the same way that iBoot does it. There is a small difference in the 3-word unlock sequence, however (see code for details). Only implementing nor routines for this chip greatly simplifies things for us, but it is possible Apple will use incompatible chips in the future. For now, however, we can mark this item as done. (Unless someone shows us an iPhone with a different NOR chip).

Tasks

• Implement NOR driver for SST39WF800A (Assigned to: planetbeing)
• Implement NOR driver for other NOR chips (Assigned to: No one)

AES (Done)

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).

Status

We can encrypt and decrypt with the iPhone hardware and its AES keys and we should be able to use them to patch LLB, iBoot, etc.

Tasks

• Implement AES encryption/decryption using the uid/gid keys and/or our own custom keys (Assigned to: planetbeing, wizdaz)
• Implement other device functions, such as interrupt-driven decryption (Assigned to: no one)

SPI (Done)

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.

Status

A best effort has been made to create a SPI implementation based on reverse engineering what iBoot does. Most of it is pretty clear, but the purpose of some configuration settings are still unknown. Code has been written but untested.

Tasks

• Test the SPI driver (Assigned to: planetbeing)

GPIO (Done)

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.

Status

A best effort has been made to create a GPIO implementation based on reverse engineering what iBoot does. Unfortunately, some stuff is still voodoo. There's a basic idea of what these functions MUST do, but we have no idea what goes on in bits 1-3 of register 0x320. However, the good news is that our voodoo code works the way we expect it to.

Tasks

• Test the GPIO driver (Assigned to: planetbeing)
• Figure out what bits 1-3 actually do (Assigned to: No one)

I²C (Done)

I²C 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!)

Status

Very early on, planetbeing has already documented the I2C code, so it's just a matter of rewriting them.

Tasks

• Write the I²C initialization routines and helpers (Assigned to: planetbeing)
• Write the I²C core operations loop (Assigned to: planetbeing)

LCD (Done)

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 to have feedback independent of a hooked up computer, which is important if we want to release things to a mass audience.

Status

Code has been written for the controller initialization part. Now, only merlot_init and the gamma table installation remains. Code has been written and tested for LCD output. Unfortunately, we are currently unable to install the gamma tables, and without them, the display is essentially unusable (often, all the gamma values for blue are written as zero, meaning it's not possible to use blue, etc.) However, gamma tables can be manipulated if we do not reset the power control for the LCD. However, we cannot depend on iBoot's initializations as a permanent measure, because we eventually want to start straight from NOR flash. However, it is interesting to note that iBEC, the version of iBoot designed to be bootstrapped from iBoot, does not even attempt to install gamma tables, whereas iBoot, which does have gamma table code, is not designed to be started from another copy of iBoot. This may mean that our code implementation is correct, but will only work when written to flash and booted there as the first stage after LLB. Everything works now. Fault is because of a combination of deprecated system controller power code, a few typos, and clock SDIV adjustment. See commit logs for more details.

Tasks

• Write hardware initialization routines for the LCD controller (Assigned to: planetbeing)
• Write code to calculate and create the windows/framebuffer (Assigned to: planetbeing)
• Write code to initialize the LCD panel (Assigned to: planetbeing)
• Write code to install the gamma tables (Assigned to: planetbeing)
• Check if gamma table code works from iBoot-style booting (Assigned to: planetbeing)

PMU (Partially Done)

The PMU controls power to the various different components of the iPhone, such as the backlight. It also contains nonvolatile memory in the form of a few registers 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.

Status

We have basic code to read and write PMU registers, and can use them to do stuff like adjust the backlight level. A lot of code to take care of the various other PMU functionality must be written though.

Tasks

• Write basic PMU register access routines (Assigned to: planetbeing)
• Write code to turn off the iPhone (Assigned to: No one)
• Write code to control iPhone charging (Assigned to: planetbeing)
• Write code to make the nonvolatile registers sane instead of having crazy boot failure counts. (Assigned to: planetbeing)
• Actuallly figure out what to write in those nonvolatile registers (Assigned to: No one)

Buttons (Done, Needs Improvement)

The physical buttons on the iPhone. They work via GPIO. Would be nice if we could get input from them.

Status

We can poll GPIO to read the status of the buttons, just like iBoot, but it would be nice to be able to get button events in the form of interrupts. Naively hooking the interrupts marked "buttons" in the device tree doesn't work (they're never called).

Tasks

• Write basic button code (Assigned to: planetbeing)
• Add more button GPIOs for multiple platforms (Assigned to: No one)
• Make button code interrupt driven (Assigned to: No one)

NAND (Partially Done)

The block of memory the filesystem data, operating system is stored on. We will need it eventually to use as the storage medium to install Linux on. 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.

Status

We currently have working read from the raw flash. No capability of writing or erasing the flash yet. It is also apparent that we need to either fully reverse engineer the FTL or give up on interoperability. We have decided to give reverse engineering the FTL a shot and have begun efforts in that vein. We now have enough of the FTL that we can read from the filesystem! Still no write capability whatsoever.

Tasks

• Reverse engineer and implement the FIL. (Assigned to: planetbeing, CPICH)
• Implement the VFL_Init and FTL_Init routines (Assigned to: planetbeing)
• Implement the VFL_Open function (Assigned to: planetbeing)
• Implement the VFL_Read function (Assigned to: planetbeing, CPICH)
• Implement _FTL_Read (Assigned to: planetbeing, CPICH)
• Implement FTL_Open (Assigned to: planetbeing)
• Implement _FTLRestore (Assigned to: pumpkin, planetbeing)
• Implement the filesystem (Assigned to: planetbeing)
• Figure out how to do writes. (Assigned to: No one)