PinePhone

This page is a work in progress.

This page may thus be incomplete. Its content may be changed in the near future.

The PinePhone is an open hardware smartphone from Pine64. It features all the stuff you'd expect from a modern smartphone, although don't expect the latest and greatest variants of each. Full schematics are available on the Pine64 wiki. Unfortunately, open hardware does not mean that full datasheets for all chips are available.

Beware the slight but incompatible changes between different hardware revisions - such as different GPIO pins being used. This page is written about the Community Edition with the v1.2b mainboard, the latest as of writing.

The PinePhone Pro is a different device with similar but incompatible hardware! (such as an entirely different CPU chip from Rockchip)

Resources

• https://linux-sunxi.org/
• https://linux-sunxi.org/File:Allwinner_A64_User_Manual_V1.1.pdf - includes memory map; full register documentation for several basic peripherals including GPIOs, DMA, timers...
• https://wiki.pine64.org/index.php?title=PinePhone#PinePhone_board_information,_schematics_and_certifications

The CPU is an Allwinner A64 (a.k.a. "sun50i"), which is also used in some of Pine64's single-board mcomputers. Although Allwinner does not release full documentation, significant reverse-engineered information is available through the linux-sunxi project. This is presumably one reason Pine64 chose this CPU.

Requirements

To write an SD/eMMC image you need the mksunxiboot tool from the u-boot-tools package (may vary by distribution). [TODO: or you could just write the header yourself]

To use FEL you also need the sunxi-fel tool from the sunxi-tools package.

Since the OS controls all signs of whether the phone is powered on, it's probably a good idea to remove the battery, so that you can be sure whether the phone is on or off. Also, some aspects of battery charging are controlled by the OS, so this removes any chance of accidentally damaging it by applying incorrect settings (not sure if this is possible/likely). The cellular modem is powered directly from the battery and won't work if the battery is not inserted - but this won't be a problem until your OS is quite well developed. The CPU seems to work just fine while the battery is removed.

Booting

The CPU first boots from an integrated boot ROM, which then tries to boot from one of these sources:[1]

1. The microSD card, if present and boot signature (eGON header) is found
2. The internal eMMC storage, if boot signature (eGON header) is found
3. The FEL mode ROM - a USB slave mode where the host computer can read, write and execute memory.

There is also an FEL button that can theoretically be pressed to force boot in FEL mode, but on the PinePhone it is only connected to a test pad, not to an actual button.

The normal way to prepare an OS for the PinePhone is to flash a microSD card and insert it. The OS may then offer an option to install itself onto the eMMC. However, when getting started with osdev, FEL mode (which allows loading code via USB) should allow for a much faster testing cycle.

For your OS, you can choose to boot via U-boot [TODO] or directly into your own "bootloader".

Loading code via microSD/eMMC

Section TODO

Boot signature / eGON header starts at address 8192 and occupies (theoretically) up to 32KB. This region is often left unallocated; if you're low on microSD cards, you might be able to share one with a Raspberry Pi project for example, without constantly re-flashing it.

Loading code via FEL

Accessing FEL

FEL is executed if:

• You have no valid bootloader installed (eGON header not found) on microSD card nor eMMC
• You press the FEL key (not applicable to Pinephone)
• You call the FEL boot code directly

Third option is possible by writing a tiny stub to a microSD card. This is available in sunxi-tools by the name of fel-sdboot. Run make fel-sdboot.sunxi. It makes an 8kB file but only the first 124 bytes are used. Write the file to offset 8192 on any microSD card:

   sudo dd if=fel-sdboot.sunxi of=/dev/NAME_OF_SD_CARD_DEVICE bs=8192 seek=1 count=1

and you can insert this microSD card to trigger FEL mode.

NOTE: When in FEL mode, the phone provides absolutely no visible sign that it is turned on. You can check by running lsusb on the host computer - you should see a USB device like this one:

   Bus 001 Device 012: ID 1f3a:efe8 Allwinner Technology sunxi SoC OTG connector in FEL/flashing mode

and you can verify it by running sunxi-fel version:

   sunxi-tools$ ./sunxi-fel version
   AWUSBFEX soc=00001689(A64) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000

Loading code example

   sunxi-fel write 0x00010000 code.bin
   sunxi-fel execute 0x00010000

Why 0x00010000? According to the memory map this region 0x00010000-0x00017FFF is where the boot ROM normally loads user code, which means it shouldn't conflict with anything used by the boot ROM (e.g. to support the USB interface).

Your code can execute BX LR to return back to the boot loader.

To see if your toolchain works you can try to run User:Immibis/PinePhone Blinky.

Custom bootloader stuff

Skip this section if you are running your OS from U-Boot.

