PINE64 - User contributions [en]

Quartz64 Model A Using a battery

2023-03-12T04:17:06Z

Megous: /* Software */

The [[Quartz64|Quartz64 Model A]] allows for it to be powered from a single-cell 3.7V lithium-polymer battery. Because of [https://en.wikipedia.org/wiki/UPS_Airlines_Flight_6 unfortunate incidents], batteries are not easy to ship internationally, so PINE Store does not sell a matching battery for the board.

= Pin-out =

[[File:Quartz64 Model A VBAT Connector Pinout.png|right]]

The pins on the board are a JST PH-3 compatible header labelled ''+VBAT-''. As one might guess, the positive wire should be towards the +, and the ground wire towards -. The center pin of the connector is for a temperature probe.

= Ways to get a battery =

We will now go into various ways one might go about getting a working battery.

== Crimping one yourself ==

You will need:
* an Engineer PA-20 ([https://www.amazon.com/s?k=Engineer+Pa-20 Amazon Search], [https://www.ebay.com/sch/i.html?kw=Engineer%20PA-20 eBay Search]) or Hozan P-707 ([https://www.amazon.com/s?k=Hozan+P-707 Amazon Search], [https://www.ebay.com/sch/i.html?kw=Hozan%20P-707 eBay Search]) or similar crimp tool (<$80, good to have around anyway)
** The Hozan P-707 is also comparatively good at crimping "Dupont"-style terminals, in case you find yourself doing that a lot, because it provides round crimping holes in addition to rectangular ones.
* JST PHR-3 receptacles ([https://www.digikey.com/en/products/detail/jst-sales-america-inc/PHR-3/527357 ~$0.05 on digikey])
* 3× JST SPH-002T-P0.5L crimp terminals ([https://www.digikey.com/en/products/detail/jst-sales-america-inc/SPH-002T-P0-5L/1300246 ~$0.03 on digikey per terminal])
** When ordering from digikey, try to hit the minimum order cost to qualify for free shipping; you'll get free fast courier shipping with all customs and duties pre-paid.
* a single-cell 3.7V lithium-polymer battery, ideally with a temperature probe
** 2800 mAh Renata ICP606168PRT on [https://www.conrad.de/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html Conrad Germany], [https://www.conrad.ch/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html Conrad Switzerland]
** 2000 mAh Adafruit on [https://www.adafruit.com/product/2011 Adafruit US] (no temperature probe, pre-crimped with JST PHR-2; just lift up the plastic tabs and pull out the terminals and shove them back into a PHR-3 connector)
** Aliexpress: try keywords "3.7v lithium battery temperature probe"

Crimp the terminals onto the wires, crimp the strain relief onto the insulation, slide them into the connector until they firmly click in place.

== PINE64 18650 battery case ==

You will need:
* [https://pine64.com/product/lithium-battery-casing/ PINE64 Lithium Battery Casing]
* an 18650 sized lithium battery ('''not''' LiFePo4!)

'''TODO:''' Get one of these and document how to use them

= Using the battery =

== Hardware ==

# Ensure the wires in the connector are in the right order.
# Turn off your Quartz64 Model A.
# Remove the BAT ON/OFF jumper.
# Plug in your battery.
# It is now ready to use if your device tree has been set up correctly.

== Caveats ==

Not all parts of the board can be supplied from the battery. When you use battery as backup power for the board keep in mind that following parts of Quartz64-A will lose power when DCIN loses power:

* 12V Fan connector
* EDP LCD backlight
* 5V power rails on the 20 pin GPIO header
* PCIe socket (both 12V and 3.3V supplies)
* All USB ports except for the black one
* Black USB port's VBUS (the one above the USB 3.0 port) will go through a 22ms brownout to approximately VCC_SYS - 0.6V voltage, before the RK817 BOOST regulator kicks in. This will likely cause the connected USB device to reset or have its internal state corrupted.

[[File:Quartz 64 Model A VBUS Brownout.png|640px]]

== Software ==

For the battery to be correctly detected, you will need to edit the device tree to add the charger and battery nodes, like this:

<pre>
// add this to root node (you may need to modify the values to fit your chosen battery)
battery: battery {
compatible = "simple-battery";
charge-full-design-microamp-hours = <6400000>;
charge-term-current-microamp = <200000>;
constant-charge-current-max-microamp = <2000000>;
constant-charge-voltage-max-microvolt = <4200000>;
factory-internal-resistance-micro-ohms = <117000>;
voltage-max-design-microvolt = <4200000>;
voltage-min-design-microvolt = <3200000>;

ocv-capacity-celsius = <20>;
ocv-capacity-table-0 = <4200000 100>, <4054000 95>, <3984000 90>, <3926000 85>,
<3874000 80>, <3826000 75>, <3783000 70>, <3746000 65>,
<3714000 60>, <3683000 55>, <3650000 50>, <3628000 45>,
<3612000 40>, <3600000 35>, <3587000 30>, <3571000 25>,
<3552000 20>, <3525000 15>, <3492000 10>, <3446000 5>,
<3400000 0>;
};

// add this to &rk817 node
rk817_charger: charger {
monitored-battery = <&battery>;
rockchip,resistor-sense-micro-ohms = <10000>;
rockchip,sleep-enter-current-microamp = <300000>;
rockchip,sleep-filter-current-microamp = <100000>;
};
</pre>

You will also need to make sure that CONFIG_CHARGER_RK817 is enabled in your kernel.

[[Category:Quartz64]]

Quartz64 Model A Using a battery

2023-03-12T04:09:35Z

Megous: /* Software */

The [[Quartz64|Quartz64 Model A]] allows for it to be powered from a single-cell 3.7V lithium-polymer battery. Because of [https://en.wikipedia.org/wiki/UPS_Airlines_Flight_6 unfortunate incidents], batteries are not easy to ship internationally, so PINE Store does not sell a matching battery for the board.

= Pin-out =

[[File:Quartz64 Model A VBAT Connector Pinout.png|right]]

The pins on the board are a JST PH-3 compatible header labelled ''+VBAT-''. As one might guess, the positive wire should be towards the +, and the ground wire towards -. The center pin of the connector is for a temperature probe.

= Ways to get a battery =

We will now go into various ways one might go about getting a working battery.

== Crimping one yourself ==

You will need:
* an Engineer PA-20 ([https://www.amazon.com/s?k=Engineer+Pa-20 Amazon Search], [https://www.ebay.com/sch/i.html?kw=Engineer%20PA-20 eBay Search]) or Hozan P-707 ([https://www.amazon.com/s?k=Hozan+P-707 Amazon Search], [https://www.ebay.com/sch/i.html?kw=Hozan%20P-707 eBay Search]) or similar crimp tool (<$80, good to have around anyway)
** The Hozan P-707 is also comparatively good at crimping "Dupont"-style terminals, in case you find yourself doing that a lot, because it provides round crimping holes in addition to rectangular ones.
* JST PHR-3 receptacles ([https://www.digikey.com/en/products/detail/jst-sales-america-inc/PHR-3/527357 ~$0.05 on digikey])
* 3× JST SPH-002T-P0.5L crimp terminals ([https://www.digikey.com/en/products/detail/jst-sales-america-inc/SPH-002T-P0-5L/1300246 ~$0.03 on digikey per terminal])
** When ordering from digikey, try to hit the minimum order cost to qualify for free shipping; you'll get free fast courier shipping with all customs and duties pre-paid.
* a single-cell 3.7V lithium-polymer battery, ideally with a temperature probe
** 2800 mAh Renata ICP606168PRT on [https://www.conrad.de/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html Conrad Germany], [https://www.conrad.ch/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html Conrad Switzerland]
** 2000 mAh Adafruit on [https://www.adafruit.com/product/2011 Adafruit US] (no temperature probe, pre-crimped with JST PHR-2; just lift up the plastic tabs and pull out the terminals and shove them back into a PHR-3 connector)
** Aliexpress: try keywords "3.7v lithium battery temperature probe"

Crimp the terminals onto the wires, crimp the strain relief onto the insulation, slide them into the connector until they firmly click in place.

== PINE64 18650 battery case ==

You will need:
* [https://pine64.com/product/lithium-battery-casing/ PINE64 Lithium Battery Casing]
* an 18650 sized lithium battery ('''not''' LiFePo4!)

'''TODO:''' Get one of these and document how to use them

= Using the battery =

== Hardware ==

# Ensure the wires in the connector are in the right order.
# Turn off your Quartz64 Model A.
# Remove the BAT ON/OFF jumper.
# Plug in your battery.
# It is now ready to use if your device tree has been set up correctly.

== Caveats ==

Not all parts of the board can be supplied from the battery. When you use battery as backup power for the board keep in mind that following parts of Quartz64-A will lose power when DCIN loses power:

* 12V Fan connector
* EDP LCD backlight
* 5V power rails on the 20 pin GPIO header
* PCIe socket (both 12V and 3.3V supplies)
* All USB ports except for the black one
* Black USB port's VBUS (the one above the USB 3.0 port) will go through a 22ms brownout to approximately VCC_SYS - 0.6V voltage, before the RK817 BOOST regulator kicks in. This will likely cause the connected USB device to reset or have its internal state corrupted.

[[File:Quartz 64 Model A VBUS Brownout.png|640px]]

== Software ==

For the battery to be correctly detected, you will need to edit the device tree to add the charger and battery nodes, like this:

<pre>
// add this to root node
battery: battery {
compatible = "simple-battery";
charge-full-design-microamp-hours = <6400000>;
charge-term-current-microamp = <200000>;
constant-charge-current-max-microamp = <2000000>;
constant-charge-voltage-max-microvolt = <4200000>;
factory-internal-resistance-micro-ohms = <117000>;
voltage-max-design-microvolt = <4200000>;
voltage-min-design-microvolt = <3200000>;

ocv-capacity-celsius = <20>;
ocv-capacity-table-0 = <4200000 100>, <4054000 95>, <3984000 90>, <3926000 85>,
<3874000 80>, <3826000 75>, <3783000 70>, <3746000 65>,
<3714000 60>, <3683000 55>, <3650000 50>, <3628000 45>,
<3612000 40>, <3600000 35>, <3587000 30>, <3571000 25>,
<3552000 20>, <3525000 15>, <3492000 10>, <3446000 5>,
<3400000 0>;
};

// add this to &rk817 node
rk817_charger: charger {
monitored-battery = <&battery>;
rockchip,resistor-sense-micro-ohms = <10000>;
rockchip,sleep-enter-current-microamp = <300000>;
rockchip,sleep-filter-current-microamp = <100000>;
};
</pre>

You will also need to make sure that CONFIG_CHARGER_RK817 is enabled in your kernel.

[[Category:Quartz64]]

Quartz64 Model A Using a battery

2023-03-12T04:01:52Z

Megous: /* Caveats */

The [[Quartz64|Quartz64 Model A]] allows for it to be powered from a single-cell 3.7V lithium-polymer battery. Because of [https://en.wikipedia.org/wiki/UPS_Airlines_Flight_6 unfortunate incidents], batteries are not easy to ship internationally, so PINE Store does not sell a matching battery for the board.

= Pin-out =

[[File:Quartz64 Model A VBAT Connector Pinout.png|right]]

The pins on the board are a JST PH-3 compatible header labelled ''+VBAT-''. As one might guess, the positive wire should be towards the +, and the ground wire towards -. The center pin of the connector is for a temperature probe.

= Ways to get a battery =

We will now go into various ways one might go about getting a working battery.

== Crimping one yourself ==

You will need:
* an Engineer PA-20 ([https://www.amazon.com/s?k=Engineer+Pa-20 Amazon Search], [https://www.ebay.com/sch/i.html?kw=Engineer%20PA-20 eBay Search]) or Hozan P-707 ([https://www.amazon.com/s?k=Hozan+P-707 Amazon Search], [https://www.ebay.com/sch/i.html?kw=Hozan%20P-707 eBay Search]) or similar crimp tool (<$80, good to have around anyway)
** The Hozan P-707 is also comparatively good at crimping "Dupont"-style terminals, in case you find yourself doing that a lot, because it provides round crimping holes in addition to rectangular ones.
* JST PHR-3 receptacles ([https://www.digikey.com/en/products/detail/jst-sales-america-inc/PHR-3/527357 ~$0.05 on digikey])
* 3× JST SPH-002T-P0.5L crimp terminals ([https://www.digikey.com/en/products/detail/jst-sales-america-inc/SPH-002T-P0-5L/1300246 ~$0.03 on digikey per terminal])
** When ordering from digikey, try to hit the minimum order cost to qualify for free shipping; you'll get free fast courier shipping with all customs and duties pre-paid.
* a single-cell 3.7V lithium-polymer battery, ideally with a temperature probe
** 2800 mAh Renata ICP606168PRT on [https://www.conrad.de/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html Conrad Germany], [https://www.conrad.ch/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html Conrad Switzerland]
** 2000 mAh Adafruit on [https://www.adafruit.com/product/2011 Adafruit US] (no temperature probe, pre-crimped with JST PHR-2; just lift up the plastic tabs and pull out the terminals and shove them back into a PHR-3 connector)
** Aliexpress: try keywords "3.7v lithium battery temperature probe"

Crimp the terminals onto the wires, crimp the strain relief onto the insulation, slide them into the connector until they firmly click in place.

== PINE64 18650 battery case ==

You will need:
* [https://pine64.com/product/lithium-battery-casing/ PINE64 Lithium Battery Casing]
* an 18650 sized lithium battery ('''not''' LiFePo4!)

'''TODO:''' Get one of these and document how to use them

= Using the battery =

== Hardware ==

# Ensure the wires in the connector are in the right order.
# Turn off your Quartz64 Model A.
# Remove the BAT ON/OFF jumper.
# Plug in your battery.
# It is now ready to use if your device tree has been set up correctly.

== Caveats ==

Not all parts of the board can be supplied from the battery. When you use battery as backup power for the board keep in mind that following parts of Quartz64-A will lose power when DCIN loses power:

* 12V Fan connector
* EDP LCD backlight
* 5V power rails on the 20 pin GPIO header
* PCIe socket (both 12V and 3.3V supplies)
* All USB ports except for the black one
* Black USB port's VBUS (the one above the USB 3.0 port) will go through a 22ms brownout to approximately VCC_SYS - 0.6V voltage, before the RK817 BOOST regulator kicks in. This will likely cause the connected USB device to reset or have its internal state corrupted.

[[File:Quartz 64 Model A VBUS Brownout.png|640px]]

== Software ==

For the battery to be correctly detected, you will need to edit the device tree.

'''TODO:''' Either write this section detailing how to edit the device tree, or get FDT overlays working and write about how to make an overlay

[[Category:Quartz64]]

File:Quartz 64 Model A VBUS Brownout.png

2023-03-12T03:59:14Z

Megous:

Quartz64 Model A Using a battery

2023-03-12T03:55:30Z

Megous: Info about what gets powered down on DCIN power loss

The [[Quartz64|Quartz64 Model A]] allows for it to be powered from a single-cell 3.7V lithium-polymer battery. Because of [https://en.wikipedia.org/wiki/UPS_Airlines_Flight_6 unfortunate incidents], batteries are not easy to ship internationally, so PINE Store does not sell a matching battery for the board.

= Pin-out =

[[File:Quartz64 Model A VBAT Connector Pinout.png|right]]

The pins on the board are a JST PH-3 compatible header labelled ''+VBAT-''. As one might guess, the positive wire should be towards the +, and the ground wire towards -. The center pin of the connector is for a temperature probe.

= Ways to get a battery =

We will now go into various ways one might go about getting a working battery.

== Crimping one yourself ==

You will need:
* an Engineer PA-20 ([https://www.amazon.com/s?k=Engineer+Pa-20 Amazon Search], [https://www.ebay.com/sch/i.html?kw=Engineer%20PA-20 eBay Search]) or Hozan P-707 ([https://www.amazon.com/s?k=Hozan+P-707 Amazon Search], [https://www.ebay.com/sch/i.html?kw=Hozan%20P-707 eBay Search]) or similar crimp tool (<$80, good to have around anyway)
** The Hozan P-707 is also comparatively good at crimping "Dupont"-style terminals, in case you find yourself doing that a lot, because it provides round crimping holes in addition to rectangular ones.
* JST PHR-3 receptacles ([https://www.digikey.com/en/products/detail/jst-sales-america-inc/PHR-3/527357 ~$0.05 on digikey])
* 3× JST SPH-002T-P0.5L crimp terminals ([https://www.digikey.com/en/products/detail/jst-sales-america-inc/SPH-002T-P0-5L/1300246 ~$0.03 on digikey per terminal])
** When ordering from digikey, try to hit the minimum order cost to qualify for free shipping; you'll get free fast courier shipping with all customs and duties pre-paid.
* a single-cell 3.7V lithium-polymer battery, ideally with a temperature probe
** 2800 mAh Renata ICP606168PRT on [https://www.conrad.de/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html Conrad Germany], [https://www.conrad.ch/de/p/renata-icp606168prt-spezial-akku-prismatisch-kabel-lipo-3-7-v-2800-mah-1214021.html Conrad Switzerland]
** 2000 mAh Adafruit on [https://www.adafruit.com/product/2011 Adafruit US] (no temperature probe, pre-crimped with JST PHR-2; just lift up the plastic tabs and pull out the terminals and shove them back into a PHR-3 connector)
** Aliexpress: try keywords "3.7v lithium battery temperature probe"

Crimp the terminals onto the wires, crimp the strain relief onto the insulation, slide them into the connector until they firmly click in place.

== PINE64 18650 battery case ==

You will need:
* [https://pine64.com/product/lithium-battery-casing/ PINE64 Lithium Battery Casing]
* an 18650 sized lithium battery ('''not''' LiFePo4!)

'''TODO:''' Get one of these and document how to use them

= Using the battery =

== Hardware ==

# Ensure the wires in the connector are in the right order.
# Turn off your Quartz64 Model A.
# Remove the BAT ON/OFF jumper.
# Plug in your battery.
# It is now ready to use if your device tree has been set up correctly.

== Caveats ==

Not all parts of the board can be supplied from the battery. When you use battery as backup power for the board keep in mind that following parts of Quartz64-A will lose power when DCIN loses power:

* 12V Fan connector
* EDP LCD backlight
* 5V power rails on the 20 pin GPIO header
* PCIe socket (both 12V and 3.3V supplies)
* All USB ports except for the black one
* Black USB port's VBUS (the one above the USB 3.0 port) will go through a 22ms brownout to approximately VCC_SYS - 0.6V voltage, before the RK817 BOOST regulator kicks in. This will likely cause the connected USB device to reset or have its internal state corrupted.

[[File:Quartz 64 Model A VBUS Brownout.png]]

== Software ==

For the battery to be correctly detected, you will need to edit the device tree.

'''TODO:''' Either write this section detailing how to edit the device tree, or get FDT overlays working and write about how to make an overlay

[[Category:Quartz64]]

PinePhone Pro

2022-08-01T14:12:53Z

Megous: /* The battery is fully drained */

[[File:Pinephone_double.png|400px|thumb|right|Rendering of the PinePhone Pro]]

The '''PinePhone Pro''' is PINE64's flagship smartphone announced on October 15, 2021. It features 4GB of RAM, an 128GB eMMC and is using an Rockchip RK3399S SoC, which is a specialized version of the RK3399 made specifically for the PinePhone Pro.

== Introduction ==

The PinePhone Pro is PINE64’s second smartphone and a successor to the original PinePhone. It does not, however, replace the original PinePhone. It should also not be considered a second generation PinePhone; it is a higher-end device, with much better specs, aimed at those who wish to daily-drive a open system stack. Achieving this goal will, however, take time as the software and overall smartphone software ecosystem needs to mature.

More information about the PinePhone Pro can be found on the device [https://www.pine64.org/pinephonepro/ main page].

=== State of the software ===
([[PinePhone Pro Software State|view separately]])

{{:PinePhone Pro Software State}}

=== Editions and revisions ===
Similarly to the original PinePhone, various PinePhone Pro editions are planned, the first of which is the Developer Edition (aimed at developers, as the name entails) followed by the Explorer Edition, which is aimed at early adopters.

* [[PinePhone Pro Developer Edition]]
* [[PinePhone Pro Explorer Edition]]

=== Help and support ===

Still have any questions regarding software, shipping, or ordering after reading this Wiki? Please don't hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See [[Main Page#Community and Support]].

Please keep in mind that PINE64 is not like a regular company (see the [https://www.pine64.org/philosophy/ PINE64 philosophy]) and that support resources are limited - the best way to get support quickly is to ask in the community chat! Please only contact the PINE64 support directly if questions couldn't be solved via the community chat or this wiki.

== First time setup ==
[[File:Pinephone_warning.png|320px|thumb|right|A protection foil isolates the battery for the shipping.]]

When shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery '''will not''' charge or boot until it is removed and the battery is connected again.

{{Info|To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery.}}

The PinePhone's SIM slot only accepts a micro-SIM, please do not insert a nano-SIM without an adapter and make sure that the nano-SIM does not get released from its adapter. The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot.

{{Info|Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them!}}

[[File:Pinephone slots.png|600px|thumb|none|The microSD belongs in the upper slot, the micro-SIM in the lower slot.]]

An adapter from a nano to a micro-SIM might be included under tape in the camera notch of the phone's packaging. Some nano-SIMs will not fit firmly into that adapter that comes with the PinePhone and if the included adapter is used without a well-fitting nano-SIM, the contact pins might get damaged. In that case it is highly recommended to acquire a better fitting adapter.

== Software ==

The software section explains how to install the available software releases for the PinePhone Pro to the internal eMMC or a microSD card, how to boot them and how to solve common booting issues.

=== Software releases ===

The [[PinePhone Pro Software Releases]] page has a complete list of currently supported phone-optimized operating system images that work with the PinePhone Pro.

{{Info|Images of the regular PinePhone are not compatible with the PinePhone Pro.}}

=== Boot order ===

The RK3399S processor in the PinePhone Pro searches for the bootloader (such as ''U-Boot'') in the following order:

# SPI flash
# eMMC (the internal memory)
# MicroSD card

The bootloader uses its own boot order for loading the kernel and other core operating system components at boot, which for example may result in the boot loader residing on the eMMC loading and booting the kernel from a microSD card.

The SPI flash and the eMMC chip can be bypassed during boot by temporarily disabling them at the hardware level using the following method, which can be used in cases such as having corrupted installation on the SPI flash or the eMMC:

* On the '''Explorer Edition''' hold the ''RE'' button underneath the cover for a few seconds, while powering on the device.

* On the '''Developer Edition''', which was an earlier revision intended for developers only, the SPI and the eMMC can be bypassed by shorting the bypass test points while booting. The process is explained in the article [[PinePhone Pro Developer Edition#Nuking the factory AOSP installation|PinePhone Pro Developer Edition]]. Please join the community chat for any questions regarding the process.

The bypass disables the SPI and the eMMC while being applied and the PinePhone Pro will try to boot from the next available boot medium, which is the microSD card. Note: When holding the ''RE'' button (or when shorting the contact points in case of the ''Developer Edition'') for a longer time at boot the operating system will not initialize the SPI and eMMC and it will not be possible to write to these storage mediums until the next reboot.

{{Info|The bootloader (such as ''U-Boot'') resides in the free space in front of the first partition. Wiping the bootloader from the eMMC to make the PinePhone Pro boot from microSD card can be done using <code>sudo dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=400 conv=fsync</code>. Formatting the drive or deleting the partition table is not sufficient to wipe the bootloader.}}

See [[RK3399 boot sequence]] for details regarding the boot sequence.

=== Installation instructions ===

The software releases can be installed (the process is being referred to as ''flashing'') to the eMMC or to an microSD card.

==== Flashing to microSD card ====
To install an image to the microSD card:

# Download a compatible image from [[PinePhone Pro Software Releases]]
# Extract the compressed image
# Write the image to your microSD card using your favorite method, examples:
#* Using ''dd'': On the device you're flashing the microSD card from, find the correct device under <code>lsblk</code> and then flash the image to the microSD card using <code>sudo dd if='''IMAGE.img''' of=/dev/'''[DEVICE]''' bs=1M status=progress conv=fsync</code>. Make sure the target is the whole microSD card and not its first partition (''sdc1'' or ''mmcblk0p1'' are wrong!).
#* Using ''bmaptool'': Make sure to select the correct device using <code>lsblk</code>. Then run bmaptool with the correct device: Download the ''IMAGE.xz'' and the ''IMAGE.bmap'' files, then run <code>bmaptool copy --bmap '''IMAGE.bmap''' '''IMAGE.xz''' /dev/'''[DEVICE]'''</code>. This takes around 2.5 minutes to flash a 4 GB file.
#* Using ''a graphical tool'': A graphical tool such as Gnome Disks under Linux or Etcher under Windows may also be used.
# Insert the microSD card into the top slot of the PinePhone Pro. Make sure the microSD card is inserted all the way and that the notch of the right side of the microSD card is not visible anymore, see [[:File:Pinephone_slots.png|here]].
# Power on the PinePhone Pro. If there is an '''existing bootloader on the eMMC''' already you need to bypass or wipe the bootloader on the eMMC as explained in the section [[PinePhone Pro#Boot order|Boot order]].

==== Flashing to the eMMC ====
Flashing to the eMMC can be done by booting an operating system from the microSD (see the section [[PinePhone Pro#Flashing to microSD card|Flashing to microSD card]]) and by writing to the eMMC directly from there:

# Boot an operating system [[PinePhone Pro#Flashing to microSD card|from the microSD card]]. If there is already a bootloader on the eMMC installed see the section [[PinePhone Pro#Boot order|Boot order]] to bypass it
# Download or copy the desired image to the microSD card as file
# Check if the eMMC appears under <code>lsblk</code>. If it doesn't appear in the output of the command, the eMMC wasn't initialized due to applying the above explained bypass method for a too long time during the boot
# Extract the image
# Flash the extracted image using <code>sudo dd if='''IMAGE.img''' of=/dev/mmcblk2 bs=1M status=progress conv=fsync</code>
# Reboot the PinePhone Pro

=== Troubleshooting ===

If the PinePhone Pro is not booting (either booting incompletely into a boot splash or tty or if the PinePhone Pro is showing no signs of life) this will typically have the following two reasons:

==== The battery is fully drained ====
The bootloader ''U-Boot'' is currently booting into a boot loop if the battery is fully drained. In that case it is not possible to charge the phone. The battery can be charged by interrupting the boot loop by booting the PinePhone Pro into ''Maskrom mode'' or by charging the battery externally. To boot the PinePhone Pro into ''Maskrom mode'':

* Remove any microSD card from the phone and keep it removed for the below procedure
* Remove the battery, any USB cable and any serial cable
* Reinsert the battery
* Hold the ''RE'' button underneath the back cover of your ''Explorer Edition'' (or short the bypass contact points on the ''Developer Edition'')
{{Info|Confirm that the label of the button says ''RE'' and not ''RESET''! If the button label says ''RESET'' instead you probably have a regular PinePhone and you're reading the wrong page.}}
* Connect the phone to an USB port of a computer, while still holding the button for some time
* Check if the phone in Maskrom mode appears in the output of the terminal command <code>lsusb</code> on the computer, the expected ''VID:PID'' of the device is ''2207:330c'' (under ''Windows'' this can be checked using the ''Device Manager'' and checking the VID and PID of an appearing ''Unknown device'')
* Let the phone charge for at least two hours

{{Info|If the device doesn't appear under ''lsusb'' please try again with a different known good USB-C cable and make sure that there is no microSD card in the phone inserted.}}

The device should now be able to boot from the boot medium again. If that is not the case the installation got corrupted, as explained below.

Levinboot bootloader doesn't have the bootloop issue, because it configures high input current limit (2A) during early boot, which is sufficient to complete the boot even with discharged battery, without any boot loops.

==== The installation is corrupted ====
The PinePhone Pro won't be able to boot if the installation on the SPI flash, the eMMC or the microSD card got corrupted. To boot a working operating system:

* Prepare a microSD card as explained in the section [[PinePhone Pro#Flashing to microSD card|Flashing to microSD card]]
* Remove any USB-C cable or device or add-on case from the PinePhone Pro
* Make sure the device is powered off by shortly removing the battery for a second
* Insert the microSD card into the top slot of the PinePhone Pro. Make sure the microSD card is inserted all the way and that the notch of the right side of the microSD card is not visible anymore.
* Power on the device while bypassing the SPI and eMMC as explained under [[PinePhone Pro#Boot order|Boot order]]

The device should now boot from the microSD card. If the phone does not boot from the microSD card the microSD card was flashed with an incompatible image or the battery got drained as explained above.

=== Bootloaders ===
The following section contains notes regarding compatible bootloaders with the PinePhone Pro.

==== U-Boot ====
The pre-installed operating system on the PinePhone Pro Explorer Edition is using ''U-Boot'' as default bootloader.

==== Tow-Boot ====
There are plans to possibly ship the PinePhone Pro with ''Tow-Boot'' pre-installed to the SPI flash in a future batch, which is an opinionated distribution of ''U-Boot'' and brings numerous advantages over stock ''U-Boot'', such as the possibility to choose from booting the eMMC or microSD card using the volume buttons during boot, as well as a ''USB Mass Storage mode'', where the device can be written to by connecting the device to a computer via USB.

The user can flash Tow-Boot to the PinePhone Pro using the [https://tow-boot.org/devices/pine64-pinephonePro.html instructions on the Tow-Boot website].

==== levinboot ====
The levinboot bootloader is another option for the PinePhone Pro. The project repository can be found [https://gitlab.com/DeltaGem/levinboot/-/tree/master/ here]. (Pinephone Pro supporting fork is [https://xff.cz/git/levinboot/ here].)

== Privacy switch configuration ==

[[File:PinePhone Kill Interruptors de Maquinari del PinePhone 4529.jpg|320px|thumb|right|Picture of the privacy switches]]

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.

{| class="wikitable"
|-
! Number
! Name
! Description
|-
| 1
| Modem
| "On" enables 2G/3G/4G communication and GNSS hardware, "off" disables it.
|-
| 2
| WiFi / Bluetooth
| "On" enables WiFi and Bluetooth communication hardware, "off" disables it.
|-
| 3
| Microphone
| "On" enables audio input from on-board microphones (not 3.5 mm jack), "off" disables it.
|-
| 4
| Rear camera
| "On" enables the rear camera, "off" disables it.
|-
| 5
| Front camera
| "On" enables the front camera, "off" disables it.
|-
| 6
| Headphone
| "On" enables audio input and output via the 3.5 mm audio jack, "off" switches the jack to hardware UART¹ mode.
|}

¹ Note: The baud rate may be 1500000 instead of 115200.

== Specifications ==

* '''Dimensions:''' 160.8 x 76.6 x 11.1mm
* '''Weight:''' Approx. 220g
* '''SIM Card:''' Micro-SIM
* '''Display:'''
** '''Size:''' 6 inches (151mm) diagonal
** '''Type:''' 1440 x 720 in-cell IPS with Gorilla Glass 4™
** '''Resolution:''' 1440x720, 18:9 ratio
* '''System on Chip:''' Rockchip RK3399S 64bit SoC – 2x A72 and 4x A53 CPU cores @ 1.5GHz
* '''RAM:''' 4GB LPDDR4 @ 800MHz
* '''Internal Storage:''' 128GB eMMC, extendable up to 2TB via microSD, supports SDHC and SDXC
* '''NOR Flash:''' Listed as [GigaDevices] GD25LQ128EWIGR, but physical inspection found a SiliconKaiser SK25LP128.
* '''Back [[#Camera|Camera]]:''' 13MP Sony IMX258 with Gorilla Glass 4™ protective layer, LED Flash
* '''Front Camera:''' 8MP, OmniVision OV8858 front-facing camera
* '''Sound:''' Loudspeaker, 3.5mm jack & mic (jack doubles as hardware UART if hardware switch 6 is deactivated)
* '''Communication:'''
** '''[[#Modem|Modem]]:''' [https://www.quectel.com/product/lte-eg25-g/ Quectel EG25-G]
** '''LTE-FDD''': B1, B2, B3, B4, B5, B7, B8, B12, B13, B18, B19, B20, B25, B26, B28
** '''LTE-TDD''': B38, B39, B40, B41
** '''WCDMA''': B1, B2, B4, B5, B6, B8, B19
** '''GSM''': B2, B3, B5, B8 (850, 900, 1800, 1900 MHz)
** '''WLAN & Bluetooth:''' Wi-Fi 802.11AC, hotspot capable + Bluetooth V5.0
** '''GNSS:''' GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS
* '''Sensors:''' Accelerometer, gyroscope, proximity, ambient light, compass
* '''Privacy switches:''' Modem, WiFi & Bluetooth, Microphone, Cameras
* '''[[#Battery|Battery]]:''' 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, USB Host, DisplayPort Alternate Mode output, 15W 5V 3A Quick Charge, follows USB PD specification

== Components ==

{| class="wikitable"
! Component
! Model
|-
| Touchscreen
| Goodix GT917S
|-
| LCD
| Himax HX8394 compatible
|-
| Rear camera
| IMX258
|-
| Front camera
| OV8858
|-
| Camera flash
| AW3641EDNR
|-
| WiFi + Bluetooth
| [https://www.azurewave.com/img/wireless-modules/AW_CM256SM_DS_Rev15_CYW.pdf AzureWave AW-CM256SM]
|-
| Modem
| [http://static.abstore.pl/design/accounts/soyter/img/dokumentacje/quectel_eg25-g.pdf Quectel EG25-G]
|-
| GNSS/GPS
| [http://static.abstore.pl/design/accounts/soyter/img/dokumentacje/quectel_eg25-g.pdf Quectel EG25-G]
|-
| 3 Axis Magnetometer
| [https://www.st.com/en/mems-and-sensors/lis3mdl.html ST LIS3MDL]
|-
| Geo Magnetic Sensor
| [http://www.voltafield.com/products01.html Voltafield AF8133J]
|-
| Ambient light / Proximity
| STK3311-A
|-
| Accelerometer / Gyroscope
| [https://invensense.tdk.com/products/motion-tracking/6-axis/mpu-6500/ TDK MPU-6500]
|-
| Vibration motor
|
|-
| Notification LED
| LED0603RGB
|-
| Audio Codec
| ALC5616 and ALC5640
|-
| Volume buttons
| Buttons connected to the KEYADC
|-
| Power button
|
|-
| Battery fuel gauge
| [https://rockchip.fr/RK818%20datasheet%20V1.0.pdf RK818]
|}

== Datasheets, schematics and certifications ==

* PinePhone Pro mainboard schematic:
** [https://files.pine64.org/doc/PinePhonePro/PinephonePro-Schematic-V1.0-20211127.pdf PinePhone Pro mainboard Explorer Edition Released Schematic ver 1.0 20211127]
** [https://files.pine64.org/doc/PinePhonePro/PinephonePro_PCB_Component_Placement-V02_20211127-top.pdf PinePhone Pro mainboard Explorer Edition component top placement ver 1.0 20211127]
** [https://files.pine64.org/doc/PinePhonePro/PinephonePro_PCB_Component_Placement-V02_20211127-bottom.pdf PinePhone Pro mainboard Explorer Edition component bottom placement ver 1.0 20211127]

* PinePhone Pro USB-C small board schematic:
** TBD

* Certifications:
** [https://files.pine64.org/doc/cert/PinePhone%20Pro%20FCC%20Certificate-S21101902805001.pdf PinePhone Pro FCC Certificate]
** [https://files.pine64.org/doc/cert/PinePhonePro%20SAR%20Evaluation%20Report-S21101902806001.pdf PinePhone Pro SAR Evaluation Report]
** [https://files.pine64.org/doc/cert/PinePhone%20Pro%20CE%20RED%20Certificate-S21101902802-R1.pdf PinePhone Pro CE RED Certificate]
** [https://files.pine64.org/doc/cert/PinePhonePro%20RoHS%20Test%20Report.pdf PinePhone Pro ROHS Test Report]

== Factory Test Build for Hardware Checking ==

* Please note that this Android build solely for PinePhone Pro hardware checking purpose and solely used by support team. This is NOT a general release build.
* DD image (for 8GB microSD Card or larger)
** [http://files.pine64.org/os/PinePhonePro/pinephone_pro_dd_android9_QC_Test_SDboot_20220215-8GB.img.gz Direct download from pine64.org]
*** MD5 (GZip file): 214e063c8205c1a98d44b2015a21bb5d
*** File Size: 722MB

* Download the build, extract the image and dd it to a 8 GB or larger microSD card, takes out the PinePhone Pro Explorer Edition then insert it into microSD slot (upper slot).
* Insert battery, press RE button (bypass SPI and eMMC boot) while plug in USB-C power. After 3 seconds release RE button.
* When power up, below battery icon screen show up and press power key for two second, the Rockchip logo screen shows up.

[[File:PPP_Abdroid_Test_Utility-1.jpg|300px]][[File:PPP_Abdroid_Test_Utility-2.jpg|300px]]

* Wait for home screen, double tap on the test app icon (mark red circuit) and this will bring up the factory test screen. Please note that SD test is disable due to this is a SD boot build.
* After running particular test function, please snapshot test result and pass back to support team
** Note: Please slot in functional Sim card when perform SIM test
** Note: When perform GPS test, the first result may fail and please ignore this false message.
** Note: For light sensing test, please have touch light shine to PinePhone Pro when perform test.

[[File:PPP_Abdroid_Test_Utility-4.jpg|300px]][[File:PPP_Abdroid_Test_Utility-5.jpg|538px]]

== Using Factory Test Build for Battery charging ==

* Please note that this Android build solely for PinePhone Pro hardware checking purpose and solely used by support team. This is NOT a general release build.
* DD image (for 8GB microSD Card or larger)
** [http://files.pine64.org/os/PinePhonePro/pinephone_pro_dd_android9_QC_Test_SDboot_20220215-8GB.img.gz Direct download from pine64.org]
*** MD5 (GZip file): 214e063c8205c1a98d44b2015a21bb5d
*** File Size: 722MB

* Download the build, extract the image and dd it to a 8 GB or larger microSD card, takes out the PinePhone Pro Explorer Edition then insert it into microSD slot (upper slot).
* Insert battery, press RE button (bypass SPI and eMMC boot) while plug in USB-C power. After 3 seconds release RE button.
* When power up, below battery icon screen show up and battery will start charging.
* The battery icon display for few seconds and then LCD panel turn off while charging. To check charging status, just quick press power button (about 0.5 second) and battery icon will display progress.

[[File:PPP_Abdroid_Test_Utility-1.jpg|300px]]

== Press ==

For an overview about media of the PinePhone Pro you can use for the news, blogs, or similar see [[PinePhone Press]].

== External links ==
* [https://www.pine64.org/pinephonepro/ Product Page]
* [https://www.youtube.com/watch?v=wP2-6Z74W44 Announcement video]
* [https://www.pine64.org/2021/10/15/october-update-introducing-the-pinephone-pro/ Blog post] with the announcement

[[Category:PinePhone Pro]][[Category:Rockchip RK3399]]

PinePhone Pro

2022-08-01T14:09:30Z

Megous: /* levinboot */

[[File:Pinephone_double.png|400px|thumb|right|Rendering of the PinePhone Pro]]

The '''PinePhone Pro''' is PINE64's flagship smartphone announced on October 15, 2021. It features 4GB of RAM, an 128GB eMMC and is using an Rockchip RK3399S SoC, which is a specialized version of the RK3399 made specifically for the PinePhone Pro.

== Introduction ==

The PinePhone Pro is PINE64’s second smartphone and a successor to the original PinePhone. It does not, however, replace the original PinePhone. It should also not be considered a second generation PinePhone; it is a higher-end device, with much better specs, aimed at those who wish to daily-drive a open system stack. Achieving this goal will, however, take time as the software and overall smartphone software ecosystem needs to mature.

More information about the PinePhone Pro can be found on the device [https://www.pine64.org/pinephonepro/ main page].

=== State of the software ===
([[PinePhone Pro Software State|view separately]])

{{:PinePhone Pro Software State}}

=== Editions and revisions ===
Similarly to the original PinePhone, various PinePhone Pro editions are planned, the first of which is the Developer Edition (aimed at developers, as the name entails) followed by the Explorer Edition, which is aimed at early adopters.

* [[PinePhone Pro Developer Edition]]
* [[PinePhone Pro Explorer Edition]]

=== Help and support ===

Still have any questions regarding software, shipping, or ordering after reading this Wiki? Please don't hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See [[Main Page#Community and Support]].

Please keep in mind that PINE64 is not like a regular company (see the [https://www.pine64.org/philosophy/ PINE64 philosophy]) and that support resources are limited - the best way to get support quickly is to ask in the community chat! Please only contact the PINE64 support directly if questions couldn't be solved via the community chat or this wiki.

== First time setup ==
[[File:Pinephone_warning.png|320px|thumb|right|A protection foil isolates the battery for the shipping.]]

When shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery '''will not''' charge or boot until it is removed and the battery is connected again.

{{Info|To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery.}}

The PinePhone's SIM slot only accepts a micro-SIM, please do not insert a nano-SIM without an adapter and make sure that the nano-SIM does not get released from its adapter. The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot.

{{Info|Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them!}}

[[File:Pinephone slots.png|600px|thumb|none|The microSD belongs in the upper slot, the micro-SIM in the lower slot.]]

An adapter from a nano to a micro-SIM might be included under tape in the camera notch of the phone's packaging. Some nano-SIMs will not fit firmly into that adapter that comes with the PinePhone and if the included adapter is used without a well-fitting nano-SIM, the contact pins might get damaged. In that case it is highly recommended to acquire a better fitting adapter.

== Software ==

The software section explains how to install the available software releases for the PinePhone Pro to the internal eMMC or a microSD card, how to boot them and how to solve common booting issues.

=== Software releases ===

The [[PinePhone Pro Software Releases]] page has a complete list of currently supported phone-optimized operating system images that work with the PinePhone Pro.

{{Info|Images of the regular PinePhone are not compatible with the PinePhone Pro.}}

=== Boot order ===

The RK3399S processor in the PinePhone Pro searches for the bootloader (such as ''U-Boot'') in the following order:

# SPI flash
# eMMC (the internal memory)
# MicroSD card

The bootloader uses its own boot order for loading the kernel and other core operating system components at boot, which for example may result in the boot loader residing on the eMMC loading and booting the kernel from a microSD card.

The SPI flash and the eMMC chip can be bypassed during boot by temporarily disabling them at the hardware level using the following method, which can be used in cases such as having corrupted installation on the SPI flash or the eMMC:

* On the '''Explorer Edition''' hold the ''RE'' button underneath the cover for a few seconds, while powering on the device.

* On the '''Developer Edition''', which was an earlier revision intended for developers only, the SPI and the eMMC can be bypassed by shorting the bypass test points while booting. The process is explained in the article [[PinePhone Pro Developer Edition#Nuking the factory AOSP installation|PinePhone Pro Developer Edition]]. Please join the community chat for any questions regarding the process.

The bypass disables the SPI and the eMMC while being applied and the PinePhone Pro will try to boot from the next available boot medium, which is the microSD card. Note: When holding the ''RE'' button (or when shorting the contact points in case of the ''Developer Edition'') for a longer time at boot the operating system will not initialize the SPI and eMMC and it will not be possible to write to these storage mediums until the next reboot.

{{Info|The bootloader (such as ''U-Boot'') resides in the free space in front of the first partition. Wiping the bootloader from the eMMC to make the PinePhone Pro boot from microSD card can be done using <code>sudo dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=400 conv=fsync</code>. Formatting the drive or deleting the partition table is not sufficient to wipe the bootloader.}}

See [[RK3399 boot sequence]] for details regarding the boot sequence.

=== Installation instructions ===

The software releases can be installed (the process is being referred to as ''flashing'') to the eMMC or to an microSD card.

==== Flashing to microSD card ====
To install an image to the microSD card:

# Download a compatible image from [[PinePhone Pro Software Releases]]
# Extract the compressed image
# Write the image to your microSD card using your favorite method, examples:
#* Using ''dd'': On the device you're flashing the microSD card from, find the correct device under <code>lsblk</code> and then flash the image to the microSD card using <code>sudo dd if='''IMAGE.img''' of=/dev/'''[DEVICE]''' bs=1M status=progress conv=fsync</code>. Make sure the target is the whole microSD card and not its first partition (''sdc1'' or ''mmcblk0p1'' are wrong!).
#* Using ''bmaptool'': Make sure to select the correct device using <code>lsblk</code>. Then run bmaptool with the correct device: Download the ''IMAGE.xz'' and the ''IMAGE.bmap'' files, then run <code>bmaptool copy --bmap '''IMAGE.bmap''' '''IMAGE.xz''' /dev/'''[DEVICE]'''</code>. This takes around 2.5 minutes to flash a 4 GB file.
#* Using ''a graphical tool'': A graphical tool such as Gnome Disks under Linux or Etcher under Windows may also be used.
# Insert the microSD card into the top slot of the PinePhone Pro. Make sure the microSD card is inserted all the way and that the notch of the right side of the microSD card is not visible anymore, see [[:File:Pinephone_slots.png|here]].
# Power on the PinePhone Pro. If there is an '''existing bootloader on the eMMC''' already you need to bypass or wipe the bootloader on the eMMC as explained in the section [[PinePhone Pro#Boot order|Boot order]].

==== Flashing to the eMMC ====
Flashing to the eMMC can be done by booting an operating system from the microSD (see the section [[PinePhone Pro#Flashing to microSD card|Flashing to microSD card]]) and by writing to the eMMC directly from there:

# Boot an operating system [[PinePhone Pro#Flashing to microSD card|from the microSD card]]. If there is already a bootloader on the eMMC installed see the section [[PinePhone Pro#Boot order|Boot order]] to bypass it
# Download or copy the desired image to the microSD card as file
# Check if the eMMC appears under <code>lsblk</code>. If it doesn't appear in the output of the command, the eMMC wasn't initialized due to applying the above explained bypass method for a too long time during the boot
# Extract the image
# Flash the extracted image using <code>sudo dd if='''IMAGE.img''' of=/dev/mmcblk2 bs=1M status=progress conv=fsync</code>
# Reboot the PinePhone Pro

=== Troubleshooting ===

If the PinePhone Pro is not booting (either booting incompletely into a boot splash or tty or if the PinePhone Pro is showing no signs of life) this will typically have the following two reasons:

==== The battery is fully drained ====
The bootloader ''U-Boot'' is currently booting into a boot loop if the battery is fully drained. In that case it is not possible to charge the phone. The battery can be charged by interrupting the boot loop by booting the PinePhone Pro into ''Maskrom mode'' or by charging the battery externally. To boot the PinePhone Pro into ''Maskrom mode'':

* Remove any microSD card from the phone and keep it removed for the below procedure
* Remove the battery, any USB cable and any serial cable
* Reinsert the battery
* Hold the ''RE'' button underneath the back cover of your ''Explorer Edition'' (or short the bypass contact points on the ''Developer Edition'')
{{Info|Confirm that the label of the button says ''RE'' and not ''RESET''! If the button label says ''RESET'' instead you probably have a regular PinePhone and you're reading the wrong page.}}
* Connect the phone to an USB port of a computer, while still holding the button for some time
* Check if the phone in Maskrom mode appears in the output of the terminal command <code>lsusb</code> on the computer, the expected ''VID:PID'' of the device is ''2207:330c'' (under ''Windows'' this can be checked using the ''Device Manager'' and checking the VID and PID of an appearing ''Unknown device'')
* Let the phone charge for at least two hours

{{Info|If the device doesn't appear under ''lsusb'' please try again with a different known good USB-C cable and make sure that there is no microSD card in the phone inserted.}}

The device should now be able to boot from the boot medium again. If that is not the case the installation got corrupted, as explained below.

==== The installation is corrupted ====
The PinePhone Pro won't be able to boot if the installation on the SPI flash, the eMMC or the microSD card got corrupted. To boot a working operating system:

* Prepare a microSD card as explained in the section [[PinePhone Pro#Flashing to microSD card|Flashing to microSD card]]
* Remove any USB-C cable or device or add-on case from the PinePhone Pro
* Make sure the device is powered off by shortly removing the battery for a second
* Insert the microSD card into the top slot of the PinePhone Pro. Make sure the microSD card is inserted all the way and that the notch of the right side of the microSD card is not visible anymore.
* Power on the device while bypassing the SPI and eMMC as explained under [[PinePhone Pro#Boot order|Boot order]]

The device should now boot from the microSD card. If the phone does not boot from the microSD card the microSD card was flashed with an incompatible image or the battery got drained as explained above.

=== Bootloaders ===
The following section contains notes regarding compatible bootloaders with the PinePhone Pro.

==== U-Boot ====
The pre-installed operating system on the PinePhone Pro Explorer Edition is using ''U-Boot'' as default bootloader.

==== Tow-Boot ====
There are plans to possibly ship the PinePhone Pro with ''Tow-Boot'' pre-installed to the SPI flash in a future batch, which is an opinionated distribution of ''U-Boot'' and brings numerous advantages over stock ''U-Boot'', such as the possibility to choose from booting the eMMC or microSD card using the volume buttons during boot, as well as a ''USB Mass Storage mode'', where the device can be written to by connecting the device to a computer via USB.

The user can flash Tow-Boot to the PinePhone Pro using the [https://tow-boot.org/devices/pine64-pinephonePro.html instructions on the Tow-Boot website].

==== levinboot ====
The levinboot bootloader is another option for the PinePhone Pro. The project repository can be found [https://gitlab.com/DeltaGem/levinboot/-/tree/master/ here]. (Pinephone Pro supporting fork is [https://xff.cz/git/levinboot/ here].)

== Privacy switch configuration ==

[[File:PinePhone Kill Interruptors de Maquinari del PinePhone 4529.jpg|320px|thumb|right|Picture of the privacy switches]]

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.

{| class="wikitable"
|-
! Number
! Name
! Description
|-
| 1
| Modem
| "On" enables 2G/3G/4G communication and GNSS hardware, "off" disables it.
|-
| 2
| WiFi / Bluetooth
| "On" enables WiFi and Bluetooth communication hardware, "off" disables it.
|-
| 3
| Microphone
| "On" enables audio input from on-board microphones (not 3.5 mm jack), "off" disables it.
|-
| 4
| Rear camera
| "On" enables the rear camera, "off" disables it.
|-
| 5
| Front camera
| "On" enables the front camera, "off" disables it.
|-
| 6
| Headphone
| "On" enables audio input and output via the 3.5 mm audio jack, "off" switches the jack to hardware UART¹ mode.
|}

¹ Note: The baud rate may be 1500000 instead of 115200.

== Specifications ==

* '''Dimensions:''' 160.8 x 76.6 x 11.1mm
* '''Weight:''' Approx. 220g
* '''SIM Card:''' Micro-SIM
* '''Display:'''
** '''Size:''' 6 inches (151mm) diagonal
** '''Type:''' 1440 x 720 in-cell IPS with Gorilla Glass 4™
** '''Resolution:''' 1440x720, 18:9 ratio
* '''System on Chip:''' Rockchip RK3399S 64bit SoC – 2x A72 and 4x A53 CPU cores @ 1.5GHz
* '''RAM:''' 4GB LPDDR4 @ 800MHz
* '''Internal Storage:''' 128GB eMMC, extendable up to 2TB via microSD, supports SDHC and SDXC
* '''NOR Flash:''' Listed as [GigaDevices] GD25LQ128EWIGR, but physical inspection found a SiliconKaiser SK25LP128.
* '''Back [[#Camera|Camera]]:''' 13MP Sony IMX258 with Gorilla Glass 4™ protective layer, LED Flash
* '''Front Camera:''' 8MP, OmniVision OV8858 front-facing camera
* '''Sound:''' Loudspeaker, 3.5mm jack & mic (jack doubles as hardware UART if hardware switch 6 is deactivated)
* '''Communication:'''
** '''[[#Modem|Modem]]:''' [https://www.quectel.com/product/lte-eg25-g/ Quectel EG25-G]
** '''LTE-FDD''': B1, B2, B3, B4, B5, B7, B8, B12, B13, B18, B19, B20, B25, B26, B28
** '''LTE-TDD''': B38, B39, B40, B41
** '''WCDMA''': B1, B2, B4, B5, B6, B8, B19
** '''GSM''': B2, B3, B5, B8 (850, 900, 1800, 1900 MHz)
** '''WLAN & Bluetooth:''' Wi-Fi 802.11AC, hotspot capable + Bluetooth V5.0
** '''GNSS:''' GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS
* '''Sensors:''' Accelerometer, gyroscope, proximity, ambient light, compass
* '''Privacy switches:''' Modem, WiFi & Bluetooth, Microphone, Cameras
* '''[[#Battery|Battery]]:''' 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, USB Host, DisplayPort Alternate Mode output, 15W 5V 3A Quick Charge, follows USB PD specification

== Components ==

{| class="wikitable"
! Component
! Model
|-
| Touchscreen
| Goodix GT917S
|-
| LCD
| Himax HX8394 compatible
|-
| Rear camera
| IMX258
|-
| Front camera
| OV8858
|-
| Camera flash
| AW3641EDNR
|-
| WiFi + Bluetooth
| [https://www.azurewave.com/img/wireless-modules/AW_CM256SM_DS_Rev15_CYW.pdf AzureWave AW-CM256SM]
|-
| Modem
| [http://static.abstore.pl/design/accounts/soyter/img/dokumentacje/quectel_eg25-g.pdf Quectel EG25-G]
|-
| GNSS/GPS
| [http://static.abstore.pl/design/accounts/soyter/img/dokumentacje/quectel_eg25-g.pdf Quectel EG25-G]
|-
| 3 Axis Magnetometer
| [https://www.st.com/en/mems-and-sensors/lis3mdl.html ST LIS3MDL]
|-
| Geo Magnetic Sensor
| [http://www.voltafield.com/products01.html Voltafield AF8133J]
|-
| Ambient light / Proximity
| STK3311-A
|-
| Accelerometer / Gyroscope
| [https://invensense.tdk.com/products/motion-tracking/6-axis/mpu-6500/ TDK MPU-6500]
|-
| Vibration motor
|
|-
| Notification LED
| LED0603RGB
|-
| Audio Codec
| ALC5616 and ALC5640
|-
| Volume buttons
| Buttons connected to the KEYADC
|-
| Power button
|
|-
| Battery fuel gauge
| [https://rockchip.fr/RK818%20datasheet%20V1.0.pdf RK818]
|}

== Datasheets, schematics and certifications ==

* PinePhone Pro mainboard schematic:
** [https://files.pine64.org/doc/PinePhonePro/PinephonePro-Schematic-V1.0-20211127.pdf PinePhone Pro mainboard Explorer Edition Released Schematic ver 1.0 20211127]
** [https://files.pine64.org/doc/PinePhonePro/PinephonePro_PCB_Component_Placement-V02_20211127-top.pdf PinePhone Pro mainboard Explorer Edition component top placement ver 1.0 20211127]
** [https://files.pine64.org/doc/PinePhonePro/PinephonePro_PCB_Component_Placement-V02_20211127-bottom.pdf PinePhone Pro mainboard Explorer Edition component bottom placement ver 1.0 20211127]

* PinePhone Pro USB-C small board schematic:
** TBD

* Certifications:
** [https://files.pine64.org/doc/cert/PinePhone%20Pro%20FCC%20Certificate-S21101902805001.pdf PinePhone Pro FCC Certificate]
** [https://files.pine64.org/doc/cert/PinePhonePro%20SAR%20Evaluation%20Report-S21101902806001.pdf PinePhone Pro SAR Evaluation Report]
** [https://files.pine64.org/doc/cert/PinePhone%20Pro%20CE%20RED%20Certificate-S21101902802-R1.pdf PinePhone Pro CE RED Certificate]
** [https://files.pine64.org/doc/cert/PinePhonePro%20RoHS%20Test%20Report.pdf PinePhone Pro ROHS Test Report]

== Factory Test Build for Hardware Checking ==

* Please note that this Android build solely for PinePhone Pro hardware checking purpose and solely used by support team. This is NOT a general release build.
* DD image (for 8GB microSD Card or larger)
** [http://files.pine64.org/os/PinePhonePro/pinephone_pro_dd_android9_QC_Test_SDboot_20220215-8GB.img.gz Direct download from pine64.org]
*** MD5 (GZip file): 214e063c8205c1a98d44b2015a21bb5d
*** File Size: 722MB

* Download the build, extract the image and dd it to a 8 GB or larger microSD card, takes out the PinePhone Pro Explorer Edition then insert it into microSD slot (upper slot).
* Insert battery, press RE button (bypass SPI and eMMC boot) while plug in USB-C power. After 3 seconds release RE button.
* When power up, below battery icon screen show up and press power key for two second, the Rockchip logo screen shows up.

[[File:PPP_Abdroid_Test_Utility-1.jpg|300px]][[File:PPP_Abdroid_Test_Utility-2.jpg|300px]]

* Wait for home screen, double tap on the test app icon (mark red circuit) and this will bring up the factory test screen. Please note that SD test is disable due to this is a SD boot build.
* After running particular test function, please snapshot test result and pass back to support team
** Note: Please slot in functional Sim card when perform SIM test
** Note: When perform GPS test, the first result may fail and please ignore this false message.
** Note: For light sensing test, please have touch light shine to PinePhone Pro when perform test.

[[File:PPP_Abdroid_Test_Utility-4.jpg|300px]][[File:PPP_Abdroid_Test_Utility-5.jpg|538px]]

== Using Factory Test Build for Battery charging ==

* Please note that this Android build solely for PinePhone Pro hardware checking purpose and solely used by support team. This is NOT a general release build.
* DD image (for 8GB microSD Card or larger)
** [http://files.pine64.org/os/PinePhonePro/pinephone_pro_dd_android9_QC_Test_SDboot_20220215-8GB.img.gz Direct download from pine64.org]
*** MD5 (GZip file): 214e063c8205c1a98d44b2015a21bb5d
*** File Size: 722MB

* Download the build, extract the image and dd it to a 8 GB or larger microSD card, takes out the PinePhone Pro Explorer Edition then insert it into microSD slot (upper slot).
* Insert battery, press RE button (bypass SPI and eMMC boot) while plug in USB-C power. After 3 seconds release RE button.
* When power up, below battery icon screen show up and battery will start charging.
* The battery icon display for few seconds and then LCD panel turn off while charging. To check charging status, just quick press power button (about 0.5 second) and battery icon will display progress.

[[File:PPP_Abdroid_Test_Utility-1.jpg|300px]]

== Press ==

For an overview about media of the PinePhone Pro you can use for the news, blogs, or similar see [[PinePhone Press]].

== External links ==
* [https://www.pine64.org/pinephonepro/ Product Page]
* [https://www.youtube.com/watch?v=wP2-6Z74W44 Announcement video]
* [https://www.pine64.org/2021/10/15/october-update-introducing-the-pinephone-pro/ Blog post] with the announcement

[[Category:PinePhone Pro]][[Category:Rockchip RK3399]]

PinePhone (Pro) Keyboard

2022-01-12T11:54:45Z

Megous: /* Frequently asked questions */ Add hashes

{{Under construction}}

[[File:PP_KB_Front-1024x576.jpg|400px|thumb|right|Picture of the PinePhone (Pro) Keyboard]]

The '''PinePhone (Pro) Keyboard Case''' is a case compatible with the PinePhone and PinePhone Pro, adding a keyboard functionality to the phone. It features a clam-shell design and uses the pogo pins located on the smartphone’s midsection and attaches by replacing the default back cover. This add-on effectively turns the PinePhone (Pro) into a PDA with an in-built LTE modem.

== Getting started ==
[[File:Ppkb_description.png|thumb|upright=1.2|]]

The keyboard case works with both the PinePhone and PinePhone Pro and features a clam-shell design. It uses pogo pins located on the phone’s midsection and attaches by replacing the default back cover. When folded, the phone’s screen and the keyboard rest securely against each other. The hinge features a 180° design, which not only allows for two-hand typing on a surface but also for comfortable thumb-typing when fully extended. The etched keycaps can be easily relocated for alternate layouts such as AZERTY or QWERTZ. The keyboard case runs an [https://xff.cz/git/pinephone-keyboard/ open firmware], which means that anyone with the know-how can alter existing functions or add new ones. The bottom (keyboard) and top (phone) sections of the assembly are well-balanced thanks to the large, 6000mAh, internal battery capable of charging the PinePhone (Pro) during operation. The internal battery effectively triples the phone’s battery life. The internal keyboard battery can be manually toggled on/off and the keyboard’s battery charge level can be read in the supported OSes; the keyboard remains functional with the battery fully depleted.

You do not lose access to the PinePhone (Pro)’s USB-C port, speaker, microphone, or any external features, such as volume and lock buttons, with the keyboard attached. There is also a cut-out for the camera, torch, and headphone jack. The USB-C port on the keyboard is capable of powering both the keyboard and PinePhone (Pro) simultaneously. This means that you can plug in a USB mouse, a USB-C dongle, or some other peripheral while the phone and keyboard’s internal battery charge. Please keep in mind that the keyboard case transforms the PinePhone (Pro) into a PDA, which means that taking calls will likely prove awkward without a wired or wireless headset connected.

=== Mounting the keyboard ===
Power OFF your PinePhone and remove the back case. To remove the back case of the PinePhone use your fingernail or another soft object to pry up the back case. A notch to easily remove the cover is located at the bottom left of the PinePhone with the backcover facing the user.

Open and place the keyboard flat on a hard surface with the hinge fully extended. Proceed to insert the PinePhone into the keyboard at an angle of approx. 15 degrees. Make sure that the PinePhone’s pogo pins and the corresponding pads ① on the keyboard are aligned. The leading edge with volume and power buttons should make contact first. Firmly press the PinePhone into place. Multiple clicks should be heard as the two snap into place.

The PinePhone can be removed from the keyboard easily using a notch similar to the one found on the back case. The notch is located at the bottom of the leading edge with the power and volume buttons.

=== Keyboard and internal battery operation ===
The keyboard will function automatically once a PinePhone running a compatible operating system is mounted. For alterations to physical layout and firmware see the relevant sections respectively.

The keyboard features an in-built 6000mAh battery. The battery can be turned ON/OFF using the button on the right leading edge of the keyboard ②. A short button press activates the internal battery while a long (15 seconds) press deactivates it. Compatible operating systems display both the PinePhone’s and keyboard’s battery status.

You should charge the PinePhone and the keyboard only using the USB-C ③ port on the keyboard. The keyboard’s USB-C port cannot be used for peripherals. The PinePhone’s USB-C port remains operational when mounted in the keyboard and can be used for data and peripherals.

== Software support ==

=== Kernel-space driver ===
=== User-space driver ===

== Keyboard layout ==
The keyboard features a default layout (pictured below) created and agreed upon by the community. The keyboard layout can be altered using software as well as by physically repositioning keycaps. All keycaps, with the exception of space and return keys, can be easily and safely relocated for alternative layouts corresponding to software settings.

<gallery mode="nolines" widths="800px" heights="400px">
Image:Ppkb_layout2.png|The keyboard layout how the keys were originally intended
</gallery>

== Keyboard firmware ==
PinePhone’s keyboard firmware was developed independently by Ondřej Jirman as a free-of-charge contribution to PINE64. The firmware source code is freely and publicly available and you can modify it, and the supporting utilities, using common FOSS tools.

=== Firmware and supporting utilities ===
The design of the firmware allows the keys, modifier keys, and their combinations to be handled in virtually unlimited ways, without a need to flash a customized version of the firmware. Mapping of keys is defined at runtime, using the supporting utilities, and is not hardcoded in the firmware. Different keyboard layouts can be loaded dynamically to support various use cases.

The repository that contains the source code of the firmware, supporting utilities and associated documentation is located at https://xnux.eu/pinephone-keyboard/.

You are welcome to contribute patches and improvements to the firmware and the supporting utilities. A summary of firmware development history is available at https://xnux.eu/log/ alongside other development updates from the firmware author.

Much time and effort went into the development of this firmware. If you wish to send a token of appreciation or support the development efforts in any way, please consider making a donation to the author via one of the methods listed at the bottom of this web page: https://xnux.eu/contribute.html.

=== Firmware License ===

<blockquote>Copyright (C) 2021 Ondřej Jirman <megi@xff.cz>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, with either version 3 of the License or
(at your discretion) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See GNU General Public License for more details.

GNU General Public License http://www.gnu.org/licenses/</blockquote>

== Hardware ==
Detailed keyboard specifications including schematics can be found on our Wiki: https://wiki.pine64.org/wiki/PinePhoneKeyboard

Key hardware specifications:
* Dimensions (closed): 161 x 95 x 21.5mm
* Weights (without / with PinePhone mounted): ~ 191 / ~391 grams
* Number of keys: 54
* Number of rows: 5
** Keyboard IC: Keyboard IC: EM85F684A 8-bit microcontroller with 256 bytes RAM, 2048/ bytes XRAM; 16kB for user’s own firmware
* Battery capacity: 6000mAh (22.2Wh 3.7V)
* Charger input: 5V, 3A (15W)
** Charging and battery IC chip: IP5209 power management IC with charge indicate controller and boost converter

== Safety ==
TODO

== Frequently asked questions ==
{{Under construction}}

''' The keyboard does not work under OSK-SDL (full-disk encryption UI at boot) ''' 
That is a known bug, see https://gitlab.com/postmarketOS/pmaports/-/issues/1383.

''' What is the keyboard driver situation? ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#drivers

''' Are keyboard drivers included in my distribution? ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#distros

''' What's the status of the existing software for the keyboard? ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#sw-status

''' My keyboard doesn't work (well)! ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#faq-ts

''' How does charging work? ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#charging

''' What charger is best for the keyboard? ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#chargers

''' How safe is the charger circuit in the keyboard? ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#safety

''' Keyboard doesn't react to any key presses ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#ts

''' Keyboard works but top row of keys is less responsive ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#ts

''' Phone is not charging from the keyboard ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#ts

''' Phone is charging slowly from the keyboard battery ''' 
See https://xnux.eu/pinephone-keyboard/faq.html#ts

== External links ==
* [https://wiki.pine64.org/wiki/File:USER_MANUAL-KEYBOARD-V2-EN-DE-FR-ES.pdf The official keyboard manual]
* [https://www.pine64.org/2022/01/11/pinephone-pro-explorer-edition-pre-orders-open-january-11/ Pre-order announcement]
* FAQ of the developer megous: https://xnux.eu/pinephone-keyboard/faq.html

PinePhone Pro Development

2021-11-17T01:52:01Z

Megous: /* Levinboot Based Kernel Development Image */ Fix links

This page documents the current status of software support for the [[PinePhone Pro]], and provides links to resources to help prospective contributors get started.

== Overview ==

=== Upstreaming Status ===

{| class="wikitable plainrowheaders" border="1"
! scope="col" | Function
! scope="col" colspan="2" | Status
! scope="col" | Component
! scope="col" | Notes
|-
! scope="row" | TBD
| colspan="2" style="background:#F99; text-align:center;"|...
| <code>...</code>
|
|}

== Current Status ==

The following sections give an overview over the current status of different parts of the phone. Some parts are waiting on a driver to be written or ported, others only need various adjustments.

=== Working ===

TBD

=== Linux kernel ===

There's no canonical location for Pinephone Pro Linux kernel development, because Pinephone Pro DT is not mainline, yet. [https://xff.cz/git/linux/log/?h=orange-pi-5.16 megi's kernel tree] is the most complete one, as of November 2021.

== Levinboot Based Kernel Development Image ==

This guide will help you get a comfortable environment for testing your kernel builds on Pinephone Pro. It assumes you either already know how to build or cross-build a Linux kernel for arm64, or if you have a way to get a pre-built kernel from somewhere. For a quick test that your setup works, you can use [https://xff.cz/kernels/ megi's pre-built kernels].

Quick and easy way to get started with kernel development and testing is to use CrystalGamma's Levinboot patched with support for Pinephone Pro and 3-option boot selection using volume keys. [https://xnux.eu/log/#049 You will be able to switch between kernels quickly without swapping uSD cards, which is necessary for painless kernel development experience.]

1) Create a following partitioning scheme on a uSD card using <code>sfdisk</code>:

<pre>
label: gpt
first-lba: 64
table-length: 8

start=64, size=8128, type=D7B1F817-AA75-2F4F-830D-84818A145370, name="sd-lboot"
size=60M, type=E5AB07A0-8E5E-46F6-9CE8-41A518929B7C, name="sd-lpayload1"
size=60M, type=5f04b556-c920-4b6d-bd77-804efe6fae01, name="sd-lpayload2"
size=60M, type=c195cc59-d766-4b78-813f-a0e1519099d8, name="sd-lpayload3"
size=14G name="sd-rootfs1"
name="sd-rootfs2"
</pre>

2) Write Levinboot to <code>sd-lboot</code> partition using <code>dd</code>. You can get a pre-built and tested version [https://xff.cz/kernels/pinephone-pro/ here] There are two options <code>levinboot-sd.img</code> and <code>levinboot-emmc.img</code> you can use either one of them for your <code>sd-lboot</code> partition. They differ in where they load the payloads from (either from SD or eMMC) and not in where they can be flashed to. For uSD card only workflow, you'll want <code>levinboot-sd.img</code>.

3) Prepare payloads for Levinboot and copy them to appropriate partitions. Partition <code>sd-lpayload1</code> is used by default, <code>sd-lpayload2</code> when you hold a volume down key during powerup, and <code>sd-lpayload3</code> when you hold the volume up key.

Preparing a payload involves getting a TF-A <code>bl31.elf</code> build, kernel <code>Image</code> build, <code>DTB</code> file for Pinephone Pro, and optionally an initramfs archive, modifying DTB to include kernel boot arguments, and compressing these using <code>lz4</code> in specific order, as shown below.

<pre>
BOOTOPTS=(
console=tty1

earlycon=uart8250,mmio32,0xff1a0000
console=ttyS2,1500000n8

root=PARTLABEL=emmc-rootfs1
rootfstype=f2fs
rootflags=fastboot
rootwait
rw

loglevel=7
)

BOOTOPTS="${BOOTOPTS[@]}"
ALGO="lz4 -zc"

cp -f rk3399-pinephone-pro.dtb board-cfg.dtb
fdtput -pt s board-cfg.dtb /chosen bootargs "$BOOTOPTS"

(
$ALGO bl31.elf
$ALGO board-cfg.dtb
$ALGO Image
# $ALGO initramfs.img
) > payload.img

dd if=payload.img of=/dev/disk/by-partlabel/sd-payload1 bs=4M oflag=direct
</pre>

4) Prepare root filesystem. You can use any Linux distribution for aarch64 for development. For example if you want to use Arch Linux ARM, you would need to format the <code>sd-rootfs1</code> partition with <code>f2fs</code> filesystem and extract the Arch Linux ARM rootfs tarball there. That will give you a bootable SD card image for Pinephone Pro.

5) Repeat steps 3 and 4 if you want either more kernel payloads, or more Linux distributions on the same uSD card. I recommend having at least some module-less working kernel in <code>sd-payload3</code> and perhaps a small userspace in <code>sd-rootfs1</code> with a pre-configured WiFi connection, that will allow you to always quickly recover if your development kernel fails to boot, just by pressing volume up key during boot and updating the the kernel in one of the primary payload partitions over WiFi.

== Development discussion ==

Most of the discussion happens in #pinedev channel on [https://www.pine64.org/web-irc/ Pine64 IRC server]

[[Category:Pinephone Pro]][[Category:Rockchip RK3399]]

PinePhone Pro

2021-11-17T01:49:08Z

Megous: /* Developer works */

PinePhone Pro

2021-11-17T01:48:52Z

Megous: /* Developer works */

PinePhone Pro Development

2021-11-17T01:48:07Z

Megous: Fix link

This page documents the current status of software support for the [[PinePhone Pro]], and provides links to resources to help prospective contributors get started.

== Overview ==

=== Upstreaming Status ===

{| class="wikitable plainrowheaders" border="1"
! scope="col" | Function
! scope="col" colspan="2" | Status
! scope="col" | Component
! scope="col" | Notes
|-
! scope="row" | TBD
| colspan="2" style="background:#F99; text-align:center;"|...
| <code>...</code>
|
|}

== Current Status ==

The following sections give an overview over the current status of different parts of the phone. Some parts are waiting on a driver to be written or ported, others only need various adjustments.

=== Working ===

TBD

=== Linux kernel ===

There's no canonical location for Pinephone Pro Linux kernel development, because Pinephone Pro DT is not mainline, yet. [https://xff.cz/git/linux/log/?h=orange-pi-5.16 megi's kernel tree] is the most complete one, as of November 2021.

== Levinboot Based Kernel Development Image ==

This guide will help you get a comfortable environment for testing your kernel builds on Pinephone Pro. It assumes you either already know how to build or cross-build a Linux kernel for arm64, or if you have a way to get a pre-built kernel from somewhere. For a quick test that your setup works, you can use [https://xff.cz/kernels/ megi's pre-built kernels].

Quick and easy way to get started with kernel development and testing is to use CrystalGamma's Levinboot patched with support for Pinephone Pro and 3-option boot selection using volume keys. [https://xnux.eu/log/#049 You will be able to switch between kernels quickly without swapping uSD cards, which is necessary for painless kernel development experience.]

1) Create a following partitioning scheme on a uSD card using <code>sfdisk</code>:

<pre>
label: gpt
first-lba: 64
table-length: 8

start=64, size=8128, type=D7B1F817-AA75-2F4F-830D-84818A145370, name="sd-lboot"
size=60M, type=E5AB07A0-8E5E-46F6-9CE8-41A518929B7C, name="sd-lpayload1"
size=60M, type=5f04b556-c920-4b6d-bd77-804efe6fae01, name="sd-lpayload2"
size=60M, type=c195cc59-d766-4b78-813f-a0e1519099d8, name="sd-lpayload3"
size=14G name="sd-rootfs1"
name="sd-rootfs2"
</pre>

2) Write Levinboot to <code>sd-lboot</code> partition using <code>dd</code>. You can get a pre-built and tested version [https://xff.cz/kernels/ here] There are two options <code>levinboot-sd.img</code> and <code>levinboot-emmc.img</code> you can use either one of them for your <code>sd-lboot</code> partition. They differ in where they load the payloads from (either from SD or eMMC) and not in where they can be flashed to. For uSD card only workflow, you'll want <code>levinboot-sd.img</code>.

3) Prepare payloads for Levinboot and copy them to appropriate partitions. Partition <code>sd-lpayload1</code> is used by default, <code>sd-lpayload2</code> when you hold a volume down key during powerup, and <code>sd-lpayload3</code> when you hold the volume up key.

Preparing a payload involves getting a TF-A <code>bl31.elf</code> build, kernel <code>Image</code> build, <code>DTB</code> file for Pinephone Pro, and optionally an initramfs archive, modifying DTB to include kernel boot arguments, and compressing these using <code>lz4</code> in specific order, as shown below.

<pre>
BOOTOPTS=(
console=tty1

earlycon=uart8250,mmio32,0xff1a0000
console=ttyS2,1500000n8

root=PARTLABEL=emmc-rootfs1
rootfstype=f2fs
rootflags=fastboot
rootwait
rw

loglevel=7
)

BOOTOPTS="${BOOTOPTS[@]}"
ALGO="lz4 -zc"

cp -f rk3399-pinephone-pro.dtb board-cfg.dtb
fdtput -pt s board-cfg.dtb /chosen bootargs "$BOOTOPTS"

(
$ALGO bl31.elf
$ALGO board-cfg.dtb
$ALGO Image
# $ALGO initramfs.img
) > payload.img

dd if=payload.img of=/dev/disk/by-partlabel/sd-payload1 bs=4M oflag=direct
</pre>

4) Prepare root filesystem. You can use any Linux distribution for aarch64 for development. For example if you want to use Arch Linux ARM, you would need to format the <code>sd-rootfs1</code> partition with <code>f2fs</code> filesystem and extract the Arch Linux ARM rootfs tarball there. That will give you a bootable SD card image for Pinephone Pro.

5) Repeat steps 3 and 4 if you want either more kernel payloads, or more Linux distributions on the same uSD card. I recommend having at least some module-less working kernel in <code>sd-payload3</code> and perhaps a small userspace in <code>sd-rootfs1</code> with a pre-configured WiFi connection, that will allow you to always quickly recover if your development kernel fails to boot, just by pressing volume up key during boot and updating the the kernel in one of the primary payload partitions over WiFi.

== Development discussion ==

Most of the discussion happens in #pinedev channel on [https://www.pine64.org/web-irc/ Pine64 IRC server]

[[Category:Pinephone Pro]][[Category:Rockchip RK3399]]

PinePhone Pro Development

2021-11-17T01:46:11Z

Megous: Added initial page about starting with Pinephone Pro kernel development

This page documents the current status of software support for the [[Pinephone Pro]], and provides links to resources to help prospective contributors get started.

== Overview ==

=== Upstreaming Status ===

{| class="wikitable plainrowheaders" border="1"
! scope="col" | Function
! scope="col" colspan="2" | Status
! scope="col" | Component
! scope="col" | Notes
|-
! scope="row" | TBD
| colspan="2" style="background:#F99; text-align:center;"|...
| <code>...</code>
|
|}

== Current Status ==

The following sections give an overview over the current status of different parts of the phone. Some parts are waiting on a driver to be written or ported, others only need various adjustments.

=== Working ===

TBD

=== Linux kernel ===

There's no canonical location for Pinephone Pro Linux kernel development, because Pinephone Pro DT is not mainline, yet. [https://xff.cz/git/linux/log/?h=orange-pi-5.16 megi's kernel tree] is the most complete one, as of November 2021.

== Levinboot Based Kernel Development Image ==

This guide will help you get a comfortable environment for testing your kernel builds on Pinephone Pro. It assumes you either already know how to build or cross-build a Linux kernel for arm64, or if you have a way to get a pre-built kernel from somewhere. For a quick test that your setup works, you can use [https://xff.cz/kernels/ megi's pre-built kernels].

Quick and easy way to get started with kernel development and testing is to use CrystalGamma's Levinboot patched with support for Pinephone Pro and 3-option boot selection using volume keys. [https://xnux.eu/log/#049 You will be able to switch between kernels quickly without swapping uSD cards, which is necessary for painless kernel development experience.]

1) Create a following partitioning scheme on a uSD card using <code>sfdisk</code>:

<pre>
label: gpt
first-lba: 64
table-length: 8

start=64, size=8128, type=D7B1F817-AA75-2F4F-830D-84818A145370, name="sd-lboot"
size=60M, type=E5AB07A0-8E5E-46F6-9CE8-41A518929B7C, name="sd-lpayload1"
size=60M, type=5f04b556-c920-4b6d-bd77-804efe6fae01, name="sd-lpayload2"
size=60M, type=c195cc59-d766-4b78-813f-a0e1519099d8, name="sd-lpayload3"
size=14G name="sd-rootfs1"
name="sd-rootfs2"
</pre>

2) Write Levinboot to <code>sd-lboot</code> partition using <code>dd</code>. You can get a pre-built and tested version [https://xff.cz/kernels/ here] There are two options <code>levinboot-sd.img</code> and <code>levinboot-emmc.img</code> you can use either one of them for your <code>sd-lboot</code> partition. They differ in where they load the payloads from (either from SD or eMMC) and not in where they can be flashed to. For uSD card only workflow, you'll want <code>levinboot-sd.img</code>.

3) Prepare payloads for Levinboot and copy them to appropriate partitions. Partition <code>sd-lpayload1</code> is used by default, <code>sd-lpayload2</code> when you hold a volume down key during powerup, and <code>sd-lpayload3</code> when you hold the volume up key.

Preparing a payload involves getting a TF-A <code>bl31.elf</code> build, kernel <code>Image</code> build, <code>DTB</code> file for Pinephone Pro, and optionally an initramfs archive, modifying DTB to include kernel boot arguments, and compressing these using <code>lz4</code> in specific order, as shown below.

<pre>
BOOTOPTS=(
console=tty1

earlycon=uart8250,mmio32,0xff1a0000
console=ttyS2,1500000n8

root=PARTLABEL=emmc-rootfs1
rootfstype=f2fs
rootflags=fastboot
rootwait
rw

loglevel=7
)

BOOTOPTS="${BOOTOPTS[@]}"
ALGO="lz4 -zc"

cp -f rk3399-pinephone-pro.dtb board-cfg.dtb
fdtput -pt s board-cfg.dtb /chosen bootargs "$BOOTOPTS"

(
$ALGO bl31.elf
$ALGO board-cfg.dtb
$ALGO Image
# $ALGO initramfs.img
) > payload.img

dd if=payload.img of=/dev/disk/by-partlabel/sd-payload1 bs=4M oflag=direct
</pre>

4) Prepare root filesystem. You can use any Linux distribution for aarch64 for development. For example if you want to use Arch Linux ARM, you would need to format the <code>sd-rootfs1</code> partition with <code>f2fs</code> filesystem and extract the Arch Linux ARM rootfs tarball there. That will give you a bootable SD card image for Pinephone Pro.

5) Repeat steps 3 and 4 if you want either more kernel payloads, or more Linux distributions on the same uSD card. I recommend having at least some module-less working kernel in <code>sd-payload3</code> and perhaps a small userspace in <code>sd-rootfs1</code> with a pre-configured WiFi connection, that will allow you to always quickly recover if your development kernel fails to boot, just by pressing volume up key during boot and updating the the kernel in one of the primary payload partitions over WiFi.

== Development discussion ==

Most of the discussion happens in #pinedev channel on [https://www.pine64.org/web-irc/ Pine64 IRC server]

[[Category:Pinephone Pro]][[Category:Rockchip RK3399]]

PinePhone Software Releases

2020-11-25T01:41:55Z

Megous: /* Multi-boot image with 13 distributions */

This page contains a list of all available releases for the PinePhone as well as links to further resources.

See [[PinePhone Installation Instructions]] on how to install the operating systems.

Note: Some releases may not have a good setup for the backlight at low brightness. If configured too low the backlight shuts down completely, but the screen is still displayed and usable in bright front-light.

= Software Releases =
This is a list of OSes that specifically support the PinePhone, but as support is included in Mainline Linux, in principle any ARM Linux OS can be used, if possible required patches are included.

== postmarketOS ==
[[File:PostmarketOS-logo.png|100px]]

postmarketOS is a preconfigured version of [https://www.alpinelinux.org/ Alpine Linux] for mobile devices that offers a choice of several desktop environments including Plasma Mobile and Phosh.

* ''' Download location '''
Rather than downloading a demo image, postmarketOS [https://wiki.postmarketos.org/wiki/Installation_guide recommends the use of their script], pmbootstrap, that can tailor build your SD card for you.

Note: pmbootstrap offers an option [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone)#Installation to install to the eMMC].

Demo images can be found [http://images.postmarketos.org/pinephone/ here].

* ''' username/password '''
demo/147147 (for demo images only - when building an image with pmbootstrap you set your own username and password (the Phosh lock screen requires your password, but only presents a numeric keyboard, so you should use only numbers in your password).

* ''' What works, what does not work '''
See [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone) postmarketOS dedicated PinePhone wiki page]

If you install Firefox browser (or are using a demo image that already has it installed) then [https://wiki.postmarketos.org/wiki/Firefox these hints] in the pmOS wiki are recommended.

* ''' How to contribute and report defects '''
[https://gitlab.com/postmarketOS/postmarketos/issues/3 postmarketOS issue tracker] for PinePhone support. See [https://wiki.postmarketos.org/wiki/Contributing postmarketOS wiki] for options to contribute.

=== Factory-loaded PostMarketOS build with testing utility ===

* This is a PostMarketOS build that was preloaded in the factory with testing utility.
* Download the build, extract the image and dd it to the microSD and then insert it into the phone. Power up the PinePhone, perform and complete the test routine, then apply the build from microSD card to eMMC.
* dd the image on a 8 GB micoSD card or larger.
** [https://files.pine64.org/os/PinePhone/PostMarketOS/pine64-pinephone-20200726-phosh-v20.05-factory.img.xz Direct download from pine64.org]
*** MD5 (XZip file): 244093be2f6d728fcbd1d29114607727
*** File Size: 517MB

== Ubuntu Touch by UBports ==
[[File:Ubports-logo.png|100px]]

A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community.

Ubuntu touch is a mobile version of Ubuntu developed by the UBports community. Installation instructions can be found on [https://gitlab.com/ubports/community-ports/pinephone#how-do-i-install-ubuntu-touch-on-my-pinephone the UBports PinePhone project]. There is also a [https://github.com/goddard/pinephone/ script] to download the latest image and flash to your PinePhone. In the future, Ubuntu Touch will be able to be installed onto the PinePhone with the [https://devices.ubuntu-touch.io/installer UBports installer] GUI tool.

* ''' Download location '''
[https://gitlab.com/ubports/community-ports/pinephone#how-do-i-install-ubuntu-touch-on-my-pinephone UBports PinePhone project]

* ''' username/password '''
Set up during boot

* ''' What works, what does not work '''
Scroll down to the bottom of [https://gitlab.com/ubports/community-ports/pinephone this page].

* ''' How to contribute and report defects '''
See [https://gitlab.com/ubports/community-ports/pinephone UBports gitlab page]. See [https://ubports.com/foundation/sponsors UBports website] for how to donate.

=== Factory-loaded UBPorts OS build with testing utility ===

* This is an UBPorts OS build that was preloaded in the factory with testing utility.
* Download the build, extract the image and dd it to the microSD and then insert it into the phone. Power up the PinePhone, perform and complete the test routine, then apply the build from microSD card to eMMC.
* dd the image on a 8 GB micoSD card or larger.
** [https://files.pine64.org/os/PinePhone/UBPorts/PinePhone-flasher-ubuntu-7b.img.gz Direct download from pine64.org]
*** MD5 (GZip file): 2d7f5271e7a281db8f1b1219bedbe131
*** File Size: 1.05GB

== Mobian ==
[[File:Debian-logo.png]]

An unofficial Debian build for ARM64 running with the Phosh user interface (developed by Purism, Phosh uses Wayland instead of Xorg). The base system is pure Debian, with only the GUI applications and a few others (ModemManager, WiFi chip firmware) being built from modified sources (as well as the kernel and u-boot). Current version is Debian Bullseye.

* ''' Download location '''
[http://images.mobian-project.org/ Mobian downloadable images]

Don't forget to extract the image before installing:
$ gzip -d Downloads/mobian-pinephone-*.img.gz

See the [https://wiki.mobian-project.org/doku.php?id=install project page] for specific installation instructions.

* ''' username/password '''
mobian/1234

* ''' What works, what does not work '''

See [https://gitlab.com/mobian1/mobian-recipes/-/blob/master/README.md the project's README file] or [https://wiki.mobian-project.org/doku.php?id=pinephone the wiki]for most up to date status.

Check [https://gitlab.com/a-wai/debos-pinephone/-/issues bug tracker] for known issues. Questions? Ask on our [https://forum.pine64.org/showthread.php?tid=9016 thread].

* ''' How to contribute and report defects '''
It is recommended that you log your bug reports in [https://gitlab.com/mobian1/issues the project's issue tracker]. As a general rule, issues with third-party apps (even the default ones) should be reported upstream. A Mobian issue would be related to getting the hardware to work on the PinePhone, but if unsure where the issue should be reported just open a ticket or ask. Feel free to pick an open issue to work on, or send a merge request on [https://gitlab.com/mobian1 Gitlab].

* ''' Notes '''
See [[Mobian for PinePhone]] or [https://wiki.mobian-project.org/doku.php?id=start the wiki] for additional information regarding screen resolution, USB networking, WiFi hotspot, Chatty and the repository.

== SailfishOS ==
[[File:Sailfish_logo.png|150px]]

Sailfish OS is a Linux-based operating system based on open source projects such as Mer and including a closed source UI.

* ''' Download location '''
The SailfishOS image is built on Gitlab CI. The latest 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 from our CI, 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>
# Verify that you have the <code>bsdtar</code> package installed
# Execute it: <code>./flash-it.sh</code>
# Follow the instructions. Some commands in the script require root permissions (for example: mounting and flashing the SD card).
* ''' username/password '''

OR...when asked where to flash, type 'raw' and it will build the image on your pc/mac

OR....download the .img from https://gitlab.com/as400l/pp-sailfishos-images

Set PIN on initialization.

* ''' What works, what does not work '''
NB The first run sometimes stalls before the tutorial. Reboot and it starts from setting the security pin.
The homescreen may be locked unless you boot with a sim card inserted. An old expired sim will do. If you do not have a SIM card on hands, do NOT set a security code on first boot. When a screen with a loading circle is displayed, just left/right swipe it away.

May 4th 2020: 3.3.0.16 release. Nextcloud integration.

Sept 17. Calls work.....sort of. Volunteer troubleshooters required. 4G works. Nextcloud sync works. Camera still WIP.

October 10. The most recent build still has call problems. The battery indicator stays at value on boot and the battery discharges very quickly. Apart from all that SFOS is still the snappiest most responsive UI, with none of the scaling and lagging problems that make phosh such a drag.

October 20. New build improves battery indicator but it's still erratic. Calls still problematic. No camera.

If you're not familiar with SFOS pay attention to the tutorial - the interface works great but isn't immediately obvious. If you are familiar with SF you can skip the tutorial by touching all 4 corners starting top left. There is a limited selection of apps available from the Jolla store, the vast majority are hosted on openrepos.net. The Storeman app for openrepos is now preinstalled, and also Webcat browser as the built in browser is not working at the moment.

* ''' How to contribute and report defects '''

See the [https://sailfishos.org/wiki/Collaborative_Development#Reporting_issues SailfishOS wiki] for links to their forum as well as info required when reporting an issue. See the [https://sailfishos.org/wiki/SailfishOS SailfishOS wiki] for options to contribute

* ''' Notes '''
OTA is supported: <code>zypper refresh && zypper update</code> as root (<code>devel-su</code> to get root access). Things that need reflash are bootloader specific at the moment. If improvements like crust or changes of partition layout are added then you need to reflash.

== PureOS ==
[[File:Pureos.png]]

PureOS is a GNU/Linux distribution focusing on privacy and security, using the GNOME desktop environment. It is developed and maintained by Purism.

* ''' Download location '''
This is an unofficial/unsupported PinePhone port by ''mozzwald'' and maintained by clover that can be downloaded [https://www.ironrobin.net/pureos/droppy/#/Images here].

* ''' source code '''
If you want to report a bug or look at what goes into the PinePhone build of PureOS, visit the Git [https://www.ironrobin.net/pureos/git/clover/pinephone/ repository].

* ''' username/password '''
purism/123456

* ''' Build instructions '''
If you want to build it yourself you can follow the instructions posted [https://mozzwald.com/pp/pureos-pinephone-build-instructions.txt here].

== Fedora ==
[[File:Fedora-logo.png|100px]]

An (unofficial) vanilla Fedora rawhide build for aarch64 with megi's kernel and [https://copr.fedorainfracloud.org/coprs/njha/mobile/packages/ some additional packages] to tie it all together. It aims to eventually be an upstream part of the Fedora project, rather than a phone-specific distribution.

See [https://forum.pine64.org/showthread.php?tid=9347 this thread in the forum].

* ''' Download location '''
[https://github.com/nikhiljha/pp-fedora-sdsetup/releases/ flashable images] or [https://github.com/nikhiljha/pp-fedora-sdsetup/tree/image build scripts]

* ''' username/password '''
pine/1111

* ''' What works, what does not work '''
WiFi, Bluetooth, SMS, Data, Calls all work! There are still a few bugs though, and [some features don't have driver support yet https://xnux.eu/devices/pine64-pinephone.html#toc-feature-driver-support-matrix] on any PinePhone distribution.

* ''' How to contribute and report defects '''
Please send your bug reports at [https://github.com/nikhiljha/pp-fedora-sdsetup/issues the project's issue tracker]. Be sure to include logs if applicable! Send us merge requests on [https://github.com/nikhiljha/pp-fedora-sdsetup/ Github].

== Arch Linux ARM ==
[[File:Archlinux-logo.png|100px]]

(Unofficial) Arch Linux ARM with Phosh as the UI selection, it's usable on the PinePhone and currently being maintained by the DanctNIX community.

* ''' Download location '''
Get the latest image here: https://github.com/dreemurrs-embedded/Pine64-Arch/releases

* ''' username/password '''
alarm/123456

* ''' What works, what does not work '''
Most of the things now works, there are some minor issues with crust.

* ''' How to contribute and report defects '''
Feel free to send us merge requests and report issues on [https://github.com/dreemurrs-embedded/Pine64-Arch/pulls GitHub].

== Manjaro ARM ==
[[File:Manjaro-logo.svg|100px]]

Manjaro is a user-friendly Linux distribution based on the independently developed Arch operating system with the Plasma Mobile desktop environment.

* ''' Download location '''

Phosh: [https://osdn.net/projects/manjaro-arm/storage/pinephone/phosh/ Download link for Phosh releases]

Plasma: [https://osdn.net/projects/manjaro-arm/storage/pinephone/plasma-mobile/ Download link for Plasma-Mobile releases]

Lomiri: [https://osdn.net/projects/manjaro-arm/storage/pinephone/lomiri/ Download link for Lomiri releases]

* ''' username/password '''
** manjaro/123456
** root/root

* ''' What works, what does not work '''
See Manjaro's [https://forum.manjaro.org/t/manjaro-arm-beta1-with-phosh-pinephone/32307 announcement].

* ''' How to contribute and report defects '''

See the end of the [https://forum.manjaro.org/t/manjaro-arm-beta1-with-phosh-pinephone/32307 announcement].

=== Factory-loaded Manjaro build with testing utility ===

* This is a Manjaro OS build that was preloaded in the factory with testing utility.
* Download the build, extract the image and dd it to the microSD and then insert it into the phone. Power up the PinePhone, perform and complete the test routine, then apply the build from microSD card to eMMC.
* dd the image on a 8 GB micoSD card or larger.
** [https://files.pine64.org/os/PinePhone/Manjaro/pine64-pinephone-20201013-manjaro-stable-20201018-factory56.img.xz Direct download from pine64.org]
*** MD5 (XZip file): 4edfd4dceaefdd32a3417c1727161c29
*** File Size: 1.04 GB

== Maemo Leste ==
[[File:Maemoleste-logo.png|100px]]

[https://en.wikipedia.org/wiki/Maemo Maemo] is a trimmed-down version of Debian for mobile devices, originally a collaboration between Nokia and many open source projects (the [http://maemo.org/intro/ Maemo community]) before Nokia abandoned it. The community now takes full responsibility in developing fully open source Maemo for a variety of mobile devices.

The new version Maemo 7 "Leste" is an ARM64 port of [https://devuan.org/ Devuan] (Debian without systemd) and runs the mainline Linux kernel. The default user interface stack is [https://en.wikipedia.org/wiki/Hildon Hildon], [https://en.wikipedia.org/wiki/X.Org_Server Xorg], [https://en.wikipedia.org/wiki/Matchbox_(window_manager) Matchbox WM], and [https://en.wikipedia.org/wiki/GTK GTK]. The current version is Devuan Ascii (Debian Stretch) and they are working on an upgrade to Devuan Beowulf (Debian Buster) as well as simultaneous support for both Devuan and Debian. In addition to the main repository, they [https://maemo-leste.github.io/maemo-leste-repositories-and-community-packages.html announced] a [https://github.com/maemo-leste-extras/bugtracker community repository]. To keep updated they use automation in their package maintenance with [https://github.com/maemo-leste/jenkins-integration jenkins] (similar to [https://www.debian.org/devel/buildd/ debian's buildd]). Porting packages to Maemo Leste is basically a simple matter of porting to arm64 version of Debian/Devuan, which benefits both projects.

More detailed information can be found on [https://leste.maemo.org/Main_Page the Maemo Leste wiki], or follow [https://maemo-leste.github.io/ announcements on their website], and check out [https://leste.maemo.org/Leste_FAQ Frequently Asked Questions].

* ''' Download location '''
[http://maedevu.maemo.org/images/pinephone/ Maemo Leste test builds]. There is also an [https://github.com/maemo-leste/image-builder image builder], see their wiki for instructions on how to [https://leste.maemo.org/Image_Builder build a custom image].

* ''' username/password '''
root/toor

You may use "sudo" directly.

* ''' What works, what does not work '''
For current status and work arounds please read their [https://leste.maemo.org/PinePhone PinePhone wiki page], and update as necessary (make sure to notify them of new issues by leaving a report on their github, see below).

* ''' How to contribute and report defects '''
Most discussion occurs at #maemo-leste on freenode IRC. The Maemo website also has an [https://talk.maemo.org/showthread.php?p=1565822 ongoing forum thread] for feedback about Maemo Leste on the PinePhone BraveHeart edition.

All other contact information is listed on the [https://leste.maemo.org/Main_Page main page] of the Maemo wiki. You should [https://github.com/maemo-leste/bugtracker/issues submit bug reports] on github. To track known issues, you may use these search terms: [https://github.com/maemo-leste/bugtracker/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+pinephone pinephone], [https://github.com/maemo-leste/bugtracker/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+pine64 pine64]. Learn about [https://leste.maemo.org/Development development], [https://leste.maemo.org/Development/Porting_Packages porting packages], [https://leste.maemo.org/Development/Building_Packages building packages], [https://leste.maemo.org/Development/Tasks todo list], and general info on [https://wiki.debian.org/HowToPackageForDebian how to package for Debian]. Some tasks have funding available.

== Nemo Mobile ==


Nemo Mobile is the open source build of Sailfish OS, see the new website nemomobile.net.

You can install Nemo on any device that runs Sailfish, see the above website for details. Or you can flash the image to SD card/emmc on the PinePhone, download here https://yadi.sk/d/8oSZp-frGidscw (requires Yandex Disk account).

* ''' Download location '''
Download location is [https://github.com/neochapay/nemo-device-dont_be_evil/ here on GitHub]. The latest version is not an image file and therefore not for beginners!

Alternative easy installation method: install Sailfish on your PP first (follow instructions on this page under Sailfish). Enable developer mode.
In the terminal run as root (devel-su):

ssu ar nemo-devel-ux http://repo.merproject.org/obs/home:/neochapay:/nemo-ux/sailfish_latest_armv7hl/

then
pkcon refresh

then install the nemo-specific Glacier packages:

pkcon install lipstick-glacier-home-qt5

If necessary, reboot.

* ''' username/password '''

* ''' What works, what does not work '''
Scroll down the page [https://github.com/neochapay/nemo-device-dont_be_evil/ here].

* ''' How to contribute and report defects '''
For more info please visit [https://github.com/neochapay/nemo-device-dont_be_evil neochapay's Github page]

== KDE Neon ==


Based on KDE Neon for the desktop, comes with Plasma Mobile.

* ''' Download location '''
Plasma mobile images can be found [https://images.plasma-mobile.org/pinephone/ here].

* ''' username/password '''
phablet/1234

* ''' What works, what does not work '''

* ''' How to contribute and report defects '''

== NixOS ==


''NixOS support is handled through the Mobile NixOS project.''

* [https://mobile.nixos.org/ Project home page]
* [https://github.com/NixOS/mobile-nixos Source code repository]

There is no pre-built complete image. For now users are expected to follow the instructions in the [https://mobile.nixos.org/getting-started.html Getting Started page], and on [https://mobile.nixos.org/devices/pine64-pinephone-braveheart.html the device's page].

* ''' What works, what does not work '''

This information may change, but currently it boots, it's as compatible as the Android-based devices are with Mobile NixOS. It even supports a bit more since it can use Wi-Fi.

<cite>
Support for all of the hardware will be coming, this project is a breadth-first work, where the work spans multiple devices in parallel.
</cite>

* ''' How to contribute and report defects '''
On [https://github.com/NixOS/mobile-nixos/issues the project's repository]. Please specify that you are using a PinePhone when reporting issues. Details about contributions and donations are on the [https://nixos.org/nixos/community.html NixOS website].

== LuneOS ==


Based on WebOS by LG, comes with Luna Next desktop environment.

* ''' Download location '''
[http://build.webos-ports.org/luneos-testing/images/pinephone/ LuneOS test image for PinePhone]
Tofe recommends using bmaptool ; for example "bmaptool copy http://build.webos-ports.org/luneos-testing/images/pinephone/luneos-dev-image-pinephone-testing-0-15.rootfs.wic.gz /dev/mmcblk0". Rename .wic file to .img for standard dd usage.

* ''' username/password '''

* ''' What works, what does not work '''

* ''' How to contribute and report defects '''

== Sxmo ==

A collection of Suckless programs to create a mobile UI. Based on Postmarket OS

* ''' Download location '''
Sxmo images can be found [http://images.lrdu.org/pinephone/ here].

* ''' username/password '''
mo/mo

* ''' What works, what does not work '''

PinePhone's backlight turns off at 2/10 brightness.

* ''' How to contribute and report defects '''

All the contributing information is [https://git.sr.ht/~mil/sxmo-docs/tree/master/CONTRIBUTING.md here].

== openSUSE ==
[[File:SLEM-OS-logo.png|100px]]

openSUSE running on the PinePhone

* ''' Download location '''
Offical openSUSE images can be found [https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/PinePhone/images/ here].

Nightly images [https://download.opensuse.org/repositories/home:/alefnode:/devel:/ARM:/Factory:/Contrib:/PinePhone/images/ here].

CI/CD for nightly slemos images [https://jenkins.alefnode.com/job/public/job/slemos-imagebuilder/ here].

* ''' username/password'''
pine/1234

* ''' What works, what does not work '''
You can find all information about the progress of the project [https://gitlab.com/slem.os/slem.os/-/blob/master/CHANGELOG.md here].

== AVMultiPhone ==

AVMultimedia linux running on the PinePhone

* ''' Download location '''

https://de.osdn.net/projects/avmultimedia/releases/

* ''' username/password'''
archivista/1234

* ''' What works, what does not work '''

All linux applications (Firefox, LibreOffice, Gimp, Inkscape, Kodi etc.). Phone calls and SMS (text messages), primitiv acces to camera (1280x720).

AVMultiPhone offers a classic Linux desktop (Mate) on the PinePhone. The basis is PostmarketOS. In contrast to other PinePhone distributions, AVMultiPhone offers real Linux feeling without sacrificing the functionality of a smartphone.

== GloDroid ==

A fully open source port of Android to the PinePhone

* ''' Download location '''

https://github.com/GloDroid/glodroid_manifest/releases

* ''' username/password'''
* ''' What works, what does not work '''
Works: WiFi, screen dimming, touchscreen and charging work.
Don't work: Bluetooth, Telephony, GPS

== Multi-boot image with 17 distributions ==

The purpose of this image is for users to easily try many of the above Linux distributions, without having to figure out how to flash them individually and juggle with many uSD cards.

More information can be found at:

https://xnux.eu/p-boot-demo/

You can find here some help for [[setting-up a boot SDCARD for p-boot]]

== Gentoo ==

An unofficial gentoo overlay with ebuilds for the pinephone. There is no image - you'll be building it yourself, picking which kernel, bootloader and desktop environment you want to use.

* ''' Download location '''

https://gitlab.com/bingch/gentoo-overlay/-/blob/master/README.md

= Factory Test OS =
On the BraveHeart model there was a pmOS based basic factory test OS pre-installed on the eMMC. Martijn Braam from pmOS has improved the functionality of the image considerably.

Since the 20200501 version it is able to test all the hardware. It also includes functionality to install a new OS to the eMMC when using with an test image that includes that OS image. The downloadable image just does the hardware tests.

Do not flash eMMC to test your device, just copy it to mSD and test from there. New versions are distributed as part of the pmOS distribution.

Links:
* [https://images.postmarketos.org/pinephone/ Software Images] (download the latest one that is marked pine-pinephone-YYYYMMDD-factorytestX.img.xz)
* [https://gitlab.com/MartijnBraam/factorytest Git repo]
* [https://gitlab.com/MartijnBraam/factorytest/-/blob/master/README.rst Documentation]

= Installing other ARM64 distributions =
'''Warning:''' Distributions not on this page may not even boot after you follow this section. In the best case, they will be barely usable. This is more for fun, or if you would like to port a new distribution to the PinePhone.

'''Note:''' This section uses megi's kernel releases, and not the official ones from PINE64. While it is possible to use the official (and in the future, mainline) kernel, megi provides binary releases, which makes it very easy.

If you would like to see specific commands for how to complete these steps, see https://github.com/nikhiljha/pp-fedora-sdsetup (an example for Fedora) or https://xnux.eu/howtos/install-arch-linux-arm.html (an example for Arch Linux).

# Create a boot (from 4 MB to about 252 MB) and root (from 252 MB to the end of the card) filesystem on the SD card.
# Format the boot partition with vfat, and the root partition with f2fs.
# Extract the root filesystem from your distribution's ARM image into the root filesystem on the SD card. Do not copy the partition, copy the files (in archive mode: like rsync -ar).
# Edit /etc/fstab to match your partitions.
# Grab megi's kernel from https://xff.cz/kernels/ (you probably want 5.6 or later).
# Follow the README instructions, which involves copying the kernel modules into the SD card rootfs and writing u-boot and the bootloader.

= Other Resources =
Community
* [[Main_Page#Community_and_Support|Links to the community services]]

Hardware information
* [[PinePhone|General PinePhone hardware info]] in this Pine64 wiki.
* [[PinePhone_v1.1_-_Braveheart|PinePhone 1.1 BraveHeart hardware details]] (details specific to the BraveHeart Edition).
* [[PinePhone_v1.2|PinePhone 1.2 hardware details]] (details specific to the Community Edition).
* The postmarketOS wiki has a detailed page on the PinePhone hardware [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone) here,] and the preceding devkit [https://wiki.postmarketos.org/wiki/PINE64_Don%27t_be_evil_devkit_(pine64-dontbeevil) here].

Other software information
* [https://linux-sunxi.org/Main_Page sunxi community wiki]
* [https://xnux.eu/devices/pine64-pinephone.html megi feature/driver support matrix]
* [https://megous.com/dl/tmp/README.bootui megi bootUI notes (for dualbooting/multibooting)] see demonstration [https://www.youtube.com/watch?v=ZL1GREqoqx8 on YouTube,]
* [https://github.com/ayufan-pine64/boot-tools ayufan boot tools]

Other
* [https://pine64.com/?post_type=product Pine64 shop]
* [https://www.pine64.org/2020/01/24/setting-the-record-straight-pinephone-misconceptions/ Pine64 blog on blobs]
* [https://tuxphones.com/yet-another-librem-5-and-pinephone-linux-smartphone-comparison/ Martijn Braam Librem 5 comparison, especially covering openness/blobs]
* [https://fam-ribbers.com/2019/12/28/State-of-Linux-on-mobile-and-common-misconceptions.html Bart Ribbers blog on Linux distributions and desktop environments on mobile devices]
* [https://www.jeffgeerling.com/blog/2019/a2-class-microsd-cards-offer-no-better-performance-raspberry-pi Jeff Geerling on testing microSD cards]

[[Category:PinePhone]]

PinePhone Software Releases

2020-09-15T17:34:50Z

Megous: Add information about the multi-boot image

This page contains a list of all available releases for the PinePhone as well as links to further resources.

See [[PinePhone Installation Instructions]] on how to install the operating systems.

Note: Some releases may not have a good setup for the backlight at low brightness. If configured too low the backlight shuts down completely, but the screen is still displayed and usable in bright front-light.

= Software Releases =
This is a list of OSes that specifically support the PinePhone, but as support is included in Mainline Linux, in principle any ARM Linux OS can be used, if possible required patches are included.

== postmarketOS ==
[[File:PostmarketOS-logo.png|100px]]

postmarketOS is a preconfigured version of [https://www.alpinelinux.org/ Alpine Linux] for mobile devices that offers a choice of several desktop environments including Plasma Mobile and Phosh.

* ''' Download location '''
Rather than downloading a demo image, postmarketOS [https://wiki.postmarketos.org/wiki/Installation_guide recommends the use of their script], pmbootstrap, that can tailor build your SD card for you.

Note: pmbootstrap offers an option [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone)#Installation to install to the eMMC].

Demo images can be found [http://images.postmarketos.org/pinephone/ here].

* ''' username/password '''
demo/147147 (for demo images only - when building an image with pmbootstrap you set your own username and password (the Phosh lock screen requires your password, but only presents a numeric keyboard, so you should use only numbers in your password).

* ''' What works, what does not work '''
See [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone) postmarketOS dedicated PinePhone wiki page]

If you install Firefox browser (or are using a demo image that already has it installed) then [https://wiki.postmarketos.org/wiki/Firefox these hints] in the pmOS wiki are recommended.

* ''' How to contribute and report defects '''
[https://gitlab.com/postmarketOS/postmarketos/issues/3 postmarketOS issue tracker] for PinePhone support. See [https://wiki.postmarketos.org/wiki/Contributing postmarketOS wiki] for options to contribute.

== Ubuntu Touch by UBports ==
[[File:Ubports-logo.png|100px]]

A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community.

Ubuntu touch is a mobile version of Ubuntu developed by the UBports community. Installation instructions can be found on [https://gitlab.com/ubports/community-ports/pinephone#how-do-i-install-ubuntu-touch-on-my-pinephone the UBports PinePhone project]. There is also a [https://github.com/goddard/pinephone/ script] to download the latest image and flash to your PinePhone. In the future, Ubuntu Touch will be able to be installed onto the PinePhone with the [https://devices.ubuntu-touch.io/installer UBports installer] GUI tool.

* ''' Download location '''
[https://gitlab.com/ubports/community-ports/pinephone#how-do-i-install-ubuntu-touch-on-my-pinephone UBports PinePhone project]

* ''' username/password '''
Set up during boot

* ''' What works, what does not work '''
Scroll down to the bottom of [https://gitlab.com/ubports/community-ports/pinephone this page].

* ''' How to contribute and report defects '''
See [https://gitlab.com/ubports/community-ports/pinephone UBports gitlab page]. See [https://ubports.com/foundation/sponsors UBports website] for how to donate.

== Mobian ==
[[File:Debian-logo.png]]

An unofficial Debian build for ARM64 running with the Phosh user interface (developed by Purism, Phosh uses Wayland instead of Xorg). The base system is pure Debian, with only the GUI applications and a few others (ModemManager, WiFi chip firmware) being built from modified sources (as well as the kernel and u-boot). Current version is Debian Bullseye.

* ''' Download location '''
[http://images.mobian-project.org/ Mobian downloadable images]

Don't forget to extract the image before installing:
$ gzip -d Downloads/mobian-pinephone-*.img.gz

See the [https://wiki.mobian-project.org/doku.php?id=install project page] for specific installation instructions.

* ''' username/password '''
mobian/1234

* ''' What works, what does not work '''

See [https://gitlab.com/mobian1/mobian-recipes/-/blob/master/README.md the project's README file] or [https://wiki.mobian-project.org/doku.php?id=pinephone the wiki]for most up to date status.

Check [https://gitlab.com/a-wai/debos-pinephone/-/issues bug tracker] for known issues. Questions? Ask on our [https://forum.pine64.org/showthread.php?tid=9016 thread].

* ''' How to contribute and report defects '''
It is recommended that you log your bug reports in [https://gitlab.com/mobian1/issues the project's issue tracker]. As a general rule, issues with third-party apps (even the default ones) should be reported upstream. A Mobian issue would be related to getting the hardware to work on the PinePhone, but if unsure where the issue should be reported just open a ticket or ask. Feel free to pick an open issue to work on, or send a merge request on [https://gitlab.com/mobian1 Gitlab].

* ''' Notes '''
See [[Mobian for PinePhone]] or [https://wiki.mobian-project.org/doku.php?id=start the wiki] for additional information regarding screen resolution, USB networking, WiFi hotspot, Chatty and the repository.

== SailfishOS ==


Sailfish OS is a Linux-based operating system based on open source projects such as Mer and including a closed source UI.

* ''' Download location '''
The SailfishOS image is built on Gitlab CI. The latest 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 from our CI, 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>
# Verify that you have the <code>bsdtar</code> package installed
# Execute it: <code>./flash-it.sh</code>
# Follow the instructions. Some commands in the script require root permissions (for example: mounting and flashing the SD card).
* ''' username/password '''

Set PIN on initialization.

* ''' What works, what does not work '''
May 4th 2020: The SFOS image is now the latest 3.3.0.16 release. This has resolved many problems (for example MTP file transfer now works) but there are several glitches, the most serious being very intermittent wifi. Random hissing noise for about 10 seconds. This release of SF has Nextcloud integration.

May 24th 2020: Voice calls now work but not available in public builds yet. If you have a Jolla registration a minor bug means you have to submit the request twice. WiFi still intermittent. The battery indicator previously only showed level at boot, now improved but far from reliable.

If you're not familiar with SFOS pay attention to the tutorial - the interface works great but isn't immediately obvious. If you are familiar with SF you can skip the tutorial by touching all 4 corners starting top left. There is a limited selection of apps available from the Jolla store, the vast majority are hosted on openrepos.net. The Storeman app for openrepos is now preinstalled, and also Webcat browser as the built in browser is not working at the moment.

* ''' How to contribute and report defects '''

See the [https://sailfishos.org/wiki/Collaborative_Development#Reporting_issues SailfishOS wiki] for links to their forum as well as info required when reporting an issue. See the [https://sailfishos.org/wiki/SailfishOS SailfishOS wiki] for options to contribute

* ''' Notes '''
OTA is supported: <code>zypper refresh && zypper update</code> as root (<code>devel-su</code> to get root access). Things that need reflash are bootloader specific at the moment. If improvements like crust or changes of partition layout are added then you need to reflash.

== PureOS ==
[[File:Pureos.png]]

PureOS is a GNU/Linux distribution focusing on privacy and security, using the GNOME desktop environment. It is developed and maintained by Purism.

* ''' Download location '''
This is an unofficial/unsupported PinePhone port by ''mozzwald'' and maintained by clover that can be downloaded [https://www.ironrobin.net/pureos/droppy/#/Images here].

* ''' source code '''
If you want to report a bug or look at what goes into the PinePhone build of PureOS, visit the Git [https://www.ironrobin.net/pureos/git/clover/pinephone/ repository].

* ''' username/password '''
purism/123456

* ''' Build instructions '''
If you want to build it yourself you can follow the instructions posted [https://mozzwald.com/pp/pureos-pinephone-build-instructions.txt here].

== Fedora ==
[[File:Fedora-logo.png|100px]]

An (unofficial) vanilla Fedora rawhide build for aarch64 with megi's kernel and [https://copr.fedorainfracloud.org/coprs/njha/mobile/packages/ some additional packages] to tie it all together. It aims to eventually be an upstream part of the Fedora project, rather than a phone-specific distribution.

See [https://forum.pine64.org/showthread.php?tid=9347 this thread in the forum].

* ''' Download location '''
[https://github.com/nikhiljha/pp-fedora-sdsetup/releases/ flashable images] or [https://github.com/nikhiljha/pp-fedora-sdsetup/tree/image build scripts]

* ''' username/password '''
pine/1111

* ''' What works, what does not work '''
WiFi, Bluetooth, SMS, Data, Calls all work! There are still a few bugs though, and [some features don't have driver support yet https://xnux.eu/devices/pine64-pinephone.html#toc-feature-driver-support-matrix] on any PinePhone distribution.

* ''' How to contribute and report defects '''
Please send your bug reports at [https://github.com/nikhiljha/pp-fedora-sdsetup/issues the project's issue tracker]. Be sure to include logs if applicable! Send us merge requests on [https://github.com/nikhiljha/pp-fedora-sdsetup/ Github].

== Arch Linux ARM ==
[[File:Archlinux-logo.png|100px]]

(Unofficial) Arch Linux ARM with Phosh as the UI selection, it's usable on the PinePhone and currently being maintained by the DanctNIX community.

* ''' Download location '''
Get the latest image here: https://github.com/dreemurrs-embedded/Pine64-Arch/releases

* ''' username/password '''
alarm/123456

* ''' What works, what does not work '''
Most of the things now works, there are some minor issues with crust.

* ''' How to contribute and report defects '''
Feel free to send us merge requests and report issues on [https://github.com/dreemurrs-embedded/Pine64-Arch/pulls GitHub].

== Manjaro ARM ==
[[File:Manjaro-logo.svg|100px]]

Manjaro is a user-friendly Linux distribution based on the independently developed Arch operating system with the Plasma Mobile desktop environment.

* ''' Download location '''

Phosh: [https://forum.manjaro.org/t/manjaro-arm-alpha2-with-phosh-pinephone/148 See Manjaro forum announcement of Alpha2 version]

Plasma: [https://osdn.net/projects/manjaro-arm/storage/pinephone/plasma-mobile/alpha7/ Download link for the Alpha7 version of the Plasma Mobile release]

Lomiri: [https://osdn.net/projects/manjaro-arm/storage/pinephone/lomiri/ Download link for the Alpha0 version of the Lomiri release]

* ''' username/password '''
** manjazo/123456
** root/root

* ''' What works, what does not work '''
See Manjaro's [https://forum.manjaro.org/t/manjaro-arm-alpha5-for-pinephone-testing-branch/136614 announcement]. In particular, phone calls do not yet work from the Phone application.

* ''' How to contribute and report defects '''

See the end of the [https://forum.manjaro.org/t/manjaro-arm-alpha5-for-pinephone-testing-branch/136614 announcement].

== Maemo Leste ==


[https://en.wikipedia.org/wiki/Maemo Maemo] is a trimmed-down version of Debian for mobile devices, originally a collaboration between Nokia and many open source projects (the [http://maemo.org/intro/ Maemo community]) before Nokia abandoned it. The community now takes full responsibility in developing fully open source Maemo for a variety of mobile devices.

The new version Maemo 7 "Leste" is an ARM64 port of [https://devuan.org/ Devuan] (Debian without systemd) and runs the mainline Linux kernel. The default user interface stack is [https://en.wikipedia.org/wiki/Hildon Hildon], [https://en.wikipedia.org/wiki/X.Org_Server Xorg], [https://en.wikipedia.org/wiki/Matchbox_(window_manager) Matchbox WM], and [https://en.wikipedia.org/wiki/GTK GTK]. The current version is Devuan Ascii (Debian Stretch) and they are working on an upgrade to Devuan Beowulf (Debian Buster) as well as simultaneous support for both Devuan and Debian. In addition to the main repository, they [https://maemo-leste.github.io/maemo-leste-repositories-and-community-packages.html announced] a [https://github.com/maemo-leste-extras/bugtracker community repository]. To keep updated they use automation in their package maintenance with [https://github.com/maemo-leste/jenkins-integration jenkins] (similar to [https://www.debian.org/devel/buildd/ debian's buildd]). Porting packages to Maemo Leste is basically a simple matter of porting to arm64 version of Debian/Devuan, which benefits both projects.

More detailed information can be found on [https://leste.maemo.org/Main_Page the Maemo Leste wiki], or follow [https://maemo-leste.github.io/ announcements on their website], and check out [https://leste.maemo.org/Leste_FAQ Frequently Asked Questions].

* ''' Download location '''
[http://maedevu.maemo.org/images/pinephone/ Maemo Leste test builds]. There is also an [https://github.com/maemo-leste/image-builder image builder], see their wiki for instructions on how to [https://leste.maemo.org/Image_Builder build a custom image].

* ''' username/password '''
root/toor

You may use "sudo" directly.

* ''' What works, what does not work '''
For current status and work arounds please read their [https://leste.maemo.org/PinePhone PinePhone wiki page], and update as necessary (make sure to notify them of new issues by leaving a report on their github, see below).

* ''' How to contribute and report defects '''
Most discussion occurs at #maemo-leste on freenode IRC. The Maemo website also has an [https://talk.maemo.org/showthread.php?p=1565822 ongoing forum thread] for feedback about Maemo Leste on the PinePhone BraveHeart edition.

All other contact information is listed on the [https://leste.maemo.org/Main_Page main page] of the Maemo wiki. You should [https://github.com/maemo-leste/bugtracker/issues submit bug reports] on github. To track known issues, you may use these search terms: [https://github.com/maemo-leste/bugtracker/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+pinephone pinephone], [https://github.com/maemo-leste/bugtracker/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+pine64 pine64]. Learn about [https://leste.maemo.org/Development development], [https://leste.maemo.org/Development/Porting_Packages porting packages], [https://leste.maemo.org/Development/Building_Packages building packages], [https://leste.maemo.org/Development/Tasks todo list], and general info on [https://wiki.debian.org/HowToPackageForDebian how to package for Debian]. Some tasks have funding available.

== Nemo Mobile ==


Nemo Mobile is the open source build of Sailfish OS, see the new website nemomobile.net.

You can install Nemo on any device that runs Sailfish, see the above website for details. Or you can flash the image to SD card/emmc on the PinePhone, download here https://yadi.sk/d/8oSZp-frGidscw (requires Yandex Disk account).

* ''' Download location '''
Download location is [https://github.com/neochapay/nemo-device-dont_be_evil/ here on GitHub]. The latest version is not an image file and therefore not for beginners!

Alternative easy installation method: install Sailfish on your PP first (follow instructions on this page under Sailfish). Enable developer mode.
In the terminal run as root (devel-su):

ssu ar nemo-devel-ux http://repo.merproject.org/obs/home:/neochapay:/nemo-ux/sailfish_latest_armv7hl/

then
pkcon refresh

then install the nemo-specific Glacier packages:

pkcon install lipstick-glacier-home-qt5

If necessary, reboot.

* ''' username/password '''

* ''' What works, what does not work '''
Scroll down the page [https://github.com/neochapay/nemo-device-dont_be_evil/ here].

* ''' How to contribute and report defects '''
For more info please visit [https://github.com/neochapay/nemo-device-dont_be_evil neochapay's Github page]

== KDE Neon ==


Based on KDE Neon for the desktop, comes with Plasma Mobile.

* ''' Download location '''
Plasma mobile images can be found [https://images.plasma-mobile.org/pinephone/ here].

* ''' username/password '''
phablet/1234

* ''' What works, what does not work '''

* ''' How to contribute and report defects '''

== NixOS ==


''NixOS support is handled through the Mobile NixOS project.''

* [https://mobile.nixos.org/ Project home page]
* [https://github.com/NixOS/mobile-nixos Source code repository]

There is no pre-built complete image. For now users are expected to follow the instructions in the [https://mobile.nixos.org/getting-started.html Getting Started page], and on [https://mobile.nixos.org/devices/pine64-pinephone-braveheart.html the device's page].

* ''' What works, what does not work '''

This information may change, but currently it boots, it's as compatible as the Android-based devices are with Mobile NixOS. It even supports a bit more since it can use Wi-Fi.

<cite>
Support for all of the hardware will be coming, this project is a breadth-first work, where the work spans multiple devices in parallel.
</cite>

* ''' How to contribute and report defects '''
On [https://github.com/NixOS/mobile-nixos/issues the project's repository]. Please specify that you are using a PinePhone when reporting issues. Details about contributions and donations are on the [https://nixos.org/nixos/community.html NixOS website].

== LuneOS ==


Based on WebOS by LG, comes with Luna Next desktop environment.

* ''' Download location '''
[http://build.webos-ports.org/luneos-testing/images/pinephone/ LuneOS test image for PinePhone]
Tofe recommends using bmaptool ; for example "bmaptool copy http://build.webos-ports.org/luneos-testing/images/pinephone/luneos-dev-image-pinephone-testing-0-15.rootfs.wic.gz /dev/mmcblk0". Rename .wic file to .img for standard dd usage.

* ''' username/password '''

* ''' What works, what does not work '''

* ''' How to contribute and report defects '''

== Sxmo ==

A collection of Suckless programs to create a mobile UI. Based on Postmarket OS

* ''' Download location '''
Sxmo images can be found [http://images.lrdu.org/pinephone/ here].

* ''' username/password '''
mo/mo

* ''' What works, what does not work '''

PinePhone's backlight turns off at 2/10 brightness.

* ''' How to contribute and report defects '''

All the contributing information is [https://git.sr.ht/~mil/sxmo-docs/tree/master/CONTRIBUTING.md here].

== openSUSE ==
[[File:SLEM-OS-logo.png|100px]]

openSUSE running on the PinePhone

* ''' Download location '''
openSUSE images can be found [http://images.alefnode.com/ here].

Nightly images [http://images.alefnode.com/nightly/ here].

CI/CD for nightly images [https://jenkins.alefnode.com/job/public/job/slemos-imagebuilder/ here].

* ''' username/password'''
pine/1234

* ''' What works, what does not work '''
You can find all information about the progress of the project [https://gitlab.com/slem.os/slem.os/-/blob/master/CHANGELOG.md here].

== AVMultiPhone ==

AVMultimedia linux running on the PinePhone

* ''' Download location '''

https://de.osdn.net/projects/avmultimedia/releases/

* ''' username/password'''
archivista/1234

* ''' What works, what does not work '''

All linux applications (Firefox, LibreOffice, Gimp, Inkscape, Kodi etc.). Phone calls and SMS (text messages), primitiv acces to camera (1280x720).

AVMultiPhone offers a classic Linux desktop (Mate) on the PinePhone. The basis is PostmarketOS. In contrast to other PinePhone distributions, AVMultiPhone offers real Linux feeling without sacrificing the functionality of a smartphone.

== GloDroid ==

A fully open source port of Android to the PinePhone

* ''' Download location '''

https://github.com/GloDroid/glodroid_manifest/releases

* ''' username/password'''
* ''' What works, what does not work '''
WiFi, screen dimming, touchscreen and charging all work. No Bluetooth support yet.

== Multi-boot image with 13 distributions ==

The purpose of this image is for users to easily try many of the above Linux distributions, without having to figure out how to flash them individually and juggle with many uSD cards.

More information can be found at:

https://xnux.eu/p-boot-demo/

= Factory Test OS =
On the BraveHeart model there was a pmOS based basic factory test OS pre-installed on the eMMC. Martijn Braam from pmOS has improved the functionality of the image considerably.

Since the 20200501 version it is able to test all the hardware. It also includes functionality to install a new OS to the eMMC when using with an test image that includes that OS image. The downloadable image just does the hardware tests.

Do not flash eMMC to test your device, just copy it to mSD and test from there. New versions are distributed as part of the pmOS distribution.

Links:
* [https://images.postmarketos.org/pinephone/ Software Images] (download the latest one that is marked pine-pinephone-YYYYMMDD-factorytestX.img.xz)
* [https://gitlab.com/MartijnBraam/factorytest Git repo]
* [https://gitlab.com/MartijnBraam/factorytest/-/blob/master/README.rst Documentation]

= Installing other ARM64 distributions =
'''Warning:''' Distributions not on this page may not even boot after you follow this section. In the best case, they will be barely usable. This is more for fun, or if you would like to port a new distribution to the PinePhone.

'''Note:''' This section uses megi's kernel releases, and not the official ones from PINE64. While it is possible to use the official (and in the future, mainline) kernel, megi provides binary releases, which makes it very easy.

If you would like to see specific commands for how to complete these steps, see https://github.com/nikhiljha/pp-fedora-sdsetup (an example for Fedora) or https://xnux.eu/howtos/install-arch-linux-arm.html (an example for Arch Linux).

# Create a boot (from 4 MB to about 252 MB) and root (from 252 MB to the end of the card) filesystem on the SD card.
# Format the boot partition with vfat, and the root partition with f2fs.
# Extract the root filesystem from your distribution's ARM image into the root filesystem on the SD card. Do not copy the partition, copy the files (in archive mode: like rsync -ar).
# Edit /etc/fstab to match your partitions.
# Grab megi's kernel from https://xff.cz/kernels/ (you probably want 5.6 or later).
# Follow the README instructions, which involves copying the kernel modules into the SD card rootfs and writing u-boot and the bootloader.

= Other Resources =
Community
* [[Main_Page#Community_and_Support|Links to the community services]]

Hardware information
* [[PinePhone|General PinePhone hardware info]] in this Pine64 wiki.
* [[PinePhone_v1.1_-_Braveheart|PinePhone 1.1 BraveHeart hardware details]] (details specific to the BraveHeart Edition).
* [[PinePhone_v1.2|PinePhone 1.2 hardware details]] (details specific to the Community Edition).
* The postmarketOS wiki has a detailed page on the PinePhone hardware [https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone) here,] and the preceding devkit [https://wiki.postmarketos.org/wiki/PINE64_Don%27t_be_evil_devkit_(pine64-dontbeevil) here].

Other software information
* [https://linux-sunxi.org/Main_Page sunxi community wiki]
* [https://xnux.eu/devices/pine64-pinephone.html megi feature/driver support matrix]
* [https://megous.com/dl/tmp/README.bootui megi bootUI notes (for dualbooting/multibooting)] see demonstration [https://www.youtube.com/watch?v=ZL1GREqoqx8 on YouTube,]
* [https://github.com/ayufan-pine64/boot-tools ayufan boot tools]

Other
* [https://store.pine64.org/?post_type=product Pine64 shop]
* [https://www.pine64.org/2020/01/24/setting-the-record-straight-pinephone-misconceptions/ Pine64 blog on blobs]
* [https://tuxphones.com/yet-another-librem-5-and-pinephone-linux-smartphone-comparison/ Martijn Braam Librem 5 comparison, especially covering openness/blobs]
* [https://fam-ribbers.com/2019/12/28/State-of-Linux-on-mobile-and-common-misconceptions.html Bart Ribbers blog on Linux distributions and desktop environments on mobile devices]
* [https://www.jeffgeerling.com/blog/2019/a2-class-microsd-cards-offer-no-better-performance-raspberry-pi Jeff Geerling on testing micro SD cards]

[[Category:PinePhone]]

User:Oogwaymaki/Kernel Installation

2020-06-30T10:53:11Z

Megous: /* Why would you want to install a custom kernel? */

===Why would you want to install a custom kernel?===

The reasons why you'd want to instal a custom kernel is if there were fixes in the kernel
that allows the device to function better than it was before, or if you want to deviate with probably better functionality that the mass user base isn't configured for.
You can experiment with new features that are not yet documented or ready but could provide a great functionality when using your phone or device or operating system

Other reason is that the newest rc kernel contains code that is closest to getting mainlined into the Linus' kernel tree, so giving it some testing helps with catching
issues prior to these issues potentially affecting more people than necessary. You'll be helping the development.

===Things to look out for when installing a custom kernel and problems that can happen===

Some things to look out for when installing a custom kernel are the following:

* Does the kernel have all the modules you need installed for the system to boot liked
* Drivers
* Functionality

If you don't have the proper drivers for your particular kernel such as if you use a particular file system or
feature it will not work if not compiled into the kernel.

===What to do if the kernel does not have all your functionality but you want the patch it fixes or address?===

You would want to compile the kernel from scratch, adding all the features and functionality you need, and using the patch utility and methods you need. This takes added time like 30 min to several hours.

===Installing Megi's pre-compiled kernel===

prereqs:

You'll need a uart or a way to connect to your device to call

<pre>
depmod -a

</pre>

Install dependencies:

* u-boot-tools allows you to make images
* rsync allows you to copy and backup

<pre>
# apt-get update
# apt-get install rsync u-boot-tools
</pre>

First, download the the PinePhone CE (1.2) Kernel:

<pre>
# wget https://xff.cz/kernels/5.8/pp2.tar.gz
</pre>

Extract the kernel:

Create a separate folder for organization and separation:
Extract the a "tar" "gz" file using tar.

<pre>
# tar -zxvf pp2.tar.gz
</pre>

A default Mobian Installation looks like this:

<pre>
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 1953 250000 248048 121.1M 83 Linux
/dev/sda2 250001 7421874 7171874 3.4G 83 Linux
</pre>

Notice the small size on the /boot partition.

This means we probably will have to, either ignore the the first partition or resize both partitions so we can
keep existing structure.

Easiest thing to do:

Please all all the new files on the /dev/sda2 (they'll probably be more than 121 M)

Next we need to update the initrd image, to have the new modules, (the initrd image is a RAM disk helping the system to boot and needs kernel drivers while booting):

How to get and update initrd image:

Mount Mobian boot image:
Make sure your the root user for this for ease of installation:
Delete the old kernel modules and put the new latest ones there
<pre>
# mkdir debianboot
# mount /dev/sda1 /media/debianboot
# cd /usr/src
# mkdir initrd
# cd /usr/src/initrd
# cp /media/debianboot/initrd.img-5.7-pinephone .
# zcat initrd.img-5.7-pinephone | cpio -idmv
# rm initrd.img-5.7-pinephone
# cd /usr/src/initrd/lib/modules
# rm -rf /usr/src/initrd/lib/modules/5.7-pinephone
# rsync -avh pp2-5.8/modules/lib/modules/ initrd/lib/modules/

</pre>

Repackage the Mobian Boot Image after new kernel modules installed and copy over to main mobian image now

<pre>

# find . | cpio -o -c | gzip -9 > initrd.img-5.8-pinephone
# mkdir /media/mobianroot
# mount /dev/sda2 /media/mobianroot
# cp initrd/initrd.img-5.8-pinephone /media/mobianroot/boot/
</pre>

Copy the pp 2.8 kernel and dab definition files to Mobian boot folder and update the boot.scr
<pre>
# cp pp2-5.8/board.dtb /media/mobianroot/boot/
# cp pp2-5.8/Image /media/mobianroot/boot/
</pre>

Change the old boot.cmd to the new settings:

<pre>
if test ${mmc_bootdev} -eq 0; then
echo "Booting from SD"
setenv linux_mmcdev 0
else
echo "Booting from eMMC"
setenv linux_mmcdev 2
fi

# If we have at least 2 partitions, then the 1st one is /boot, and / is #2
if fstype mmc ${mmc_bootdev}:2; then
setenv rootpart 2
else
setenv rootpart 1
setenv bootdir "/boot"
fi

setenv bootargs console=ttyS0,115200 no_console_suspend panic=10 consoleblank=0 loglevel=7 root=/dev/mmcblk${linux_mmcdev}p${rootpart} rw splash plymouth.ignore-serial-consoles vt.global_cursor_default=0

led 1 on

echo "Loading kernel..."
load mmc ${mmc_bootdev}:1 ${ramdisk_addr_r} ${bootdir}/Image.gz

echo "Uncompressing kernel..."
unzip ${ramdisk_addr_r} ${kernel_addr_r}

echo "Loading initramfs..."
load mmc ${mmc_bootdev}:1 ${ramdisk_addr_r} ${bootdir}/initrd.img
setenv ramdisk_size ${filesize}

echo "Loading dtb..."
load mmc ${mmc_bootdev}:1 ${fdt_addr_r} ${bootdir}/dtb/${fdtfile}

led 2 on

echo "Booting..."
booti ${kernel_addr_r} ${ramdisk_addr_r}:0x${ramdisk_size} ${fdt_addr_r}

</pre>

Remove the old boot.cmd

<pre>

# rm boot.cmd

</pre>
to this, we removed the configuration of the first disk we won't be using it
we also pointed everything to second disk for kernel and boot images

<pre>

if test ${mmc_bootdev} -eq 0; then
echo "Booting from SD"
setenv linux_mmcdev 0
else
echo "Booting from eMMC"
setenv linux_mmcdev 2
fi

# If we have at least 2 partitions, then the 1st one is /boot, and / is #2
if fstype mmc ${mmc_bootdev}:2; then
setenv rootpart 2
setenv bootdir "/boot"
else
setenv rootpart 2
setenv bootdir "/boot"
fi

setenv bootargs console=ttyS0,115200 no_console_suspend panic=10 consoleblank=0 loglevel=7 root=/dev/mmcblk${linux_mmcdev}p${rootpart} rw splash plymouth.ignore-serial-consoles vt.global_cursor_default=0 initrd=/boot/initrd.img-5.8-pinephone

led 1 on

echo "Loading kernel..."
load mmc ${mmc_bootdev}:2 ${kernel_addr_r} ${bootdir}/Image

echo "Loading dtb..."
load mmc ${mmc_bootdev}:2 ${fdt_addr_r} /boot/board.dtb

led 2 on

echo "Booting..."
booti ${kernel_addr_r} - ${fdt_addr_r}
</pre>

Save new boot.cmd to /dev/sda1 root folder (where the old boot.cmd was)

# cd /media/mobianboot
<pre>
# mkimage -C none -A arm64 -T script -d boot.cmd boot.scr
root@wifirouter:/media/mobianboot# mkimage -C none -A arm64 -T script -d boot.cmd boot.scr
Image Name:
Created: Mon Jun 29 19:13:19 2020
Image Type: AArch64 Linux Script (uncompressed)
Data Size: 876 Bytes = 0.86 KiB = 0.00 MiB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 868 Bytes = 0.85 KiB = 0.00 MiB
</pre>
<pre>
# e2label /dev/sda2 ROOT
# make fstab look like this:
LABEL=ROOT / ext4 defaults 0 0
</pre>
boot up device.l
== References ==

* https://access.redhat.com/solutions/24029
* https://linux-sunxi.org/U-Boot

PinePhone Hardware Accessory Compatibility

2020-06-11T21:16:28Z

Megous: /* Peripheral equipment */

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
|-
|}

== Protection ==

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

PinePhone v1.1 - Braveheart

2020-06-06T17:19:43Z

Megous: /* USB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off */

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 Power issue preventing charge and battery-less operation (one-off HW issue ?) ===

''Seems to be a one-time hardware issue, no change needed?''

I received a PinePhone that never charged when plugged on USB. Also the phone does not boot when plugged without the battery. I tried: computer, 1A charger, 2A Asus charger, 2.1A battery. On OSes: latest pmOS and Ubuntu Touch, default test software.
Apart from that (USB power issue), the phone seems to work correctly. The phone is seen has a "PinePhone" when connected with USB to a Linux computer. See https://forum.pine64.org/showthread.php?tid=9042

Investigations:
If I measure VBUS (aka DCIN in older schematics) on the USB-C daughter board connector (using multimeter, touch the leftmost pins on the bottom row, they can be reached even with the flex cable plugged), I get when flex cable unplugged: 4.7V (sometimes 2.3V but less often and not reproducibly), when flex cable plugged: 1.21V (it should be 5V!).

I did measurements using names from "PinePhone USB-C small board schematic v1.0 20190730.pdf" given to me by TL on the Telegram dev chat.
I measure C101 to be 3.3 uf instead of 4.7 uf according to schematics. I measure C104 to be 265 pf, C105 to be 0.26nf, C106 to be > 10 uf (my tool does not go above)., C107 to be: 0.18nf.

I decided to bypass OVP to try fixing my PinePhone:

<gallery mode="traditional">
File:Braveheart_VBUS_1_from_diode.jpg|A 0.3mm insulated wire takes VBUS_1 (VBUS unprotected from overvoltages) from diode. See OVP component in PDF "PinePhone USB-C small board top placement v1.0 20190730.pdf".
File:Braveheart_VBUS_1_to_VBUS_at_pogopin.jpg|At the appropriate pogopin of my Braveheart, VBUS_1 is plugged directly to VBUS to bypass OVP which is not working on my USB-C daughter board. ! Be careful that in revisions following Braveheart the pogopins usage could change ! Do not inject 5V in 3V3 bus or I2C !
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.
</gallery>

With this bypass, the phone is able to boot with or without the battery, and to charge the battery. As this is a hack that reduces safety I will try to have my USB-C daughter board replaced.

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

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

This issue is also present on the PinePhone 1.2 (CE) version.

=== 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-06-06T12:56:33Z

Megous: Add information about USB-C issues

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 Power issue preventing charge and battery-less operation (one-off HW issue ?) ===

''Seems to be a one-time hardware issue, no change needed?''

I received a PinePhone that never charged when plugged on USB. Also the phone does not boot when plugged without the battery. I tried: computer, 1A charger, 2A Asus charger, 2.1A battery. On OSes: latest pmOS and Ubuntu Touch, default test software.
Apart from that (USB power issue), the phone seems to work correctly. The phone is seen has a "PinePhone" when connected with USB to a Linux computer. See https://forum.pine64.org/showthread.php?tid=9042

Investigations:
If I measure VBUS (aka DCIN in older schematics) on the USB-C daughter board connector (using multimeter, touch the leftmost pins on the bottom row, they can be reached even with the flex cable plugged), I get when flex cable unplugged: 4.7V (sometimes 2.3V but less often and not reproducibly), when flex cable plugged: 1.21V (it should be 5V!).

I did measurements using names from "PinePhone USB-C small board schematic v1.0 20190730.pdf" given to me by TL on the Telegram dev chat.
I measure C101 to be 3.3 uf instead of 4.7 uf according to schematics. I measure C104 to be 265 pf, C105 to be 0.26nf, C106 to be > 10 uf (my tool does not go above)., C107 to be: 0.18nf.

I decided to bypass OVP to try fixing my PinePhone:

<gallery mode="traditional">
File:Braveheart_VBUS_1_from_diode.jpg|A 0.3mm insulated wire takes VBUS_1 (VBUS unprotected from overvoltages) from diode. See OVP component in PDF "PinePhone USB-C small board top placement v1.0 20190730.pdf".
File:Braveheart_VBUS_1_to_VBUS_at_pogopin.jpg|At the appropriate pogopin of my Braveheart, VBUS_1 is plugged directly to VBUS to bypass OVP which is not working on my USB-C daughter board. ! Be careful that in revisions following Braveheart the pogopins usage could change ! Do not inject 5V in 3V3 bus or I2C !
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.
</gallery>

With this bypass, the phone is able to boot with or without the battery, and to charge the battery. As this is a hack that reduces safety I will try to have my USB-C daughter board replaced.

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

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

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 75Ohm resistor when the switch is OFF.

=== 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.2

2020-05-15T01:14:04Z

Megous: /* Backlight */ Cleanups

The PinePhone v1.2 is a hardware revision of the PinePhone that shipped in 2020.

This page contains information and resources which are specific to the v1.2 revision of the PinePhone. For other revisions, or for resources related to all PinePhone revisions, see [[PinePhone]].



== Changes from v1.1 ==

The v1.2 mainboard revision changes the routing of several GPIOs to fix bugs and to improve power management. Therefore, it needs an updated device tree. The state of PL6 at boot can be used to distinguish between v1.1 (it can be pulled high) and v1.2 (it will remain low).

# The WiFi module's <tt>CHIP_EN</tt> input (connected to the kill switch) is now pulled down, so the WiFi will turn off reliably when the switch is off.
# PL2 is now connected to the WiFi module's reset pin, allowing the WiFi to be turned off or reset in software.
# The magnetometer's <tt>DRDY</tt> pin is now connected to PB1, allowing interrupt-driven periodic sensor readings.
# <tt>LINEOUTP</tt> is again connected to the speaker amplifier's INP input (like in v1.0), increasing the SNR of the rear speaker.
# PH7 is now connected to the modem's <tt>AP_READY</tt> input (instead of <tt>WAKEUP_IN</tt>), allowing the modem to buffer URCs (interrupts) while the phone is asleep.
# The modem's <tt>RI</tt> output and <tt>DTR</tt> input had their GPIOs swapped between PL6 and PB2, so the <tt>RI</tt> signal can be detected without powering the main pin controller.
# Both PL9 and <tt>VBUS_CTRL</tt> (from the ANX7688) are now connected to <tt>N_VBUSEN</tt> on the PMIC. This causes the PMIC to automatically stop drawing power from the USB port when supplying power to a USB OTG peripheral. It also allows the ANX7688 to automatically control the direction of current flowing through the USB port.
# As part of the previous change, the ANX7688's reset input was moved to PD6; this pin previously controlled the USB OTG power.
# Some of the regulators supplying the ANX7688 were rearranged, to reduce power consumption when the USB port is not connected and not being used to transmit video.
# As part of the previous change, PD11 now controls the ANX7688's 1v0 digital power domain.
# The modem's <tt>STATUS</tt> output is now connected to PH9, allowing the modem on/off state to be visible in software (note: this only works while the modem is powered). Since it is no longer connected to PB3, reading <tt>STATUS</tt> no longer turns the modem on.
# The modem no longer has access to the I2C bus containing the sensors.
# <tt>HBIAS</tt> is now connected to the headphone jack.

== Quirks ==

=== Backlight ===

Backlight LED current regulation depends on gpio0-ldo voltage stability due to feedback voltage from current sensing resistor being modified via SoC's PWM pin and pullup resistor to gpio0-ldo. gpio0-ldo also powers the CTP controller and light/proximity sensor, among other things. When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily. It's not a very good idea to tie boost converter's current regulating feedback circuit to the potential source of noise, especially since the noise will have much larger effect when the backlight LED current is low. It's possible this can be mittigated if C1110 can be raised to 22-47uF range, or by changing the resitor values in the feedback circuit.

PWM duty cycle for the lowest brightness of the backlight is also not very predictable, varying from 7-20% (sample size of 2 :)). Therefore it's not possible to come up with a single device tree brightness settings that will work for everyone, requiring per-device calibration.

On PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE pin of the regulator, and lowest brightness setting seems more stable. OTOH, the lowest achievable brightness was brighter than on 1.1+.

PinePhone v1.2

2020-05-15T01:12:04Z

Megous: Backlight quirks

The PinePhone v1.2 is a hardware revision of the PinePhone that shipped in 2020.

This page contains information and resources which are specific to the v1.2 revision of the PinePhone. For other revisions, or for resources related to all PinePhone revisions, see [[PinePhone]].



== Changes from v1.1 ==

The v1.2 mainboard revision changes the routing of several GPIOs to fix bugs and to improve power management. Therefore, it needs an updated device tree. The state of PL6 at boot can be used to distinguish between v1.1 (it can be pulled high) and v1.2 (it will remain low).

# The WiFi module's <tt>CHIP_EN</tt> input (connected to the kill switch) is now pulled down, so the WiFi will turn off reliably when the switch is off.
# PL2 is now connected to the WiFi module's reset pin, allowing the WiFi to be turned off or reset in software.
# The magnetometer's <tt>DRDY</tt> pin is now connected to PB1, allowing interrupt-driven periodic sensor readings.
# <tt>LINEOUTP</tt> is again connected to the speaker amplifier's INP input (like in v1.0), increasing the SNR of the rear speaker.
# PH7 is now connected to the modem's <tt>AP_READY</tt> input (instead of <tt>WAKEUP_IN</tt>), allowing the modem to buffer URCs (interrupts) while the phone is asleep.
# The modem's <tt>RI</tt> output and <tt>DTR</tt> input had their GPIOs swapped between PL6 and PB2, so the <tt>RI</tt> signal can be detected without powering the main pin controller.
# Both PL9 and <tt>VBUS_CTRL</tt> (from the ANX7688) are now connected to <tt>N_VBUSEN</tt> on the PMIC. This causes the PMIC to automatically stop drawing power from the USB port when supplying power to a USB OTG peripheral. It also allows the ANX7688 to automatically control the direction of current flowing through the USB port.
# As part of the previous change, the ANX7688's reset input was moved to PD6; this pin previously controlled the USB OTG power.
# Some of the regulators supplying the ANX7688 were rearranged, to reduce power consumption when the USB port is not connected and not being used to transmit video.
# As part of the previous change, PD11 now controls the ANX7688's 1v0 digital power domain.
# The modem's <tt>STATUS</tt> output is now connected to PH9, allowing the modem on/off state to be visible in software (note: this only works while the modem is powered). Since it is no longer connected to PB3, reading <tt>STATUS</tt> no longer turns the modem on.
# The modem no longer has access to the I2C bus containing the sensors.
# <tt>HBIAS</tt> is now connected to the headphone jack.

== Quirks ==

=== Backlight ===

Backlight LED current regulation depends on voltage on gpio0-ldo voltage stability due to feedback voltage from current sensing resistor being modified via SoC's PWM pin and pullup resistor to gpio0-ldo. gpio0-ldo also powers the CTP controller and light/proximity sensor, among other things. When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily. It's not a very good idea to tie boost converter's current regulating feedback circuit to the potential source of noise, especially since the noise will have much larger effect when the backlight LED current is low. It's possible this can improve if C1110 can be raised to 22-47uF range.

PWM duty cycle for the lowest brightness of the backlight is also not very predictable, varying from 7-20% (sample size of 2 :)). Therefore it's not possible to come up with a single device tree brightness settings that will work for everyone, requiring per-device calibration.

On PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE pin of the regulator, and lowest brightness setting seems more stable. OTOH, the lowest achievable brightness was brighter than on 1.1+.

PinePhone Power Management

2020-02-24T01:56:38Z

Megous: /* Open Questions */

The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].

== Regulators ==

=== Current Assignments ===

{| class="wikitable"
|-
! Name/GPIO
! Output Voltage
! Can disable at runtime?
! Can disable in suspend?
! Consumers (internal/external separated by semicolon)
|-
| DCDC1
| 3.3V
| No
| No (VCC-IO)
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN
|-
| DCDC2
| DVFS
| No
| Yes
| VDD-CPUX
|-
| DCDC3
| DVFS
| N/A
| N/A
| VDD-CPUX (polyphase with DCDC2)
|-
| DCDC4
| N/A
| Yes
| Yes
| Not used
|-
| DCDC5
| 1.2V
| No
| Yes (future)
| VCC-DRAM; DRAM
|-
| DCDC6
| 1.1V
| No
| Yes (future)
| VDD-SYS
|-
| DC1SW
| N/A
| Yes
| Yes
| Not used
|-
| ALDO1
| 2.8V
| Yes
| Yes
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C
|-
| ALDO2
| 1.8V
| No
| No (VCC-PL)
| VCC-PL; Pogo INT
|-
| ALDO3
| 3.0V
| No
| No (KEYADC)
| AVCC, KEYADC, VCC-PLL
|-
| DLDO1
| 3.3V
| No
| No (ANX7688 AVDD33)
| HVCC, VCC-DSI; ANX7688 [AVDD33, HDMI_VT, I2C, ANX-V1.0 Enable, VCONN_EN Disable Pull-up], HDMI [DDC, HPD], Proximity LED, Sensor I2C, Sensor VDD
|-
| DLDO2
| 1.8V? 3.3V?
| Yes
| Yes
| MIPI-DSI VIO
|-
| DLDO3
| 2.8V
| Yes
| Yes
| Camera AVDD
|-
| DLDO4
| 1.8V-3.3V
| Yes
| Yes
| VCC-PG; VQMMC1
|-
| ELDO1
| 1.8V
| No
| No (DRAM)
| CPVDD; DRAM
|-
| ELDO2
| N/A
| Yes
| Yes
| Not used
|-
| ELDO3
| 1.8V
| Yes
| Yes
| Camera DVDD
|-
| FLDO1
| 1.2V
| Yes
| Yes
| HSIC-VCC (not used)
|-
| FLDO2
| 1.1V
| No
| No (VDD-CPUS)
| VDD-CPUS
|-
| GPIO0-LDO
| 3.3V
| Yes
| Yes
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]
|-
| GPIO1-LDO
| 1.8V
| No
| No (ANX7688 DVDD1V8)
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]
|-
| PD6
| 5.0V
| Yes
| Yes
| USB OTG
|-
| PD8
| 5.0V
| Yes
| Yes
| Pogo supply, USB OTG via PD6
|-
| PD9
| 5.0V
| Yes
| Yes
| VCONN (USB Type C)
|-
| PH10
| PWM
| Yes
| Yes
| Backlight
|-
| PL7
| VBAT
| Yes
| Yes
| Modem
|-
| ANX-V1.0
| 1.0V
| Yes
| Yes
| ANX7688 [AVDD1V0, DVDD1V0]
|}

=== Suggested Regulator Hardware Changes ===

==== ANX7688 ====

# Move ANX7688 AVDD33 (the chip input only, not the other things connected to 3v3) and ANX7688 I2C Level Shift (3.3V side) from DLD01 to DCDC1
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO

These are all medium priority.

The result of these changes would be that:
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered
# GPIO1-LDO only needs to be powered when a USB cable is detected, and is enough to power the rest of the chip (except HDMI)
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in



=== Assignments after Suggested Changes ===

Note: Only regulators that were modified are included here.

{| class="wikitable"
|-
! Name/GPIO
! Output Voltage
! Can disable at runtime?
! Can disable in suspend?
! Consumers (internal/external separated by semicolon)
|-
| DCDC1
| 3.3V
| No
| No (VCC-IO)
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; ANX7688 [AVDD33, I2C], Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN
|-
| ALDO2
| 1.8V
| No
| No (VCC-PL)
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT
|-
| DLDO1
| 3.3V
| Yes
| Yes
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD
|-
| GPIO0-LDO
| 3.3V
| Yes
| Yes
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]
|-
| GPIO1-LDO
| 1.8V
| Yes
| Yes
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]
|}

=== Open Questions ===

* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.
** From LCD and LCD controller datasheets, this should be 1.8V.
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?
** Looks like this is N/A, because DLDO2 should be 1.8V.

=== Software Updates Needed ===

==== Drivers that Need Regulator Consumers ====

* LCD Panel for VCC-LCD
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO
* STK3311-A

==== Drivers that Need to Suspend Regulators ====

* STK3311-A
* LIS3MDL
* MPU6050
* Goodix touchscreen
* sunxi pinctrl (maybe)
* USB PHY

== GPIO ==

=== Current Modem Pin Assignments ===

Note: only pins relevant to power management are included in this table.

{| class="wikitable"
|-
! Pin
! Signal Name
! Description
! Direction (as modem)
! Needed in suspend?
! Connected to
|-
| 1
| <tt>WAKEUP_IN</tt>
| Drive low to wake up the modem
| I
| No
| PH7 (active high)
|-
| 2
| <tt>AP_READY</tt>
| Drive high/low to signal the A64 is ready to receive URCs
| I
| No (if held)
| NC
|-
| 4
| <tt>W_DISABLE#</tt>
| Drive low to enter Airplane Mode
| I
| No (if held/tristate)
| PH8 (active high)
|-
| 20
| <tt>RESET_N</tt>
| Drive low to reset the modem
| I
| No (if held/tristate)
| PC4 (active high)
|-
| 21
| <tt>PWRKEY</tt>
| Drive low to turn the modem on/off
| I
| No (if held/tristate)
| PB3 (active high)
|-
| 61
| <tt>STATUS</tt>
| Open drain output, pulled low when the modem is on
| O
| No
| PB3
|-
| 62
| <tt>RI</tt>
| Pulled low to request host wakeup
| O
| Yes
| PB2
|-
| 66
| <tt>DTR</tt>
| Drive low to wake up the modem
| I
| No
| PL6 (active low)
|}

=== Current Port L Pin Assignments ===

{| class="wikitable"
|-
! Pin
! Signal Name
! Description
! Direction
! Needed in suspend?
|-
| PL0
| <tt>PMU-SCK</tt>
| AXP803 I2C/RSB Clock
| O
| Yes
|-
| PL1
| <tt>PMU-SDA</tt>
| AXP803 I2C/RSB Data
| I/O
| Yes
|-
| PL2
| <tt>WL-REG-ON</tt>
| Not Connected
| N/A
| N/A
|-
| PL3
| <tt>WL-WAKE-AP</tt>
| Wake-on-WLAN Interrupt
| I
| Yes
|-
| PL4
| <tt>BT-RST-N</tt>
| Bluetooth Reset Control
| O
| No (if held)
|-
| PL5
| <tt>BT-WAKE-AP</tt>
| Wake-on-BT Interrupt
| I
| Yes
|-
| PL6
| <tt>DTR</tt>
| Modem DTR (Wakeup Request)
| O
| No
|-
| PL7
| <tt>4G-PWR-BAT</tt>
| Modem Power Supply Control
| O
| No (if held)
|-
| PL8
| <tt>ANX7688-CABLE_DET</tt>
| ANX7688 Cable Detection Interrupt
| I
| Yes
|-
| PL9
| <tt>ANX_RESET</tt>
| ANX7688 Reset Control
| O
| No (if held)
|-
| PL10
| <tt>LCD-PWM</tt>
| LCD Backlight PWM Brightness Control
| O
| No
|-
| PL11
| <tt>ANX7688-INT</tt>
| ANX7688 Alert Interrupt
| I
| Yes
|-
| PL12
| <tt>POGO-INT</tt>
| Pogo Pin Interrupt
| I
| Yes
|}

=== Pins Held During Suspend ===

=== Pins Active During Suspend ===

=== Suggested GPIO Hardware Changes ===

# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up to VDD_EXT on the modem side.
# Swap <tt>DTR</tt> (was at PL6, now at PB2 with level shift) and <tt>RI</tt> (was at PB2, now at PL6 with '''no level shift''', but a pull-up to ALDO2 on the A64 side*). ''partly a bugfix''
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''
# Connect the modem <tt>STATUS</tt> to an A64 GPIO input (any 3.3V pin bank is fine; this can reuse the level shifter previously connected to PL6). This needs a pull-up to VDD_EXT on the modem side. ''bugfix''
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).
# Connect the modem debug UART TX/RX to PD0-1.
# Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere.
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).
## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.
## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.
# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)
# Remove the transistors inverting <tt>VCONN1_EN</tt> and <tt>VCONN2_EN</tt>, and use a pull-up to <tt>DVDD1V8</tt> (that is really already present) instead of the pull-up to <tt>3V3</tt>.

'''Note:'''
Changes 1-7 and 11 are high priority.
Changes 12-13 are medium priority.
Changes 6-10 are low priority.

* There should be at least one pin where the default value at boot changes, due to being pulled differently, for use in distinguishing the hardware revisions. In v1.1, PL6 reads 0 at boot. Since RI is an active-low interrupt, it needs a pull up. And it doesn't need any level translation. So that's our perfect opportunity. If PL6 reads low at boot, it's a v1.1 device; if PL6 reads high at boot, it's a v1.2 device.

=== Open Questions ===

* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?
* Currently STATUS pin is connected to PWRKEY and to PB3. STATUS can't be read reliably since voltage divider from R1526 and R1517 places the STATUS signal at 0V or 0.5*Vcc-IO, which is unspecified input value according to A64 datasheet (Vih is 0.7*Vcc-IO, Vil is 0.3*Vcc-IO, the range in between is unspecified).

PinePhone Power Management

2020-02-24T01:55:09Z

Megous: /* Open Questions */

The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].

== Regulators ==

=== Current Assignments ===

{| class="wikitable"
|-
! Name/GPIO
! Output Voltage
! Can disable at runtime?
! Can disable in suspend?
! Consumers (internal/external separated by semicolon)
|-
| DCDC1
| 3.3V
| No
| No (VCC-IO)
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN
|-
| DCDC2
| DVFS
| No
| Yes
| VDD-CPUX
|-
| DCDC3
| DVFS
| N/A
| N/A
| VDD-CPUX (polyphase with DCDC2)
|-
| DCDC4
| N/A
| Yes
| Yes
| Not used
|-
| DCDC5
| 1.2V
| No
| Yes (future)
| VCC-DRAM; DRAM
|-
| DCDC6
| 1.1V
| No
| Yes (future)
| VDD-SYS
|-
| DC1SW
| N/A
| Yes
| Yes
| Not used
|-
| ALDO1
| 2.8V
| Yes
| Yes
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C
|-
| ALDO2
| 1.8V
| No
| No (VCC-PL)
| VCC-PL; Pogo INT
|-
| ALDO3
| 3.0V
| No
| No (KEYADC)
| AVCC, KEYADC, VCC-PLL
|-
| DLDO1
| 3.3V
| No
| No (ANX7688 AVDD33)
| HVCC, VCC-DSI; ANX7688 [AVDD33, HDMI_VT, I2C, ANX-V1.0 Enable, VCONN_EN Disable Pull-up], HDMI [DDC, HPD], Proximity LED, Sensor I2C, Sensor VDD
|-
| DLDO2
| 1.8V? 3.3V?
| Yes
| Yes
| MIPI-DSI VIO
|-
| DLDO3
| 2.8V
| Yes
| Yes
| Camera AVDD
|-
| DLDO4
| 1.8V-3.3V
| Yes
| Yes
| VCC-PG; VQMMC1
|-
| ELDO1
| 1.8V
| No
| No (DRAM)
| CPVDD; DRAM
|-
| ELDO2
| N/A
| Yes
| Yes
| Not used
|-
| ELDO3
| 1.8V
| Yes
| Yes
| Camera DVDD
|-
| FLDO1
| 1.2V
| Yes
| Yes
| HSIC-VCC (not used)
|-
| FLDO2
| 1.1V
| No
| No (VDD-CPUS)
| VDD-CPUS
|-
| GPIO0-LDO
| 3.3V
| Yes
| Yes
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]
|-
| GPIO1-LDO
| 1.8V
| No
| No (ANX7688 DVDD1V8)
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]
|-
| PD6
| 5.0V
| Yes
| Yes
| USB OTG
|-
| PD8
| 5.0V
| Yes
| Yes
| Pogo supply, USB OTG via PD6
|-
| PD9
| 5.0V
| Yes
| Yes
| VCONN (USB Type C)
|-
| PH10
| PWM
| Yes
| Yes
| Backlight
|-
| PL7
| VBAT
| Yes
| Yes
| Modem
|-
| ANX-V1.0
| 1.0V
| Yes
| Yes
| ANX7688 [AVDD1V0, DVDD1V0]
|}

=== Suggested Regulator Hardware Changes ===

==== ANX7688 ====

# Move ANX7688 AVDD33 (the chip input only, not the other things connected to 3v3) and ANX7688 I2C Level Shift (3.3V side) from DLD01 to DCDC1
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO

These are all medium priority.

The result of these changes would be that:
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered
# GPIO1-LDO only needs to be powered when a USB cable is detected, and is enough to power the rest of the chip (except HDMI)
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in



=== Assignments after Suggested Changes ===

Note: Only regulators that were modified are included here.

{| class="wikitable"
|-
! Name/GPIO
! Output Voltage
! Can disable at runtime?
! Can disable in suspend?
! Consumers (internal/external separated by semicolon)
|-
| DCDC1
| 3.3V
| No
| No (VCC-IO)
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; ANX7688 [AVDD33, I2C], Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN
|-
| ALDO2
| 1.8V
| No
| No (VCC-PL)
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT
|-
| DLDO1
| 3.3V
| Yes
| Yes
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD
|-
| GPIO0-LDO
| 3.3V
| Yes
| Yes
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]
|-
| GPIO1-LDO
| 1.8V
| Yes
| Yes
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]
|}

=== Open Questions ===

* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.
** From LCD and LCD controller datasheets, this should be 1.8V.
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?
** Looks like this is N/A, because DLDO2 should be 1.8V.

=== Software Updates Needed ===

==== Drivers that Need Regulator Consumers ====

* LCD Panel for VCC-LCD
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO
* STK3311-A

==== Drivers that Need to Suspend Regulators ====

* STK3311-A
* LIS3MDL
* MPU6050
* Goodix touchscreen
* sunxi pinctrl (maybe)
* USB PHY

== GPIO ==

=== Current Modem Pin Assignments ===

Note: only pins relevant to power management are included in this table.

{| class="wikitable"
|-
! Pin
! Signal Name
! Description
! Direction (as modem)
! Needed in suspend?
! Connected to
|-
| 1
| <tt>WAKEUP_IN</tt>
| Drive low to wake up the modem
| I
| No
| PH7 (active high)
|-
| 2
| <tt>AP_READY</tt>
| Drive high/low to signal the A64 is ready to receive URCs
| I
| No (if held)
| NC
|-
| 4
| <tt>W_DISABLE#</tt>
| Drive low to enter Airplane Mode
| I
| No (if held/tristate)
| PH8 (active high)
|-
| 20
| <tt>RESET_N</tt>
| Drive low to reset the modem
| I
| No (if held/tristate)
| PC4 (active high)
|-
| 21
| <tt>PWRKEY</tt>
| Drive low to turn the modem on/off
| I
| No (if held/tristate)
| PB3 (active high)
|-
| 61
| <tt>STATUS</tt>
| Open drain output, pulled low when the modem is on
| O
| No
| PB3
|-
| 62
| <tt>RI</tt>
| Pulled low to request host wakeup
| O
| Yes
| PB2
|-
| 66
| <tt>DTR</tt>
| Drive low to wake up the modem
| I
| No
| PL6 (active low)
|}

=== Current Port L Pin Assignments ===

{| class="wikitable"
|-
! Pin
! Signal Name
! Description
! Direction
! Needed in suspend?
|-
| PL0
| <tt>PMU-SCK</tt>
| AXP803 I2C/RSB Clock
| O
| Yes
|-
| PL1
| <tt>PMU-SDA</tt>
| AXP803 I2C/RSB Data
| I/O
| Yes
|-
| PL2
| <tt>WL-REG-ON</tt>
| Not Connected
| N/A
| N/A
|-
| PL3
| <tt>WL-WAKE-AP</tt>
| Wake-on-WLAN Interrupt
| I
| Yes
|-
| PL4
| <tt>BT-RST-N</tt>
| Bluetooth Reset Control
| O
| No (if held)
|-
| PL5
| <tt>BT-WAKE-AP</tt>
| Wake-on-BT Interrupt
| I
| Yes
|-
| PL6
| <tt>DTR</tt>
| Modem DTR (Wakeup Request)
| O
| No
|-
| PL7
| <tt>4G-PWR-BAT</tt>
| Modem Power Supply Control
| O
| No (if held)
|-
| PL8
| <tt>ANX7688-CABLE_DET</tt>
| ANX7688 Cable Detection Interrupt
| I
| Yes
|-
| PL9
| <tt>ANX_RESET</tt>
| ANX7688 Reset Control
| O
| No (if held)
|-
| PL10
| <tt>LCD-PWM</tt>
| LCD Backlight PWM Brightness Control
| O
| No
|-
| PL11
| <tt>ANX7688-INT</tt>
| ANX7688 Alert Interrupt
| I
| Yes
|-
| PL12
| <tt>POGO-INT</tt>
| Pogo Pin Interrupt
| I
| Yes
|}

=== Pins Held During Suspend ===

=== Pins Active During Suspend ===

=== Suggested GPIO Hardware Changes ===

# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up to VDD_EXT on the modem side.
# Swap <tt>DTR</tt> (was at PL6, now at PB2 with level shift) and <tt>RI</tt> (was at PB2, now at PL6 with '''no level shift''', but a pull-up to ALDO2 on the A64 side*). ''partly a bugfix''
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''
# Connect the modem <tt>STATUS</tt> to an A64 GPIO input (any 3.3V pin bank is fine; this can reuse the level shifter previously connected to PL6). This needs a pull-up to VDD_EXT on the modem side. ''bugfix''
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).
# Connect the modem debug UART TX/RX to PD0-1.
# Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere.
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).
## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.
## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.
# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)
# Remove the transistors inverting <tt>VCONN1_EN</tt> and <tt>VCONN2_EN</tt>, and use a pull-up to <tt>DVDD1V8</tt> (that is really already present) instead of the pull-up to <tt>3V3</tt>.

'''Note:'''
Changes 1-7 and 11 are high priority.
Changes 12-13 are medium priority.
Changes 6-10 are low priority.

* There should be at least one pin where the default value at boot changes, due to being pulled differently, for use in distinguishing the hardware revisions. In v1.1, PL6 reads 0 at boot. Since RI is an active-low interrupt, it needs a pull up. And it doesn't need any level translation. So that's our perfect opportunity. If PL6 reads low at boot, it's a v1.1 device; if PL6 reads high at boot, it's a v1.2 device.

=== Open Questions ===

* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?
* Currently STATUS pin is being connected to PWRKEY and to PB3. STATUS can't be read reliably since voltage divider from R1526 and R1517 places the STATUS signal at 0V or 0.5*Vcc-IO, which is unspecified input value according to A64 datasheet (Vih is 0.7*Vcc-IO, Vil is 0.3*Vcc-IO, the range in between is unspecified).

PinePhone Power Management

2020-02-24T01:51:53Z

Megous: /* Suggested GPIO Hardware Changes */

PinePhone Power Management

2020-02-24T01:51:17Z

Megous: /* Suggested GPIO Hardware Changes */

The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].

== Regulators ==

=== Current Assignments ===

{| class="wikitable"
|-
! Name/GPIO
! Output Voltage
! Can disable at runtime?
! Can disable in suspend?
! Consumers (internal/external separated by semicolon)
|-
| DCDC1
| 3.3V
| No
| No (VCC-IO)
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN
|-
| DCDC2
| DVFS
| No
| Yes
| VDD-CPUX
|-
| DCDC3
| DVFS
| N/A
| N/A
| VDD-CPUX (polyphase with DCDC2)
|-
| DCDC4
| N/A
| Yes
| Yes
| Not used
|-
| DCDC5
| 1.2V
| No
| Yes (future)
| VCC-DRAM; DRAM
|-
| DCDC6
| 1.1V
| No
| Yes (future)
| VDD-SYS
|-
| DC1SW
| N/A
| Yes
| Yes
| Not used
|-
| ALDO1
| 2.8V
| Yes
| Yes
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C
|-
| ALDO2
| 1.8V
| No
| No (VCC-PL)
| VCC-PL; Pogo INT
|-
| ALDO3
| 3.0V
| No
| No (KEYADC)
| AVCC, KEYADC, VCC-PLL
|-
| DLDO1
| 3.3V
| No
| No (ANX7688 AVDD33)
| HVCC, VCC-DSI; ANX7688 [AVDD33, HDMI_VT, I2C, ANX-V1.0 Enable, VCONN_EN Disable Pull-up], HDMI [DDC, HPD], Proximity LED, Sensor I2C, Sensor VDD
|-
| DLDO2
| 1.8V? 3.3V?
| Yes
| Yes
| MIPI-DSI VIO
|-
| DLDO3
| 2.8V
| Yes
| Yes
| Camera AVDD
|-
| DLDO4
| 1.8V-3.3V
| Yes
| Yes
| VCC-PG; VQMMC1
|-
| ELDO1
| 1.8V
| No
| No (DRAM)
| CPVDD; DRAM
|-
| ELDO2
| N/A
| Yes
| Yes
| Not used
|-
| ELDO3
| 1.8V
| Yes
| Yes
| Camera DVDD
|-
| FLDO1
| 1.2V
| Yes
| Yes
| HSIC-VCC (not used)
|-
| FLDO2
| 1.1V
| No
| No (VDD-CPUS)
| VDD-CPUS
|-
| GPIO0-LDO
| 3.3V
| Yes
| Yes
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]
|-
| GPIO1-LDO
| 1.8V
| No
| No (ANX7688 DVDD1V8)
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]
|-
| PD6
| 5.0V
| Yes
| Yes
| USB OTG
|-
| PD8
| 5.0V
| Yes
| Yes
| Pogo supply, USB OTG via PD6
|-
| PD9
| 5.0V
| Yes
| Yes
| VCONN (USB Type C)
|-
| PH10
| PWM
| Yes
| Yes
| Backlight
|-
| PL7
| VBAT
| Yes
| Yes
| Modem
|-
| ANX-V1.0
| 1.0V
| Yes
| Yes
| ANX7688 [AVDD1V0, DVDD1V0]
|}

=== Suggested Regulator Hardware Changes ===

==== ANX7688 ====

# Move ANX7688 AVDD33 (the chip input only, not the other things connected to 3v3) and ANX7688 I2C Level Shift (3.3V side) from DLD01 to DCDC1
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO

These are all medium priority.

The result of these changes would be that:
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered
# GPIO1-LDO only needs to be powered when a USB cable is detected, and is enough to power the rest of the chip (except HDMI)
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in



=== Assignments after Suggested Changes ===

Note: Only regulators that were modified are included here.

{| class="wikitable"
|-
! Name/GPIO
! Output Voltage
! Can disable at runtime?
! Can disable in suspend?
! Consumers (internal/external separated by semicolon)
|-
| DCDC1
| 3.3V
| No
| No (VCC-IO)
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; ANX7688 [AVDD33, I2C], Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN
|-
| ALDO2
| 1.8V
| No
| No (VCC-PL)
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT
|-
| DLDO1
| 3.3V
| Yes
| Yes
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD
|-
| GPIO0-LDO
| 3.3V
| Yes
| Yes
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]
|-
| GPIO1-LDO
| 1.8V
| Yes
| Yes
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]
|}

=== Open Questions ===

* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.
** From LCD and LCD controller datasheets, this should be 1.8V.
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?
** Looks like this is N/A, because DLDO2 should be 1.8V.

=== Software Updates Needed ===

==== Drivers that Need Regulator Consumers ====

* LCD Panel for VCC-LCD
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO
* STK3311-A

==== Drivers that Need to Suspend Regulators ====

* STK3311-A
* LIS3MDL
* MPU6050
* Goodix touchscreen
* sunxi pinctrl (maybe)
* USB PHY

== GPIO ==

=== Current Modem Pin Assignments ===

Note: only pins relevant to power management are included in this table.

{| class="wikitable"
|-
! Pin
! Signal Name
! Description
! Direction (as modem)
! Needed in suspend?
! Connected to
|-
| 1
| <tt>WAKEUP_IN</tt>
| Drive low to wake up the modem
| I
| No
| PH7 (active high)
|-
| 2
| <tt>AP_READY</tt>
| Drive high/low to signal the A64 is ready to receive URCs
| I
| No (if held)
| NC
|-
| 4
| <tt>W_DISABLE#</tt>
| Drive low to enter Airplane Mode
| I
| No (if held/tristate)
| PH8 (active high)
|-
| 20
| <tt>RESET_N</tt>
| Drive low to reset the modem
| I
| No (if held/tristate)
| PC4 (active high)
|-
| 21
| <tt>PWRKEY</tt>
| Drive low to turn the modem on/off
| I
| No (if held/tristate)
| PB3 (active high)
|-
| 61
| <tt>STATUS</tt>
| Open drain output, pulled low when the modem is on
| O
| No
| PB3
|-
| 62
| <tt>RI</tt>
| Pulled low to request host wakeup
| O
| Yes
| PB2
|-
| 66
| <tt>DTR</tt>
| Drive low to wake up the modem
| I
| No
| PL6 (active low)
|}

=== Current Port L Pin Assignments ===

{| class="wikitable"
|-
! Pin
! Signal Name
! Description
! Direction
! Needed in suspend?
|-
| PL0
| <tt>PMU-SCK</tt>
| AXP803 I2C/RSB Clock
| O
| Yes
|-
| PL1
| <tt>PMU-SDA</tt>
| AXP803 I2C/RSB Data
| I/O
| Yes
|-
| PL2
| <tt>WL-REG-ON</tt>
| Not Connected
| N/A
| N/A
|-
| PL3
| <tt>WL-WAKE-AP</tt>
| Wake-on-WLAN Interrupt
| I
| Yes
|-
| PL4
| <tt>BT-RST-N</tt>
| Bluetooth Reset Control
| O
| No (if held)
|-
| PL5
| <tt>BT-WAKE-AP</tt>
| Wake-on-BT Interrupt
| I
| Yes
|-
| PL6
| <tt>DTR</tt>
| Modem DTR (Wakeup Request)
| O
| No
|-
| PL7
| <tt>4G-PWR-BAT</tt>
| Modem Power Supply Control
| O
| No (if held)
|-
| PL8
| <tt>ANX7688-CABLE_DET</tt>
| ANX7688 Cable Detection Interrupt
| I
| Yes
|-
| PL9
| <tt>ANX_RESET</tt>
| ANX7688 Reset Control
| O
| No (if held)
|-
| PL10
| <tt>LCD-PWM</tt>
| LCD Backlight PWM Brightness Control
| O
| No
|-
| PL11
| <tt>ANX7688-INT</tt>
| ANX7688 Alert Interrupt
| I
| Yes
|-
| PL12
| <tt>POGO-INT</tt>
| Pogo Pin Interrupt
| I
| Yes
|}

=== Pins Held During Suspend ===

=== Pins Active During Suspend ===

=== Suggested GPIO Hardware Changes ===

# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up to VDD_EXT on the modem side.
# Swap <tt>DTR</tt> (was at PL6, now at PB2 with level shift) and <tt>RI</tt> (was at PB2, now at PL6 with '''no level shift''', but a pull-up to ALDO2 on the A64 side*). ''partly a bugfix''
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''
# Connect the modem <tt>STATUS</tt> to an A64 GPIO input (any 3.3V pin bank is fine; this can reuse the level shifter previously connected to PL6). This needs a pull-up to VDD_EXT on the modem side. ''bugfix''
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).
# Connect the modem debug UART TX/RX to PD0-1.
# Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere.
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).
## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.
## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.
# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)
# Remove the transistors inverting <tt>VCONN1_EN</tt> and <tt>VCONN2_EN</tt>, and use a pull-up to <tt>DVDD1V8</tt> (that is really already present) instead of the pull-up to <tt>3V3</tt>.

'''Note:'''
Changes 1-5 and 11 are high priority.
Changes 12-13 are medium priority.
Changes 6-10 are low priority.

* There should be at least one pin where the default value at boot changes, due to being pulled differently, for use in distinguishing the hardware revisions. In v1.1, PL6 reads 0 at boot. Since RI is an active-low interrupt, it needs a pull up. And it doesn't need any level translation. So that's our perfect opportunity. If PL6 reads low at boot, it's a v1.1 device; if PL6 reads high at boot, it's a v1.2 device.

=== Open Questions ===

* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?

PinePhone v1.1 - Braveheart

2020-02-09T20:00:32Z

Megous: /* Known issues */

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship 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.

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.

=== Excess power consumption while using USB OTG ===

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 would be fixed by populating R1300.

There is a possible (but less reliable) software workaround, by setting a control bit to temporarily disable drawing power from the USB bus.

=== Modem Ring Indicator placement prevents deep sleep ===

The EG25G's Ring Indicator pin is currently routed to GPIO pin PB2.

Ring Indicator is a configurable signaling pin capable of notifying the modem's host of incoming messages or calls. This makes it important to read the status of the pin during (ARISC / Super Standby) sleep, since incoming calls or text messages must wake the device.

Using the PB bank of GPIO on the A64 requires VCC-IO to be switched on. DCDC1, which powers VCC-IO, also powers most of the rest of the phone, including the eMMC, microSD, and USB controller, and enables the POGO pins, WiFi, modem sound, motor, headphone port, etc.

The only GPIO bank that works (can receive interrupts) while the A64 is suspended, and is independent from the regulators powering other periphherals, is Port L (on <tt>R_PIO</tt>).

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

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

Ideally, when the modem is communicating over USB, it can use the USB host suspend state to know when the host is active, and would not need the separate <tt>AP_READY</tt> signal. It is not known whether this is the case.

=== Modem PWR_KEY signal is not connected ===

On 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 anyhting 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 UART flow control is broken ===

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.

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

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.

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

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 ===

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.

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

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.

PinePhone v1.1 - Braveheart

2020-02-01T19:45:42Z

Megous: /* Magnetometer's IRQ signal is routed to the wrong pin */

PinePhone v1.1 - Braveheart

2020-02-01T19:42:17Z

Megous: /* Known issues */ Magnetometer

PinePhone v1.1 - Braveheart

2020-01-16T17:04:55Z

Megous: /* Modem PWR_KEY signal is not connected */

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship 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.

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.

=== Excess power consumption while using USB OTG ===

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 would be fixed by populating R1300.

There is a possible (but less reliable) software workaround, by setting a control bit to temporarily disable drawing power from the USB bus.

=== Modem Ring Indicator placement is not ideal ===

The EG25G's Ring Indicator pin is currently routed to GPIO pin PB2.

Ring Indicator is a configurable signaling pin capable of notifying the modem's host of incoming messages or calls. This makes it important to read the status of the pin during (ARISC / Super Standby) sleep, since incoming calls or text messages must wake the device.

Using the PB bank of GPIO on the A64 requires VCC-IO to be switched on. The only bank that does not have this requirement is the PL bank, at least as far as we can tell. Using information from the (related) A83T's manual:

"In the super standby mode,GPIO B/C/D/E/F/G/H of VDD_SYS domain can hold a particular output state through GPIO pad hold function,but VCC power of GPIO can not be closed at this time"

Ideally, Ring Indicator would be routed to somewhere on the PL bank because it stays active even when VCC-IO is switched off. In the current form, VCC-IO must stay on in Super Standby to allow the use of the Ring Indicator. The power usage difference between VCC-IO off and on is currently unknown, however, since [https://github.com/crust-firmware/crust crust] is not able to disable peripherals or clock trees.

Re-routing Ring Indicator would require a new Device Tree for the system, so different images may need to be created.

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

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

Ideally, when the modem is communicating over USB, it can use the USB host suspend state to know when the host is active, and would not need the separate <tt>AP_READY</tt> signal. It is not known whether this is the case.

=== Modem PWR_KEY signal is not connected ===

On 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 anyhting 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 UART flow control is broken ===

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.

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

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.

PinePhone v1.1 - Braveheart

2020-01-16T17:04:24Z

Megous: /* Modem PWR_KEY signal is not connected */

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship 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.

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.

=== Excess power consumption while using USB OTG ===

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 would be fixed by populating R1300.

There is a possible (but less reliable) software workaround, by setting a control bit to temporarily disable drawing power from the USB bus.

=== Modem Ring Indicator placement is not ideal ===

The EG25G's Ring Indicator pin is currently routed to GPIO pin PB2.

Ring Indicator is a configurable signaling pin capable of notifying the modem's host of incoming messages or calls. This makes it important to read the status of the pin during (ARISC / Super Standby) sleep, since incoming calls or text messages must wake the device.

Using the PB bank of GPIO on the A64 requires VCC-IO to be switched on. The only bank that does not have this requirement is the PL bank, at least as far as we can tell. Using information from the (related) A83T's manual:

"In the super standby mode,GPIO B/C/D/E/F/G/H of VDD_SYS domain can hold a particular output state through GPIO pad hold function,but VCC power of GPIO can not be closed at this time"

Ideally, Ring Indicator would be routed to somewhere on the PL bank because it stays active even when VCC-IO is switched off. In the current form, VCC-IO must stay on in Super Standby to allow the use of the Ring Indicator. The power usage difference between VCC-IO off and on is currently unknown, however, since [https://github.com/crust-firmware/crust crust] is not able to disable peripherals or clock trees.

Re-routing Ring Indicator would require a new Device Tree for the system, so different images may need to be created.

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

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

Ideally, when the modem is communicating over USB, it can use the USB host suspend state to know when the host is active, and would not need the separate <tt>AP_READY</tt> signal. It is not known whether this is the case.

=== Modem PWR_KEY signal is not connected ===

On 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 anyhting 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 asserted 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 UART flow control is broken ===

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.

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

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.

PinePhone v1.1 - Braveheart

2020-01-16T16:55:35Z

Megous: /* Modem PWR_KEY signal is not connected */

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship 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.

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.

=== Excess power consumption while using USB OTG ===

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 would be fixed by populating R1300.

There is a possible (but less reliable) software workaround, by setting a control bit to temporarily disable drawing power from the USB bus.

=== Modem Ring Indicator placement is not ideal ===

The EG25G's Ring Indicator pin is currently routed to GPIO pin PB2.

Ring Indicator is a configurable signaling pin capable of notifying the modem's host of incoming messages or calls. This makes it important to read the status of the pin during (ARISC / Super Standby) sleep, since incoming calls or text messages must wake the device.

Using the PB bank of GPIO on the A64 requires VCC-IO to be switched on. The only bank that does not have this requirement is the PL bank, at least as far as we can tell. Using information from the (related) A83T's manual:

"In the super standby mode,GPIO B/C/D/E/F/G/H of VDD_SYS domain can hold a particular output state through GPIO pad hold function,but VCC power of GPIO can not be closed at this time"

Ideally, Ring Indicator would be routed to somewhere on the PL bank because it stays active even when VCC-IO is switched off. In the current form, VCC-IO must stay on in Super Standby to allow the use of the Ring Indicator. The power usage difference between VCC-IO off and on is currently unknown, however, since [https://github.com/crust-firmware/crust crust] is not able to disable peripherals or clock trees.

Re-routing Ring Indicator would require a new Device Tree for the system, so different images may need to be created.

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

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

Ideally, when the modem is communicating over USB, it can use the USB host suspend state to know when the host is active, and would not need the separate <tt>AP_READY</tt> signal. It is not known whether this is the case.

=== Modem PWR_KEY signal is not connected ===

On 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 anyhting 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.

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

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.

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

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.

PinePhone v1.1 - Braveheart

2020-01-16T16:55:06Z

Megous: /* Modem PWR_KEY signal is not connected */

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship 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.

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.

=== Excess power consumption while using USB OTG ===

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 would be fixed by populating R1300.

There is a possible (but less reliable) software workaround, by setting a control bit to temporarily disable drawing power from the USB bus.

=== Modem Ring Indicator placement is not ideal ===

The EG25G's Ring Indicator pin is currently routed to GPIO pin PB2.

Ring Indicator is a configurable signaling pin capable of notifying the modem's host of incoming messages or calls. This makes it important to read the status of the pin during (ARISC / Super Standby) sleep, since incoming calls or text messages must wake the device.

Using the PB bank of GPIO on the A64 requires VCC-IO to be switched on. The only bank that does not have this requirement is the PL bank, at least as far as we can tell. Using information from the (related) A83T's manual:

"In the super standby mode,GPIO B/C/D/E/F/G/H of VDD_SYS domain can hold a particular output state through GPIO pad hold function,but VCC power of GPIO can not be closed at this time"

Ideally, Ring Indicator would be routed to somewhere on the PL bank because it stays active even when VCC-IO is switched off. In the current form, VCC-IO must stay on in Super Standby to allow the use of the Ring Indicator. The power usage difference between VCC-IO off and on is currently unknown, however, since [https://github.com/crust-firmware/crust crust] is not able to disable peripherals or clock trees.

Re-routing Ring Indicator would require a new Device Tree for the system, so different images may need to be created.

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

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

Ideally, when the modem is communicating over USB, it can use the USB host suspend state to know when the host is active, and would not need the separate <tt>AP_READY</tt> signal. It is not known whether this is the case.

=== Modem PWR_KEY signal is not connected ===

On 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 anyhting 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 previous status, it's necessary to know the current status before sending the pulse.

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

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.

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

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.

PinePhone v1.1 - Braveheart

2020-01-16T15:58:53Z

Megous: /* Modem PWR_KEY signal is not connected */

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship 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.

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.

=== Excess power consumption while using USB OTG ===

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 would be fixed by populating R1300.

There is a possible (but less reliable) software workaround, by setting a control bit to temporarily disable drawing power from the USB bus.

=== Modem Ring Indicator placement is not ideal ===

The EG25G's Ring Indicator pin is currently routed to GPIO pin PB2.

Ring Indicator is a configurable signaling pin capable of notifying the modem's host of incoming messages or calls. This makes it important to read the status of the pin during (ARISC / Super Standby) sleep, since incoming calls or text messages must wake the device.

Using the PB bank of GPIO on the A64 requires VCC-IO to be switched on. The only bank that does not have this requirement is the PL bank, at least as far as we can tell. Using information from the (related) A83T's manual:

"In the super standby mode,GPIO B/C/D/E/F/G/H of VDD_SYS domain can hold a particular output state through GPIO pad hold function,but VCC power of GPIO can not be closed at this time"

Ideally, Ring Indicator would be routed to somewhere on the PL bank because it stays active even when VCC-IO is switched off. In the current form, VCC-IO must stay on in Super Standby to allow the use of the Ring Indicator. The power usage difference between VCC-IO off and on is currently unknown, however, since [https://github.com/crust-firmware/crust crust] is not able to disable peripherals or clock trees.

Re-routing Ring Indicator would require a new Device Tree for the system, so different images may need to be created.

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

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

Ideally, when the modem is communicating over USB, it can use the USB host suspend state to know when the host is active, and would not need the separate <tt>AP_READY</tt> signal. It is not known whether this is the case.

=== Modem PWR_KEY signal is not connected ===

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

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

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.

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

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.

PinePhone v1.1 - Braveheart

2020-01-16T15:58:03Z

Megous: /* Known issues */ Add BH modem PWRKEY issue

The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship 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.

== Known issues ==

This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.

=== Excess power consumption while using USB OTG ===

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 would be fixed by populating R1300.

There is a possible (but less reliable) software workaround, by setting a control bit to temporarily disable drawing power from the USB bus.

=== Modem Ring Indicator placement is not ideal ===

The EG25G's Ring Indicator pin is currently routed to GPIO pin PB2.

Ring Indicator is a configurable signaling pin capable of notifying the modem's host of incoming messages or calls. This makes it important to read the status of the pin during (ARISC / Super Standby) sleep, since incoming calls or text messages must wake the device.

Using the PB bank of GPIO on the A64 requires VCC-IO to be switched on. The only bank that does not have this requirement is the PL bank, at least as far as we can tell. Using information from the (related) A83T's manual:

"In the super standby mode,GPIO B/C/D/E/F/G/H of VDD_SYS domain can hold a particular output state through GPIO pad hold function,but VCC power of GPIO can not be closed at this time"

Ideally, Ring Indicator would be routed to somewhere on the PL bank because it stays active even when VCC-IO is switched off. In the current form, VCC-IO must stay on in Super Standby to allow the use of the Ring Indicator. The power usage difference between VCC-IO off and on is currently unknown, however, since [https://github.com/crust-firmware/crust crust] is not able to disable peripherals or clock trees.

Re-routing Ring Indicator would require a new Device Tree for the system, so different images may need to be created.

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

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

Ideally, when the modem is communicating over USB, it can use the USB host suspend state to know when the host is active, and would not need the separate <tt>AP_READY</tt> signal. It is not known whether this is the case.

=== Modem PWR_KEY signal is not connected ===

On 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 anyhting, 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).

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

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.

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

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.