PINE64 - User contributions [en]

PinePhone v1.1 - Braveheart

2021-04-06T18:48:48Z

M@yeulC: /* DIY Hardware fixes */ Link to WIP page on VBUS fix

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone that shipped in January 2020.

This page contains resources which are exclusive to the 1.1 revision of the PinePhone. For newer revisions or for resources related to other PinePhone revisions see [[PinePhone#Hardware revisions]].

== Schematic ==

[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]

== Changes from 1.0 ==

Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.

# Added CPU shielding and cover plate
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot
# Connect WiFi enable to VD33
# Set the EG25G's PWRKEY on by default (see resistor R1526)
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.
# Add voltage shift to Pogo pins I2C-CLK, I2C-DATA, and INT. The Pogo Pin specified voltage is 3.3v while the A64's I2C is 2.8V.
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential

== DIY Hardware fixes ==
Some of the known issues can be fixed with more or less involved hardware modifications:
* VCONN mod: USB-C CC pins are pulled to GND, [[PinePhone_1.2_VCONN_Hardware_Fix|removing small switches]] can make USB-OTG work. A proper fix is to replace those with another component.
* [[PinePhone 1.1 VBUS power usage Hardware Fix]] to lower power consumption, especially when the phone is powered off.
* PMIC mod

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision. Most of these were fixed in the 1.2 revision mainboard.

=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===

''Resolved in v1.2 by PL6 being connected directly to the modem, instead of through the level shifter, so it is pulled low at boot.''

To load the correct device tree, there needs to be some hardware feature that can distinguish the two versions. This can be as simple as an I/O pin that is pulled differently by default between v1.1 and v1.2. Reading the pin in SPL will tell us which device tree to use.

=== WiFi module cannot be disabled or reset in software ===

''Resolved in v1.2 by connecting PL2 to the WiFi module's WiFi reset pin.''

Neither the <tt>WL-REG-ON</tt> nor <tt>WL-PMU-EN</tt> signal is connected to anything, and the WiFi module's <tt>CHIP_EN</tt> pin is connected (through the killswitch) to a regulator that cannot be turned off (easily, if at all). So while the killswitch works, there's no way to disable the WiFi module in software. This will lead to excess power consumption when WiFi is turned off.

=== Magnetometer's IRQ signal is routed to the wrong pin ===

''Resolved in v1.2 by connecting the magnetometer's <tt>DRDY</tt> pin to PB1.''

It needs to go to DRDY, not to INT. The kernel driver expects the trigger events to be fired when DRDY changes, and does not even configure the interrupts to be enabled on the INT pin.

Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.

=== Speaker output could be differential ===

''Resolved in v1.2 by connecting <tt>LINEOUTP</tt> to the speaker amplifier's <tt>INP</tt> input.''

Using a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.

=== Modem AP_READY signal is not connected ===

''Resolved in v1.2 by connecting PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>.''

The [https://www.quectel.com/UploadImage/Downlad/Quectel_EC2x&EG9x_Power_Management_Application_Note_V1.0.pdf modem's power management documentation] describes how to implement modem power saving. The modem can wake up the host using either the Ring Indicator pin (section 4.5) or USB remote wakeup (section 4.3). Either way, it suggests the <tt>AP_READY</tt> signal needs to be connected. The modem needs that signal to know when the host is asleep (and the modem needs to queue its messages and wake it up), and when the host has finished waking up (and is ready to receive the queued messages).

=== Modem RI signal routing prevents wakeup ===

''Resolved in v1.2 by connecting <tt>RI</tt> to PL6.''

The EG25G's Ring Indicator (RI) pin is currently routed to GPIO pin PB2. The A64 needs to receive interrupts via this pin while suspended, so the modem can wake up the A64 (for incoming calls and text messages). The only GPIO bank that can receive interrupts while the A64 is suspended is Port L (on <tt>R_PIO</tt>).

'''Note''': Port L is powered by VCC-PL, and runs at 1v8, so it should ''not'' have a level shift to DCDC1/3v3 between the AP and the modem, like DTR currently has. The way DTR is currently connected is a bug.

=== Excess power usage while driving VBUS ===

''Resolved in v1.2 by connecting PL9 and <tt>VBUS_CTRL</tt> on the ANX7688 to <tt>N_VBUSEN</tt> on the PMIC.'' A [[PinePhone 1.1 VBUS power usage Hardware Fix | crude hardware workaround]] is also possible.

The <tt>N_VBUSEN/DRIVEVBUS</tt> input on the AXP803 PMIC, labeled <tt>USB-DRVVBUS</tt> on the schematic, is not connected to the USB OTG boost regulator enable input, because R1300 is marked "NC". This prevents the AXP803 from automatically detecting when the USB port is being powered from the battery. Thus, the PMIC continues to draw power from the USB port, and this doubles the drain on the battery (since the whole phone is being powered by the USB OTG boost regulator). This could be fixed by populating R1300.

The ANX7688's VBUS_CTRL pin should also be connected to the DRVVBUS signal to perform role switching in hardware without needing OS interaction. In that case PD6 becomes an input. Otherwise, we would need to hook up the VBUS status change interrupt from the ANX7688 to control the USB PHY driver.

=== ANX7688 power supply situation is problematic ===

''Resolved in v1.2 by powering always-on 3v3 from DCDC1, video-related 3v3 from DLDO1, 1v8 from GPIO-LDO1, and 1v0 controlled by PD11.''

ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).
* The main 3v3 input, to AVDD33, should always be on according to the datasheet. For this reason, it should be connected to an always-on regulator, such as DCDC1, so DLDO1 can be turned off when the screen is off. It has extremely low power consumption.
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.
* The only other 3v3 consumer is the VCONN_EN pull-ups. These could be pulled to GPIO1-LDO (1.8V) instead; the pins are open drain.
* The DVDD18 input should also always be on according to the datasheet. It has extremely low power consumption. I recommend connecting it and the PL11 pull-up to VCC-PL, so GPIO1-LDO can be turned off.
* The remaining 1v8 inputs only need to be enabled when a USB cable is connected (supply or OTG). They are connected to their own regulator (GPIO1-LDO), so that is fine. (Note that the next issue suggests removing the pull-ups for POWER_EN and RESET_N.)
* The 1v0 input is only needed when a USB cable is connected (supply or OTG). It is currently controlled by DLDO1, but I think controlling it with GPIO1-LDO would be an improvement. That way DLDO1 only needs to be enabled when transmitting video, not always when a cable is connected.

=== Modem PWR_KEY signal resistor population ===

''Resolved in v1.2 by separating the modem <tt>PWRKEY</tt> (PB3) and <tt>STATUS</tt> (PH9) signals.''

On the dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can't do anything to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).

It would be nice to also have access to the STATUS signal from the modem, so that the driver can detect whether the modem is on or off (userspace might have turned modem off already via AT commands). Given that PWR_KEY pulse will either turn the modem on or off, based on the current status, it's necessary to know the current status before sending the pulse.

There's a STATUS signal routed to PWR_KEY on BraveHeart, that keeps the PWRKEY deasserted when the modem is on and it's not possible to pull it up from PB3, even if R1516 would be optionally mounted.

So after powerup you can't change PWR_KEY signal anymore from PB3 even if R1516 is mounted, and it's not possible to turn off the modem via PB3.

=== Modem has access to sensors on I2C1 ===

''Resolved in v1.2 by disconnecting the modem's I2C port.''

The modem is a master on the I2C1 bus. A malicious firmware on the modem would be able to read the phone's gravity/light/proximity sensors and prevent the main Linux OS from reading them. The [https://www.quectel.com/UploadImage/Downlad/Quectel_WCDMA&LTE_Audio_Design_Note_V1.1.pdf modem's audio design note] describes the <tt>AT+QIIC</tt> command which can be used to read and write registers on I2C devices.

According to the modem documentation, its I2C interface is only used for direct connection to a standalone audio codec. On the PinePhone, since the modem's audio is routed through the A64 SoC, the modem's I2C interface has no legitimate use.

The modem's I2C interface should be left floating. U1503 pins A1, A2, B1, and B2 can be disconnected, and R1527/R1528 can be removed.

=== Allow access the modem debug UART ===

''Not resolved in v1.2 -- would have required moving several other GPIOs.''

Instead of the modem's I2C pins, which aren't very useful (see above), it would be great to have access to the modem's debug UART, for debugging/updating the modem. This could be on UART3 (PD0-PD1, no flow control), while the main modem UART is on UART4 (PD2-PD5, with flow control).

=== Modem UART flow control is broken ===

''Not resolved in v1.2 -- assumption is that USB will be used for high-bandwidth modem I/O.''

BB-TX and BB-RX are connected to UART3 (PD0/PD1). BB-RTS and BB-CTS are connected to UART4 (PD4/PD5). To use hardware flow control, TX/RX would need to be connected to UART4, swapping PD0/PD1 with the motor control and rear camera reset GPIOs at PD2/PD3. This would need a device tree change.

Hardware flow control can be disabled with the <tt>AT+IFC</tt> command, and USB can also be used for commands instead of the UART. So the impact of this problem is unclear.

=== ANX7688 power/reset control pulled the wrong way ===

''Not resolved in v1.2 -- this has minimal impact.''

Both <tt>ANX_POWER_EN</tt> and <tt>ANX_RESET_N</tt> have pull-ups when they should not. Both signals need to be pulled low by default. They only need to be brought high (turning the chip on) when a USB cable is attached; and they should only be brought high after the 1v8 and 1v0 regulators are turned on. <tt>ANX_POWER_EN</tt> needs an external pull-down. <tt>ANX_RESET_N</tt> has an internal pull-down.

=== VCONN_EN signals are possibly inverted ===

''Further investigation determined that the hardware is correct as-is in v1.1, so no change was made.''

I don't have a datasheet for the AW3512 chips, but I assume the enable input is active-high. VCONN1_EN and VCONN2_EN are open-drain. When they are open, it appears that VCONN should be enabled. But right now, when they are open, VCONN is disabled, because the AW3512 EN pin will be pulled low by the FET.

=== Cameras have the same default I2C address ===

''Resolved in software by reprogramming the one of the cameras' I2C addresses at boot.''

This makes it hard to keep both of them powered at the same time and switch quickly between them (on the per-frame basis) without having to re-initialize the sensors on each switch, which takes some time.

=== USB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off ===

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this can only be worked around by manual selection of PinePhone's data and power role by the user.

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles. I confirmed that desoldering fixes the issue. (Howto: https://megous.com/dl/tmp/pp-usbc-fix.jpg)

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

This issue is also present on the PinePhone 1.2 (CE) version and was fixed with revision 1.2a. See the [[PinePhone_1.2_VCONN_Hardware_Fix|workaround]] for affected revisions.

=== Pogo Pins supply 5 V, not 3.3 V ===

''No hardware change suggested, to maintain accessory compatibility.''

This is possibly just a documentation issue. [https://wiki.pine64.org/index.php/PinePhone#Pogo_Pins The wiki claims] they provide a "3.3 V power source", and on this page, "The Pogo Pin specified voltage is 3.3 V". But according to the schematic, they are connected to <tt>USB-5V</tt>, the output of the 5 V boost regulator.

[[Category:PinePhone]]

PinePhone v1.1 - Braveheart

2021-04-06T18:47:12Z

M@yeulC: /* Excess power usage while driving VBUS */ Link to WIP fix page

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone that shipped in January 2020.

This page contains resources which are exclusive to the 1.1 revision of the PinePhone. For newer revisions or for resources related to other PinePhone revisions see [[PinePhone#Hardware revisions]].

== Schematic ==

[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]

== Changes from 1.0 ==

Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.

# Added CPU shielding and cover plate
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot
# Connect WiFi enable to VD33
# Set the EG25G's PWRKEY on by default (see resistor R1526)
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.
# Add voltage shift to Pogo pins I2C-CLK, I2C-DATA, and INT. The Pogo Pin specified voltage is 3.3v while the A64's I2C is 2.8V.
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential

== DIY Hardware fixes ==
Some of the known issues can be fixed with more or less involved hardware modifications:
* VCONN mod: USB-C CC pins are pulled to GND, [[PinePhone_1.2_VCONN_Hardware_Fix|removing small switches]] can make USB-OTG work. A proper fix is to replace those with another component.
* PMIC mod

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision. Most of these were fixed in the 1.2 revision mainboard.

=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===

''Resolved in v1.2 by PL6 being connected directly to the modem, instead of through the level shifter, so it is pulled low at boot.''

To load the correct device tree, there needs to be some hardware feature that can distinguish the two versions. This can be as simple as an I/O pin that is pulled differently by default between v1.1 and v1.2. Reading the pin in SPL will tell us which device tree to use.

=== WiFi module cannot be disabled or reset in software ===

''Resolved in v1.2 by connecting PL2 to the WiFi module's WiFi reset pin.''

Neither the <tt>WL-REG-ON</tt> nor <tt>WL-PMU-EN</tt> signal is connected to anything, and the WiFi module's <tt>CHIP_EN</tt> pin is connected (through the killswitch) to a regulator that cannot be turned off (easily, if at all). So while the killswitch works, there's no way to disable the WiFi module in software. This will lead to excess power consumption when WiFi is turned off.

=== Magnetometer's IRQ signal is routed to the wrong pin ===

''Resolved in v1.2 by connecting the magnetometer's <tt>DRDY</tt> pin to PB1.''

It needs to go to DRDY, not to INT. The kernel driver expects the trigger events to be fired when DRDY changes, and does not even configure the interrupts to be enabled on the INT pin.

Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.

=== Speaker output could be differential ===

''Resolved in v1.2 by connecting <tt>LINEOUTP</tt> to the speaker amplifier's <tt>INP</tt> input.''

Using a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.

=== Modem AP_READY signal is not connected ===

''Resolved in v1.2 by connecting PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>.''

The [https://www.quectel.com/UploadImage/Downlad/Quectel_EC2x&EG9x_Power_Management_Application_Note_V1.0.pdf modem's power management documentation] describes how to implement modem power saving. The modem can wake up the host using either the Ring Indicator pin (section 4.5) or USB remote wakeup (section 4.3). Either way, it suggests the <tt>AP_READY</tt> signal needs to be connected. The modem needs that signal to know when the host is asleep (and the modem needs to queue its messages and wake it up), and when the host has finished waking up (and is ready to receive the queued messages).

=== Modem RI signal routing prevents wakeup ===

''Resolved in v1.2 by connecting <tt>RI</tt> to PL6.''

The EG25G's Ring Indicator (RI) pin is currently routed to GPIO pin PB2. The A64 needs to receive interrupts via this pin while suspended, so the modem can wake up the A64 (for incoming calls and text messages). The only GPIO bank that can receive interrupts while the A64 is suspended is Port L (on <tt>R_PIO</tt>).

'''Note''': Port L is powered by VCC-PL, and runs at 1v8, so it should ''not'' have a level shift to DCDC1/3v3 between the AP and the modem, like DTR currently has. The way DTR is currently connected is a bug.

=== Excess power usage while driving VBUS ===

''Resolved in v1.2 by connecting PL9 and <tt>VBUS_CTRL</tt> on the ANX7688 to <tt>N_VBUSEN</tt> on the PMIC.'' A [[PinePhone 1.1 VBUS power usage Hardware Fix | crude hardware workaround]] is also possible.

The <tt>N_VBUSEN/DRIVEVBUS</tt> input on the AXP803 PMIC, labeled <tt>USB-DRVVBUS</tt> on the schematic, is not connected to the USB OTG boost regulator enable input, because R1300 is marked "NC". This prevents the AXP803 from automatically detecting when the USB port is being powered from the battery. Thus, the PMIC continues to draw power from the USB port, and this doubles the drain on the battery (since the whole phone is being powered by the USB OTG boost regulator). This could be fixed by populating R1300.

The ANX7688's VBUS_CTRL pin should also be connected to the DRVVBUS signal to perform role switching in hardware without needing OS interaction. In that case PD6 becomes an input. Otherwise, we would need to hook up the VBUS status change interrupt from the ANX7688 to control the USB PHY driver.

=== ANX7688 power supply situation is problematic ===

''Resolved in v1.2 by powering always-on 3v3 from DCDC1, video-related 3v3 from DLDO1, 1v8 from GPIO-LDO1, and 1v0 controlled by PD11.''

ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).
* The main 3v3 input, to AVDD33, should always be on according to the datasheet. For this reason, it should be connected to an always-on regulator, such as DCDC1, so DLDO1 can be turned off when the screen is off. It has extremely low power consumption.
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.
* The only other 3v3 consumer is the VCONN_EN pull-ups. These could be pulled to GPIO1-LDO (1.8V) instead; the pins are open drain.
* The DVDD18 input should also always be on according to the datasheet. It has extremely low power consumption. I recommend connecting it and the PL11 pull-up to VCC-PL, so GPIO1-LDO can be turned off.
* The remaining 1v8 inputs only need to be enabled when a USB cable is connected (supply or OTG). They are connected to their own regulator (GPIO1-LDO), so that is fine. (Note that the next issue suggests removing the pull-ups for POWER_EN and RESET_N.)
* The 1v0 input is only needed when a USB cable is connected (supply or OTG). It is currently controlled by DLDO1, but I think controlling it with GPIO1-LDO would be an improvement. That way DLDO1 only needs to be enabled when transmitting video, not always when a cable is connected.

=== Modem PWR_KEY signal resistor population ===

''Resolved in v1.2 by separating the modem <tt>PWRKEY</tt> (PB3) and <tt>STATUS</tt> (PH9) signals.''

On the dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can't do anything to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).

It would be nice to also have access to the STATUS signal from the modem, so that the driver can detect whether the modem is on or off (userspace might have turned modem off already via AT commands). Given that PWR_KEY pulse will either turn the modem on or off, based on the current status, it's necessary to know the current status before sending the pulse.

There's a STATUS signal routed to PWR_KEY on BraveHeart, that keeps the PWRKEY deasserted when the modem is on and it's not possible to pull it up from PB3, even if R1516 would be optionally mounted.

So after powerup you can't change PWR_KEY signal anymore from PB3 even if R1516 is mounted, and it's not possible to turn off the modem via PB3.

=== Modem has access to sensors on I2C1 ===

''Resolved in v1.2 by disconnecting the modem's I2C port.''

The modem is a master on the I2C1 bus. A malicious firmware on the modem would be able to read the phone's gravity/light/proximity sensors and prevent the main Linux OS from reading them. The [https://www.quectel.com/UploadImage/Downlad/Quectel_WCDMA&LTE_Audio_Design_Note_V1.1.pdf modem's audio design note] describes the <tt>AT+QIIC</tt> command which can be used to read and write registers on I2C devices.

According to the modem documentation, its I2C interface is only used for direct connection to a standalone audio codec. On the PinePhone, since the modem's audio is routed through the A64 SoC, the modem's I2C interface has no legitimate use.

The modem's I2C interface should be left floating. U1503 pins A1, A2, B1, and B2 can be disconnected, and R1527/R1528 can be removed.

=== Allow access the modem debug UART ===

''Not resolved in v1.2 -- would have required moving several other GPIOs.''

Instead of the modem's I2C pins, which aren't very useful (see above), it would be great to have access to the modem's debug UART, for debugging/updating the modem. This could be on UART3 (PD0-PD1, no flow control), while the main modem UART is on UART4 (PD2-PD5, with flow control).

=== Modem UART flow control is broken ===

''Not resolved in v1.2 -- assumption is that USB will be used for high-bandwidth modem I/O.''

BB-TX and BB-RX are connected to UART3 (PD0/PD1). BB-RTS and BB-CTS are connected to UART4 (PD4/PD5). To use hardware flow control, TX/RX would need to be connected to UART4, swapping PD0/PD1 with the motor control and rear camera reset GPIOs at PD2/PD3. This would need a device tree change.

Hardware flow control can be disabled with the <tt>AT+IFC</tt> command, and USB can also be used for commands instead of the UART. So the impact of this problem is unclear.

=== ANX7688 power/reset control pulled the wrong way ===

''Not resolved in v1.2 -- this has minimal impact.''

Both <tt>ANX_POWER_EN</tt> and <tt>ANX_RESET_N</tt> have pull-ups when they should not. Both signals need to be pulled low by default. They only need to be brought high (turning the chip on) when a USB cable is attached; and they should only be brought high after the 1v8 and 1v0 regulators are turned on. <tt>ANX_POWER_EN</tt> needs an external pull-down. <tt>ANX_RESET_N</tt> has an internal pull-down.

=== VCONN_EN signals are possibly inverted ===

''Further investigation determined that the hardware is correct as-is in v1.1, so no change was made.''

I don't have a datasheet for the AW3512 chips, but I assume the enable input is active-high. VCONN1_EN and VCONN2_EN are open-drain. When they are open, it appears that VCONN should be enabled. But right now, when they are open, VCONN is disabled, because the AW3512 EN pin will be pulled low by the FET.

=== Cameras have the same default I2C address ===

''Resolved in software by reprogramming the one of the cameras' I2C addresses at boot.''

This makes it hard to keep both of them powered at the same time and switch quickly between them (on the per-frame basis) without having to re-initialize the sensors on each switch, which takes some time.

=== USB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off ===

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this can only be worked around by manual selection of PinePhone's data and power role by the user.

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles. I confirmed that desoldering fixes the issue. (Howto: https://megous.com/dl/tmp/pp-usbc-fix.jpg)

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

This issue is also present on the PinePhone 1.2 (CE) version and was fixed with revision 1.2a. See the [[PinePhone_1.2_VCONN_Hardware_Fix|workaround]] for affected revisions.

=== Pogo Pins supply 5 V, not 3.3 V ===

''No hardware change suggested, to maintain accessory compatibility.''

This is possibly just a documentation issue. [https://wiki.pine64.org/index.php/PinePhone#Pogo_Pins The wiki claims] they provide a "3.3 V power source", and on this page, "The Pogo Pin specified voltage is 3.3 V". But according to the schematic, they are connected to <tt>USB-5V</tt>, the output of the 5 V boost regulator.

[[Category:PinePhone]]

PinePhone 1.1 VBUS power usage Hardware Fix

2020-08-17T10:32:22Z

M@yeulC: Create page (with a lot of placeholders still)

This page details a hardware fix for an issue that affects some early [[PinePhone#Hardware_revisions | PinePhone]] units, namely [[PinePhone v1.1 - Braveheart | v1.1 Braveheart]] units (fixed since [[PinePhone v1.2 | 1.2 community edition]] included).

The issue was [[PinePhone_v1.1_-_Braveheart#Excess_power_usage_while_driving_VBUS | originally reported here]] by megi.

TODO: Add more pictures and schematics, better reference the fix origin and tradeofs, remove TODOs/FIXMEs.

== Affected Units ==
# [[PinePhone v1.1 - Braveheart]]

FIXME: confirm [[Project Don't be evil|"Project Don't Be Evil" devkit]] and [[PinePhone v1.0 - Dev|PinePhone v1.0 - Developer batch]] are unaffected.

== Disclaimer ==

Though easier to perform than the [[PinePhone 1.2 VCONN Hardware Fix]], this fix requires desoldering relatively small Surface Mount Technology (SMT) components, therefore some experience with soldering is recommended.

== Issue description ==
TODO: pictures

The AXP803 cannot detect when the USB port is powered by the battery. Therefore, the Power Management IC (PMIC) continues draining current from it. This is especially problematic since this USB port is powered from the battery with the USB OTG boost regulator. One of the symptoms is the battery discharging rather quickly even when the phone is powered off.

== Workaround ==

HW workaround is desoldering the U1301 regulator (TODO: describe its role) and shorting pads for R1309 on the PCB (this is a "0 ohm" resistor on the schematic, so it's completely fine).

Shorting the pads is easy to do with some solder (while carefully avoiding to short it with nearby resistors).

Desoldering the regulator is harder to do, since its large pads are designed to use the PCB as a heatsink and will happily cool down while you are trying to melt it. It should be possible to use properly sized pliers to cut the pins first, please edit if you attempt this.

Please be careful not to overheat nearby components trough the PCB traces when applying heat to the regulator. It can be helpful to start the operation with melting some leaded solder tin together with the pads, and lifting the regulator while applying heat also helps. Start with the side that has only one pad: though it is bigger, it should be easier to lift up. It might be useful to apply a relatively large quantity of molten solder tin to each pin, in turn, while lifting the regulator, to reduce the PCB heatsink effectiveness.

Feel free to add your experiences and tips here.

=== Tradeoffs ===
TODO: Unknown to the author

== Proper fix ==
TODO

== Sources and tutorials ==
* [https://xnux.eu/devices/pp-pmic-fix.jpg Tutorial from megi]
* [https://xnux.eu/devices/feature/anx7688.html Description from megi] at the end of the page

PinePhone Hardware Accessory Compatibility

2020-07-31T14:39:02Z

M@yeulC: /* Peripheral equipment */ Add dell WD-15 test result (positive)

List of devices that have been tried on the PinePhone, and the results.

== Peripheral equipment ==

{| class="wikitable sortable"

!Type || Make/Model || Connected via || Hardware IDs || Result || Tested OS || Notes
|-
|5-1 USB-C hub || [https://www.aliexpress.com/item/32954358411.html from aliexpress] || USBC || 05e3:0626 hub || PD not working, rest not working yet ||UBPorts/pmOS || HDMI, GBit eth, 2xUSB-3, USB-C PD [http://www.sympato.ch/~dryak/files/usbc-dock.jpg image]
|-
|Generic Bluetooth keyboard || generic || BT || -- || No pairing via ui, but functional via terminal || pmOS || [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone)#Bluetooth Instructions]
|-
|UMAX U-Connect Type-C Multiport H7 || [https://www.tsbohemia.cz/umax-u-connect-type-c-multiport-h7_d350000.html ts-bohemia] || USBC || - || USB-A ports, PD, HDMI works, SD card reader not enumerating on PP with removed VCONN switches (may need VCONN) || Arch Linux || HDMI, 3xUSB-3, USB-C PD, SD reader
|-
|Google Pixel USB-C to 3.5mm adapter || [https://store.google.com/?srp=/product/usb_c_headphone_adapter google] || USBC || 18d1:5029 || Works, recognized as usb soundcard, but only if a cable is plugged in || pmOS ||
|-
|-
|Anker PowerExpand+ 7-in-1 USB-C PD Ethernet Hub || [https://www.anker.com/products/variant/powerexpand--7in1-usbc-pd-ethernet-hub/A83520A1 Anker] || USBC || -- || USB Ports and HDMI Port work, can charge while using this device (needs VCONN HW mod) || [https://wiki.mobian-project.org/doku.php?id=mods Mobian] || HDMI, USB3, Ethernet, PD-USBC, SD Card, Micro SD Card
|-
|Dell WD-15 Docking station || [https://www.dell.com/support/article/en-us/sln296829/how-to-use-and-troubleshoot-dell-docking-station-wd15?lang=en Dell] || USB-C || 0424:2807 || USB Ports and charging works. Audio sinks and DP status changes are detected (needs VCONN HW mod and ANX firmware) || pmOS || HDMI, VGA and DP might work after a kernel update. ANX firmware is needed for charging after VCONN mod.
|-
|}

== Protection ==

=== Screen protector ===

Official: [https://store.pine64.org/product/pinephone-tempered-glass-screen-protector/ PinePhone Tempered Glass Screen Protector]

Most screen protectors for the iPhone 11 Pro Max and the iPhone XS Max fit the PinePhone (if the top notch is not obscured by a black foil or similar).

=== Case ===

The Pine store got official cases:

* [https://store.pine64.org/?product=pinephone-hard-protective-case PinePhone Hard Protective Case]
* [https://store.pine64.org/?product=pinephone-soft-tpu-protective-case-reduce-digital-gap-donation-program PinePhone Soft TPU Protective Case - "Reduce Digital Gap" Donation Program]

Tight-fit cases of other phones can't be alienated for the PinePhone due as most times the proportions and/or camera notch won't fit. The phone can however also be used with "phone sleeves", such as those from fitBAG.

User:M@yeulC

2020-07-31T10:23:35Z

M@yeulC: Create my user page

postmarketOS contributor. Electronics/Embedded systems Engineer, microelectronics PhD student.

Matrix: Ask for MayeulC in #PinePhone.

Devices owned:
* PinePhone 1.1 Braveheart

Meet me at fosdem :)

PinePhone 1.2 VCONN Hardware Fix

2020-07-30T22:48:58Z

M@yeulC: /* Sources and tutorials */ fix attribution

This page details a hardware fix for an issue that affects some early PinePhone units (fixed since 1.2a included).

The issue was [[PinePhone_v1.1_-_Braveheart#USB-C_CC_pins_are_pulled_to_the_GND_by_AW3512_.28VCONN_switches.29_when_VCONN_is_off | originally reported here]] by megi.

TODO: Add more pictures and schematics, better reference the fix origin and tradeofs, remove TODOs/FIXMEs.

== Affected Units ==
# (FIXME confirm this) [[Project Don't be evil|"Project Don't Be Evil" devkit]]
# (FIXME confirm this)[[PinePhone v1.0 - Dev|PinePhone v1.0 - Developer batch]]
# [[PinePhone v1.1 - Braveheart]]
# [[PinePhone v1.2‎]] - Community Edition

== Disclaimer ==

This fix requires desoldering tiny (1 mm per 1 mm, from the datasheet) BGA components, therefore some experience with soldering is highly recommended.

== Issue description ==
[[File:Martjin_VCONN_switches_1.1.jpg|thumb|frame|Close-up picture of the two identical switches the issue originates from, with the ANX USB controller in the frame]]

[[File:Schematic_VCONN_switches.png|thumb|frame|Excerpt from the PinePhone schematic showing the two components.]]

The USB standard [https://microchipdeveloper.com/usb:tc-pins specifies] that both halves (top and bottom) of the USB-C port contains one "CC" pin (CC1 and CC2, respectively). A regular cable will connect a CC pin from one end to the other end. This allows detecting which way the cable is plugged. Some active USB-C cables exist (both "e-marked" and "managed active cables"); they contain a chip, which needs to be powered. This is done by having one of the cable end connect its CC pins to 5V and VCONN, and requires switches to plug the right CC pin to the right voltage.

The issue arises due to the switches that were chosen up to v1.2a (the a revision excluded) of the PCB assembly: the [https://www.awinic.com/cn/index/pageview/catid/122/id/2.html infamous AW3512], labelled U1305 and U1309 on the schematic. Instead of leaving the output pin "dangling" with a high impedance when disabled, the switch pull the output down. This feature is intended for discharging a capacitor, hence its "Quick output discharge" name. This is an excerpt from the datasheet:

<q> The AW3512/AW35122 includes the Quick Output Discharge (QOD) feature, in order to discharge the application capacitor connected on OUT pin.When EN pin is set to low level (disable state), a discharge resistance with a typical value of 276Ω (AW35122: 75Ω)is connected between the output and ground, pull down the output and prevent it from floating when the device is disabled.</q>

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this could theoretically be worked around by manual selection of PinePhone's data and power role by the user, but hasn't been attempted, and might damage hardware if done incorrectly.

== Workaround ==

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles.

=== Tradeoffs ===
Voiding the VCONN control might (TODO: gather more data) prevent some accessories from working, notably those using an active cable.

== Proper fix ==

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

PCBA revision 1.2a onwards should incorporate that fix. (TODO: confirm this).

== Sources and tutorials ==
* [https://megous.com/dl/tmp/pp-usbc-fix.jpg megi's writeup]
* [https://xnux.eu/devices/feature/anx7688.html another writeup from megi] with a few words on firmware
* [https://www.youtube.com/watch?v=xf8OJtjNWUM Video: "The right way"] with a hot air gun/reflow station, by mozzwald
* [https://www.youtube.com/watch?v=ZqOb45N2sMc Vdeo: "The equally stupid way"], workaround video by Dalton, using a soldering iron. Less chances to permanently damage the board than the next if you are handy with a soldering iron, but still high.
* [https://www.youtube.com/watch?v=j3jc7Mvn9Eo Video: "The stupid way"] workaround video by Lukasz, with pliers. Slightly damages the circuit board, preventing you from soldering the replacement chips at a later point. You might be fine with this.

PinePhone 1.2 VCONN Hardware Fix

2020-07-30T22:42:18Z

M@yeulC: /* Sources and tutorials */ add xnux

This page details a hardware fix for an issue that affects some early PinePhone units (fixed since 1.2a included).

The issue was [[PinePhone_v1.1_-_Braveheart#USB-C_CC_pins_are_pulled_to_the_GND_by_AW3512_.28VCONN_switches.29_when_VCONN_is_off | originally reported here]] by megi.

TODO: Add more pictures and schematics, better reference the fix origin and tradeofs, remove TODOs/FIXMEs.

== Affected Units ==
# (FIXME confirm this) [[Project Don't be evil|"Project Don't Be Evil" devkit]]
# (FIXME confirm this)[[PinePhone v1.0 - Dev|PinePhone v1.0 - Developer batch]]
# [[PinePhone v1.1 - Braveheart]]
# [[PinePhone v1.2‎]] - Community Edition

== Disclaimer ==

This fix requires desoldering tiny (1 mm per 1 mm, from the datasheet) BGA components, therefore some experience with soldering is highly recommended.

== Issue description ==
[[File:Martjin_VCONN_switches_1.1.jpg|thumb|frame|Close-up picture of the two identical switches the issue originates from, with the ANX USB controller in the frame]]

[[File:Schematic_VCONN_switches.png|thumb|frame|Excerpt from the PinePhone schematic showing the two components.]]

The USB standard [https://microchipdeveloper.com/usb:tc-pins specifies] that both halves (top and bottom) of the USB-C port contains one "CC" pin (CC1 and CC2, respectively). A regular cable will connect a CC pin from one end to the other end. This allows detecting which way the cable is plugged. Some active USB-C cables exist (both "e-marked" and "managed active cables"); they contain a chip, which needs to be powered. This is done by having one of the cable end connect its CC pins to 5V and VCONN, and requires switches to plug the right CC pin to the right voltage.

The issue arises due to the switches that were chosen up to v1.2a (the a revision excluded) of the PCB assembly: the [https://www.awinic.com/cn/index/pageview/catid/122/id/2.html infamous AW3512], labelled U1305 and U1309 on the schematic. Instead of leaving the output pin "dangling" with a high impedance when disabled, the switch pull the output down. This feature is intended for discharging a capacitor, hence its "Quick output discharge" name. This is an excerpt from the datasheet:

<q> The AW3512/AW35122 includes the Quick Output Discharge (QOD) feature, in order to discharge the application capacitor connected on OUT pin.When EN pin is set to low level (disable state), a discharge resistance with a typical value of 276Ω (AW35122: 75Ω)is connected between the output and ground, pull down the output and prevent it from floating when the device is disabled.</q>

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this could theoretically be worked around by manual selection of PinePhone's data and power role by the user, but hasn't been attempted, and might damage hardware if done incorrectly.

== Workaround ==

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles.

=== Tradeoffs ===
Voiding the VCONN control might (TODO: gather more data) prevent some accessories from working, notably those using an active cable.

== Proper fix ==

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

PCBA revision 1.2a onwards should incorporate that fix. (TODO: confirm this).

== Sources and tutorials ==
* [https://megous.com/dl/tmp/pp-usbc-fix.jpg megi's writeup]
* [https://xnux.eu/devices/feature/anx7688.html xnux's writeup] with a few words on firmware
* [https://www.youtube.com/watch?v=xf8OJtjNWUM Video: "The right way"] with a hot air gun/reflow station, by mozzwald
* [https://www.youtube.com/watch?v=ZqOb45N2sMc Vdeo: "The equally stupid way"], workaround video by Dalton, using a soldering iron. Less chances to permanently damage the board than the next if you are handy with a soldering iron, but still high.
* [https://www.youtube.com/watch?v=j3jc7Mvn9Eo Video: "The stupid way"] workaround video by Lukasz, with pliers. Slightly damages the circuit board, preventing you from soldering the replacement chips at a later point. You might be fine with this.

PinePhone v1.1 - Braveheart

2020-07-30T18:16:33Z

M@yeulC:

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone that shipped in January 2020.

This page contains resources which are exclusive to the 1.1 revision of the PinePhone. For other revisions, or for resources related to all PinePhone revisions, see [[PinePhone]].

== Schematic ==

[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]

== Changes from 1.0 ==

Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.

# Added CPU shielding and cover plate
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot
# Connect WiFi enable to VD33
# Set the EG25G's PWRKEY on by default (see resistor R1526)
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.
# Add voltage shift to Pogo pins I2C-CLK, I2C-DATA, and INT. The Pogo Pin specified voltage is 3.3v while the A64's I2C is 2.8V.
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential

== DIY Hardware fixes ==
Some of the known issues can be fixed with more or less involved hardware modifications:
* USB-C CC pins are pulled to GND: [[PinePhone_1.2_VCONN_Hardware_Fix| Removing small switches]] can make USB OTG work.A proper fix is to replace those with another component.

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision. Most of these were fixed in the 1.2 revision mainboard.

=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===

''Resolved in v1.2 by PL6 being connected directly to the modem, instead of through the level shifter, so it is pulled low at boot.''

To load the correct device tree, there needs to be some hardware feature that can distinguish the two versions. This can be as simple as an I/O pin that is pulled differently by default between v1.1 and v1.2. Reading the pin in SPL will tell us which device tree to use.

=== WiFi module cannot be disabled or reset in software ===

''Resolved in v1.2 by connecting PL2 to the WiFi module's WiFi reset pin.''

Neither the <tt>WL-REG-ON</tt> nor <tt>WL-PMU-EN</tt> signal is connected to anything, and the WiFi module's <tt>CHIP_EN</tt> pin is connected (through the killswitch) to a regulator that cannot be turned off (easily, if at all). So while the killswitch works, there's no way to disable the WiFi module in software. This will lead to excess power consumption when WiFi is turned off.

=== Magnetometer's IRQ signal is routed to the wrong pin ===

''Resolved in v1.2 by connecting the magnetometer's <tt>DRDY</tt> pin to PB1.''

It needs to go to DRDY, not to INT. The kernel driver expects the trigger events to be fired when DRDY changes, and does not even configure the interrupts to be enabled on the INT pin.

Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.

=== Speaker output could be differential ===

''Resolved in v1.2 by connecting <tt>LINEOUTP</tt> to the speaker amplifier's <tt>INP</tt> input.''

Using a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.

=== Modem AP_READY signal is not connected ===

''Resolved in v1.2 by connecting PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>.''

The [https://www.quectel.com/UploadImage/Downlad/Quectel_EC2x&EG9x_Power_Management_Application_Note_V1.0.pdf modem's power management documentation] describes how to implement modem power saving. The modem can wake up the host using either the Ring Indicator pin (section 4.5) or USB remote wakeup (section 4.3). Either way, it suggests the <tt>AP_READY</tt> signal needs to be connected. The modem needs that signal to know when the host is asleep (and the modem needs to queue its messages and wake it up), and when the host has finished waking up (and is ready to receive the queued messages).

=== Modem RI signal routing prevents wakeup ===

''Resolved in v1.2 by connecting <tt>RI</tt> to PL6.''

The EG25G's Ring Indicator (RI) pin is currently routed to GPIO pin PB2. The A64 needs to receive interrupts via this pin while suspended, so the modem can wake up the A64 (for incoming calls and text messages). The only GPIO bank that can receive interrupts while the A64 is suspended is Port L (on <tt>R_PIO</tt>).

'''Note''': Port L is powered by VCC-PL, and runs at 1v8, so it should ''not'' have a level shift to DCDC1/3v3 between the AP and the modem, like DTR currently has. The way DTR is currently connected is a bug.

=== Excess power usage while driving VBUS ===

''Resolved in v1.2 by connecting PL9 and <tt>VBUS_CTRL</tt> on the ANX7688 to <tt>N_VBUSEN</tt> on the PMIC.''

The <tt>N_VBUSEN/DRIVEVBUS</tt> input on the AXP803 PMIC, labeled <tt>USB-DRVVBUS</tt> on the schematic, is not connected to the USB OTG boost regulator enable input, because R1300 is marked "NC". This prevents the AXP803 from automatically detecting when the USB port is being powered from the battery. Thus, the PMIC continues to draw power from the USB port, and this doubles the drain on the battery (since the whole phone is being powered by the USB OTG boost regulator). This could be fixed by populating R1300.

The ANX7688's VBUS_CTRL pin should also be connected to the DRVVBUS signal to perform role switching in hardware without needing OS interaction. In that case PD6 becomes an input. Otherwise, we would need to hook up the VBUS status change interrupt from the ANX7688 to control the USB PHY driver.

=== ANX7688 power supply situation is problematic ===

''Resolved in v1.2 by powering always-on 3v3 from DCDC1, video-related 3v3 from DLDO1, 1v8 from GPIO-LDO1, and 1v0 controlled by PD11.''

ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).
* The main 3v3 input, to AVDD33, should always be on according to the datasheet. For this reason, it should be connected to an always-on regulator, such as DCDC1, so DLDO1 can be turned off when the screen is off. It has extremely low power consumption.
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.
* The only other 3v3 consumer is the VCONN_EN pull-ups. These could be pulled to GPIO1-LDO (1.8V) instead; the pins are open drain.
* The DVDD18 input should also always be on according to the datasheet. It has extremely low power consumption. I recommend connecting it and the PL11 pull-up to VCC-PL, so GPIO1-LDO can be turned off.
* The remaining 1v8 inputs only need to be enabled when a USB cable is connected (supply or OTG). They are connected to their own regulator (GPIO1-LDO), so that is fine. (Note that the next issue suggests removing the pull-ups for POWER_EN and RESET_N.)
* The 1v0 input is only needed when a USB cable is connected (supply or OTG). It is currently controlled by DLDO1, but I think controlling it with GPIO1-LDO would be an improvement. That way DLDO1 only needs to be enabled when transmitting video, not always when a cable is connected.

=== Modem PWR_KEY signal resistor population ===

''Resolved in v1.2 by separating the modem <tt>PWRKEY</tt> (PB3) and <tt>STATUS</tt> (PH9) signals.''

On the dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can't do anything to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).

It would be nice to also have access to the STATUS signal from the modem, so that the driver can detect whether the modem is on or off (userspace might have turned modem off already via AT commands). Given that PWR_KEY pulse will either turn the modem on or off, based on the current status, it's necessary to know the current status before sending the pulse.

There's a STATUS signal routed to PWR_KEY on BraveHeart, that keeps the PWRKEY deasserted when the modem is on and it's not possible to pull it up from PB3, even if R1516 would be optionally mounted.

So after powerup you can't change PWR_KEY signal anymore from PB3 even if R1516 is mounted, and it's not possible to turn off the modem via PB3.

=== Modem has access to sensors on I2C1 ===

''Resolved in v1.2 by disconnecting the modem's I2C port.''

The modem is a master on the I2C1 bus. A malicious firmware on the modem would be able to read the phone's gravity/light/proximity sensors and prevent the main Linux OS from reading them. The [https://www.quectel.com/UploadImage/Downlad/Quectel_WCDMA&LTE_Audio_Design_Note_V1.1.pdf modem's audio design note] describes the <tt>AT+QIIC</tt> command which can be used to read and write registers on I2C devices.

According to the modem documentation, its I2C interface is only used for direct connection to a standalone audio codec. On the PinePhone, since the modem's audio is routed through the A64 SoC, the modem's I2C interface has no legitimate use.

The modem's I2C interface should be left floating. U1503 pins A1, A2, B1, and B2 can be disconnected, and R1527/R1528 can be removed.

=== Allow access the modem debug UART ===

''Not resolved in v1.2 -- would have required moving several other GPIOs.''

Instead of the modem's I2C pins, which aren't very useful (see above), it would be great to have access to the modem's debug UART, for debugging/updating the modem. This could be on UART3 (PD0-PD1, no flow control), while the main modem UART is on UART4 (PD2-PD5, with flow control).

=== Modem UART flow control is broken ===

''Not resolved in v1.2 -- assumption is that USB will be used for high-bandwidth modem I/O.''

BB-TX and BB-RX are connected to UART3 (PD0/PD1). BB-RTS and BB-CTS are connected to UART4 (PD4/PD5). To use hardware flow control, TX/RX would need to be connected to UART4, swapping PD0/PD1 with the motor control and rear camera reset GPIOs at PD2/PD3. This would need a device tree change.

Hardware flow control can be disabled with the <tt>AT+IFC</tt> command, and USB can also be used for commands instead of the UART. So the impact of this problem is unclear.

=== ANX7688 power/reset control pulled the wrong way ===

''Not resolved in v1.2 -- this has minimal impact.''

Both <tt>ANX_POWER_EN</tt> and <tt>ANX_RESET_N</tt> have pull-ups when they should not. Both signals need to be pulled low by default. They only need to be brought high (turning the chip on) when a USB cable is attached; and they should only be brought high after the 1v8 and 1v0 regulators are turned on. <tt>ANX_POWER_EN</tt> needs an external pull-down. <tt>ANX_RESET_N</tt> has an internal pull-down.

=== VCONN_EN signals are possibly inverted ===

''Further investigation determined that the hardware is correct as-is in v1.1, so no change was made.''

I don't have a datasheet for the AW3512 chips, but I assume the enable input is active-high. VCONN1_EN and VCONN2_EN are open-drain. When they are open, it appears that VCONN should be enabled. But right now, when they are open, VCONN is disabled, because the AW3512 EN pin will be pulled low by the FET.

=== Cameras have the same default I2C address ===

''Resolved in software by reprogramming the one of the cameras' I2C addresses at boot.''

This makes it hard to keep both of them powered at the same time and switch quickly between them (on the per-frame basis) without having to re-initialize the sensors on each switch, which takes some time.

=== USB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off ===

'''This issue is also present on the PinePhone 1.2 (CE) version.''' It was fixed with revision 1.2a. [[PinePhone_1.2_VCONN_Hardware_Fix|See the workaround]].

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this can only be worked around by manual selection of PinePhone's data and power role by the user.

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles. I confirmed that desoldering fixes the issue. (Howto: https://megous.com/dl/tmp/pp-usbc-fix.jpg)

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

=== Pogo Pins supply 5v0, not 3v3 ===

''No hardware change suggested, to maintain accessory compatibility.''

This is possibly just a documentation issue. [https://wiki.pine64.org/index.php/PinePhone#Pogo_Pins The wiki claims] they provide a "3.3v power source", and on this page, "The Pogo Pin specified voltage is 3.3v". But according to the schematic, they are connected to <tt>USB-5V</tt>, the output of the 5V boost regulator.

PinePhone v1.1 - Braveheart

2020-07-30T18:07:02Z

M@yeulC: /* USB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off */ Add link to workaround page

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone that shipped in January 2020.

This page contains resources which are exclusive to the 1.1 revision of the PinePhone. For other revisions, or for resources related to all PinePhone revisions, see [[PinePhone]].

== Schematic ==

[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]

== Changes from 1.0 ==

Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.

# Added CPU shielding and cover plate
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot
# Connect WiFi enable to VD33
# Set the EG25G's PWRKEY on by default (see resistor R1526)
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.
# Add voltage shift to Pogo pins I2C-CLK, I2C-DATA, and INT. The Pogo Pin specified voltage is 3.3v while the A64's I2C is 2.8V.
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision. Most of these were fixed in the 1.2 revision mainboard.

=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===

''Resolved in v1.2 by PL6 being connected directly to the modem, instead of through the level shifter, so it is pulled low at boot.''

To load the correct device tree, there needs to be some hardware feature that can distinguish the two versions. This can be as simple as an I/O pin that is pulled differently by default between v1.1 and v1.2. Reading the pin in SPL will tell us which device tree to use.

=== WiFi module cannot be disabled or reset in software ===

''Resolved in v1.2 by connecting PL2 to the WiFi module's WiFi reset pin.''

Neither the <tt>WL-REG-ON</tt> nor <tt>WL-PMU-EN</tt> signal is connected to anything, and the WiFi module's <tt>CHIP_EN</tt> pin is connected (through the killswitch) to a regulator that cannot be turned off (easily, if at all). So while the killswitch works, there's no way to disable the WiFi module in software. This will lead to excess power consumption when WiFi is turned off.

=== Magnetometer's IRQ signal is routed to the wrong pin ===

''Resolved in v1.2 by connecting the magnetometer's <tt>DRDY</tt> pin to PB1.''

It needs to go to DRDY, not to INT. The kernel driver expects the trigger events to be fired when DRDY changes, and does not even configure the interrupts to be enabled on the INT pin.

Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.

=== Speaker output could be differential ===

''Resolved in v1.2 by connecting <tt>LINEOUTP</tt> to the speaker amplifier's <tt>INP</tt> input.''

Using a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.

=== Modem AP_READY signal is not connected ===

''Resolved in v1.2 by connecting PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>.''

The [https://www.quectel.com/UploadImage/Downlad/Quectel_EC2x&EG9x_Power_Management_Application_Note_V1.0.pdf modem's power management documentation] describes how to implement modem power saving. The modem can wake up the host using either the Ring Indicator pin (section 4.5) or USB remote wakeup (section 4.3). Either way, it suggests the <tt>AP_READY</tt> signal needs to be connected. The modem needs that signal to know when the host is asleep (and the modem needs to queue its messages and wake it up), and when the host has finished waking up (and is ready to receive the queued messages).

=== Modem RI signal routing prevents wakeup ===

''Resolved in v1.2 by connecting <tt>RI</tt> to PL6.''

The EG25G's Ring Indicator (RI) pin is currently routed to GPIO pin PB2. The A64 needs to receive interrupts via this pin while suspended, so the modem can wake up the A64 (for incoming calls and text messages). The only GPIO bank that can receive interrupts while the A64 is suspended is Port L (on <tt>R_PIO</tt>).

'''Note''': Port L is powered by VCC-PL, and runs at 1v8, so it should ''not'' have a level shift to DCDC1/3v3 between the AP and the modem, like DTR currently has. The way DTR is currently connected is a bug.

=== Excess power usage while driving VBUS ===

''Resolved in v1.2 by connecting PL9 and <tt>VBUS_CTRL</tt> on the ANX7688 to <tt>N_VBUSEN</tt> on the PMIC.''

The <tt>N_VBUSEN/DRIVEVBUS</tt> input on the AXP803 PMIC, labeled <tt>USB-DRVVBUS</tt> on the schematic, is not connected to the USB OTG boost regulator enable input, because R1300 is marked "NC". This prevents the AXP803 from automatically detecting when the USB port is being powered from the battery. Thus, the PMIC continues to draw power from the USB port, and this doubles the drain on the battery (since the whole phone is being powered by the USB OTG boost regulator). This could be fixed by populating R1300.

The ANX7688's VBUS_CTRL pin should also be connected to the DRVVBUS signal to perform role switching in hardware without needing OS interaction. In that case PD6 becomes an input. Otherwise, we would need to hook up the VBUS status change interrupt from the ANX7688 to control the USB PHY driver.

=== ANX7688 power supply situation is problematic ===

''Resolved in v1.2 by powering always-on 3v3 from DCDC1, video-related 3v3 from DLDO1, 1v8 from GPIO-LDO1, and 1v0 controlled by PD11.''

ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).
* The main 3v3 input, to AVDD33, should always be on according to the datasheet. For this reason, it should be connected to an always-on regulator, such as DCDC1, so DLDO1 can be turned off when the screen is off. It has extremely low power consumption.
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.
* The only other 3v3 consumer is the VCONN_EN pull-ups. These could be pulled to GPIO1-LDO (1.8V) instead; the pins are open drain.
* The DVDD18 input should also always be on according to the datasheet. It has extremely low power consumption. I recommend connecting it and the PL11 pull-up to VCC-PL, so GPIO1-LDO can be turned off.
* The remaining 1v8 inputs only need to be enabled when a USB cable is connected (supply or OTG). They are connected to their own regulator (GPIO1-LDO), so that is fine. (Note that the next issue suggests removing the pull-ups for POWER_EN and RESET_N.)
* The 1v0 input is only needed when a USB cable is connected (supply or OTG). It is currently controlled by DLDO1, but I think controlling it with GPIO1-LDO would be an improvement. That way DLDO1 only needs to be enabled when transmitting video, not always when a cable is connected.

=== Modem PWR_KEY signal resistor population ===

''Resolved in v1.2 by separating the modem <tt>PWRKEY</tt> (PB3) and <tt>STATUS</tt> (PH9) signals.''

On the dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can't do anything to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).

It would be nice to also have access to the STATUS signal from the modem, so that the driver can detect whether the modem is on or off (userspace might have turned modem off already via AT commands). Given that PWR_KEY pulse will either turn the modem on or off, based on the current status, it's necessary to know the current status before sending the pulse.

There's a STATUS signal routed to PWR_KEY on BraveHeart, that keeps the PWRKEY deasserted when the modem is on and it's not possible to pull it up from PB3, even if R1516 would be optionally mounted.

So after powerup you can't change PWR_KEY signal anymore from PB3 even if R1516 is mounted, and it's not possible to turn off the modem via PB3.

=== Modem has access to sensors on I2C1 ===

''Resolved in v1.2 by disconnecting the modem's I2C port.''

The modem is a master on the I2C1 bus. A malicious firmware on the modem would be able to read the phone's gravity/light/proximity sensors and prevent the main Linux OS from reading them. The [https://www.quectel.com/UploadImage/Downlad/Quectel_WCDMA&LTE_Audio_Design_Note_V1.1.pdf modem's audio design note] describes the <tt>AT+QIIC</tt> command which can be used to read and write registers on I2C devices.

According to the modem documentation, its I2C interface is only used for direct connection to a standalone audio codec. On the PinePhone, since the modem's audio is routed through the A64 SoC, the modem's I2C interface has no legitimate use.

The modem's I2C interface should be left floating. U1503 pins A1, A2, B1, and B2 can be disconnected, and R1527/R1528 can be removed.

=== Allow access the modem debug UART ===

''Not resolved in v1.2 -- would have required moving several other GPIOs.''

Instead of the modem's I2C pins, which aren't very useful (see above), it would be great to have access to the modem's debug UART, for debugging/updating the modem. This could be on UART3 (PD0-PD1, no flow control), while the main modem UART is on UART4 (PD2-PD5, with flow control).

=== Modem UART flow control is broken ===

''Not resolved in v1.2 -- assumption is that USB will be used for high-bandwidth modem I/O.''

BB-TX and BB-RX are connected to UART3 (PD0/PD1). BB-RTS and BB-CTS are connected to UART4 (PD4/PD5). To use hardware flow control, TX/RX would need to be connected to UART4, swapping PD0/PD1 with the motor control and rear camera reset GPIOs at PD2/PD3. This would need a device tree change.

Hardware flow control can be disabled with the <tt>AT+IFC</tt> command, and USB can also be used for commands instead of the UART. So the impact of this problem is unclear.

=== ANX7688 power/reset control pulled the wrong way ===

''Not resolved in v1.2 -- this has minimal impact.''

Both <tt>ANX_POWER_EN</tt> and <tt>ANX_RESET_N</tt> have pull-ups when they should not. Both signals need to be pulled low by default. They only need to be brought high (turning the chip on) when a USB cable is attached; and they should only be brought high after the 1v8 and 1v0 regulators are turned on. <tt>ANX_POWER_EN</tt> needs an external pull-down. <tt>ANX_RESET_N</tt> has an internal pull-down.

=== VCONN_EN signals are possibly inverted ===

''Further investigation determined that the hardware is correct as-is in v1.1, so no change was made.''

I don't have a datasheet for the AW3512 chips, but I assume the enable input is active-high. VCONN1_EN and VCONN2_EN are open-drain. When they are open, it appears that VCONN should be enabled. But right now, when they are open, VCONN is disabled, because the AW3512 EN pin will be pulled low by the FET.

=== Cameras have the same default I2C address ===

''Resolved in software by reprogramming the one of the cameras' I2C addresses at boot.''

This makes it hard to keep both of them powered at the same time and switch quickly between them (on the per-frame basis) without having to re-initialize the sensors on each switch, which takes some time.

=== USB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off ===

'''This issue is also present on the PinePhone 1.2 (CE) version.''' It was fixed with revision 1.2a. [[PinePhone_1.2_VCONN_Hardware_Fix|See the workaround]].

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this can only be worked around by manual selection of PinePhone's data and power role by the user.

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles. I confirmed that desoldering fixes the issue. (Howto: https://megous.com/dl/tmp/pp-usbc-fix.jpg)

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

=== Pogo Pins supply 5v0, not 3v3 ===

''No hardware change suggested, to maintain accessory compatibility.''

This is possibly just a documentation issue. [https://wiki.pine64.org/index.php/PinePhone#Pogo_Pins The wiki claims] they provide a "3.3v power source", and on this page, "The Pogo Pin specified voltage is 3.3v". But according to the schematic, they are connected to <tt>USB-5V</tt>, the output of the 5V boost regulator.

PinePhone 1.2 VCONN Hardware Fix

2020-07-30T18:05:19Z

M@yeulC:

This page details a hardware fix for an issue that affects some early PinePhone units (fixed since 1.2a included).

The issue was [[PinePhone_v1.1_-_Braveheart#USB-C_CC_pins_are_pulled_to_the_GND_by_AW3512_.28VCONN_switches.29_when_VCONN_is_off | originally reported here]] by megi.

TODO: Add more pictures and schematics, better reference the fix origin and tradeofs, remove TODOs/FIXMEs.

== Affected Units ==
# (FIXME confirm this) [[Project Don't be evil|"Project Don't Be Evil" devkit]]
# (FIXME confirm this)[[PinePhone v1.0 - Dev|PinePhone v1.0 - Developer batch]]
# [[PinePhone v1.1 - Braveheart]]
# [[PinePhone v1.2‎]] - Community Edition

== Disclaimer ==

This fix requires desoldering tiny (1 mm per 1 mm, from the datasheet) BGA components, therefore some experience with soldering is highly recommended.

== Issue description ==
[[File:Martjin_VCONN_switches_1.1.jpg|thumb|frame|Close-up picture of the two identical switches the issue originates from, with the ANX USB controller in the frame]]

[[File:Schematic_VCONN_switches.png|thumb|frame|Excerpt from the PinePhone schematic showing the two components.]]

The USB standard [https://microchipdeveloper.com/usb:tc-pins specifies] that both halves (top and bottom) of the USB-C port contains one "CC" pin (CC1 and CC2, respectively). A regular cable will connect a CC pin from one end to the other end. This allows detecting which way the cable is plugged. Some active USB-C cables exist (both "e-marked" and "managed active cables"); they contain a chip, which needs to be powered. This is done by having one of the cable end connect its CC pins to 5V and VCONN, and requires switches to plug the right CC pin to the right voltage.

The issue arises due to the switches that were chosen up to v1.2a (the a revision excluded) of the PCB assembly: the [https://www.awinic.com/cn/index/pageview/catid/122/id/2.html infamous AW3512], labelled U1305 and U1309 on the schematic. Instead of leaving the output pin "dangling" with a high impedance when disabled, the switch pull the output down. This feature is intended for discharging a capacitor, hence its "Quick output discharge" name. This is an excerpt from the datasheet:

<q> The AW3512/AW35122 includes the Quick Output Discharge (QOD) feature, in order to discharge the application capacitor connected on OUT pin.When EN pin is set to low level (disable state), a discharge resistance with a typical value of 276Ω (AW35122: 75Ω)is connected between the output and ground, pull down the output and prevent it from floating when the device is disabled.</q>

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this could theoretically be worked around by manual selection of PinePhone's data and power role by the user, but hasn't been attempted, and might damage hardware if done incorrectly.

== Workaround ==

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles.

=== Tradeoffs ===
Voiding the VCONN control might (TODO: gather more data) prevent some accessories from working, notably those using an active cable.

== Proper fix ==

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

PCBA revision 1.2a onwards should incorporate that fix. (TODO: confirm this).

== Sources and tutorials ==
* [https://megous.com/dl/tmp/pp-usbc-fix.jpg megi's writeup]
* [https://www.youtube.com/watch?v=xf8OJtjNWUM Video: "The right way"] with a hot air gun/reflow station, by mozzwald
* [https://www.youtube.com/watch?v=ZqOb45N2sMc Vdeo: "The equally stupid way"], workaround video by Dalton, using a soldering iron. Less chances to permanently damage the board than the next if you are handy with a soldering iron, but still high.
* [https://www.youtube.com/watch?v=j3jc7Mvn9Eo Video: "The stupid way"] workaround video by Lukasz, with pliers. Slightly damages the circuit board, preventing you from soldering the replacement chips at a later point. You might be fine with this.

PinePhone 1.2 VCONN Hardware Fix

2020-07-30T18:02:59Z

M@yeulC: /* Sources and tutorials */ clarify which are workaround videos

This page details a hardware fix for an issue that affects some early PinePhone units (fixed since 1.2a included).

TODO: Add more pictures and schematics, better reference the fix origin and tradeofs, remove TODOs/FIXMEs.

== Affected Units ==
# (FIXME confirm this) [[Project Don't be evil|"Project Don't Be Evil" devkit]]
# (FIXME confirm this)[[PinePhone v1.0 - Dev|PinePhone v1.0 - Developer batch]]
# [[PinePhone v1.1 - Braveheart]]
# [[PinePhone v1.2‎]] - Community Edition

== Disclaimer ==

This fix requires desoldering tiny (1 mm per 1 mm, from the datasheet) BGA components, therefore some experience with soldering is highly recommended.

== Issue description ==
[[File:Martjin_VCONN_switches_1.1.jpg|thumb|frame|Close-up picture of the two identical switches the issue originates from, with the ANX USB controller in the frame]]

[[File:Schematic_VCONN_switches.png|thumb|frame|Excerpt from the PinePhone schematic showing the two components.]]

The USB standard [https://microchipdeveloper.com/usb:tc-pins specifies] that both halves (top and bottom) of the USB-C port contains one "CC" pin (CC1 and CC2, respectively). A regular cable will connect a CC pin from one end to the other end. This allows detecting which way the cable is plugged. Some active USB-C cables exist (both "e-marked" and "managed active cables"); they contain a chip, which needs to be powered. This is done by having one of the cable end connect its CC pins to 5V and VCONN, and requires switches to plug the right CC pin to the right voltage.

The issue arises due to the switches that were chosen up to v1.2a (the a revision excluded) of the PCB assembly: the [https://www.awinic.com/cn/index/pageview/catid/122/id/2.html infamous AW3512], labelled U1305 and U1309 on the schematic. Instead of leaving the output pin "dangling" with a high impedance when disabled, the switch pull the output down. This feature is intended for discharging a capacitor, hence its "Quick output discharge" name. This is an excerpt from the datasheet:

<q> The AW3512/AW35122 includes the Quick Output Discharge (QOD) feature, in order to discharge the application capacitor connected on OUT pin.When EN pin is set to low level (disable state), a discharge resistance with a typical value of 276Ω (AW35122: 75Ω)is connected between the output and ground, pull down the output and prevent it from floating when the device is disabled.</q>

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this could theoretically be worked around by manual selection of PinePhone's data and power role by the user, but hasn't been attempted, and might damage hardware if done incorrectly.

== Workaround ==

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles.

=== Tradeoffs ===
Voiding the VCONN control might (TODO: gather more data) prevent some accessories from working, notably those using an active cable.

== Proper fix ==

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

PCBA revision 1.2a onwards should incorporate that fix. (TODO: confirm this).

== Sources and tutorials ==
* [https://megous.com/dl/tmp/pp-usbc-fix.jpg megi's writeup]
* [https://www.youtube.com/watch?v=xf8OJtjNWUM Video: "The right way"] with a hot air gun/reflow station, by mozzwald
* [https://www.youtube.com/watch?v=ZqOb45N2sMc Vdeo: "The equally stupid way"], workaround video by Dalton, using a soldering iron. Less chances to permanently damage the board than the next if you are handy with a soldering iron, but still high.
* [https://www.youtube.com/watch?v=j3jc7Mvn9Eo Video: "The stupid way"] workaround video by Lukasz, with pliers. Slightly damages the circuit board, preventing you from soldering the replacement chips at a later point. You might be fine with this.

PinePhone 1.2 VCONN Hardware Fix

2020-07-30T18:01:55Z

M@yeulC: Create page

This page details a hardware fix for an issue that affects some early PinePhone units (fixed since 1.2a included).

TODO: Add more pictures and schematics, better reference the fix origin and tradeofs, remove TODOs/FIXMEs.

== Affected Units ==
# (FIXME confirm this) [[Project Don't be evil|"Project Don't Be Evil" devkit]]
# (FIXME confirm this)[[PinePhone v1.0 - Dev|PinePhone v1.0 - Developer batch]]
# [[PinePhone v1.1 - Braveheart]]
# [[PinePhone v1.2‎]] - Community Edition

== Disclaimer ==

This fix requires desoldering tiny (1 mm per 1 mm, from the datasheet) BGA components, therefore some experience with soldering is highly recommended.

== Issue description ==
[[File:Martjin_VCONN_switches_1.1.jpg|thumb|frame|Close-up picture of the two identical switches the issue originates from, with the ANX USB controller in the frame]]

[[File:Schematic_VCONN_switches.png|thumb|frame|Excerpt from the PinePhone schematic showing the two components.]]

The USB standard [https://microchipdeveloper.com/usb:tc-pins specifies] that both halves (top and bottom) of the USB-C port contains one "CC" pin (CC1 and CC2, respectively). A regular cable will connect a CC pin from one end to the other end. This allows detecting which way the cable is plugged. Some active USB-C cables exist (both "e-marked" and "managed active cables"); they contain a chip, which needs to be powered. This is done by having one of the cable end connect its CC pins to 5V and VCONN, and requires switches to plug the right CC pin to the right voltage.

The issue arises due to the switches that were chosen up to v1.2a (the a revision excluded) of the PCB assembly: the [https://www.awinic.com/cn/index/pageview/catid/122/id/2.html infamous AW3512], labelled U1305 and U1309 on the schematic. Instead of leaving the output pin "dangling" with a high impedance when disabled, the switch pull the output down. This feature is intended for discharging a capacitor, hence its "Quick output discharge" name. This is an excerpt from the datasheet:

<q> The AW3512/AW35122 includes the Quick Output Discharge (QOD) feature, in order to discharge the application capacitor connected on OUT pin.When EN pin is set to low level (disable state), a discharge resistance with a typical value of 276Ω (AW35122: 75Ω)is connected between the output and ground, pull down the output and prevent it from floating when the device is disabled.</q>

This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There's no SW workaround for automatic detection of cable plug or power role.

In SW this could theoretically be worked around by manual selection of PinePhone's data and power role by the user, but hasn't been attempted, and might damage hardware if done incorrectly.

== Workaround ==

HW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles.

=== Tradeoffs ===
Voiding the VCONN control might (TODO: gather more data) prevent some accessories from working, notably those using an active cable.

== Proper fix ==

HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn't have the "quick discharge function" that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.

PCBA revision 1.2a onwards should incorporate that fix. (TODO: confirm this).

== Sources and tutorials ==
* [https://megous.com/dl/tmp/pp-usbc-fix.jpg megi's writeup]
* [https://www.youtube.com/watch?v=xf8OJtjNWUM Video: "The right way"] with a hot air gun/reflow station, by mozzwald
* [https://www.youtube.com/watch?v=ZqOb45N2sMc Vdeo: "The equally stupid way"], by Dalton, using a soldering iron. Less chances to permanently damage the board than the next if you are handy with a soldering iron, but still high.
* [https://www.youtube.com/watch?v=j3jc7Mvn9Eo Video: "The stupid way"] by Lukasz, with pliers. Slightly damages the circuit board, preventing you from soldering the replacement chips at a later point. You might be fine with this.

File:Schematic VCONN switches.png

2020-07-30T17:57:32Z

M@yeulC: Excerpt from the PinePhone schematic showing switches that need to be replaced prior to PCB revision 1.2a

== Summary ==
Excerpt from the PinePhone schematic showing switches that need to be replaced prior to PCB revision 1.2a
== Licensing ==
{{CC0}}

File:Martjin VCONN switches 1.1.jpg

2020-07-30T17:47:45Z

M@yeulC: Close-up of the VCONN switches that need to be replaced on PinePhone models prior to 1.2a to enable some USB functionality. Picture taken by MartijnBraam on 2020-06-09.

== Summary ==
Close-up of the VCONN switches that need to be replaced on PinePhone models prior to 1.2a to enable some USB functionality.

Picture taken by MartijnBraam on 2020-06-09.
== Licensing ==
{{CC0}}

PinePhone

2020-02-21T13:25:24Z

M@yeulC: /* Datasheets for Components and Peripherals */ Link modem AT command manual

The PinePhone is a smartphone created by Pine64, capable of running mainline Linux and supported by many partner projects. The "BraveHeart" edition was the first publicly-available version of the phone, though it came without a fully functional OS (factory test image) and was geared specifically towards tinkerers and hackers. People looking for a stable consumer-grade phone should wait for the final release, which is expected to occur in March 2020 and will be available for at least five years.

== "BraveHeart" PinePhone Unboxing and First Time Preparation Guide ==

From the factory the battery has a sticker on it that isolates the battery from the phone. The battery '''will not''' charge until this is removed.

After unboxing remove the back panel. Then remove the battery and peel off the clear plastic below it that isolates the charging contact. Then replace the battery.

If you power on the phone the factory test image will boot. RTL8723CS (WiFi modem) will fail unless there is a WiFi network in range for it to see and the battery is charged. EG25 will fail until battery is changed.

By default there is no true OS image installed on Braveheart phones. An SD card with a bootable image needs to be inserted into the phone. See section 12 below for a list of OS options. Note the SD and sim sockets are stacked on each other The SD slot is the "shallower" socket and the SIM card goes in the "deeper" socket.

'''Some videos that illustrate the process:'''

[https://www.youtube.com/watch?v=ACcxegtDVBI Excellent first time guide video from Rob Braxman Tech]

[https://www.youtube.com/watch?v=Z0FMW72_OYcI Flash an OS to microSD card video from Rob Braxman Tech]

== Specifications ==

'''Dimensions:''' 160.5 x 76.6 x 9.2mm 
'''Weight:''' Between 180-200 grams 
'''SIM Card:''' Micro-SIM 
'''Display:'''
: '''Size:''' 5.95 inches (151mm) diagonal
: '''Type:''' HD IPS capacitive touchscreen, 16M colors
: '''Resolution:''' 1440x720, 18:9 ratio 
'''System on Chip:''' [https://linux-sunxi.org/A64 Allwinner A64] 
'''RAM:''' 2GB LPDDR3 SDRAM 
'''Internal Storage:''' 16GB eMMC, extendable up to 2TB via microSD, supports SDHC and SDXC 
'''Back Camera:''' Single 5MP, 1/4", LED Flash 
'''Selfie Camera:''' Single 2MP, f/2.8, 1/5" 
'''Sound:''' Loudspeaker, 3.5mm jack & mic (jack doubles as hardware UART if killswitch 6 is deactivated) 
'''Communication: [http://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EG25-G_LTE_Specification_V1.1_Preliminary_20180522%20(002).pdf EG25-G]'''
: '''LTE:''' B1, B2, B3, B4, B5, B7, B8, B12, B13, B18, B19, B20, B25, B26, B28, B38, B39, B40, B41
: '''WCDMA:''' B1, B2, B4, B5, B6, B8, B19
: '''GSM:''' 850, 900, 1800, 1900 (MHz)
: '''WLAN:''' Wi-Fi 802.11 b/g/n, single-band, hotspot
: '''Bluetooth:''' 4.0, A2DP
: '''GNSS:''' GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS
'''Sensors:''' Accelerometer, gyro, proximity, ambient light, compass 
'''[[#Killswitch configuration|Killswitches]]:''' Modem, Wifi & Bluetooth, Microphone, Cameras 
'''[[#Battery|Battery]]:''' [https://wiki.pine64.org/images/0/04/PinePhone_Battery_model_QZ01-396172-2750.pdf Lithium ion] Rated Capacity 2800mAh (10.64Wh), Typical Capacity 3000mAh (11.40Wh) (nominally replaceable with any Samsung J7 form-factor battery) 
'''I/O:''' USB Type-C (SlimPort), USB Host, DisplayPort Alternate Mode output, 15W 5V 3A Quick Charge, follows USB PD specification

== PinePhone Board Information, Schematics and Certifications ==
* PinePhone Main Board Schematic:
** [http://files.pine64.org/doc/PinePhone/PinePhone%20Schematic%20v1.1%2020191031.pdf "Braveheart" PinePhone mainboard Schematic ver 1.1]
** [http://files.pine64.org/doc/PinePhone/PinePhone%20mainboard%20top%20placement%20v1.1%2020191031.pdf "Braveheart" PinePhone mainboard component top placement drawing ver 1.1]
** [http://files.pine64.org/doc/PinePhone/PinePhone%20mainboard%20bottom%20placement%20v1.1%2020191031.pdf "Braveheart" PinePhone mainboard component bottom placement drawing ver 1.1]
* PinePhone USB-C Small Board Schematic:
** [http://files.pine64.org/doc/PinePhone/PinePhone%20USB-C%20small%20board%20schematic%20v1.0%2020190730.pdf "Braveheart" PinePhone USB-C small board Schematic ver 1.0]
** [http://files.pine64.org/doc/PinePhone/PinePhone%20USB-C%20small%20board%20top%20placement%20v1.0%2020190730.pdf "Braveheart" PinePhone USB-C small board component top placement drawing ver 1.0]
** [http://files.pine64.org/doc/PinePhone/PinePhone%20USB-C%20small%20board%20bottom%20placement%20v1.0%2020190730.pdf "Braveheart" PinePhone USB-C small board component bottom placement drawing ver 1.0]
* PINE A64 Certifications:
** Not yet available

== Datasheets for Components and Peripherals ==
* Allwinner A64 SoC information:
** [http://files.pine64.org/doc/datasheet/pine64/A64%20brief%20v1.0%2020150323.pdf Allwinner A64 SoC Brief Introduction]
** [http://files.pine64.org/doc/datasheet/pine64/A64_Datasheet_V1.1.pdf Allwinner A64 SoC Data Sheet V1.1 (Official Released Version)]
** [http://files.pine64.org/doc/datasheet/pine64/Allwinner_A64_User_Manual_V1.0.pdf Allwinner A64 SoC User Manual V1.0 (Official Release Version)]
* X-Powers AXP803 PMU (Power Management Unit) information:
** [http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf AXP803 PMIC Datasheet]
* LPDDR3 (178 Balls) SDRAM:
** [http://files.pine64.org/doc/datasheet/pinephone/ATL3A1632H12A_mobile_lpddr3_11x11.5_v1.0_1600.pdf Artmem LPDDR3 Datasheet]
* CMOS Camera module information:
** [http://files.pine64.org/doc/datasheet/pinephone/QZ01-rear-2019-0717(HW)%20Model.pdf PinePhone 5M Pixel Real CMOS Image Sensor Module]
** [http://files.pine64.org/doc/datasheet/pinephone/OV5640_datasheet.pdf OV5640 5MP CMOS Image Sensor SoC for Rear Module Datasheet]
** [http://files.pine64.org/doc/datasheet/pinephone/QZ01-front-2019-0717(HW)%20Model.pdf PinePhone 2M Pixel Front CMOS Image Sensor Module]
** [http://files.pine64.org/doc/datasheet/pinephone/GC2145%20CSP%20DataSheet%20release%20V1.0_20131201.pdf GC2145 2MP CMOS Image Sensor SoC for Front Module Datasheet]
* LCD Touch Screen Panel information:
** [http://files.pine64.org/doc/datasheet/pinephone/PinePhone%20LCD-QZ01.pdf 5.99" 1440x720 LCD IPS Panel Specification]
** [http://files.pine64.org/doc/datasheet/pinephone/ST7703_DS_v01_20160128.pdf ST7703 LCD Controller Datasheet]

** [http://files.pine64.org/doc/datasheet/pinephone/GT917S-Datasheet.pdf GOODiX GT917S Capacitive Touch Controller Datasheet]
* Lithium Battery information:
** [http://files.pine64.org/doc/datasheet/pinephone/PinePhone%20QZ01%20Battery%20Specification.pdf PinePhone Lithium Battery Specification]
** [http://files.pine64.org/doc/datasheet/pinephone/PinePhone%20QZ01%20Battery%20ZCV%20Curve%20Chart.xlsx PinePhone Lithium Battery ZCV Curve Chart]
* Wifi/BT module information:

* LTE module information:
** [http://files.pine64.org/doc/datasheet/pinephone/Quectel_EG25-G_LTE_Specification_V1.0.pdf Quectel EG25-G LTE Module Specification]
** [[Media:Quectel EC25EC21 AT Commands Manual V1.2.pdf|EC25&EC21 AT Commands Manual]]
* Sensors:
** [https://www.st.com/en/mems-and-sensors/lis3mdl.html ST LIS3MDL 3-axis Magnetomater Datasheet]
** [https://www.invensense.com/products/motion-tracking/6-axis/mpu-6050/ InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS Datasheet]
** [http://www.sensortek.com.tw/en/product/Proximity_Sensor_with_ALS.html SensorTek STK3335 Ambient Light Sensor and Proximity Sensor]
* Digital Video to USB-C Bridge:
** [https://www.analogix.com/en/system/files/AA-002281-PB-6-ANX7688_Product_Brief.pdf ANX7688 Product Brief]
* Case information:
** [http://files.pine64.org/doc/datasheet/pinephone/PinePhone%20Exploded%20Diagram%20ver%201.0.pdf PinePhone Case Exploded Diagram]
** [http://files.pine64.org/doc/datasheet/pinephone/PinePhone%20Back%20Cover.stp PinePhone Back Battery Cover 3D file]

== Developer works ==

=== Megous ===
[https://xnux.eu/howtos/pine64-pinephone-getting-started.html Getting start with PinePhone Hardware]

[https://xnux.eu/devices/pine64-pinephone.html#toc-pine64-pinephone State of development progress]

[https://xnux.eu/news.html PinePhone Technical News and Update, also applies to other Allwinner devices including PINE A64 SBC]

== Hardware Revisions ==

# [[Project Anakin]]
# [[Project Don't be evil|"Project Don't Be Evil" devkit]]
# [[PinePhone v1.0 - Dev|PinePhone v1.0 - Developer batch]]
# [[PinePhone v1.1 - Braveheart]]

== Hardware Addons ==

===[[PinePhone Hardware Accessory Compatibility]] list===
List of devices working with the PinePhone (depending on OS support)

===Pogo Pins===

The PinePhone has 6 "pogo pins" on the back allowing for custom hardware extensions such as wireless charging or an IR blaster. The pogo pins provide access to an interrupt line, power input to charge the battery, 3.3v power source, and an I2C interface.

'''A step/stl/stp (3D model) file for the back cover is [http://files.pine64.org/doc/PinePhone/PinePhone%20Back%20Cover%20ver%200.5.stp freely available] for creating custom cases that interface with the pogo pins.'''

=== Serial console ===
[[File:Uart pinephone connection.gif|250px|thumb|left|UART serial connector for PineBook and PinePhone]]
The PinePhone has a serial port in the headphone connector, it's activated by the 6th contact on the dipswitch. If the switch is on then the headphone connector is in audio mode, if it's off then it's in UART mode.

The uart is 115200n8

The pinout for the serial connector on the tablet side is:

* Tip: RX
* Ring: TX
* Sleeve: GND

The serial connection is 3.3V

You can also buy the debug cable from [https://store.pine64.org PINE64 Store]
The store cable uses a 4 ring plug, as seen in the [http://files.pine64.org/doc/pinebook/guide/Pinebook_Earphone_Serial_Console_Developer_Guide.pdf PDF], but a 3 ring plug works just as well. That cable uses a CH340 chipset based serial to USB converter, but any 3.3v serial connection can be used.

== Killswitch configuration ==

The PinePhone features six switches that can be used to configure its hardware. They are numbered 1-6, with switch 1 located nearest to the modem. Their on position is toward the top of the phone.

[[File:PinePhone switches.jpeg|600px|thumb|left|Photo of Brave Heart switches from OSAKANA TARO on Twitter]]

# Modem: On enables 2G/3G/4G communication and GNSS hardware, off disables.
# WiFi/BT: On enables Wi-Fi and Bluetooth communication hardware, off disables.
# Microphone: On enables audio input from on-board microphones (not 3.5mm jack), off disables.
# Rear camera: On enables the rear camera, off disables.
# Front camera: On enables the front camera, off disables.
# Headphone: On enables audio input and output via the 3.5mm audio jack, off switches the jack to hardware UART mode.

== Battery ==

The [https://wiki.pine64.org/images/0/04/PinePhone_Battery_model_QZ01-396172-2750.pdf supplied battery] is [https://forum.pine64.org/showthread.php?tid=8120&pid=53307#pid53307 meant to be] compatible with Samsung part number EB-BJ700BBC / BBE / CBE from the 2015 J7 phone. There is [https://forum.pine64.org/showthread.php?tid=8563&pid=55053#pid55053 a report] that the EB-BJ700CBE isn't quite the same size, causing the back not to fit properly.

The battery terminals, in order from nearest the edge to nearest the middle, are:

# +ve
# thermistor
# -ve
# not connected

The battery includes a protection circuit that isolates it in a number of fault conditions, including if it is discharged too far. The fully discharged battery [https://forum.pine64.org/showthread.php?tid=8563&pid=55377#pid55377 can be recharged] by connecting the phone to a charger. Once it has charged sufficiently you will be able to boot the phone.

If your battery is hard to remove from the phone, try loosening the screws around it. Possibly cutting up a piece of plastic and sliding it under the battery as a pull tab can work too.

'''When you first receive your Pinephone you will need to remove the plastic tab under the battery terminals to boot it. This is to protect it from turning on during shipping.'''

''' It's also important to note that the EG25 modem and RTL8723CS wifi/bluetooth do not work without the battery plugged in, even if you are supplying enough power to the Pinephone with USB-C'''

== Modem and Carrier Support ==

To check if the PinePhone is supported on your carrier:

Search for your carrier on [https://www.frequencycheck.com/ frequencycheck.com] and compare the carrier's LTE/GSM/WCDMA frequencies to the PinePhone's supported frequencies (listed under the [[#Specifications|specifications]] section).

It is likely that there will be a few frequencies that your carrier uses which are not supported by the PinePhone. Not all of the carrier's frequencies need to be supported by the PinePhone for it to work - as long as ''most'' of them are supported, you will still get good coverage.

== Factory Test Requirements ==

Most of the self tests should just work, but a couple of them will fail unless certain requirements are met.

=== RTL8723CS - WiFi ===

* The self test needs a visible access point nearby so it can discover an SSID.
* The self test may fail if the battery charge is too low.

=== EG25 - Modem ===

* A working micro-SIM that doesn't require a PIN to unlock
* Enough battery charge

== Operating Systems ==
The PinePhone will automatically boot from microSD if a bootable card is inserted. Although it is technically possible to use any ARM distro (because the PinePhone uses the mainline kernel), there are a few that are designed specifically for phones:
* [[#postmarketOS|postmarketOS]]
* [[#Ubuntu Touch|Ubuntu Touch]]
* [[#Sailfish OS|Sailfish OS]]
* [[#Maemo Leste|Maemo Leste]]
* [[#LuneOS|LuneOS]]
* [[#Manjaro|Manjaro]]
* [[#Neon|Neon]]
* [[#Aurora|Aurora]]

For an exhaustive list of information about the different OSs, see [[PinePhone Software Release]].

=== postmarketOS ===
postmarketOS is a preconfigured version of [https://www.alpinelinux.org/ Alpine Linux] for mobile devices. The latest builds can be downloaded from the [https://images.postmarketos.org/pinephone/ images page] to be flashed to the PinePhone.

More information is available at [https://postmarketos.org postmarketos.org] and on their [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone) dedicated PinePhone wiki page].

=== Ubuntu Touch ===
[https://ubuntu-touch.io/ Ubuntu touch] is a mobile version of Ubuntu developed by the UBports community. Images can be downloaded from [https://ci.ubports.com/job/rootfs/job/rootfs-pinephone/ here]. The default password is <code>phablet</code>. In the future, Ubuntu Touch will be able to be installed onto the PinePhone with the [https://ubuntu-touch.io/get-ut UBports installer] GUI tool.

=== Sailfish OS ===
The latest Sailfish OS image can be installed using the [https://raw.githubusercontent.com/sailfish-on-dontbeevil/flash-it/master/flash-it.sh flashing script].

The script downloads the image and bootloader, extracts everything and burns it onto the SD card. '''Note:''' The script will format and erase the SD card!

'''Instructions:'''
# Download the flashing script
# Insert a microSD card in your device
# Make the script executable: <code>chmod +x flash-it.sh</code>
# Execute it: <code>./flash-it.sh</code>
# Follow the instructions. Some commands in the script require root permissions.

Note that after baking µSD card and booting phone, as per [https://www.reddit.com/r/pinephone/comments/f1l7bm/sailfish_os_on_pinephone_best_os_so_far_in_my/fh8o0s2/ Reddit comment] you have to adjust autobrightness settings in order to actually see interface.

=== Nemo Mobile ===
Nemo Mobile is the open source build of Sailfish OS. The latest images for the PinePhone are released [https://github.com/neochapay/nemo-device-dont_be_evil/releases here].

* Nemo Mobile 20170217 Release [microSD Boot]
* DD image (for 8GB micoSD card and above)
** [http://files.pine64.org/os/PinePhone/NemoMobile/nemo-pinephone-release2020-02-17.img.gz Direct download from pine64.org]
** MD5 (GZip file): bb93d76c38bf688c11343de52fc92775
** File Size: 365MB

=== Maemo Leste ===
[https://maemo-leste.github.io/ Maemo Leste] images can be downloaded [https://maedevu.maemo.org/images/pinephone-dontbeevil/ here]. The default username is <code>root</code> and the password is <code>toor</code>

=== LuneOS ===
[https://www.webos-ports.org/wiki/Main_Page LuneOS] downloads are available [http://build.webos-ports.org/luneos-testing/images/pinephone/ here].

* LuneOS Test Build 0-78 Release [microSD Boot]
* DD image (for 8GB micoSD card and above)
** [http:///files.pine64.org/os/PinePhone/LuneOS/luneos-dev-image-pinephone-testing-0-78.rootfs.img.gz Direct download from pine64.org]
** MD5 (GZip file): f85131d5d9309d3fd793ec19a40a1ff6
** File Size: 418MB

=== Manjaro ===
[https://wiki.manjaro.org/index.php Manjaro] downloads are available [https://osdn.net/projects/manjaro-arm/storage/pinephone/ here].

=== Neon ===
[https://images.plasma-mobile.org/pinephone/ Neon images] A changelog (for the postmarketOS version) can be found [https://images.postmarketos.org/pinephone/#changelog here] username: phablet pw: 1234

=== Aurora ===
Available soon.

File:Quectel EC25EC21 AT Commands Manual V1.2.pdf

2020-02-21T13:19:21Z

M@yeulC: This document presents the AT Commands Set for Quectel cellular engine EC25&EC21.

This document presents the AT Commands Set for Quectel cellular engine EC25&EC21.

PinePhone

2019-12-06T13:06:53Z

M@yeulC: /* postmarketOS */ Add wiki page link

The PinePhone is a smartphone created by Pine64, capable of running mainline Linux and supported by many partner projects. A "braveheart" edition is currently available for purchase from the PINE64 store, though it should be noted that this version comes without a preinstalled OS, and is geared specifically towards tinkerers and hackers. People looking for a stable consumer-grade phone should wait for the final release, which is expected to occur in March 2020 and will be available for at least five years.

== Specifications ==

'''Dimensions:''' 160.5 x 76.6 x 9.2mm 
'''Weight:''' Between 180-200 grams 
'''Build:''' Plastic 
'''SIM Card:''' Micro-SIM 
'''Display:'''
: '''Size:''' 5.95 inches (151mm) diagonal
: '''Type:''' HD IPS capacitive touchscreen, 16M colors
: '''Resolution:''' 1440x720, 18:9 ratio 
'''System on Chip:''' [https://linux-sunxi.org/A64 Allwinner A64] 
'''RAM:''' 2GB LPDDR3 SDRAM 
'''Internal Storage:''' 16GB eMMC, extendable up to 2TB via microSD, supports SDHC and SDXC 
'''Back Camera:''' Single 5MP, 1/4", LED Flash 
'''Selfie Camera:''' Single 2MP, f/2.8, 1/5" 
'''Sound:''' Loudspeaker, 3.5mm jack & mic (jack doubles as hardware UART if killswitch 6 is deactivated) 
'''Communication: [http://files.pine64.org/doc/datasheet/project_anakin/LTE_module/Quectel_EG25-G_LTE_Specification_V1.1_Preliminary_20180522%20(002).pdf EG25-G]'''
: '''LTE:''' B1, B2, B3, B4, B5, B7, B8, B12, B13, B18, B19, B20, B25, B26, B28, B38, B39, B40, B41
: '''WCDMA:''' B1, B2, B4, B5, B6, B8, B19
: '''GSM:''' 850, 900, 1800, 1900 (MHz)
: '''WLAN:''' Wi-Fi 802.11 b/g/n, single-band, hotspot
: '''Bluetooth:''' 4.0, A2DP
: '''GNSS:''' GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS
'''Sensors:''' Accelerometer, gyro, proximity, ambient light, compass 
'''[[#Killswitch configuration|Killswitches]]:''' Modem, Wifi & Bluetooth, Microphone, Cameras 
'''Battery:''' 2750-3000 mAh [https://wiki.pine64.org/images/0/04/PinePhone_Battery_model_QZ01-396172-2750.pdf Lithium ion] (replaceable with any Samsung J7 form-factor battery) 
'''I/O:''' USB Type-C (SlimPort), USB Host, DisplayPort Alternate Mode output, 15W 5V 3A Quick Charge, follows USB PD specification

== History ==

The PinePhone was announced at [https://archive.fosdem.org/2019/ FOSDEM 2019], February 2-4, 2019. The first [[Project Don't be evil]] devkit was on display at the Pine64 booth during the weekend.

=== Hardware revisions ===

The PinePhone platform went through two "developer kit" phases that partner projects used to prove their software on the upcoming platform.

# [[Project Anakin]]
# [[Project Don't be evil]]

Additionally, two "early adopter" revisions of the platform were created:

# PinePhone 1.0 "Developer"
# PinePhone 1.1 "Brave Heart" ([http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf schematic]).

Version 1.1 was the first PinePhone available to the general public. Pre-orders for this batch started on November 15, 2019. It is expected to ship sometime in December 2019 to January 2020.

A "full release" Pinephone, which will likely have board revision 1.2, will be released in 2020.

== Killswitch configuration ==

The PinePhone features six switches that can be used to configure its hardware. They are numbered 1-6, with switch 1 located nearest to the modem. Their on position is toward the top of the phone.

[[File:PinePhone-main-board.jpg|600px|thumb|centre|Photo of Developer mainboard courtesy of Martijn Braam, postmarketOS]]

# Modem: On enables 2G/3G/4G communication and GNSS hardware, off disables.
# WiFi/BT: On enables Wi-Fi and Bluetooth communication hardware, off disables.
# Microphone: On enables audio input from on-board microphones (not 3.5mm jack), off disables.
# Rear camera: On enables the rear camera, off disables.
# Front camera: On enables the front camera, off disables.
# Headphone: On enables audio input and output via the 3.5mm audio jack, off switches the jack to hardware UART mode.

== Modem and Carrier Support ==

To check if the PinePhone is supported on your carrier:

Search for your carrier on [https://www.frequencycheck.com/ frequencycheck.com] and compare the carrier's LTE/GSM/WCDMA frequencies to the PinePhone's supported frequencies (listed under the [[#Specifications|specifications]] section).

It is likely that there will be a few frequencies that your carrier uses which are not supported by the PinePhone. Not all of the carrier's frequencies need to be supported by the PinePhone for it to work - as long as ''most'' of them are supported, you will still get good coverage.

== Operating Systems ==
The PinePhone will automatically boot from microSD if a bootable card is inserted. Although it is technically possible to use any ARM distro (because the PinePhone uses the mainline kernel), there are a few that are designed specifically for phones:
* [[#postmarketOS|postmarketOS]]
* [[#Ubuntu Touch|Ubuntu Touch]]
* [[#Sailfish OS|Sailfish OS]]
* [[#Maemo Leste|Maemo Leste]]
* [[#LuneOS|LuneOS]]

=== postmarketOS ===
postmarketOS is a preconfigured version of [https://www.alpinelinux.org/ Alpine Linux] for mobile devices. The latest builds can be downloaded from the [https://images.postmarketos.org/pinephone/ images page] to be flashed to the PinePhone.

More information is available at [https://postmarketos.org postmarketos.org] and on their [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone) dedicated PinePhone wiki page].

=== Ubuntu Touch ===
[https://ubuntu-touch.io/ Ubuntu touch] is a mobile version of Ubuntu developed by the UBports community. Images can be downloaded from [https://ci.ubports.com/job/rootfs/job/rootfs-pinephone/ here]. In the future, Ubuntu Touch will be able to be installed onto the PinePhone with the [https://ubuntu-touch.io/get-ut UBports installer] GUI tool.

=== Sailfish OS ===
The latest Sailfish OS image can be installed using the [https://raw.githubusercontent.com/sailfish-on-dontbeevil/flash-it/master/flash-it.sh flashing script].

The script downloads the image and bootloader, extracts everything and burns it onto the SD card. '''Note:''' The script will format and erase the SD card!

'''Instructions:'''
# Download the flashing script
# Insert a microSD card in your device
# Make the script executable: <code>chmod +x flash-it.sh</code>
# Execute it: <code>./flash-it.sh</code>
# Follow the instructions. Some commands in the script require root permissions.

=== Maemo Leste ===
[https://maemo-leste.github.io/ Maemo Leste] images can be downloaded [https://maedevu.maemo.org/images/pinephone-dontbeevil/ here]. The default username is <code>root</code> and the password is <code>toor</code>

=== LuneOS ===
[https://www.webos-ports.org/wiki/Main_Page LuneOS] downloads are available [http://build.webos-ports.org/luneos-testing/images/pinephone/ here].