You might notice accessing the 2GB/3GB (depending on model) DRAM area at address 0x40000000 upwards causes the processor to hang, so you only have the SRAM areas (a few hundred kB) to play with. That's because the boot ROM doesn't initialize the DRAM controller. It only uses ROM and SRAM. On a PC, the BIOS would have initialized the memory for you, but this is an embedded system, not a PC. The bootloader is the BIOS, and you are the bootloader.

See PinePhone/DRAM initialization

Power distribution

As this is a battery-powered device you probably want to be aware of what is powered up at any given time. Turning off chips you're not using will make the battery last longer! It looks like all the big power users are off by default, anyway.

If some hardware isn't working, find it in the schematic and make sure all its power sources are turned on. The AXP803 power manager is connected to the CPU via an I2C bus. (TODO: Is any communication actually needed or is everything on by default?)

List of built-in peripherals

eMMC

• CPU's SDC2 port is connected to the eMMC chip.

SD card

• CPU's SDC0 port (4 bits wide) connected to the SD card.
• GPIO PF6 detects whether a card is inserted.

Power management unit (PMU)

Chip type: AXP803

• CPU's PL0/PL1 connected to this chip's I2C port for configuration and status
• Resets the CPU when power is not okay
• Triggers NMI on CPU
• No idea why it connects to USB0 data pins

WLAN/BT

Powered by VCC-PG, VCC-WiFi, DCDC1.

RTL8723CS chip. 4-bit-wide SD interface connects to CPU's SDC1 interface (Port PG).

• CHIP_EN is controlled by a hardware switch under the back cover.
• CPU's SDC1 interface (4 bits wide) is connected to the SD interface on this chip
• UART (not BT_UART1) connects to CPU UART1. Only TX/RX/CTS. It seems RTS was accidentally not connected on the schematic, despite being labeled?
• BT_UART1 is not connected.
• CPU's PCM1 interface is connected to this chip.
• Additional GPIO connections - labeled as they appear on the schematic: BT-RST-N, BT-WAKE-AP, WL-PMU-EN, AP-WAKE-BT

Pogo pin expansion port

General purpose low-speed interface exposed via 6 pogo pins (springy pins) inside the back cover.

Power pins: DCIN directly connects to the USB port's power rail. USB-5V is the voltage the phone could output to the USB port, but doesn't have to actually output as there is a switch in the way. Software can turn on a boost converter to get 5V here, otherwise you get slightly lower than the main system voltage (3 to 5V).

Data pins: SDA/SCK/INT connect to GPIOs PE15, PE14 and PL12 respectively. The I2C pins (SDA/SCK) do connect to a hardware I2C block which is dedicated for this port.

Audio

Audio interfaces built into the CPU.

• PHONEIN, LINEIN, PHONEOUT: Unused - connected to nothing - don't even bother.
• EAROUT: is the "receiver" (top speaker when using as a phone?) Direct connection, no other power supply needed.
• LINEOUT: is the main speaker, amplified via U800. You have to tell the amplifier to actually work by outputting high(?) from GPIO pin PC7. Turn it off when unused, to avoid wasting power.
• HPOUT: to the headphone jack. There's a DETect pin which tells you if something is plugged into the port. When the back cover switch is set to disable headphones, it triggers an analog switch to connect the UART instead of the headphones, and it also overrides the detect signal so it detects nothing plugged in. It doesn't affect the microphone connection, and allegedly the analog switch might not fully isolate the sound signal from the UART, so you probably don't want to play sound.
• MIC2: is the headphone jack microphone port. For headphones without microphone it's just shorted to ground. Microphone power provided by HBIAS from CPU, through a high resistance so there is no problem even if microphone is shorted to ground.
• MIC1: is the microphone below the screen. Microphone power provided by MBIAS from CPU; interrupted by one of the switches under the back cover. Hopefully the microphone doesn't work without this power.

Headphone jack UART: It's UART0 on the CPU, PB8=TX, PB9=RX

Camera

[not researched, no idea how to make it work]

AFVCC-CSI supplies the PE port. CSI occupies pins PE0 (PCLK), PE1 (MCLK), PE2 (HSYNC), PE3 (VSYNC), PE4-PE11 (D0-D7), PE12 (SCK), PE13 (SDA).

