PinePhone
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 computers. 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]
- The microSD card, if present and boot signature (eGON header) is found
- The internal eMMC storage, if boot signature (eGON header) is found
- 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!
Most power comes from a single chip, U600, an AXP803. It comes with a bunch of useful converters all in one chip.
PS is the main power supply rail, from either the battery or USB input.
It has several regulators in the one chip (and supporting components):
- DC/DC 1 -> DCDC1 general purpose rail
- DC/DC 2 -> DCDC2-3 rail (in parallel with DC/DC 3)
- DC/DC 3 -> DCDC2-3 rail (in parallel with DC/DC 2)
- DC/DC 4 -> not connected (don't even bother)
- DC/DC 5 -> DCDC5 rail. High accuracy feedback measurement near the CPU
- DC/DC 6 -> DCDC6 rail. High accuracy feedback measurement near the CPU
- DLDO1 -> DLDO1 rail
- DLDO2 -> DLDO2 rail
- DLDO3 -> AVDD-CSI rail
- DLDO4 -> DLDO4 rail
- ELDO1 -> CPVDD rail
- ELDO2 -> ELDO2 rail
- ELDO3 -> DVDD1V8-CSI rail
- FLDO1 -> FLDO1 rail
- FLDO2 -> FLDO2 rail
- GPIO0/LDO -> GPIO0-LDO rail
- GPIO1/LDO -> GPIO0-LDO rail
- ALDO1: AFVCC-CSI rail
- ALDO2: ALDO2 rail
- ALDO3: ALDO3 rail
- VCC-RTC: VCC-RTC rail
- PWROK -> AP_RESET#
- IRQ -> AP_NMI#
- SCK/SDA -> PMU_SCK/SDA
PS1/PS2 connected to PS rail. VBAT -> current shunt -> 4G-VBAT VBAT -> same current shunt -> transistor Q600 (controlled by N_BATDRV output of AXP803) -> PS rail
VIN for all DC/DCs comes from "PS" rail, what does this mean? DLDOIN and ELDOIN and FLDOIN and ALDOIN also PS rail. ACIN1/2 and VBUS come from DCIN rail
VINT, VREF pins: unknown. Rails labeled VINT, VREF DC/DC 5 also has a DC5SET pin which is disconnected; a comment says a resistor can be placed to change the voltage slightly.
Battery connects to VBAT/GND, and temperature sensor TS U601 is a boost converter that converts PS up to 5V (USB-5V rail) when PD8-VCC5V_EN is high(?). Note that when the converter is off, USB-5V receives a voltage slightly lower than PS voltage. It doesn't turn off the rail, just the converter.
Peripherals
eMMC
This occupies pins PC1 (DS), PC5 (RCLK), PC6 (CMD), PC8-15 (D0-D7), PC16 (RST). You could bitbang it using these pins, or you could be smart about it, and enable the SDC2 peripheral interface which uses these exact pins.
The chip is powered (VCC) by DCDC1 and (VCCQ) by VCC-PC. The port is also powered by VCC-PC. Some other miscellaneous GPIOs are on the same port PC and so also use VCC-PC.
SD card
Is connected to CPU interface SDC0, using GPIO PF0 (D1), PF1 (D0), PF2 (CLK), PF3 (CMD), PF4 (D3) and PF5 (D2).
PF6 is low when a card is inserted, high otherwise.
Card is powered from DCDC1.
SIM card
VDD connects to USIM-VDD. Signals USIM-RST, USIM-CLK, USIM-DATA, USIM-VDD. USIM-DATA is pulled up.
This occupies pins PC1 (K18),
PMU
PL0/S-RSB-SCK/S-TWI-SCK (pad D17) = PMU-SCK = U600 SCK pin
PL1/S-RSB-SDA/S-TWI-SDA (pad C17) = PMU-SDA = U600 SDA pin
PWROK -> AP-RESET# -> CPU ?? pin
IRQ -> AP-NMI# -> CPU ?? pin
It also has DP/DM that connect to USB0 DP/DM pins??
WLAN/BT
PL2/S-UART-TX (pad A19) = WL-PMU-EN (also test pad CPUS-UTX)
PL3/S-UART-RX (pad E19) = WL-WAKE-AP (also test pad CPUs-URX)
PL4 (pad A20) = BT-RST-N
PL5 (pad D19) = BT-WAKE-AP
Pogo pin expansion port
General purpose low-speed interface exposed via 6 pogo pins (springy pins) inside the back cover.
DCIN: connects to DCIN rail. (What does that mean for people who didn't study the power supply architecture?) USB-5V: Connects to USB-5V rail. This is generated by the phone by a boost converter when PD8-VCC5V_EN is high/low(?) otherwise the converter is off, and the rail is still powered, slightly lower than the main power supply voltage (PS) GND: it's ground, zero volts SDA/SCK: connects to CPU GPIO PE15 and PE14 respectively (aka PE TWI2 port). AFVCC-CSI is needed to power the level shifter and also the GPIO port. INT: connected to CPU GPIO PL12-POGO-INT, via some level shifter that needs DCDC1 and ALDO2 to be on.
DCDC1 is needed to pull up all 3 data pins, as wlel.
Audio
Audio interfaces built into the CPU.
Unused interfaces: PHONEIN, LINEIN, PHONEOUT. They're not connected to anything - 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. The amplifiers always has power, but you have to tell it to exit sleep mode by outputting high form CPU GPIO pin PC7 (which also requires that VCC-PC is on). According to the datasheet, the amplifier uses about 10-15mA when not in sleep mode but not outputting any audio. This is taken from the phone's main power supply (PS rail).
HPOUT: to the headphone jack. DCDC1 is required to power the analog switch and enable the HP_DET signal which tells whether a headphone is detected. Note that under the back cover is a switch which changes the headphone jack to UART mode, which switches the left channel to a UART transmitter (PB8 TX/PB9 RX, named from the computer's point of view?), and
MIC2: is the headphone jack microphone port. For headphones without microphone it's just shorted to ground.
TODO: what is MICIN1 and MBIAS?
Camera
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. Activatign both cameras presumably causes corrupted data. 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?)
PE16 = CSI-RST-F PE17 = CSI-STBY-F PD3-CSI-RST-R PC0 = PC0-CSI-STBY-R
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?)
Unknown
PC0 (pad T21) = PC0-CSI_STBY-R (VCC-PC power supply) PC2 = unconnected PC3 (pad P19) = PC3-FLASH_EN (VCC-PC power supply) PC4 = PC4-RESET-4G (VCC-PC power supply) PL6 (pad B20) = PL6-RI PL7 (pad C19) = PL7-4G-PWR-BAT PL8 (pad B21) = PL8-ANX768-CABLE_DET PL9 (pad D20) = PL9-DRVVBUS PL10/S-PWM (pad D21) = PL10-LCD-PWM PL11 (pad C20) = PL11-ANX7688-INT HTX{C/0/1/2}{P/N}, HHPD, HSCL, HSDA: H* interface. HCEC: test pad only. Interface powered by DLDO1 DSI-{CK,D0,D1,D2,D3}{P/N}: MIPI-DSI-* interface. Interface powered by DLDO1 KEYADC (pad A16) :KEYADC FEL (pad F17): internal test pad only (no FEL button) CPU has two USB data pairs: USB0 and USB1.
HSIC: unknown. HSIC-VCC comes from FLDO1; HSIC-DAT/HSIC-STR not connected?
Unknown power: CPU CPVEE, VRA1, VRA2, VRP: ????? CPU VCC-EFUSE: from DCDC1 CPU VCC-RTC: from VCC-RTC CPU AVCC: from ALDO3 CPU CPVDD: CPVDD CPU VCC-PLL: from ALDO3 CPU VCC-USB: comes from DCDC1 VCC-WIFI connects to 4G-VBAT as shown in schematic; DLDO4 connects to VCC-PG. There's an option to connect VCC-WIFI to DLDO4 instead by moving a jumper. VCC-PC connects to DCDC1 by default VCC-LED connects to GPIO0-LDO but can be connected to DC1-SW instead by moving a jumper.
RESET-KEY pulls down AP-RESET#
PH0/TWI0-SCK/PH1/TWI0-SDA/PH2/TWI1-SCK/PH3/TWI1-SDA: used as their TWI formats PH4: CTP-INT PH5: PH5-GS-INT PH6: PH6-AP-WAKE-BT PH7: PH7-AP-READY PH8: PH8-DISABLE-4G PH9: PH9-STATUS
PH10: PH10-LCD-BL-EN PH11: CTP-RST
PD0: PD0-UART3_TX PD1: PD1-UART3_RX PD2: PD2-MOTOR PD3: P3-CSI-RST-R PD4: PD4-UART4_RTS PD5: PD5-UART4_CTS PD6: PD6-ANX_RESET PD7: PD7-LPTE PD8: PD8-VCC5V_EN PD9: PD9-VCONN_5V_EN PD10: PD10-ANX_POWER PD11: PD11-ANX_1V0_EN PD12-PD17: not connected, don't bother\ PD18: LED R PD19: LED G PD20: LED B PD21-PD22: not connected, don't bother PD23: PD23-LCD-RESET PD powered by DCDC1
Misc: CPU RTC frequency is 32768Hz. CPU main crystal frequency is 24MHz