Front and rear camera both use the same CSI port, at the same time. Activating both cameras presumably causes corrupted data (but won't damage hardware due to the use of resistors for current limiting). Only use one at a time.

Both cameras use AVDD-CSI, AFVCC-CSI, DVDD1V8-CSI power supplies.

Each camera has its own RST and STBY pins which are pulled up to AFVCC-CSI (TODO: that means they're off, right?) and connected as follows:

	Front camera	Rear camera
RST	PE16	PD3
STBY	PE17	PC0 (req. VCC-PC)

Camera flash

U1000 controls the flash LED from the battery (therefore probably requires an inserted battery)

PD24-FLASH-TRIGOUT (powered by DCDC1) = EN pin PC3-FLASH-EN (powered by VCC-PC) = FLASH pin (names are swapped, yes. They can be either way around according to the schematic. TODO: which way is it really?)

Display

Backlight

GPIO PH10 tells U1100 to create a high voltage for the backlight. GPIO PL10 is a PWM signal that alters the feedback voltage the U1100 is receiving. Increasing this should make the backlight dimmer (as it thinks the output voltage is too high). If PWM is not driven at all, this is pulled up to VCC-LCD, presumably turning the backlight fully off. Turning it to output low (ignoring the pin's PWM mode) should turn the backlight fully on.

GPIO PH10 connects to EN pin. (Is that active low or active high?)

Touch panel

[not researched, no idea how to make it work]
Also known as CTP (capacitive touch panel). Connected by TWI0 bus and 2x GPIO (interrupt + reset)

Video output

[not researched, no idea how to make it work]
MIPI-DSI connected to the CPU. Two additional GPIOs: PD7 connects to DSI-TE (?) and PD23 connects to LCD-RESET#

Small items

Front LED

A simple on/off per colour channel. However it's not clear which pin is which channel as the schematic shows them two different ways.

PD18: LED R (or B?) PD19: LED G (or R?) PD20: LED B (or G?)

Sensors

TWI1-SDA/TWI1-SCK is connected to a few sensor chips you'd expect on phones. Some alternative parts may be used depending on what was available when your phone shipped.

All these sensors communicate over I2C bus connected to TWI1-SCK (PH2) and TWI1-SDA (PH3) and are powered by DLDO1; STK3311-A also powered by GPIO0-LDO (as well as DLDO1).

Proximity and ambient light sensor: STK3311-A (U1201)
INT pin connects to GPIO PB0

6-axis (i.e. 3-axis + 3-axis) gyroscope and accelerometer: MPU6050 (U1202) or BMI120 (U1204)
INT pin connects to GPIO PH5

3-axis magnetometer: LIS3MDL (U1200) or AK09911/AF8133J (U1203): ?
DRDY pin (LIS3MDL) or RSTN (AK*) connects to GPIO PB1.

Side buttons

KEYADC connects to VOL+ and VOL-, forming a resistor divider with a different value depending on which one is pressed. VOL+ has priority. If VOL+ is pressed it's not possible to detect whether VOL- is also pressed. (A shame. It would've cost nothing to give them separate pins, since there are still spare pins available!)

The reset button resets the CPU by pulling down AP-RESET#. Note that it doesn't reset other chips.

The power key goes to a signal called PWRON on the AXP803.

Vibration motor

Vibration motor controlled by GPIO PD2. Motor and GPIO are both powered by DCDC1.

4G cellular modem

[Not really researched, no idea how to make it work]

Powered by VDD_EXT (what is that?) and VBAT and DCDC1

VBAT is only connected to the modem when GPIO PL7 is high and the modem is enabled using the switch under the back cover.

• Connected to SIM card slot (nothing else can access the SIM card)
• CPU's PCM0 connects to modem's PCM port (digital audio data, bidirectional)
• CPU's UART3 connects to modem's UART port - well, data lines are UART3 on the CPU but control lines are all over the place and not on UART3.
• CPU's USB1 connects to modem's USB port.
• Other GPIOs: AP_READY, W_DISABLE#, RESET_N, PWRKEY
• A whole lot of unconnected interfaces, including EPHY, SGMII, dual SIM, SDC1, SDC2, WLAN_EN, BT_EN, DBG_

USB connector

[Not really researched, no idea how to make it work]

The ANX7888 is a big complicated-looking chip with many ports and its own firmware. It appears to control auxiliary functions of the USB port including the DisplayPort Alternate Mode, and possibly cable detection, orientation, and . Note that the main USB D+/D- lines bypass the chip and go directly to the CPU. Likewise the USB power input goes directly to the AXP803 which automatically uses it to power the system. The phone probably will not output power by default.

• HDMI input from CPU. Also DDC I2C and HHPD pins.
• Control via CSCL/CSDA pins via TWI0-SCK (GPIO PH0) / TWI0-SDA (GPIO PH1) bus
• USB to the USB connector: SSTX, SSRX, AUX and CC wires.
• Other GPIOs: POWER_EN, RESET_N, ALERT_N, CABLE_DET

Special power signals for USB:

• GPIO PD11 tells U1300 to generate some of the power rails for the ANX.
• GPIO PD9 tells U1308 to create 5V for the USB CC1/CC2 signalling pins (the ANX chip controls the pin state).
  
• GPIO PD8 tells U601 to create 5V for the USB power output. This 5V (USB-5V) is only actually connected to the USB port based on DRVVBUS signal, which is connected to AXP803's N_VBUSEN signal, and the ANX7888's VBUS_CTRL signal (but NOT the CPU pin labelled DRVVBUS). TODO: so when is it active?