https://wiki.pine64.org/api.php?action=feedcontributions&user=Smaeul&feedformat=atomPINE64 - User contributions [en]2024-03-29T12:54:31ZUser contributionsMediaWiki 1.37.1https://wiki.pine64.org/index.php?title=Quartz64_Development&diff=12864Quartz64 Development2022-04-20T04:51:15Z<p>Smaeul: Update EBC status</p>
<hr />
<div>This page documents the current status of software support for the [[Quartz64]] single-board computer, and provides links to resources to help prospective contributors get started. Information is kept current on a best-effort basis as various patches get accepted into the kernel.<br />
<br />
== Overview ==<br />
<br />
=== Upstreaming Status ===<br />
<br />
{| class="wikitable plainrowheaders" border="1"<br />
! scope="col" | Function<br />
! scope="col" colspan="2" | Status<br />
! scope="col" | Component<br />
! scope="col" | Notes<br />
! scope="col" | Applies To<br />
|-<br />
! scope="row" rowspan="3" | Video Output<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=630407]</sup><br />
| <code>rockchipdrm/VOP2</code><br />
|<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>rockchip-edpphy-naneng</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/phy/rockchip/phy-rockchip-naneng-edp.c] and [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/commit/d7ad116fb30d11d110aeb880754cf27f34c45c40#7e8e2ef87e479c54539dc519c0b92d6b31727f8d_671_681] Coordinate any porting with Rockchip first<br />
|<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>dw-mipi-dsi-rockchip</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/gpu/drm/rockchip/dw-mipi-dsi.c]<br />
|<br />
|-<br />
! scope="row" | 3D Acceleration <br />
| style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| style="background:PaleGreen; text-align:center;"|Upstream Mesa<br />
| <code>panfrost</code><br />
| As of 5.18<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=810028668c6d9da25664195d6b906c98a8169f72]</sup><br />
|-<br />
! scope="row" | Video Decode <br />
| style="background:LightYellow; text-align:center;"|Linux Staging<br />
| style="background:#F99; text-align:center;"|Not in ffmpeg<sup>[https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898]</sup><br />
| <code>hantro-vpu</code> and <code>rkvdec</code>, using <code>v4l2-requests</code><br />
| Necessary device tree changes for the Hantro VPU [https://patchwork.kernel.org/project/linux-rockchip/patch/20210719225806.26680-1-ezequiel@collabora.com/ in review]. rkvdec hardware has been updated compared to rk3399 and may require driver changes.<br />
|-<br />
! scope="row" rowspan="3" | Audio <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-i2s-tdm</code><br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43b058698f723e3c2087af7069c0da082a3ecbe1]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-spdif</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dac825b6a6bdca41347e25f07354ad94fdc97445]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk817-codec</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d6a04da9b25b9a7cf2cac5f5079e3296d3bee0f]</sup>.<br />
| Quartz64 Model A/B<br />
|-<br />
! scope="row" | u-boot<br />
| colspan="2" style="background:#F99; text-align:center;"|Waiting on ATF sources<br />
|<br />
|<br />
|-<br />
! scope="row" rowspan="4" | Device Tree<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| Quartz64 Model A<br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b33a22a1e7c4248608e533fc4fa524258b3fae84]</sup><br />
| Quartz64 Model A<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| Quartz64 Model B<br />
|<br />
| Quartz64 Model B<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| SOQuartz<br />
|<br />
| SOQuartz<br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| PineNote<br />
| As of 5.18<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d449121e5e8addcee654250cec298c887ecafb32]</sup><br />
| PineNote<br />
|-<br />
! scope="row" rowspan="2"| Gigabit Ethernet<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3566-gmac</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb3d6b1c1957e88bfc5e77a4557f7e6ba761fe3]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>yt8511-phy</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48e8c6f1612b3d2dccaea2285231def830cc5b8e]</sup><br />
|-<br />
! scope="row" | IOMMU<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-iommu</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c55356c534aa651ccc3053ef2d5d8d810adacf5f]</sup><br />
|-<br />
! scope="row" | GPIO<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>gpio-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936ee2675eee1faca0dcdfa79165c7990422e0fc]</sup><br />
|-<br />
! scope="row" | pinctrl<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
|<br />
|<br />
|-<br />
! scope="row" | Thermal Regulation<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-thermal</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4b14c055a6f644cbeb1156ba24647e92fe51ec69]</sup><br />
|-<br />
! scope="row" | PCIe<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>pcie-dw-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e898eb8df4e34c7b129452444eb7cef68a11f43]</sup><br />
|-<br />
! scope="row" | Power Management<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-pm-domains</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1782c87b44a0b1a527f01a6a184677c58ccbf9c7]</sup><br />
|-<br />
! scope="row" | Voltage Control<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3568-pmu-io-voltage-domain</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28b05a64e47cbceebb8a5f3f643033148d5c06c3]</sup><br />
|-<br />
! scope="row" | SPI <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>spi-rockchip</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d74d99229f4d48f42d674f7a8a1137179efd67ac]</sup>. Necessary device tree changes [https://patchwork.kernel.org/project/linux-rockchip/list/?series=586691 in review].<br />
|-<br />
! scope="row" | Battery<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=630567&archive=both]</sup><br />
| <code>rk817-charger</code><br />
| In the BSP tree this is handled by [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_battery.c rk817_battery.c] and [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_charger.c rk817_charger.c].<br />
| Quartz64 Model A, Pinenote<br />
|-<br />
! scope="row" | Microphone<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-saradc</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7786da3b5ae167c17f35e22ba35e06006338c2f6]</sup>. Headphone jack mic seems to connect to <code>SARADC_VIN2_HP_HOOK</code>, so I'm pretty sure that the dtsi and driver changes are needed for that mic to work<br />
|-<br />
! scope="row" | USB 2.0<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-usb2phy</code><br />
| As of 5.17<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/phy/rockchip?h=v5.17-rc1&id=42b559727a45d79c811f493515eb9b7e56016421]</sup><br />
|-<br />
! scope="row" | e-Ink<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review (RFC)<sup>[https://lore.kernel.org/linux-rockchip/20220413221916.50995-1-samuel@sholland.org/T/]</sup><br />
| <code>rockchip-ebc</code><br />
| A DRM driver is available [https://github.com/smaeul/linux/commits/rk35/ebc-drm-v5 here]; also see [[RK3566 EBC Reverse-Engineering]]<br />
|-<br />
! scope="row" | Combo PHY<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>naneng-combphy</code><br />
| As of 5.18<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7160820d742a16313f7802e33c2956c19548e488]</sup>. Still requires DTS changes<br />
|-<br />
! scope="row" | RGA<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs fixing<br />
| <code>rockchip-rga</code><br />
| [[User:CounterPillow]] experimentally enabled it<sup>[https://gist.github.com/CounterPillow/6bea809f15ada7ddd3a3d7a4994fdc4e]</sup> in the device tree and ran gstreamer's v4l2convert through it to test, resulting in a completely garbled output.<br />
|-<br />
! scope="row" | Fan Controller<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>emc2301</code><br />
| Previous attempts at mainlining: [http://lkml.iu.edu/hypermail/linux/kernel/1306.1/02473.html] and [https://lore.kernel.org/all/20200928104326.40386-1-biwen.li@oss.nxp.com/]. Latest iteration: [https://gitlab.traverse.com.au/ls1088firmware/traverse-sensors/-/commit/1cdec49171ebafcf32b347e7701224144de8620b]<br />
| SOQuartz Blade<br />
|-<br />
! scope="row" | CIF (CSI Camera)<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>video_rkcif</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/media/platform/rockchip/cif]<br />
|<br />
|}<br />
<br />
== Current Status ==<br />
<br />
The following sections give an overview over the current status of different parts of the board. Some parts are waiting on a driver to be written or ported, others only need various adjustments.<br />
<br />
According to pgwipeout, I/O device performance is within expected ranges now.<br />
<br />
=== Working ===<br />
<br />
* eMMC<br />
* SDMMC0 (SD cards)<br />
* GMAC (Gigabit Ethernet)<br />
* USB 2.0<br />
* SATA 2<br />
* SATA 3<br />
* UART<br />
** UART 0 (Pi-bus)<br />
** UART 1 (Bluetooth)<br />
** UART 2 (Pi-bus, debug)<br />
* Video Decode<br />
** VP8<br />
* Battery<br />
* GPU<br />
* Audio<br />
** Analog audio works<br />
** SPDIF works<br />
** HDMI works<br />
* SPI &mdash; works, user needs to modify device tree to add devices<br />
* I<sup>2</sup>C &mdash; works, user needs to modify device tree to add devices<br />
<br />
=== Partially Working ===<br />
<br />
* PCI-Express Controller &mdash; everything but devices that need cache coherency (e.g. dGPUs) should work<br />
** [[User:CounterPillow]] noticed some weirdness with NVMe devices disconnecting during heavy write operations, likely down due to power draw on one of the rails as the same sustained bandwidth could be achieved with a different PCIe device with no issue.<br />
* SDMMC1 (Wi-Fi) &mdash; AP6256 working, BL602 needs some work to make it flash firmware<br />
* [https://developer.arm.com/architectures/system-architectures/system-components/arm-generic-interrupt-controller GIC] &mdash; needs errata published by Rockchip to get upstream to add device-specific workarounds<sup>[https://lore.kernel.org/linux-rockchip/CAMdYzYrQ5f-mv_VmTq_CRf9tR=j3mwRpKHNLmPFgCF9whsGFRw@mail.gmail.com/]</sup><br />
* Video Output &mdash; only at 1920x1080p60 and nothing else, very buggy and rough around more than just the edges<br />
<br />
=== Confirmed Broken ===<br />
<br />
* USB 3.0 &mdash; only works with very short cables and depends on the device. This is due to a hardware design issue relating to the coupling capacitors needed for SATA, which shares the same lines as USB 3.0.<br />
** Hardware design changes have been suggested to engineers, it's in their hands now.<br />
* Module autoloading for the Ethernet PHY. The Motorcomm PHY does not have a vendor ID written into the appropriate hardware block, so there is no canonical way to identify the device.<br />
<br />
=== Needs Testing ===<br />
<br />
* E-Paper &mdash; needs EBC driver<br />
* Microphone Input<br />
* CSI &mdash; needs CIF driver<br />
<br />
== TODO ==<br />
<br />
=== ebc-dev Reverse Engineering and Development ===<br />
<br />
The [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/tree/rk356x-ebc-dev driver for the eInk panel] needs to both be reverse engineered and then rewritten as C. In its current form, it is mostly an assembly dump produced by gcc with debug symbols. See [[RK3566 EBC Reverse-Engineering]] for details.<br />
<br />
=== Investigate MCU ===<br />
<br />
The RK3566 comes with an integrated RISC-V microcontroller (MCU). It communicates with the A55 host through the Mailbox system driven by the rockchip-mailbox driver. Since this MCU would be quite useful for things such as low power standby mode, investigating how it can be turned on and have firmware flashed to it should greatly enhance the power saving features of the PineNote.<br />
<br />
=== Mainline U-Boot Work ===<br />
<br />
Currently, mainline U-Boot does not have support for the RK3566 SoC used on the Quartz64. That's why we currently use the "downstream" Rockchip U-Boot, which is based on an old version of U-Boot and contains vendor specific patches that have not undergone the same level of code review as they'd have done had they been submitted upstream.<br />
<br />
While the lack of ATF sources means that using mainline U-Boot would still require the use of Rockchip provided binaries for the firmware, the mainline U-Boot works needs to be done eventually anyway, and even with Rockchip blobs, a more modern version of U-Boot will be much nicer to use.<br />
<br />
Someone needs to get on the task of investigating what minimally needs to be ported to get the board booting with mainline U-Boot, port those changes, and submit them for review.<br />
<br />
==== Things that need to be done ====<br />
<br />
This list is non-exhaustive as we don't exactly know how much is missing<br />
<br />
* Do the <code>rk3568.dtsi</code> refactoring into <code>rk356x.dtsi</code>/<code>rk3568.dtsi</code>/<code>rk3566.dtsi</code> that the kernel did, probably just port the kernel dtsi files for this<br />
* Bring the kernel's Quartz64 DTS into the tree<br />
* Write a <code>quartz64-rk3566_defconfig</code> based on <code>evb-rk3568_defconfig</code><br />
<br />
Stretch Goals:<br />
<br />
* Port the Naneng Combo PHY driver to u-boot so we can SATA, USB 3 and PCIe boot<br />
* Look into SPI<br />
* Port the Motorcomm PHY driver to u-boot for networking?<br />
* Port a basic VOP2 driver to get a framebuffer from u-boot<br />
<br />
==== List of Useful Resources for this Task ====<br />
* Downstream Rockchip U-Boot repository with Quartz64 specific patches: https://gitlab.com/pgwipeout/u-boot-rockchip/-/tree/quartz64<br />
* Mainline Rockchip custodian U-Boot repository: https://source.denx.de/u-boot/custodians/u-boot-rockchip<br />
* U-Boot Mailing List: https://lists.denx.de/listinfo/u-boot<br />
<br />
== Linux Kernel Config Options ==<br />
<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_I2S_TDM</code><br />
** for Analog and (in the future) HDMI audio<br />
* <code>CONFIG_SND_SOC_RK817</code><br />
** for Analog audio on the Model A<br />
* <code>CONFIG_STMMAC_ETH</code><br />
** Ethernet<br />
* <code>CONFIG_DWMAC_ROCKCHIP</code><br />
** Ethernet<br />
* <code>CONFIG_MOTORCOMM_PHY</code><br />
** Ethernet, set this one to Y, m won't work out of the box as module autoloading does not work for this specific PHY (the vendor ID is zeroed out), alternatively tell users in board-specific setup instructions to force loading the <code>motorcomm</code> module if you set it to m.<br />
* <code>CONFIG_MMC_DW</code><br />
** MMC/SD<br />
* <code>CONFIG_MMC_DW_ROCKCHIP</code><br />
** MMC/SD<br />
* <code>CONFIG_MMC_SDHCI_OF_DWCMSHC</code><br />
** MMC/SD<br />
* <code>CONFIG_PCIE_ROCKCHIP_DW_HOST</code><br />
** PCIe<br />
* <code>CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY</code><br />
** PHY for PCIe/SATA/USB3, not yet upstream<br />
* <code>CONFIG_DRM_PANFROST</code><br />
** GPU<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_SPDIF</code><br />
** SPDIF audio<br />
* <code>CONFIG_ROCKCHIP_DW_HDMI</code><br />
** HDMI PHY<br />
* <code>CONFIG_ROCKCHIP_VOP2</code><br />
** Video output, not yet upstream<br />
* <code>CONFIG_ARCH_ROCKCHIP</code><br />
** General SoC support<br />
* <code>CONFIG_ROCKCHIP_PHY</code><br />
** General SoC support<br />
* <code>CONFIG_PHY_ROCKCHIP_INNO_USB2</code><br />
** USB 2<br />
* <code>CONFIG_RTC_DRV_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_COMMON_CLK_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_MFD_RK808</code><br />
** Various things relating to the RK817 chip<br />
* <code>CONFIG_REGULATOR_RK808</code><br />
** Voltage regulators<br />
* <code>CONFIG_ROCKCHIP_PM_DOMAINS</code><br />
** Power management domains<br />
* <code>CONFIG_GPIO_ROCKCHIP</code><br />
** GPIO support<br />
* <code>CONFIG_PINCTRL_ROCKCHIP</code><br />
** GPIO and general SoC support<br />
* <code>CONFIG_PWM_ROCKCHIP</code><br />
** PWM support<br />
* <code>CONFIG_ROCKCHIP_IOMMU</code><br />
** IOMMU support<br />
* <code>CONFIG_ROCKCHIP_MBOX</code><br />
** Mailbox support (for communication with MCU)<br />
* <code>CONFIG_ROCKCHIP_SARADC</code><br />
** Analog-to-digital conversion support, for e.g. microphones<br />
* <code>CONFIG_ROCKCHIP_THERMAL</code><br />
** Temperature sensor and thermal throttling support<br />
* <code>CONFIG_SPI_ROCKCHIP</code><br />
** SPI support<br />
* <code>CONFIG_VIDEO_HANTRO_ROCKCHIP</code><br />
** Hardware video decoder support<br />
* <code>CONFIG_ROCKCHIP_IODOMAIN</code><br />
** General SoC support so your I/O pins have the right voltage<br />
* <code>CONFIG_COMMON_CLK_ROCKCHIP</code><br />
** Common clock support<br />
<br />
== Resources ==<br />
=== Repositories ===<br />
<br />
* pgwipeout's kernel tree<br />
** https://gitlab.com/pgwipeout/linux-next/-/tree/quartz64-v5.15-rc1<br />
* BSP based development effort for SPL/U-Boot and Linux<br />
** https://gitlab.com/pine64-org/quartz-bsp<br />
* Image CI pipeline aimed at developers<br />
** https://gitlab.com/pgwipeout/quartz64_ci/<br />
* Rockchip U-Boot<br />
** https://github.com/rockchip-linux/u-boot<br />
* Downstream rockchip-linux kernel tree<br />
** https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux<br />
* Tianocore EDK II port for UEFI on Quartz64<br />
** https://github.com/jaredmcneill/quartz64_uefi<br />
* Mainline U-Boot Port by pgwipeout<br />
** https://gitlab.com/pgwipeout/u-boot-quartz64<br />
<br />
=== Other ===<br />
<br />
* Rockchip-SoC Patchwork Page<br />
** https://patchwork.kernel.org/project/linux-rockchip/list/<br />
* Rockchip Kernel Mailing List Archive<br />
** https://lore.kernel.org/linux-rockchip/<br />
<br />
== Board/SoC Documentation ==<br />
=== Booting ===<br />
==== Boot Order ====<br />
The RK3566 boot ROM will search for a valid ID BLOCK in the following order on the support boot media:<br />
<br />
* SPI NOR flash<br />
* SPI NAND flash<br />
* SD-Card<br />
* eMMC<br />
<br />
... if this fails, the boot ROM will initialize the USB0 port and wait for a connection from the Rockchip<br />
flash/boot tools.<br />
<br />
==== Bootloader Flashing ====<br />
<br />
As per pgwipeout's [https://gitlab.com/pine64-org/quartz-bsp/u-boot/-/commit/12d102b86813378af08b086f3b9c13ed8010754c commit message]:<br />
* Make a partition named <code>uboot</code> as partition number 1 at 8 MiB to 16 MiB<br />
* <code>dd if=idblock.bin of=/dev/''<mmc/sd>'' seek=64</code><br />
* <code>dd if=uboot.img of=/dev/''<mmc/sd>''1</code><br />
<br />
==== BSP Image Layout ====<br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=Quartz64_Development&diff=12712Quartz64 Development2022-04-01T02:54:49Z<p>Smaeul: /* Upstreaming Status */ Update PineNote status</p>
<hr />
<div>This page documents the current status of software support for the [[Quartz64]] single-board computer, and provides links to resources to help prospective contributors get started. Information is kept current on a best-effort basis as various patches get accepted into the kernel.<br />
<br />
== Overview ==<br />
<br />
=== Upstreaming Status ===<br />
<br />
{| class="wikitable plainrowheaders" border="1"<br />
! scope="col" | Function<br />
! scope="col" colspan="2" | Status<br />
! scope="col" | Component<br />
! scope="col" | Notes<br />
! scope="col" | Applies To<br />
|-<br />
! scope="row" rowspan="2" | Video Output<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=626925]</sup><br />
| <code>rockchipdrm/VOP2</code><br />
|<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>rockchip-edpphy-naneng</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/phy/rockchip/phy-rockchip-naneng-edp.c] Coordinate any porting with Rockchip first<br />
|-<br />
! scope="row" | 3D Acceleration <br />
| style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=612521]</sup><br />
| style="background:PaleGreen; text-align:center;"|Upstream Mesa<br />
| <code>panfrost</code><br />
| GPU is basically already supported in mainline but needs some device tree changes for this particular SoC<br />
|-<br />
! scope="row" | Video Decode <br />
| style="background:LightYellow; text-align:center;"|Linux Staging<br />
| style="background:#F99; text-align:center;"|Not in ffmpeg<sup>[https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898]</sup><br />
| <code>hantro-vpu</code> and <code>rkvdec</code>, using <code>v4l2-requests</code><br />
| Necessary device tree changes for the Hantro VPU [https://patchwork.kernel.org/project/linux-rockchip/patch/20210719225806.26680-1-ezequiel@collabora.com/ in review]. rkvdec hardware has been updated compared to rk3399 and may require driver changes.<br />
|-<br />
! scope="row" rowspan="3" | Audio <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-i2s-tdm</code><br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43b058698f723e3c2087af7069c0da082a3ecbe1]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-spdif</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dac825b6a6bdca41347e25f07354ad94fdc97445]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk817-codec</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d6a04da9b25b9a7cf2cac5f5079e3296d3bee0f]</sup>.<br />
| Quartz64 Model A/B<br />
|-<br />
! scope="row" | u-boot<br />
| colspan="2" style="background:#F99; text-align:center;"|Waiting on ATF sources<br />
|<br />
|<br />
|-<br />
! scope="row" rowspan="4" | Device Tree<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| Quartz64 Model A<br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b33a22a1e7c4248608e533fc4fa524258b3fae84]</sup><br />
| Quartz64 Model A<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| Quartz64 Model B<br />
|<br />
| Quartz64 Model B<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| SOQuartz<br />
|<br />
| SOQuartz<br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| PineNote<br />
| As of 5.18<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d449121e5e8addcee654250cec298c887ecafb32]</sup><br />
| PineNote<br />
|-<br />
! scope="row" rowspan="2"| Gigabit Ethernet<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3566-gmac</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb3d6b1c1957e88bfc5e77a4557f7e6ba761fe3]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>yt8511-phy</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48e8c6f1612b3d2dccaea2285231def830cc5b8e]</sup><br />
|-<br />
! scope="row" | IOMMU<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-iommu</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c55356c534aa651ccc3053ef2d5d8d810adacf5f]</sup><br />
|-<br />
! scope="row" | GPIO<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>gpio-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936ee2675eee1faca0dcdfa79165c7990422e0fc]</sup><br />
|-<br />
! scope="row" | pinctrl<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
|<br />
|<br />
|-<br />
! scope="row" | Thermal Regulation<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-thermal</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4b14c055a6f644cbeb1156ba24647e92fe51ec69]</sup><br />
|-<br />
! scope="row" | PCIe<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>pcie-dw-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e898eb8df4e34c7b129452444eb7cef68a11f43]</sup><br />
|-<br />
! scope="row" | Power Management<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-pm-domains</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1782c87b44a0b1a527f01a6a184677c58ccbf9c7]</sup><br />
|-<br />
! scope="row" | Voltage Control<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3568-pmu-io-voltage-domain</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28b05a64e47cbceebb8a5f3f643033148d5c06c3]</sup><br />
|-<br />
! scope="row" | SPI <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>spi-rockchip</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d74d99229f4d48f42d674f7a8a1137179efd67ac]</sup>. Necessary device tree changes [https://patchwork.kernel.org/project/linux-rockchip/list/?series=586691 in review].<br />
|-<br />
! scope="row" | Battery<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=536233&archive=both]</sup><br />
| <code>rk817-charger</code><br />
| In the BSP tree this is handled by [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_battery.c rk817_battery.c] and [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_charger.c rk817_charger.c].<br />
| Quartz64 Model A, Pinenote<br />
|-<br />
! scope="row" | Microphone<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-saradc</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7786da3b5ae167c17f35e22ba35e06006338c2f6]</sup>. Headphone jack mic seems to connect to <code>SARADC_VIN2_HP_HOOK</code>, so I'm pretty sure that the dtsi and driver changes are needed for that mic to work<br />
|-<br />
! scope="row" | USB 2.0<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-usb2phy</code><br />
| As of 5.17<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/phy/rockchip?h=v5.17-rc1&id=42b559727a45d79c811f493515eb9b7e56016421]</sup><br />
|-<br />
! scope="row" | e-Ink<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| <code>rockchip-ebc</code><br />
| A DRM driver is available [https://github.com/smaeul/linux/commits/rk35/ebc-drm-v5 here]; also see [[RK3566 EBC Reverse-Engineering]]<br />
|-<br />
! scope="row" | Combo PHY<br />
| colspan="2" style="background:LightYellow; text-align:center;"|Linux-Next<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/phy/rockchip?h=next-20220310&id=7160820d742a16313f7802e33c2956c19548e488]</sup><br />
| <code>naneng-combphy</code><br />
| Still requires DTS changes<br />
|-<br />
! scope="row" | RGA<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs fixing<br />
| <code>rockchip-rga</code><br />
| [[User:CounterPillow]] experimentally enabled it<sup>[https://gist.github.com/CounterPillow/6bea809f15ada7ddd3a3d7a4994fdc4e]</sup> in the device tree and ran gstreamer's v4l2convert through it to test, resulting in a completely garbled output.<br />
|-<br />
! scope="row" | Fan Controller<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>emc2301</code><br />
| Previous attempts at mainlining: [http://lkml.iu.edu/hypermail/linux/kernel/1306.1/02473.html] and [https://lore.kernel.org/all/20200928104326.40386-1-biwen.li@oss.nxp.com/]. Latest iteration: [https://gitlab.traverse.com.au/ls1088firmware/traverse-sensors/-/commit/1cdec49171ebafcf32b347e7701224144de8620b]<br />
| SOQuartz Blade<br />
|-<br />
! scope="row" | CIF (CSI Camera)<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>video_rkcif</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/media/platform/rockchip/cif]<br />
|<br />
|}<br />
<br />
== Current Status ==<br />
<br />
The following sections give an overview over the current status of different parts of the board. Some parts are waiting on a driver to be written or ported, others only need various adjustments.<br />
<br />
According to pgwipeout, I/O device performance is within expected ranges now.<br />
<br />
=== Working ===<br />
<br />
* eMMC<br />
* SDMMC0 (SD cards)<br />
* GMAC (Gigabit Ethernet)<br />
* USB 2.0<br />
* SATA 2<br />
* SATA 3<br />
* UART<br />
** UART 0 (Pi-bus)<br />
** UART 1 (Bluetooth)<br />
** UART 2 (Pi-bus, debug)<br />
* Video Decode<br />
** VP8<br />
* Battery<br />
* GPU<br />
* Audio<br />
** Analog audio works<br />
** SPDIF works<br />
** HDMI works<br />
* SPI &mdash; works, user needs to modify device tree to add devices<br />
* I<sup>2</sup>C &mdash; works, user needs to modify device tree to add devices<br />
<br />
=== Partially Working ===<br />
<br />
* PCI-Express Controller &mdash; everything but devices that need cache coherency (e.g. dGPUs) should work<br />
** [[User:CounterPillow]] noticed some weirdness with NVMe devices disconnecting during heavy write operations, likely down due to power draw on one of the rails as the same sustained bandwidth could be achieved with a different PCIe device with no issue.<br />
* SDMMC1 (Wi-Fi) &mdash; AP6256 working, BL602 needs some work to make it flash firmware<br />
* [https://developer.arm.com/architectures/system-architectures/system-components/arm-generic-interrupt-controller GIC] &mdash; needs errata published by Rockchip to get upstream to add device-specific workarounds<sup>[https://lore.kernel.org/linux-rockchip/CAMdYzYrQ5f-mv_VmTq_CRf9tR=j3mwRpKHNLmPFgCF9whsGFRw@mail.gmail.com/]</sup><br />
* Video Output &mdash; only at 1920x1080p60 and nothing else, very buggy and rough around more than just the edges<br />
<br />
=== Confirmed Broken ===<br />
<br />
* USB 3.0 &mdash; only works with very short cables and depends on the device. This is due to a hardware design issue relating to the coupling capacitors needed for SATA, which shares the same lines as USB 3.0.<br />
** Hardware design changes have been suggested to engineers, it's in their hands now.<br />
* Module autoloading for the Ethernet PHY. The Motorcomm PHY does not have a vendor ID written into the appropriate hardware block, so there is no canonical way to identify the device.<br />
<br />
=== Needs Testing ===<br />
<br />
* E-Paper &mdash; needs EBC driver<br />
* Microphone Input<br />
* CSI &mdash; needs CIF driver<br />
<br />
== TODO ==<br />
<br />
=== ebc-dev Reverse Engineering and Development ===<br />
<br />
The [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/tree/rk356x-ebc-dev driver for the eInk panel] needs to both be reverse engineered and then rewritten as C. In its current form, it is mostly an assembly dump produced by gcc with debug symbols. See [[RK3566 EBC Reverse-Engineering]] for details.<br />
<br />
=== Investigate MCU ===<br />
<br />
The RK3566 comes with an integrated RISC-V microcontroller (MCU). It communicates with the A55 host through the Mailbox system driven by the rockchip-mailbox driver. Since this MCU would be quite useful for things such as low power standby mode, investigating how it can be turned on and have firmware flashed to it should greatly enhance the power saving features of the PineNote.<br />
<br />
=== Mainline U-Boot Work ===<br />
<br />
Currently, mainline U-Boot does not have support for the RK3566 SoC used on the Quartz64. That's why we currently use the "downstream" Rockchip U-Boot, which is based on an old version of U-Boot and contains vendor specific patches that have not undergone the same level of code review as they'd have done had they been submitted upstream.<br />
<br />
While the lack of ATF sources means that using mainline U-Boot would still require the use of Rockchip provided binaries for the firmware, the mainline U-Boot works needs to be done eventually anyway, and even with Rockchip blobs, a more modern version of U-Boot will be much nicer to use.<br />
<br />
Someone needs to get on the task of investigating what minimally needs to be ported to get the board booting with mainline U-Boot, port those changes, and submit them for review.<br />
<br />
==== Things that need to be done ====<br />
<br />
This list is non-exhaustive as we don't exactly know how much is missing<br />
<br />
* Do the <code>rk3568.dtsi</code> refactoring into <code>rk356x.dtsi</code>/<code>rk3568.dtsi</code>/<code>rk3566.dtsi</code> that the kernel did, probably just port the kernel dtsi files for this<br />
* Bring the kernel's Quartz64 DTS into the tree<br />
* Write a <code>quartz64-rk3566_defconfig</code> based on <code>evb-rk3568_defconfig</code><br />
<br />
Stretch Goals:<br />
<br />
* Port the Naneng Combo PHY driver to u-boot so we can SATA, USB 3 and PCIe boot<br />
* Look into SPI<br />
* Port the Motorcomm PHY driver to u-boot for networking?<br />
* Port a basic VOP2 driver to get a framebuffer from u-boot<br />
<br />
==== List of Useful Resources for this Task ====<br />
* Downstream Rockchip U-Boot repository with Quartz64 specific patches: https://gitlab.com/pgwipeout/u-boot-rockchip/-/tree/quartz64<br />
* Mainline Rockchip custodian U-Boot repository: https://source.denx.de/u-boot/custodians/u-boot-rockchip<br />
* U-Boot Mailing List: https://lists.denx.de/listinfo/u-boot<br />
<br />
== Linux Kernel Config Options ==<br />
<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_I2S_TDM</code><br />
** for Analog and (in the future) HDMI audio<br />
* <code>CONFIG_SND_SOC_RK817</code><br />
** for Analog audio on the Model A<br />
* <code>CONFIG_STMMAC_ETH</code><br />
** Ethernet<br />
* <code>CONFIG_DWMAC_ROCKCHIP</code><br />
** Ethernet<br />
* <code>CONFIG_MOTORCOMM_PHY</code><br />
** Ethernet, set this one to Y, m won't work out of the box as module autoloading does not work for this specific PHY (the vendor ID is zeroed out), alternatively tell users in board-specific setup instructions to force loading the <code>motorcomm</code> module if you set it to m.<br />
* <code>CONFIG_MMC_DW</code><br />
** MMC/SD<br />
* <code>CONFIG_MMC_DW_ROCKCHIP</code><br />
** MMC/SD<br />
* <code>CONFIG_PCIE_ROCKCHIP_DW_HOST</code><br />
** PCIe<br />
* <code>CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY</code><br />
** PHY for PCIe/SATA/USB3, not yet upstream<br />
* <code>CONFIG_DRM_PANFROST</code><br />
** GPU<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_SPDIF</code><br />
** SPDIF audio<br />
* <code>CONFIG_ROCKCHIP_DW_HDMI</code><br />
** HDMI PHY<br />
* <code>CONFIG_ROCKCHIP_VOP2</code><br />
** Video output, not yet upstream<br />
* <code>CONFIG_ARCH_ROCKCHIP</code><br />
** General SoC support<br />
* <code>CONFIG_ROCKCHIP_PHY</code><br />
** General SoC support<br />
* <code>CONFIG_PHY_ROCKCHIP_INNO_USB2</code><br />
** USB 2<br />
* <code>CONFIG_RTC_DRV_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_COMMON_CLK_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_MFD_RK808</code><br />
** Various things relating to the RK817 chip<br />
* <code>CONFIG_REGULATOR_RK808</code><br />
** Voltage regulators<br />
* <code>CONFIG_ROCKCHIP_PM_DOMAINS</code><br />
** Power management domains<br />
* <code>CONFIG_GPIO_ROCKCHIP</code><br />
** GPIO support<br />
* <code>CONFIG_PINCTRL_ROCKCHIP</code><br />
** GPIO and general SoC support<br />
* <code>CONFIG_PWM_ROCKCHIP</code><br />
** PWM support<br />
* <code>CONFIG_ROCKCHIP_IOMMU</code><br />
** IOMMU support<br />
* <code>CONFIG_ROCKCHIP_MBOX</code><br />
** Mailbox support (for communication with MCU)<br />
* <code>CONFIG_ROCKCHIP_SARADC</code><br />
** Analog-to-digital conversion support, for e.g. microphones<br />
* <code>CONFIG_ROCKCHIP_THERMAL</code><br />
** Temperature sensor and thermal throttling support<br />
* <code>CONFIG_SPI_ROCKCHIP</code><br />
** SPI support<br />
* <code>CONFIG_VIDEO_HANTRO_ROCKCHIP</code><br />
** Hardware video decoder support<br />
* <code>CONFIG_ROCKCHIP_IODOMAIN</code><br />
** General SoC support so your I/O pins have the right voltage<br />
* <code>CONFIG_COMMON_CLK_ROCKCHIP</code><br />
** Common clock support<br />
<br />
== Resources ==<br />
=== Repositories ===<br />
<br />
* pgwipeout's kernel tree<br />
** https://gitlab.com/pgwipeout/linux-next/-/tree/quartz64-v5.15-rc1<br />
* BSP based development effort for SPL/U-Boot and Linux<br />
** https://gitlab.com/pine64-org/quartz-bsp<br />
* Image CI pipeline aimed at developers<br />
** https://gitlab.com/pgwipeout/quartz64_ci/<br />
* Rockchip U-Boot<br />
** https://github.com/rockchip-linux/u-boot<br />
* Downstream rockchip-linux kernel tree<br />
** https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux<br />
* Tianocore EDK II port for UEFI on Quartz64<br />
** https://github.com/jaredmcneill/quartz64_uefi<br />
* Mainline U-Boot Port by pgwipeout<br />
** https://gitlab.com/pgwipeout/u-boot-quartz64<br />
<br />
=== Other ===<br />
<br />
* Rockchip-SoC Patchwork Page<br />
** https://patchwork.kernel.org/project/linux-rockchip/list/<br />
* Rockchip Kernel Mailing List Archive<br />
** https://lore.kernel.org/linux-rockchip/<br />
<br />
== Board/SoC Documentation ==<br />
=== Booting ===<br />
==== Boot Order ====<br />
The RK3566 boot ROM will search for a valid ID BLOCK in the following order on the support boot media:<br />
<br />
* SPI NOR flash<br />
* SPI NAND flash<br />
* SD-Card<br />
* eMMC<br />
<br />
... if this fails, the boot ROM will initialize the USB0 port and wait for a connection from the Rockchip<br />
flash/boot tools.<br />
<br />
==== Bootloader Flashing ====<br />
<br />
As per pgwipeout's [https://gitlab.com/pine64-org/quartz-bsp/u-boot/-/commit/12d102b86813378af08b086f3b9c13ed8010754c commit message]:<br />
* Make a partition named <code>uboot</code> as partition number 1 at 8 MiB to 16 MiB<br />
* <code>dd if=idblock.bin of=/dev/''<mmc/sd>'' seek=64</code><br />
* <code>dd if=uboot.img of=/dev/''<mmc/sd>''1</code><br />
<br />
==== BSP Image Layout ====<br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=PineNote&diff=12683PineNote2022-03-20T17:33:17Z<p>Smaeul: /* Datasheets for Components and Peripherals */ Fix typo</p>
<hr />
<div>[[File:PineNote-1.jpg|400px|thumb|right|The PineNote]]<br />
<br />
The PineNote is the first hybrid notepad computer device combination of notebook, tablet and e-reader using an e-ink panel. It is derived from the Quartz64 model A SBC and powered by a Rockchip RK3566 quad-core ARM Cortex A55 64-bit processor with a MALI G-52 GPU.<br />
<br />
== Introduction ==<br />
<br />
=== State of the software ===<br />
<br />
The PineNote is based on the in 2021 released Rockchip RK3566 SoC. The upstreaming status of the SoC functionality can be found on the [[Quartz64 Development#Upstreaming Status|Quartz64 development]] wiki page of the Quartz64 single-board computer using the same SoC. <br />
<br />
The early adopter's batch of the PineNote is aimed solely at early adopters - more specifically, the units are solely intended to find their way into the hands of users with extensive Linux experience. If you’re looking to buy a PineNote in the first batch, you must expect to write software for it, not to write notes on it. The software shipping from the factory for the first batch will not be suitable for taking notes, reading e-books, or writing your dissertation. It may not even boot to a graphical environment.<br />
<br />
=== Help and support ===<br />
<br />
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]]. <br />
<br />
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.<br />
<br />
== Specification ==<br />
[[File:PineNote_Pen_function.jpg|300px|right]]<br />
[[File:PineNote_Cover-1.jpg|300px|right]]<br />
<br />
=== General Information ===<br />
* Dimensions: 191.1x232.5x7.4mm<br />
* Weight: 438g<br />
<br />
=== Core ===<br />
* CPU: RK3566 1.8GHz 64-bit quad-core A55<br />
* GPU: MALI G52 2EE<br />
* System memory: 4GB LPDDR4<br />
* Flash: 128GB eMMC<br />
<br />
=== E-ink Display ===<br />
* Size: 10.3"<br />
* Resolution: 1404x1872<br />
* DPI: 227<br />
* Grayscale: 16<br />
* Front Light: 36 level cold and warm <br />
* Capacitive multi-touch panel<br />
* EMR pen digitizer<br />
<br />
=== Network ===<br />
* WiFi: 2.4/5GHz 802.11a/b/g/n/ac<br />
* Bluetooth: 5.0<br />
<br />
=== Audio ===<br />
* Built in stereo speakers<br />
* 4 x DMIC microphone<br />
<br />
=== Sensor ===<br />
* G-Sensor for portrait and landscape sensing<br />
<br />
=== Power ===<br />
* 4000mAH LiPo battery<br />
* DC 5V @ 3A USB-C connector<br />
<br />
=== Accessories ===<br />
* Optional EMR pen with magnetic attachment (included in the first production batch)<br />
* Optional Cover (included in the first production batch)<br />
<br />
== Software releases ==<br />
* Not yet available<br />
<br />
== SoC and Memory Specifications ==<br />
* Based on [https://www.rock-chips.com/a/en/products/RK35_Series/2021/0113/1274.html Rockchip RK3566]<br />
[[File:RK3566_icon.png|right]]<br />
<br />
=== CPU Architecture ===<br />
* [https://developer.arm.com/ip-products/processors/cortex-a/cortex-a55 Quad-core ARM Cortex-A55@1.8GHz]<br />
* AArch32 for full backwards compatibility with ARMv7<br />
* ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation<br />
* Includes VFP hardware to support single and double-precision operations<br />
* ARMv8 Cryptography Extensions<br />
* Integrated 32KB L1 instruction cache and 32KB L1 data cache per core<br />
* 512KB unified system L3 cache<br />
* [https://developer.arm.com/ip-products/security-ip/trustzone TrustZone] technology support<br />
* [https://www.cnx-software.com/2020/12/01/rockchip-rk3568-processor-to-power-edge-computing-and-nvr-applications 22nm process, believed to be FD-SOI]<br />
<br />
=== GPU (Graphics Processing Unit) Capabilities ===<br />
* [https://developer.arm.com/ip-products/graphics-and-multimedia/mali-gpus/mali-g52-gpu Mali-G52 2EE Bifrost GPU@800MHz]<br />
* 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop <br />
* 128KB L2 Cache configurations<br />
* Supports OpenGL ES 1.1, 2.0, and 3.2<br />
* Supports Vulkan 1.0 and 1.1<br />
* Supports OpenCL 2.0 Full Profile<br />
* Supports 1600 Mpix/s fill rate when at 800MHz clock frequency<br />
* Supports 38.4 GLOP/s when at 800MHz clock frequency <br />
<br />
=== NPU (Neural Processing Unit) Capabilities ===<br />
* Neural network acceleration engine with processing performance of up to 0.8 TOPS<br />
* Supports integer 8 and integer 16 convolution operations<br />
* Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet<br />
<br />
=== System Memory ===<br />
* RAM Memory : 4GB LPDDR4.<br />
* Flash Memory: 128GB eMMC<br />
<br />
== PineNote Information, Schematics, and Certifications ==<br />
* PineNote Developer kit version<br />
* The early release schematic just for reference only and used by developers who received the prototype. <br />
** [https://files.pine64.org/doc/PineNote/PINENOTE_MAIN-V1R2%20-%20Schematic-20210824.pdf PineNote Mainboard Schematic ver 1.2 20210824 PDF file]<br />
** [https://files.pine64.org/doc/PineNote/PINENOTE_USB-C-Board-V1.0-sch.pdf PineNote USB-C Daughter Board Schematic ver 1.0 PDF file]<br />
** [https://files.pine64.org/doc/PineNote/PineNote_USB-C_Console_UART_breakout_board_schematic_v1.0_20210903.pdf PineNote USB-C Console UART Breakout Board Schematic ver 1.0 PDF file]<br />
* The early release schematic just for reference only and used by developers who received the prototype. <br />
** [https://files.pine64.org/doc/PineNote/PINENOTE_MAIN-V1R1%20-%20Schematic-20210726.pdf PineNote early released Schematic ver 1.1 20210726 PDF file]<br />
** [https://files.pine64.org/doc/PineNote/PINENOTE_MAIN-V1R1-REF-TOP-20210726.pdf PineNote early released ver 1.1 20210726 PCB Connector placement PDF file]<br />
<br />
* Certifications:<br />
** [https://files.pine64.org/doc/cert/PineNote%20FCC15C%20Certificate%20DTS-TC561262.pdf PineNote FCC-15C Certificate]<br />
** [https://files.pine64.org/doc/cert/PineNote%20FCC15E%20Certificate%20NII-TC973072.pdf PineNote FCC-15E Certificate]<br />
** [https://files.pine64.org/doc/cert/PineNote%20CE%20RED%20Certicate%20ET-21090682EC.pdf PineNote CE RED Certificate]<br />
** [https://files.pine64.org/doc/cert/PineNote%20RoHS%20Certificate%20ET-210900082C.pdf PineNote ROHS Certificate]<br />
<br />
== Datasheets for Components and Peripherals ==<br />
* Rockchip RK3566 SoC information:<br />
** [https://files.pine64.org/doc/quartz64/Rockchip%20RK3566%20Datasheet%20V1.0-20201210.pdf Rockchip RK3566 ver 1.0 datasheet, already got release permission from Rockchip]<br />
* Rockchip RK817 PMU (Power Management Unit) Information:<br />
** [https://www.rockchip.fr/RK817%20datasheet%20V1.01.pdf Rockchip RK817 ver 1.01 datasheet]<br />
* LPDDR4 (200 Balls) SDRAM:<br />
** ---<br />
* eMMC information:<br />
** [https://en.biwin.com.cn/product/detail/6 Biwin 128GB eMMC model: BWCTASC41P128G] <br />
* E-ink Panel information:<br />
** [https://files.pine64.org/doc/quartz64/Eink%20P-511-828-V1_ED103TC2%20Formal%20Spec%20V1.0_20190514.pdf E-Ink 10.3" 1872x1404 ED103TC2 Glass Panel Specification]<br />
** [https://files.pine64.org/doc/datasheet/PineNote/TI%20PMU-TPS651851.pdf TPS65185x PMIC for E-Ink Enabled Electronic Paper Display Datasheet]<br />
* Touch Screen information:<br />
** [https://files.pine64.org/doc/datasheet/PineNote/CYTMA448_Summary_RevC_5-26-16.pdf Cypress CYTMA448 multi-Point Capacitive Touch Controller Datasheet]<br />
** Wacom Pen Digitizer Unit Model: SUDE-10S15MI-01X for 10.3" Display Module<br />
* WiFi/BT module info:<br />
** [https://files.pine64.org/doc/datasheet/rockpro64/AW-CM256SM_DS_DF_V1.9_STD.pdf Azurewave CM256SM 11AC WiFi + Bluetooth5.0 Datasheet]]<br />
* G Sensor info:<br />
** [http://www.silan.com.cn/en/product/details/47.html#app01 Silan SC7A20 3-Axis MEMS Accelerometer]<br />
* Audio Amplifier information:<br />
** [https://files.pine64.org/doc/datasheet/PineNote/Awinic%20AW87318%20Class-K%20Audio%20Amp%20Datasheet.pdf Awinic AW87318 Class-K Audio Amp Datasheet]<br />
<br />
== Development Efforts ==<br />
<br />
* [[PineNote Development]] for general information regarding how to flash the device and other development information.<br />
<br />
=== Software ===<br />
<br />
* [[Quartz64 Development]] for the mainlining status of various functions on the Rockchip RK3566 SoC.<br />
* [[RK3566 EBC Reverse-Engineering]] for the EBC (eInk Panel) driver.<br />
<br />
=== Hardware ===<br />
<br />
This section includes discussions and their results regarding hardware changes to the PineNote.<br />
<br />
The following topics have resolved:<br />
<br />
* [[PineNote/Hardware_Changes/Closed_Case_UART]]<br />
* '''Could the USB-C port support USB 3.1 5Gbps?''' Yes and no. The RK3566 only has a host-mode 5Gbps controller, meaning it can only negotiate such a high data rate with a device such as a flash drive. When the RK3566 is acting as a device, it only supports 480Mbps transfer rates. The hardware required to switch between these modes would raise the PineNote's price unreasonably. Therefore, the USB-C port will remain at USB 2.0 speeds for Host and Device mode.<br />
* '''Could the USB-C port output DisplayPort?''' Yes and no. The hardware required to support such a feature would raise the PineNote's price unreasonably. Therefore, DisplayPort output will not be possible through the USB-C port.<br />
* '''Where is the microSD card slot?''' The case design of the PineNote is fixed, making physical changes like adding a microSD card slot would raise the cost unreasonably.<br />
* '''How will I install software to the PineNote?''' This is a hardware and software question. If the software on your PineNote is completely broken and cannot boot to a recoverable state, a Hall (magnet) sensor was fitted to the PineTab motherboard as U9009. This sensor is attached to SARADC_VIN0_KEY/RECOVERY on the RK3566. With the device powered off, and screen face down, holding a magnet over U9009 and plugging in a USB-C cable causes the device to boot into [http://opensource.rock-chips.com/wiki_Rockusb|"rockusb"] flash mode. With proper flashing software and drivers, it should be possible to load a new operating system using rockusb if the system is soft-bricked. Of course, software vendors will need to be more careful with flashing firmware and providing useful "recovery" options on this device due to this process's relative difficulty to other PINE64 devices.<br />
<br />
==== Unresolved ====<br />
<br />
The following concerns have been brought up as open, unanswered topics:<br />
<br />
* Does [https://en.wikipedia.org/wiki/USB-C#Audio_Adapter_Accessory_Mode_2|USB-C Audio Adapter Accessory Mode] work? It appears that the Headphone output of the audio codec was routed to the USB-C audio+USB switch, but it's unclear whether CC lines are hooked up correctly for detection of such a device. The PineNote hardware team will be testing this functionality soon (as of August 19, 2021). Note that Audio Accessory mode is detectable by reading the I2C registers of the WUSB3801Q. So connecting ASEL to a GPIO would be enough to get this working if it is not working already.<br />
* Why is the Headphone output of the audio codec routed to the speakers? HPL_OUT is routed from the RK817 PMIC and audio codec to U9010 (the USB-C switch) and U6 (the audio amplifier). SPK_OUT is unused. It seems like SPK_OUT should be routed to U6 and HPL_OUT to U9010.<br />
* Nitpick: The cold white charging LED bleeds through the gap between the rear case and the device's face. It does not bleed onto the screen, but it is jarring in low-light conditions or when the screen is amber. Could be resolved in software by turning off the charge LED when the screen is on.<br />
* Is there any way to indicate when the device is in rockusb mode, such as connecting a certain magic pin to the power LED?<br />
* The modem/4G connector (J6010) has its I2C and UART pins unconnected. Could those be connected to the SoC?<br />
<br />
==== USB-C Debug Accesory Mode (DAM)/UART Dongle====<br />
The USB UART dongle delivered with the PineNote allows you to have access to a serial port without having to open up the device. The factory firmware runs at a baud rate of 1500000bps, 8 data bits 1 stop bit, no parity and no flow control. The USB-C male end should go into the PineNote and the female end can be connected with a standard USB-C cable to your computer.<br />
<br />
== BSP Linux SDK ==<br />
<br />
=== BSP Linux SDK ver 4.19 for PineNote and Quart64 model A SBC ===<br />
* [http://files.pine64.org/SDK/Quartz64/QUARTZ64-model-A_BSP%20Linux.tar.gz Direct Download from pine64.org]<br />
** [https://tmp.mwfc.info/pinenote/QUARTZ64-model-A_BSP%20Linux.tar.gz mirror by mwfc]<br />
** MD5 (TAR-GZip file): 24554419aec29700add97167a3a4c9ed<br />
** File Size: 32.67.00GB<br />
<br />
== Android SDK ==<br />
<br />
=== Android 11 eink SDK for PineNote and Quart64 model A SBC ===<br />
* This is the Android SDK build for 10.3" eink panel on Quartz64 model A SBC. <br />
* [http://files.pine64.org/SDK/Quartz64/QUARTZ64-model-A_eink.android11_SDK.tar.gz Direct Download from pine64.org]<br />
** [https://tmp.mwfc.info/pinenote/QUARTZ64-model-A_eink.android11_SDK.tar.gz mirror by mwfc]<br />
** MD5 (TAR-GZip file): 293a550584298de4fb95ceae18103672<br />
** File Size: 72.88GB<br />
** Just the boot blobs (<1MB): [[File:Rk35-blobs.tar.gz]]<br />
* View [[Android SDK for RK3566]] for more information how to compile an image for the PineNote using this SDK<br />
<br />
== Torrent ==<br />
There is a [https://cdn.discordapp.com/attachments/870707390998282292/907726420204208148/pinenote.torrent torrent] with the files (100GB)<br />
<br />
== Hardware troubleshooting guide ==<br />
At present, nothing is available.<br />
<br />
[[Category:PineNote]] [[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=Quartz64_Development&diff=12505Quartz64 Development2022-02-12T17:39:14Z<p>Smaeul: /* Upstreaming Status */ Update PineNote upstreaming status</p>
<hr />
<div>This page documents the current status of software support for the [[Quartz64]] single-board computer, and provides links to resources to help prospective contributors get started. Information is kept current on a best-effort basis as various patches get accepted into the kernel.<br />
<br />
== Overview ==<br />
<br />
=== Upstreaming Status ===<br />
<br />
{| class="wikitable plainrowheaders" border="1"<br />
! scope="col" | Function<br />
! scope="col" colspan="2" | Status<br />
! scope="col" | Component<br />
! scope="col" | Notes<br />
! scope="col" | Applies To<br />
|-<br />
! scope="row" rowspan="2" | Video Output<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=608673]</sup><br />
| <code>rockchipdrm/VOP2</code><br />
|<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>rockchip-edpphy-naneng</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/phy/rockchip/phy-rockchip-naneng-edp.c] Coordinate any porting with Rockchip first<br />
|-<br />
! scope="row" | 3D Acceleration <br />
| style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=612521]</sup><br />
| style="background:PaleGreen; text-align:center;"|Upstream Mesa<br />
| <code>panfrost</code><br />
| GPU is basically already supported in mainline but needs some device tree changes for this particular SoC<br />
|-<br />
! scope="row" | Video Decode <br />
| style="background:LightYellow; text-align:center;"|Linux Staging<br />
| style="background:#F99; text-align:center;"|Not in ffmpeg<sup>[https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898]</sup><br />
| <code>hantro-vpu</code>, using <code>v4l2-requests</code><br />
| Necessary device tree changes [https://patchwork.kernel.org/project/linux-rockchip/patch/20210719225806.26680-1-ezequiel@collabora.com/ in review]<br />
|-<br />
! scope="row" rowspan="3" | Audio <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-i2s-tdm</code><br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43b058698f723e3c2087af7069c0da082a3ecbe1]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-spdif</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dac825b6a6bdca41347e25f07354ad94fdc97445]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk817-codec</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d6a04da9b25b9a7cf2cac5f5079e3296d3bee0f]</sup>.<br />
| Quartz64 Model A/B<br />
|-<br />
! scope="row" | u-boot<br />
| colspan="2" style="background:#F99; text-align:center;"|Waiting on ATF sources<br />
|<br />
|<br />
|-<br />
! scope="row" rowspan="4" | Device Tree<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| Quartz64 Model A<br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b33a22a1e7c4248608e533fc4fa524258b3fae84]</sup><br />
| Quartz64 Model A<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| Quartz64 Model B<br />
|<br />
| Quartz64 Model B<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| SOQuartz<br />
|<br />
| SOQuartz<br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Rockchip Tree<br />
| PineNote<br />
| Will be in Mainline in 5.18<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=d449121e5e8addcee654250cec298c887ecafb32]</sup><br />
|-<br />
! scope="row" rowspan="2"| Gigabit Ethernet<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3566-gmac</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb3d6b1c1957e88bfc5e77a4557f7e6ba761fe3]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>yt8511-phy</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48e8c6f1612b3d2dccaea2285231def830cc5b8e]</sup><br />
|-<br />
! scope="row" | IOMMU<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-iommu</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c55356c534aa651ccc3053ef2d5d8d810adacf5f]</sup><br />
|-<br />
! scope="row" | GPIO<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>gpio-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936ee2675eee1faca0dcdfa79165c7990422e0fc]</sup><br />
|-<br />
! scope="row" | pinctrl<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
|<br />
|<br />
|-<br />
! scope="row" | Thermal Regulation<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-thermal</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4b14c055a6f644cbeb1156ba24647e92fe51ec69]</sup><br />
|-<br />
! scope="row" | PCIe<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>pcie-dw-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e898eb8df4e34c7b129452444eb7cef68a11f43]</sup><br />
|-<br />
! scope="row" | Power Management<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-pm-domains</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1782c87b44a0b1a527f01a6a184677c58ccbf9c7]</sup><br />
|-<br />
! scope="row" | Voltage Control<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3568-pmu-io-voltage-domain</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28b05a64e47cbceebb8a5f3f643033148d5c06c3]</sup><br />
|-<br />
! scope="row" | SPI <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>spi-rockchip</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d74d99229f4d48f42d674f7a8a1137179efd67ac]</sup>. Necessary device tree changes [https://patchwork.kernel.org/project/linux-rockchip/list/?series=586691 in review].<br />
|-<br />
! scope="row" | Battery<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=536233]</sup><br />
| <code>rk817-charger</code><br />
| In the BSP tree this is handled by [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_battery.c rk817_battery.c] and [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_charger.c rk817_charger.c].<br />
| Quartz64 Model A<br />
|-<br />
! scope="row" | Microphone<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-saradc</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7786da3b5ae167c17f35e22ba35e06006338c2f6]</sup>. Headphone jack mic seems to connect to <code>SARADC_VIN2_HP_HOOK</code>, so I'm pretty sure that the dtsi and driver changes are needed for that mic to work<br />
|-<br />
! scope="row" | USB 2.0<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-usb2phy</code><br />
| As of 5.17<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/phy/rockchip?h=v5.17-rc1&id=42b559727a45d79c811f493515eb9b7e56016421]</sup><br />
|-<br />
! scope="row" | e-Ink<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| <code>rockchip-ebc</code><br />
| A DRM driver is available [https://github.com/smaeul/linux/commits/rk35/ebc here]; also see [[RK3566 EBC Reverse-Engineering]]<br />
|-<br />
! scope="row" | Combo PHY<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=601993]</sup><br />
| <code>naneng-combphy</code><br />
|<br />
|-<br />
! scope="row" | RGA<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs fixing<br />
| <code>rockchip-rga</code><br />
| [[User:CounterPillow]] experimentally enabled it<sup>[https://gist.github.com/CounterPillow/6bea809f15ada7ddd3a3d7a4994fdc4e]</sup> in the device tree and ran gstreamer's v4l2convert through it to test, resulting in a completely garbled output.<br />
|-<br />
! scope="row" | Fan Controller<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>emc2301</code><br />
| Previous attempts at mainlining: [http://lkml.iu.edu/hypermail/linux/kernel/1306.1/02473.html] and [https://lore.kernel.org/all/20200928104326.40386-1-biwen.li@oss.nxp.com/]. Latest iteration: [https://gitlab.traverse.com.au/ls1088firmware/traverse-sensors/-/commit/1cdec49171ebafcf32b347e7701224144de8620b]<br />
| SOQuartz Blade<br />
|-<br />
! scope="row" | CIF (CSI Camera)<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>video_rkcif</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/media/platform/rockchip/cif]<br />
|<br />
|}<br />
<br />
== Current Status ==<br />
<br />
The following sections give an overview over the current status of different parts of the board. Some parts are waiting on a driver to be written or ported, others only need various adjustments.<br />
<br />
According to pgwipeout, I/O device performance is within expected ranges now.<br />
<br />
=== Working ===<br />
<br />
* eMMC<br />
* SDMMC0 (SD cards)<br />
* GMAC (Gigabit Ethernet)<br />
* USB 2.0<br />
* SATA 2<br />
* SATA 3<br />
* UART<br />
** UART 0 (Pi-bus)<br />
** UART 1 (Bluetooth)<br />
** UART 2 (Pi-bus, debug)<br />
* Video Decode<br />
** VP8<br />
* Battery<br />
* GPU<br />
* Audio<br />
** Analog audio works<br />
** SPDIF works<br />
** HDMI works<br />
* SPI &mdash; works, user needs to modify device tree to add devices<br />
* I<sup>2</sup>C &mdash; works, user needs to modify device tree to add devices<br />
<br />
=== Partially Working ===<br />
<br />
* PCI-Express Controller &mdash; everything but devices that need cache coherency (e.g. dGPUs) should work<br />
** [[User:CounterPillow]] noticed some weirdness with NVMe devices disconnecting during heavy write operations, likely down due to power draw on one of the rails as the same sustained bandwidth could be achieved with a different PCIe device with no issue.<br />
* SDMMC1 (Wi-Fi) &mdash; AP6256 working, BL602 needs some work to make it flash firmware<br />
* [https://developer.arm.com/architectures/system-architectures/system-components/arm-generic-interrupt-controller GIC] &mdash; needs errata published by Rockchip to get upstream to add device-specific workarounds<sup>[https://lore.kernel.org/linux-rockchip/CAMdYzYrQ5f-mv_VmTq_CRf9tR=j3mwRpKHNLmPFgCF9whsGFRw@mail.gmail.com/]</sup><br />
* Video Output &mdash; only at 1920x1080p60 and nothing else, very buggy and rough around more than just the edges<br />
<br />
=== Confirmed Broken ===<br />
<br />
* USB 3.0 &mdash; only works with very short cables and depends on the device. This is due to a hardware design issue relating to the coupling capacitors needed for SATA, which shares the same lines as USB 3.0.<br />
** Hardware design changes have been suggested to engineers, it's in their hands now.<br />
* Module autoloading for the Ethernet PHY. The Motorcomm PHY does not have a vendor ID written into the appropriate hardware block, so there is no canonical way to identify the device.<br />
<br />
=== Needs Testing ===<br />
<br />
* E-Paper &mdash; needs EBC driver<br />
* Microphone Input<br />
* CSI &mdash; needs CIF driver<br />
<br />
== TODO ==<br />
<br />
=== ebc-dev Reverse Engineering and Development ===<br />
<br />
The [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/tree/rk356x-ebc-dev driver for the eInk panel] needs to both be reverse engineered and then rewritten as C. In its current form, it is mostly an assembly dump produced by gcc with debug symbols. See [[RK3566 EBC Reverse-Engineering]] for details.<br />
<br />
=== Investigate MCU ===<br />
<br />
The RK3566 comes with an integrated RISC-V microcontroller (MCU). It communicates with the A55 host through the Mailbox system driven by the rockchip-mailbox driver. Since this MCU would be quite useful for things such as low power standby mode, investigating how it can be turned on and have firmware flashed to it should greatly enhance the power saving features of the PineNote.<br />
<br />
=== Mainline U-Boot Work ===<br />
<br />
Currently, mainline U-Boot does not have support for the RK3566 SoC used on the Quartz64. That's why we currently use the "downstream" Rockchip U-Boot, which is based on an old version of U-Boot and contains vendor specific patches that have not undergone the same level of code review as they'd have done had they been submitted upstream.<br />
<br />
While the lack of ATF sources means that using mainline U-Boot would still require the use of Rockchip provided binaries for the firmware, the mainline U-Boot works needs to be done eventually anyway, and even with Rockchip blobs, a more modern version of U-Boot will be much nicer to use.<br />
<br />
Someone needs to get on the task of investigating what minimally needs to be ported to get the board booting with mainline U-Boot, port those changes, and submit them for review.<br />
<br />
==== Things that need to be done ====<br />
<br />
This list is non-exhaustive as we don't exactly know how much is missing<br />
<br />
* Do the <code>rk3568.dtsi</code> refactoring into <code>rk356x.dtsi</code>/<code>rk3568.dtsi</code>/<code>rk3566.dtsi</code> that the kernel did, probably just port the kernel dtsi files for this<br />
* Bring the kernel's Quartz64 DTS into the tree<br />
* Write a <code>quartz64-rk3566_defconfig</code> based on <code>evb-rk3568_defconfig</code><br />
<br />
Stretch Goals:<br />
<br />
* Port the Naneng Combo PHY driver to u-boot so we can SATA, USB 3 and PCIe boot<br />
* Look into SPI<br />
* Port the Motorcomm PHY driver to u-boot for networking?<br />
* Port a basic VOP2 driver to get a framebuffer from u-boot<br />
<br />
==== List of Useful Resources for this Task ====<br />
* Downstream Rockchip U-Boot repository with Quartz64 specific patches: https://gitlab.com/pgwipeout/u-boot-rockchip/-/tree/quartz64<br />
* Mainline Rockchip custodian U-Boot repository: https://source.denx.de/u-boot/custodians/u-boot-rockchip<br />
* U-Boot Mailing List: https://lists.denx.de/listinfo/u-boot<br />
<br />
== Linux Kernel Config Options ==<br />
<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_I2S_TDM</code><br />
** for Analog and (in the future) HDMI audio<br />
* <code>CONFIG_SND_SOC_RK817</code><br />
** for Analog audio on the Model A<br />
* <code>CONFIG_STMMAC_ETH</code><br />
** Ethernet<br />
* <code>CONFIG_DWMAC_ROCKCHIP</code><br />
** Ethernet<br />
* <code>CONFIG_MOTORCOMM_PHY</code><br />
** Ethernet, set this one to Y, m won't work out of the box as module autoloading does not work for this specific PHY (the vendor ID is zeroed out), alternatively tell users in board-specific setup instructions to force loading the <code>motorcomm</code> module if you set it to m.<br />
* <code>CONFIG_MMC_DW</code><br />
** MMC/SD<br />
* <code>CONFIG_MMC_DW_ROCKCHIP</code><br />
** MMC/SD<br />
* <code>CONFIG_PCIE_ROCKCHIP_DW_HOST</code><br />
** PCIe<br />
* <code>CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY</code><br />
** PHY for PCIe/SATA/USB3, not yet upstream<br />
* <code>CONFIG_DRM_PANFROST</code><br />
** GPU<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_SPDIF</code><br />
** SPDIF audio<br />
* <code>CONFIG_ROCKCHIP_DW_HDMI</code><br />
** HDMI PHY<br />
* <code>CONFIG_ROCKCHIP_VOP2</code><br />
** Video output, not yet upstream<br />
* <code>CONFIG_ARCH_ROCKCHIP</code><br />
** General SoC support<br />
* <code>CONFIG_ROCKCHIP_PHY</code><br />
** General SoC support<br />
* <code>CONFIG_PHY_ROCKCHIP_INNO_USB2</code><br />
** USB 2<br />
* <code>CONFIG_RTC_DRV_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_COMMON_CLK_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_MFD_RK808</code><br />
** Various things relating to the RK817 chip<br />
* <code>CONFIG_REGULATOR_RK808</code><br />
** Voltage regulators<br />
* <code>CONFIG_ROCKCHIP_PM_DOMAINS</code><br />
** Power management domains<br />
* <code>CONFIG_GPIO_ROCKCHIP</code><br />
** GPIO support<br />
* <code>CONFIG_PINCTRL_ROCKCHIP</code><br />
** GPIO and general SoC support<br />
* <code>CONFIG_PWM_ROCKCHIP</code><br />
** PWM support<br />
* <code>CONFIG_ROCKCHIP_IOMMU</code><br />
** IOMMU support<br />
* <code>CONFIG_ROCKCHIP_MBOX</code><br />
** Mailbox support (for communication with MCU)<br />
* <code>CONFIG_ROCKCHIP_SARADC</code><br />
** Analog-to-digital conversion support, for e.g. microphones<br />
* <code>CONFIG_ROCKCHIP_THERMAL</code><br />
** Temperature sensor and thermal throttling support<br />
* <code>CONFIG_SPI_ROCKCHIP</code><br />
** SPI support<br />
* <code>CONFIG_VIDEO_HANTRO_ROCKCHIP</code><br />
** Hardware video decoder support<br />
* <code>CONFIG_ROCKCHIP_IODOMAIN</code><br />
** General SoC support so your I/O pins have the right voltage<br />
* <code>CONFIG_COMMON_CLK_ROCKCHIP</code><br />
** Common clock support<br />
<br />
== Resources ==<br />
=== Repositories ===<br />
<br />
* pgwipeout's kernel tree<br />
** https://gitlab.com/pgwipeout/linux-next/-/tree/quartz64-v5.15-rc1<br />
* BSP based development effort for SPL/U-Boot and Linux<br />
** https://gitlab.com/pine64-org/quartz-bsp<br />
* Image CI pipeline aimed at developers<br />
** https://gitlab.com/pgwipeout/quartz64_ci/<br />
* Rockchip U-Boot<br />
** https://github.com/rockchip-linux/u-boot<br />
* Downstream rockchip-linux kernel tree<br />
** https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux<br />
* Tianocore EDK II port for UEFI on Quartz64<br />
** https://github.com/jaredmcneill/quartz64_uefi<br />
* Mainline U-Boot Port by pgwipeout<br />
** https://gitlab.com/pgwipeout/u-boot-quartz64<br />
<br />
=== Other ===<br />
<br />
* Rockchip-SoC Patchwork Page<br />
** https://patchwork.kernel.org/project/linux-rockchip/list/<br />
* Rockchip Kernel Mailing List Archive<br />
** https://lore.kernel.org/linux-rockchip/<br />
<br />
== Board/SoC Documentation ==<br />
=== Booting ===<br />
==== Boot Order ====<br />
The RK3566 boot ROM will search for a valid ID BLOCK in the following order on the support boot media:<br />
<br />
* SPI NOR flash<br />
* SPI NAND flash<br />
* SD-Card<br />
* eMMC<br />
<br />
... if this fails, the boot ROM will initialize the USB0 port and wait for a connection from the Rockchip<br />
flash/boot tools.<br />
<br />
==== Bootloader Flashing ====<br />
<br />
As per pgwipeout's [https://gitlab.com/pine64-org/quartz-bsp/u-boot/-/commit/12d102b86813378af08b086f3b9c13ed8010754c commit message]:<br />
* Make a partition named <code>uboot</code> as partition number 1 at 8 MiB to 16 MiB<br />
* <code>dd if=idblock.bin of=/dev/''<mmc/sd>'' seek=64</code><br />
* <code>dd if=uboot.img of=/dev/''<mmc/sd>''1</code><br />
<br />
==== BSP Image Layout ====<br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=PineNote_Development&diff=12200PineNote Development2022-01-09T03:47:44Z<p>Smaeul: /* Mainline development */</p>
<hr />
<div>This article seeks to provide general development information for the [[PineNote]].<br />
<br />
More information is available in the notes written by some developers:<br />
<br />
https://pwarren.id.au/pinenote/build_notes.txt<br />
<br />
https://github.com/DorianRudolph/pinenotes<br />
<br />
https://github.com/tpwrules/nixos-pinenote<br />
<br />
= Flashing Software =<br />
<br />
Currently, the only ways to flash software are from the factory Android installation (UART shell, adb, or fastboot) or by using rkdeveloptool.<br />
<br />
== Side-by-side setup ==<br />
<br />
It is possible to set up a partition for mainline development without disturbing the factory Android installation. This allows updating a mainline kernel, DTB, and initramfs over Wi-Fi until WiFi or USB OTG is working in mainline Linux.<br />
<br />
=== Without Repartitioning ===<br />
<br />
The recommended partition for this is <tt>mmcblk0p11</tt> aka <tt>/cache</tt>. It is large and already formatted as <tt>ext4</tt>, so it is readable from U-Boot. Here are some general steps:<br />
<br />
# From the UART or adb shell, set up your chroot in <tt>/cache</tt>. I used the Alpine Linux rootfs tarball.<br />
# Copy in your kernel and DTB, using for example <tt>scp</tt> or <tt>wget</tt> inside the chroot.<br />
# Finally, create and boot an <code>extlinux.conf</code> as described below.<br />
<br />
=== With Repartitioning ===<br />
<br />
It is possible to shrink the <tt>userdata</tt> partition, and create a new partition at the end for use with mainline Linux. This provides much more space than <tt>cache</tt>. However, because <tt>userdata</tt> is formatted with <tt>f2fs</tt>, and that filesystem cannot be shrunk, resizing the partition requires wiping <tt>userdata</tt>.<br />
<br />
# Back up any necessary files from userdata<br />
# Boot to a mainline kernel from <tt>mmcblk0p11</tt>, either using that partition as rootfs (see above), or using an initramfs with repartitioning tools<br />
# Modify the partition table with your favorite tool, e.g. <tt>fdisk</tt>, <tt>gdisk</tt>, or <tt>parted</tt><br />
# Reboot into <tt>fastboot</tt> and wipe <tt>userdata</tt>.<br />
# Reboot into Android, where you can now chroot in and install your favorite distribution to the new partition.<br />
<br />
== Using rkdeveloptool ==<br />
<br />
rkdeveloptool is a command line utility built on libusb.<br />
<br />
=== Downloading and Building rkdeveloptool ===<br />
<br />
PINE64 develops [https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool its own updated fork of rkdeveloptool on GitLab].<br />
<br />
You will need to have libusb 1.0, its development headers and scdoc installed.<br />
<br />
<pre><br />
git clone https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool.git<br />
cd rkdeveloptool<br />
mkdir build<br />
cd build<br />
cmake ..<br />
</pre><br />
<br />
This sets up all the build files. You can then compile with <code>make</code> inside the build directory.<br />
<br />
After you're done, you'll likely also need to install the udev rules, or else your user won't have permission to access the USB devices:<br />
<br />
<pre><br />
sudo cp 99-rk-rockusb.rules /etc/udev/rules.d/<br />
sudo udevadm control --reload<br />
</pre><br />
<br />
Copying the udev rules is also performed automatically when you <code>make install</code>.<br />
<br />
=== Building Downstream U-Boot ===<br />
<br />
While in maskrom mode, we need to have a u-boot to download onto the device for any of the other commands to work. To build you'll also need to install device-tree-compiler.<br />
<br />
You also need to install Python and pyelftools.<br />
<br />
<b> Note that rkbin is a &gt;5GB download!</b> This will take some time to clone and process the deltas.<br />
<br />
<pre><br />
git clone -b quartz64 https://gitlab.com/pgwipeout/u-boot-rockchip.git<br />
git clone -b rkbin https://github.com/JeffyCN/rockchip_mirrors.git rkbin<br />
cd u-boot-rockchip<br />
# If using Arch Linux, export CROSS_COMPILE=aarch64-linux-gnu-<br />
export CROSS_COMPILE=aarch64-none-linux-gnu-<br />
make rk3566-quartz64_defconfig<br />
./make.sh<br />
</pre><br />
<br />
<blockquote><br />
In the version I cloned (current as of 2022-01-02), I had to make a change to one line to get a clean compilation:<br />
<br />
<pre><br />
diff --git a/lib/avb/libavb/avb_slot_verify.c b/lib/avb/libavb/avb_slot_verify.c<br />
index 123701fc3b..64a1ce6450 100644<br />
--- a/lib/avb/libavb/avb_slot_verify.c<br />
+++ b/lib/avb/libavb/avb_slot_verify.c<br />
@@ -296,7 +296,7 @@ static AvbSlotVerifyResult load_and_verify_hash_partition(<br />
bool image_preloaded = false;<br />
uint8_t* digest;<br />
size_t digest_len;<br />
- const char* found;<br />
+ const char* found = NULL;<br />
uint64_t image_size;<br />
size_t expected_digest_len = 0;<br />
uint8_t expected_digest_buf[AVB_SHA512_DIGEST_SIZE];<br />
</pre><br />
</blockquote><br />
<br />
=== Entering Maskrom Mode ===<br />
<br />
There are two ways to get into Maskrom mode:<br />
<br />
==== The easy way ====<br />
<br />
# Flip the device around so that the display faces down<br />
# Lay the pen on the right side, with its tip pointing towards the speaker grill, and its magnet pointing towards the upper right corner of the label on the back.<br />
# Turn the device on and wait for it to show up in <code>lsusb</code>. It should now be in Loader mode, according to <code>rkdeveloptool list-devices</code><br />
# Unplug the device and plug it back in. It should now be in maskrom mode.<br />
<br />
This can be a bit fiddly to get right, and may need a few tries.<br />
<br />
==== Shorting test points ====<br />
<br />
If the bootloader is broken/corrupted, you cannot get to Maskrom without opening up the device (it can be opened using spudger and a bit of patience).<br />
<br />
Once inside, short TP1301 and TP1302 with a small tweezers, this is how it looks on board view (credit to Caleb):<br />
<br />
[[File:PineNote_Maskrom_TP.png|500px]]<br />
<br />
Then plug the device to the computer and if you see the device with VID=2207/PID=350a then it should be in Maskrom mode, you can verify by typing <code>rkdeveloptool list-devices</code>.<br />
<br />
<nowiki>Jan 07 15:04:13 melttower kernel: usb 1-14: New USB device found, idVendor=2207, idProduct=350a, bcdDevice= 1.00<br />
Jan 07 15:04:13 melttower kernel: usb 1-14: New USB device strings: Mfr=0, Product=0, SerialNumber=0<br />
<br />
$ rkdeveloptool list-devices<br />
DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=10e Maskrom</nowiki><br />
<br />
<br />
If nothing shows up, you can try to hold down the power button for 5 seconds and then try again.<br />
<br />
=== Running rkdeveloptool ===<br />
<br />
First, you'll want to make sure the device you've connected is in maskrom mode:<br />
<br />
<pre><br />
./rkdeveloptool list<br />
</pre><br />
<br />
It should output something like <code>DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=202 Maskrom</code>. If it doesn't, see [[PineNote Development#Entering Maskrom Mode]].<br />
<br />
You can now download u-boot onto it:<br />
<pre><br />
./rkdeveloptool boot ../u-boot-rockchip/rk356x_spl_loader_v1.08.111.bin<br />
</pre><br />
<br />
This should output <code>Downloading bootloader succeeded.</code>.<br />
<br />
We can now verify that this worked using e.g. the "read flash info" command:<br />
<br />
<pre><br />
./rkdeveloptool read-flash-info<br />
</pre><br />
<br />
'''TODO:''' finish this section<br />
<br />
=== Creating a mainline boot image ===<br />
<br />
You can create a filesystem image that replaces the Android boot or recovery partition by doing roughly the following:<br />
<br />
# Erase boot and dtbo with rkdeveloptool or fastboot (back them up first!!!)<br />
# Create an ext2 partition image and mount it (fallocate, mkfs.ext2)<br />
# Build your mainline kernel<br />
# Copy the kernel, dtb and an initramfs to the root of the mounted image (use any old postmarketOS initramfs)<br />
# Create a file in the root of the mounted image called <code>extlinux.conf</code> as described below<br />
# Unmount the image and then use rkdeveloptool to flash it to the "recovery" partition on the pinenote (it's about the right size until we get around to replacing the partition layout).<br />
<br />
== Using fastboot ==<br />
<br />
Follow the steps for "Creating a mainline boot.img", but instead of flashing it with rkdeveloptool, use fastboot. You can enter fastboot in either of two ways:<br />
<br />
# Use "reboot bootloader" from adb or a UART console.<br />
# Get a U-Boot prompt and run <code>fastboot usb 0</code>.<br />
<br />
= Mainline development =<br />
<br />
== Status ==<br />
<br />
Some work happening here: https://gitlab.com/calebccff/linux, the idea is to import the parts of the eink/ebc drivers which are open source and use the downstream u-boot framebuffer driver as a reference to create a basic framebuffer driver.<br />
<br />
Currently mainline struggles to boot due to weird issues while probing fixed regulators (?). It also fails to detect eMMC.<br />
<br />
Further work is being done here: https://github.com/smaeul/linux/commits/rk356x-ebc-dev. This has a complete device tree, with working eMMC. Pen input also works out of the box. Wi-Fi and BT work with firmware copied from the factory Android image.<br />
<br />
== How to boot mainline ==<br />
<br />
UART is currently REQUIRED for this to work! We depend on u-boot falling back to console. Once we have a prebuilt u-boot which will use extlinux by default, UART won't be needed anymore.<br />
<br />
=== Getting to a U-Boot prompt ===<br />
<br />
You can get to a U-Boot prompt by:<br />
<br />
# Holding Ctrl-C while the display panel initializes.<br />
# Wiping the "boot" partition.<br />
<br />
=== Using sysboot ===<br />
<br />
<code>extlinux.conf</code> should have the following contents:<br />
<br />
<pre><br />
timeout 10<br />
default MAINLINE<br />
menu title boot prev kernel<br />
<br />
label MAINLINE<br />
kernel /vmlinuz<br />
fdt /rk3566-pinenote.dtb<br />
initrd /initramfs<br />
append earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off PMOS_NO_OUTPUT_REDIRECT<br />
</pre><br />
<br />
At the u-boot console, run the following command to boot your mainline kernel:<br />
<br />
<pre><br />
sysboot ${devtype} ${devnum}:9 any ${scriptaddr} extlinux.conf<br />
</pre><br />
<br />
=== Booting with individual commands ===<br />
<br />
Booting with individual commands can be useful when you need to temporarily add some kernel command line arguments. Use these or similar commands at the U-Boot shell:<br />
<br />
load mmc 0:b ${kernel_addr_r} boot/Image<br />
load mmc 0:b ${fdt_addr_r} boot/rk3566-pinenote.dtb<br />
setenv bootargs ignore_loglevel root=/dev/mmcblk0p11 rootwait init=/bin/bash<br />
booti ${kernel_addr_r} - ${fdt_addr_r}<br />
<br />
== Configuration ==<br />
<br />
=== Firmware ===<br />
<br />
Copy WiFi/BT firmware from Android:<br />
mkdir -p /cache/lib/firmware/brcm<br />
cp /vendor/etc/firmware/fw_bcm43455c0_ag_cy.bin /cache/lib/firmware/brcm/brcmfmac43455-sdio.bin<br />
cp /vendor/etc/firmware/nvram_ap6255_cy.txt /cache/lib/firmware/brcm/brcmfmac43455-sdio.txt<br />
cp /cache/lib/firmware/BCM4345C0.hcd /cache/lib/firmware/brcm/BCM4345C0.hcd<br />
<br />
Copy waveform partition (via previously dumped file):<br />
adb root<br />
adb push waveform.img /cache/lib/firmware/waveform.bin<br />
<br />
Or via dd within Linux:<br />
dd if=/dev/mmcblk0p3 of=/lib/firmware/waveform.bin bs=1k count=2048<br />
<br />
=== Touchscreen and Pen In X.org ===<br />
<br />
By default the pen config is flipped 180° (which makes it unusable) and the touchscreen doesn't work. Placing the following config in <code>/etc/X11/xorg.conf.d/50-touchscreen.conf</code> will fix both problems:<br />
<br />
<pre><br />
Section "InputClass"<br />
Identifier "evdev touchscreen"<br />
MatchProduct "tt21000"<br />
MatchIsTouchscreen "on"<br />
Driver "evdev"<br />
EndSection<br />
Section "InputClass"<br />
Identifier "RotateTouch"<br />
MatchProduct "w9013"<br />
Option "TransformationMatrix" "-1 0 1 0 -1 1 0 0 1"<br />
EndSection<br />
</pre></div>Smaeulhttps://wiki.pine64.org/index.php?title=RK3566_EBC_Reverse-Engineering&diff=12196RK3566 EBC Reverse-Engineering2022-01-08T05:02:15Z<p>Smaeul: /* Documentation */</p>
<hr />
<div>The RK3566 SoC, used in the [[Quartz64]] SBC by PINE64, contains an eInk interface. This is referred to as <code>ebc</code> by Rockchip apparently.<br />
<br />
Unfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it.<br />
<br />
= Sources =<br />
<br />
== Downstream ==<br />
<br />
The ebc driver source is [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/gpu/drm/rockchip/ebc-dev available from the quartz-bsp repository].<br />
<br />
The files of interest are <code>ebc_dev_v8.S</code>, which implements a DRM (Direct Rendering Manager) driver for the eInk panel, and the waveform files in the <code>epdlut</code> subdirectory.<br />
<br />
There's also a simple driver for u-boot: [https://github.com/JeffyCN/rockchip_mirrors/tree/u-boot/drivers/video/rk_eink drivers/video/rk_eink at JeffyCN/rockchip_mirrors]<br />
<br />
These two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in "LUT mode": it writes the waveform LUT to registers in the TCON's MMIO space, and passes buffers of ''pixel'' data to the TCON. The Linux driver operates in "direct mode" uses the LUTs to compute waveforms in software, and passes buffers of ''waveform'' data to the TCON.<br />
<br />
Some reversing of the downstream Linux driver has been done here: https://github.com/Ralim/ebc-dev-reverse-engineering<br />
<br />
== Reimplementation ==<br />
<br />
A human-readable C reimplementation of the LUT and pixel data path [https://gitlab.com/smaeul/ebc-dev is available from smaeul here]. This provides everything needed to convert a framebuffer and a waveform data file into a series of "frames" for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver.<br />
<br />
== In-Development Driver ==<br />
<br />
[https://github.com/smaeul/linux/commits/rk356x-ebc-dev rk356x-ebc-dev] is the branch used for developing an upstreamable DRM driver based on mainline kernel sources. The driver currently functions well enough to get a virtual console and Xorg running, but it does not support features like multiple waveforms.<br />
<br />
= Documentation =<br />
<br />
== Datasheets ==<br />
<br />
=== EBC ===<br />
<br />
The EBC TCON is documented in part 2 of the RK356x TRM.<br />
<br />
=== TI TPS65185x ===<br />
<br />
This is the PMIC used to drive the e-Ink panel, for which the downstream sources also implement a driver.<br />
<br />
https://www.ti.com/lit/ds/symlink/tps65185.pdf<br />
<br />
=== Waveform ===<br />
<br />
The format of the waveform file is documented here:<br />
<br />
https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declaration.pdf<br />
<br />
https://www.waveshare.net/w/upload/archive/c/c4/20190611032540!E-paper-mode-declaration.pdf<br />
<br />
== Utilities ==<br />
<br />
The [https://github.com/fread-ink/inkwave <tt>inkwave</tt>] program is designed to parse waveform files. Currently it cannot fully handle the waveform files shipped with the PineNote. Adding support for this to the tool would be helpful.<br />
<br />
== Assembly Syntax and Semantics ==<br />
<br />
The Syntax is GNU Assembler (GAS) syntax. [https://modexp.wordpress.com/2018/10/30/arm64-assembly/ This modexp article] provides a good introduction to the syntax, calling convention, semantics and some often used instructions.<br />
<br />
The [https://developer.arm.com/documentation/ddi0487/gb/ ARM Architecture Reference Manual for ARMv8] should be used as reference for any instructions.<br />
<br />
At the very least, you should read up on the registers and calling convention used.<br />
<br />
= Various Findings =<br />
<br />
The driver isn't really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions.<br />
<br />
* It's technically a DRM subsystem driver, but doesn't really utilise what DRM provides at all.<br />
* It seems to register a new ioctl to set buffer attributes like width and height, despite DRM more than likely having a way for clients to tell a driver what size the framebuffer should be.<br />
* It directly interacts with the PMIC instead of going through regulators/hwmon.<br />
<br />
However, reverse engineering to know how it works provides a good baseline from which we can rewrite it in a more sensible manner.<br />
<br />
= Debug Information =<br />
<br />
Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage.<br />
<br />
== <code>.file ''file-number'' ''file-path''</code> ==<br />
<br />
Specifies a number to reference a file by, and its path. All following code until the next <code>.file</code> or <code>.loc</code> statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available.<br />
<br />
== <code>.loc ''file-number'' ''line-number'' 0</code> ==<br />
<br />
Specifies that the following code is generated from <code>''line-number''</code> stemming from file number <code>''file-number''</code>. See the <code>.file</code> directive for this file number to understand which source file it came from.<br />
<br />
== <code>.type ''function-name'', %function</code> ==<br />
<br />
This tells us that the following code belongs to function <code>''function-name''</code>. You'll usually see a <code>.cfi_startproc</code>, which signifies the start of the function code, until the matching <code>.cfi_endproc</code>.<br />
<br />
A quick grep for <code>%function</code> shows that we are dealing with 30 functions in this file.<br />
<br />
== <code>.type ''struct-name'', %object</code> ==<br />
<br />
This seems to signify a definition of a C struct named <code>''struct-name''</code>.<br />
<br />
A quick grep for <code>%object</code> shows that we are dealing with around 27 structs in this file.<br />
<br />
== <code>.Ldebug_info0:</code> ==<br />
<br />
'''TODO:''' This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures.<br />
<br />
= Finding Structs and Function Signatures =<br />
<br />
First, we'll need to assemble the file:<br />
<br />
<code>aarch64-linux-gnu-gcc -c -o ebc_dev_v8.o ebc_dev_v8.S</code><br />
<br />
This gives us a <code>ebc_dev_v8.o</code> which we can feed into analysis tools.<br />
<br />
For both of these, keep in mind that we're only interested in stuff from ebc_dev.c, or any other files for which we don't have the source. There's no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such.<br />
<br />
Also make sure that if you are looking up known struct accesses, that you use struct definitions from the BSP kernel, not from mainline. The kernel has no internal ABI for drivers!<br />
<br />
== Faster and Easier - Ghidra ==<br />
<br />
Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the "Data Type Manager" marked with an S icon. You'll also find functions in the symbol tree.<br />
<br />
== Slow and Painful - readelf/objdump ==<br />
<br />
Use this if you want to manually look up dwarf symbols for some reason.<br />
<br />
<code>readelf --debug-dump ebc_dev_v8.o</code><br />
<br />
This will produce a lot of output, but we're mainly concerned with the start of the dump. We'll find things like:<br />
<nowiki><br />
&lt;2&gt;&lt;101f8&gt;: Abbrev Number: 0<br />
&lt;1&gt;&lt;101f9&gt;: Abbrev Number: 79 (DW_TAG_subprogram)<br />
&lt;101fa&gt; DW_AT_name : (indirect string, offset: 0xa2b4): ebc_open<br />
&lt;101fe&gt; DW_AT_decl_file : 1<br />
&lt;101ff&gt; DW_AT_decl_line : 1377<br />
&lt;10201&gt; DW_AT_prototyped : 1<br />
&lt;10201&gt; DW_AT_type : &lt;0xc6&gt;<br />
&lt;10205&gt; DW_AT_low_pc : 0x0<br />
&lt;1020d&gt; DW_AT_high_pc : 0xc<br />
&lt;10215&gt; DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)<br />
&lt;10217&gt; DW_AT_GNU_all_call_sites: 1<br />
&lt;10217&gt; DW_AT_sibling : &lt;0x1023a&gt;<br />
&lt;2&gt;&lt;1021b&gt;: Abbrev Number: 88 (DW_TAG_formal_parameter)<br />
&lt;1021c&gt; DW_AT_name : (indirect string, offset: 0x1153): inode<br />
&lt;10220&gt; DW_AT_decl_file : 1<br />
&lt;10221&gt; DW_AT_decl_line : 1377<br />
&lt;10223&gt; DW_AT_type : &lt;0x1c54&gt;<br />
&lt;10227&gt; DW_AT_location : 0xd63 (location list)<br />
&lt;2&gt;&lt;1022b&gt;: Abbrev Number: 106 (DW_TAG_formal_parameter)<br />
&lt;1022c&gt; DW_AT_name : (indirect string, offset: 0x8b06): file<br />
&lt;10230&gt; DW_AT_decl_file : 1<br />
&lt;10231&gt; DW_AT_decl_line : 1377<br />
&lt;10233&gt; DW_AT_type : &lt;0x551f&gt;<br />
&lt;10237&gt; DW_AT_location : 1 byte block: 51 (DW_OP_reg1 (x1))</nowiki><br />
<br />
This essentially tells us the full function signature of <code>ebc_open</code>:<br />
<br />
<code>DW_TAG_subprogram</code> tells us of a function, with <code>DW_AT_name</code> letting us know that this is <code>ebc_open</code>. <code>DW_AT_type</code> of <code>0xc6</code> let's us know, once we jump to <code>&lt;c6&gt;</code>, that this function's return type is a signed 32-bit integer.<br />
<br />
The <code>DW_TAG_formal_parameter</code> that follow tell us of each of the parameter the function takes. The first one is called <code>inode</code> and is of type <code>0x1c54</code>. Referencing what this type is, we find:<br />
<br />
<nowiki><br />
<1><1c54>: Abbrev Number: 7 (DW_TAG_pointer_type)<br />
<1c55> DW_AT_byte_size : 8<br />
<1c56> DW_AT_type : <0x1970></nowiki><br />
<br />
which in of itself goes on to reference <code>0x1970</code>, and looking this one up, we'll find a struct definition:<br />
<br />
<nowiki><br />
<1><1970>: Abbrev Number: 26 (DW_TAG_structure_type)<br />
<1971> DW_AT_name : (indirect string, offset: 0x1153): inode<br />
<1975> DW_AT_byte_size : 672<br />
<1977> DW_AT_decl_file : 31<br />
<1978> DW_AT_decl_line : 611<br />
<197a> DW_AT_sibling : <0x1c4f><br />
<2><197e>: Abbrev Number: 27 (DW_TAG_member)<br />
<197f> DW_AT_name : (indirect string, offset: 0x7d00): i_mode<br />
[etc etc...]</nowiki><br />
<br />
= Reverse-Engineered Stuff =<br />
<br />
== Structs ==<br />
<br />
=== ebc_info ===<br />
<br />
<!-- I don't know why mediawiki scuffs the formatting here --><br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== ebc ===<br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== rkf_waveform ===<br />
<br />
Note: all known waveform data files are the "PVI" variant, not the "RKF" variant.<br />
<br />
<source lang="c"><br />
struct rkf_waveform {<br />
int length,<br />
char[16] format,<br />
char[16] version,<br />
char[16] timeandday,<br />
char[16] panel_name,<br />
char[16] panel_info,<br />
char[64] full_version,<br />
char[64] reset_temp_list,<br />
char[64] gc16_temp_list,<br />
char[64] gl16_temp_list,<br />
char[64] glr16_temp_list,<br />
char[64] gld16_temp_list,<br />
char[64] du_temp_list,<br />
char[64] a2_temp_list,<br />
uint[64] reset_list,<br />
uint[64] gc16_list,<br />
uint[64] gl16_list,<br />
uint[64] glr16_list,<br />
uint[64] gld16_list,<br />
uint[64] du_list,<br />
uint[64] a2_list<br />
}<br />
</source><br />
<br />
== Enums ==<br />
<br />
=== rkf_waveform_type ===<br />
<source lang="c"><br />
enum rkf_waveform_type {<br />
RKF_WF_RESET = 0,<br />
RKF_WF_DU = 1,<br />
RKF_WF_GC16 = 2,<br />
RKF_WF_GL16 = 3,<br />
RKF_WF_GLR16 = 4,<br />
RKF_WF_GLD16 = 5,<br />
RKF_WF_A2 = 6<br />
}<br />
</source><br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=PineNote_Development&diff=12195PineNote Development2022-01-08T05:00:41Z<p>Smaeul: /* Side-by-side setup */ Add basic instructions for partition setup</p>
<hr />
<div>This article seeks to provide general development information for the [[PineNote]].<br />
<br />
More information is available in the notes written by some developers:<br />
<br />
https://pwarren.id.au/pinenote/build_notes.txt<br />
<br />
https://github.com/DorianRudolph/pinenotes<br />
<br />
https://github.com/tpwrules/nixos-pinenote<br />
<br />
= Flashing Software =<br />
<br />
Currently, the only ways to flash software are from the factory Android installation (UART shell, adb, or fastboot) or by using rkdeveloptool.<br />
<br />
== Side-by-side setup ==<br />
<br />
It is possible to set up a partition for mainline development without disturbing the factory Android installation. This allows updating a mainline kernel, DTB, and initramfs over Wi-Fi until WiFi or USB OTG is working in mainline Linux.<br />
<br />
=== Without Repartitioning ===<br />
<br />
The recommended partition for this is <tt>mmcblk0p11</tt> aka <tt>/cache</tt>. It is large and already formatted as <tt>ext4</tt>, so it is readable from U-Boot. Here are some general steps:<br />
<br />
# From the UART or adb shell, set up your chroot in <tt>/cache</tt>. I used the Alpine Linux rootfs tarball.<br />
# Copy in your kernel and DTB, using for example <tt>scp</tt> or <tt>wget</tt> inside the chroot.<br />
# Finally, create and boot an <code>extlinux.conf</code> as described below.<br />
<br />
=== With Repartitioning ===<br />
<br />
It is possible to shrink the <tt>userdata</tt> partition, and create a new partition at the end for use with mainline Linux. This provides much more space than <tt>cache</tt>. However, because <tt>userdata</tt> is formatted with <tt>f2fs</tt>, and that filesystem cannot be shrunk, resizing the partition requires wiping <tt>userdata</tt>.<br />
<br />
# Back up any necessary files from userdata<br />
# Boot to a mainline kernel from <tt>mmcblk0p11</tt>, either using that partition as rootfs (see above), or using an initramfs with repartitioning tools<br />
# Modify the partition table with your favorite tool, e.g. <tt>fdisk</tt>, <tt>gdisk</tt>, or <tt>parted</tt><br />
# Reboot into <tt>fastboot</tt> and wipe <tt>userdata</tt>.<br />
# Reboot into Android, where you can now chroot in and install your favorite distribution to the new partition.<br />
<br />
== Using rkdeveloptool ==<br />
<br />
rkdeveloptool is a command line utility built on libusb.<br />
<br />
=== Downloading and Building rkdeveloptool ===<br />
<br />
PINE64 develops [https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool its own updated fork of rkdeveloptool on GitLab].<br />
<br />
You will need to have libusb 1.0, its development headers and scdoc installed.<br />
<br />
<pre><br />
git clone https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool.git<br />
cd rkdeveloptool<br />
mkdir build<br />
cd build<br />
cmake ..<br />
</pre><br />
<br />
This sets up all the build files. You can then compile with <code>make</code> inside the build directory.<br />
<br />
After you're done, you'll likely also need to install the udev rules, or else your user won't have permission to access the USB devices:<br />
<br />
<pre><br />
sudo cp 99-rk-rockusb.rules /etc/udev/rules.d/<br />
sudo udevadm control --reload<br />
</pre><br />
<br />
Copying the udev rules is also performed automatically when you <code>make install</code>.<br />
<br />
=== Building Downstream U-Boot ===<br />
<br />
While in maskrom mode, we need to have a u-boot to download onto the device for any of the other commands to work. To build you'll also need to install device-tree-compiler.<br />
<br />
You also need to install Python and pyelftools.<br />
<br />
<b> Note that rkbin is a &gt;5GB download!</b> This will take some time to clone and process the deltas.<br />
<br />
<pre><br />
git clone -b quartz64 https://gitlab.com/pgwipeout/u-boot-rockchip.git<br />
git clone -b rkbin https://github.com/JeffyCN/rockchip_mirrors.git rkbin<br />
cd u-boot-rockchip<br />
# If using Arch Linux, export CROSS_COMPILE=aarch64-linux-gnu-<br />
export CROSS_COMPILE=aarch64-none-linux-gnu-<br />
make rk3566-quartz64_defconfig<br />
./make.sh<br />
</pre><br />
<br />
<blockquote><br />
In the version I cloned (current as of 2022-01-02), I had to make a change to one line to get a clean compilation:<br />
<br />
<pre><br />
diff --git a/lib/avb/libavb/avb_slot_verify.c b/lib/avb/libavb/avb_slot_verify.c<br />
index 123701fc3b..64a1ce6450 100644<br />
--- a/lib/avb/libavb/avb_slot_verify.c<br />
+++ b/lib/avb/libavb/avb_slot_verify.c<br />
@@ -296,7 +296,7 @@ static AvbSlotVerifyResult load_and_verify_hash_partition(<br />
bool image_preloaded = false;<br />
uint8_t* digest;<br />
size_t digest_len;<br />
- const char* found;<br />
+ const char* found = NULL;<br />
uint64_t image_size;<br />
size_t expected_digest_len = 0;<br />
uint8_t expected_digest_buf[AVB_SHA512_DIGEST_SIZE];<br />
</pre><br />
</blockquote><br />
<br />
=== Entering Maskrom Mode ===<br />
<br />
There are two ways to get into Maskrom mode:<br />
<br />
==== The easy way ====<br />
<br />
# Flip the device around so that the display faces down<br />
# Lay the pen on the right side, with its tip pointing towards the speaker grill, and its magnet pointing towards the upper right corner of the label on the back.<br />
# Turn the device on and wait for it to show up in <code>lsusb</code>. It should now be in Loader mode, according to <code>rkdeveloptool list-devices</code><br />
# Unplug the device and plug it back in. It should now be in maskrom mode.<br />
<br />
This can be a bit fiddly to get right, and may need a few tries.<br />
<br />
==== Shorting test points ====<br />
<br />
If the bootloader is broken/corrupted, you cannot get to Maskrom without opening up the device (it can be opened using spudger and a bit of patience).<br />
<br />
Once inside, short TP1301 and TP1302 with a small tweezers, this is how it looks on board view (credit to Caleb):<br />
<br />
[[File:PineNote_Maskrom_TP.png|500px]]<br />
<br />
Then plug the device to the computer and if you see the device with VID=2207/PID=350a then it should be in Maskrom mode, you can verify by typing <code>rkdeveloptool list-devices</code>.<br />
<br />
<nowiki>Jan 07 15:04:13 melttower kernel: usb 1-14: New USB device found, idVendor=2207, idProduct=350a, bcdDevice= 1.00<br />
Jan 07 15:04:13 melttower kernel: usb 1-14: New USB device strings: Mfr=0, Product=0, SerialNumber=0<br />
<br />
$ rkdeveloptool list-devices<br />
DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=10e Maskrom</nowiki><br />
<br />
<br />
If nothing shows up, you can try to hold down the power button for 5 seconds and then try again.<br />
<br />
=== Running rkdeveloptool ===<br />
<br />
First, you'll want to make sure the device you've connected is in maskrom mode:<br />
<br />
<pre><br />
./rkdeveloptool list<br />
</pre><br />
<br />
It should output something like <code>DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=202 Maskrom</code>. If it doesn't, see [[PineNote Development#Entering Maskrom Mode]].<br />
<br />
You can now download u-boot onto it:<br />
<pre><br />
./rkdeveloptool boot ../u-boot-rockchip/rk356x_spl_loader_v1.08.111.bin<br />
</pre><br />
<br />
This should output <code>Downloading bootloader succeeded.</code>.<br />
<br />
We can now verify that this worked using e.g. the "read flash info" command:<br />
<br />
<pre><br />
./rkdeveloptool read-flash-info<br />
</pre><br />
<br />
'''TODO:''' finish this section<br />
<br />
=== Creating a mainline boot image ===<br />
<br />
You can create a filesystem image that replaces the Android boot or recovery partition by doing roughly the following:<br />
<br />
# Erase boot and dtbo with rkdeveloptool or fastboot (back them up first!!!)<br />
# Create an ext2 partition image and mount it (fallocate, mkfs.ext2)<br />
# Build your mainline kernel<br />
# Copy the kernel, dtb and an initramfs to the root of the mounted image (use any old postmarketOS initramfs)<br />
# Create a file in the root of the mounted image called <code>extlinux.conf</code> as described below<br />
# Unmount the image and then use rkdeveloptool to flash it to the "recovery" partition on the pinenote (it's about the right size until we get around to replacing the partition layout).<br />
<br />
== Using fastboot ==<br />
<br />
Follow the steps for "Creating a mainline boot.img", but instead of flashing it with rkdeveloptool, use fastboot. You can enter fastboot in either of two ways:<br />
<br />
# Use "reboot bootloader" from adb or a UART console.<br />
# Get a U-Boot prompt and run <code>fastboot usb 0</code>.<br />
<br />
= Mainline development =<br />
<br />
== Status ==<br />
<br />
Some work happening here: https://gitlab.com/calebccff/linux, the idea is to import the parts of the eink/ebc drivers which are open source and use the downstream u-boot framebuffer driver as a reference to create a basic framebuffer driver.<br />
<br />
Currently mainline struggles to boot due to weird issues while probing fixed regulators (?). It also fails to detect eMMC.<br />
<br />
Further work is being done here: https://github.com/smaeul/linux/commits/rk356x-ebc-dev. This has a complete device tree, with working eMMC. Pen input also works out of the box. Wi-Fi and BT work with firmware copied from the factory Android image.<br />
<br />
== How to boot mainline ==<br />
<br />
UART is currently REQUIRED for this to work! We depend on u-boot falling back to console. Once we have a prebuilt u-boot which will use extlinux by default, UART won't be needed anymore.<br />
<br />
=== Getting to a U-Boot prompt ===<br />
<br />
You can get to a U-Boot prompt by:<br />
<br />
# Holding Ctrl-C while the display panel initializes.<br />
# Wiping the "boot" partition.<br />
<br />
=== Using sysboot ===<br />
<br />
<code>extlinux.conf</code> should have the following contents:<br />
<br />
<pre><br />
timeout 10<br />
default MAINLINE<br />
menu title boot prev kernel<br />
<br />
label MAINLINE<br />
kernel /vmlinuz<br />
fdt /rk3566-pinenote.dtb<br />
initrd /initramfs<br />
append earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off PMOS_NO_OUTPUT_REDIRECT<br />
</pre><br />
<br />
At the u-boot console, run the following command to boot your mainline kernel:<br />
<br />
<pre><br />
sysboot ${devtype} ${devnum}:9 any ${scriptaddr} extlinux.conf<br />
</pre><br />
<br />
=== Booting with individual commands ===<br />
<br />
Booting with individual commands can be useful when you need to temporarily add some kernel command line arguments. Use these or similar commands at the U-Boot shell:<br />
<br />
load mmc 0:b ${kernel_addr_r} boot/Image<br />
load mmc 0:b ${fdt_addr_r} boot/rk3566-pinenote.dtb<br />
setenv bootargs ignore_loglevel root=/dev/mmcblk0p11 rootwait init=/bin/bash<br />
booti ${kernel_addr_r} - ${fdt_addr_r}</div>Smaeulhttps://wiki.pine64.org/index.php?title=PineNote_Development&diff=12194PineNote Development2022-01-08T04:54:32Z<p>Smaeul: </p>
<hr />
<div>This article seeks to provide general development information for the [[PineNote]].<br />
<br />
More information is available in the notes written by some developers:<br />
<br />
https://pwarren.id.au/pinenote/build_notes.txt<br />
<br />
https://github.com/DorianRudolph/pinenotes<br />
<br />
https://github.com/tpwrules/nixos-pinenote<br />
<br />
= Flashing Software =<br />
<br />
Currently, the only ways to flash software are from the factory Android installation (UART shell, adb, or fastboot) or by using rkdeveloptool.<br />
<br />
== Side-by-side setup ==<br />
<br />
It is possible to set up a partition for mainline development without disturbing the factory Android installation. This allows updating a mainline kernel, DTB, and initramfs over Wi-Fi until WiFi or USB OTG is working in mainline Linux.<br />
<br />
The recommended partition for this is <tt>mmcblk0p11</tt> aka <tt>/cache</tt>. It is large and already formatted as <tt>ext4</tt>, so it is readable from U-Boot. Here are some general steps:<br />
<br />
# From the UART or adb shell, set up your chroot in <tt>/cache</tt>. I used the Alpine Linux rootfs tarball.<br />
# Copy in your kernel and DTB, using for example <tt>scp</tt> or <tt>wget</tt> inside the chroot.<br />
# Finally, create and boot an <code>extlinux.conf</code> as described below.<br />
<br />
== Using rkdeveloptool ==<br />
<br />
rkdeveloptool is a command line utility built on libusb.<br />
<br />
=== Downloading and Building rkdeveloptool ===<br />
<br />
PINE64 develops [https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool its own updated fork of rkdeveloptool on GitLab].<br />
<br />
You will need to have libusb 1.0, its development headers and scdoc installed.<br />
<br />
<pre><br />
git clone https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool.git<br />
cd rkdeveloptool<br />
mkdir build<br />
cd build<br />
cmake ..<br />
</pre><br />
<br />
This sets up all the build files. You can then compile with <code>make</code> inside the build directory.<br />
<br />
After you're done, you'll likely also need to install the udev rules, or else your user won't have permission to access the USB devices:<br />
<br />
<pre><br />
sudo cp 99-rk-rockusb.rules /etc/udev/rules.d/<br />
sudo udevadm control --reload<br />
</pre><br />
<br />
Copying the udev rules is also performed automatically when you <code>make install</code>.<br />
<br />
=== Building Downstream U-Boot ===<br />
<br />
While in maskrom mode, we need to have a u-boot to download onto the device for any of the other commands to work. To build you'll also need to install device-tree-compiler.<br />
<br />
You also need to install Python and pyelftools.<br />
<br />
<b> Note that rkbin is a &gt;5GB download!</b> This will take some time to clone and process the deltas.<br />
<br />
<pre><br />
git clone -b quartz64 https://gitlab.com/pgwipeout/u-boot-rockchip.git<br />
git clone -b rkbin https://github.com/JeffyCN/rockchip_mirrors.git rkbin<br />
cd u-boot-rockchip<br />
# If using Arch Linux, export CROSS_COMPILE=aarch64-linux-gnu-<br />
export CROSS_COMPILE=aarch64-none-linux-gnu-<br />
make rk3566-quartz64_defconfig<br />
./make.sh<br />
</pre><br />
<br />
<blockquote><br />
In the version I cloned (current as of 2022-01-02), I had to make a change to one line to get a clean compilation:<br />
<br />
<pre><br />
diff --git a/lib/avb/libavb/avb_slot_verify.c b/lib/avb/libavb/avb_slot_verify.c<br />
index 123701fc3b..64a1ce6450 100644<br />
--- a/lib/avb/libavb/avb_slot_verify.c<br />
+++ b/lib/avb/libavb/avb_slot_verify.c<br />
@@ -296,7 +296,7 @@ static AvbSlotVerifyResult load_and_verify_hash_partition(<br />
bool image_preloaded = false;<br />
uint8_t* digest;<br />
size_t digest_len;<br />
- const char* found;<br />
+ const char* found = NULL;<br />
uint64_t image_size;<br />
size_t expected_digest_len = 0;<br />
uint8_t expected_digest_buf[AVB_SHA512_DIGEST_SIZE];<br />
</pre><br />
</blockquote><br />
<br />
=== Entering Maskrom Mode ===<br />
<br />
There are two ways to get into Maskrom mode:<br />
<br />
==== The easy way ====<br />
<br />
# Flip the device around so that the display faces down<br />
# Lay the pen on the right side, with its tip pointing towards the speaker grill, and its magnet pointing towards the upper right corner of the label on the back.<br />
# Turn the device on and wait for it to show up in <code>lsusb</code>. It should now be in Loader mode, according to <code>rkdeveloptool list-devices</code><br />
# Unplug the device and plug it back in. It should now be in maskrom mode.<br />
<br />
This can be a bit fiddly to get right, and may need a few tries.<br />
<br />
==== Shorting test points ====<br />
<br />
If the bootloader is broken/corrupted, you cannot get to Maskrom without opening up the device (it can be opened using spudger and a bit of patience).<br />
<br />
Once inside, short TP1301 and TP1302 with a small tweezers, this is how it looks on board view (credit to Caleb):<br />
<br />
[[File:PineNote_Maskrom_TP.png|500px]]<br />
<br />
Then plug the device to the computer and if you see the device with VID=2207/PID=350a then it should be in Maskrom mode, you can verify by typing <code>rkdeveloptool list-devices</code>.<br />
<br />
<nowiki>Jan 07 15:04:13 melttower kernel: usb 1-14: New USB device found, idVendor=2207, idProduct=350a, bcdDevice= 1.00<br />
Jan 07 15:04:13 melttower kernel: usb 1-14: New USB device strings: Mfr=0, Product=0, SerialNumber=0<br />
<br />
$ rkdeveloptool list-devices<br />
DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=10e Maskrom</nowiki><br />
<br />
<br />
If nothing shows up, you can try to hold down the power button for 5 seconds and then try again.<br />
<br />
=== Running rkdeveloptool ===<br />
<br />
First, you'll want to make sure the device you've connected is in maskrom mode:<br />
<br />
<pre><br />
./rkdeveloptool list<br />
</pre><br />
<br />
It should output something like <code>DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=202 Maskrom</code>. If it doesn't, see [[PineNote Development#Entering Maskrom Mode]].<br />
<br />
You can now download u-boot onto it:<br />
<pre><br />
./rkdeveloptool boot ../u-boot-rockchip/rk356x_spl_loader_v1.08.111.bin<br />
</pre><br />
<br />
This should output <code>Downloading bootloader succeeded.</code>.<br />
<br />
We can now verify that this worked using e.g. the "read flash info" command:<br />
<br />
<pre><br />
./rkdeveloptool read-flash-info<br />
</pre><br />
<br />
'''TODO:''' finish this section<br />
<br />
=== Creating a mainline boot image ===<br />
<br />
You can create a filesystem image that replaces the Android boot or recovery partition by doing roughly the following:<br />
<br />
# Erase boot and dtbo with rkdeveloptool or fastboot (back them up first!!!)<br />
# Create an ext2 partition image and mount it (fallocate, mkfs.ext2)<br />
# Build your mainline kernel<br />
# Copy the kernel, dtb and an initramfs to the root of the mounted image (use any old postmarketOS initramfs)<br />
# Create a file in the root of the mounted image called <code>extlinux.conf</code> as described below<br />
# Unmount the image and then use rkdeveloptool to flash it to the "recovery" partition on the pinenote (it's about the right size until we get around to replacing the partition layout).<br />
<br />
== Using fastboot ==<br />
<br />
Follow the steps for "Creating a mainline boot.img", but instead of flashing it with rkdeveloptool, use fastboot. You can enter fastboot in either of two ways:<br />
<br />
# Use "reboot bootloader" from adb or a UART console.<br />
# Get a U-Boot prompt and run <code>fastboot usb 0</code>.<br />
<br />
= Mainline development =<br />
<br />
== Status ==<br />
<br />
Some work happening here: https://gitlab.com/calebccff/linux, the idea is to import the parts of the eink/ebc drivers which are open source and use the downstream u-boot framebuffer driver as a reference to create a basic framebuffer driver.<br />
<br />
Currently mainline struggles to boot due to weird issues while probing fixed regulators (?). It also fails to detect eMMC.<br />
<br />
Further work is being done here: https://github.com/smaeul/linux/commits/rk356x-ebc-dev. This has a complete device tree, with working eMMC. Pen input also works out of the box. Wi-Fi and BT work with firmware copied from the factory Android image.<br />
<br />
== How to boot mainline ==<br />
<br />
UART is currently REQUIRED for this to work! We depend on u-boot falling back to console. Once we have a prebuilt u-boot which will use extlinux by default, UART won't be needed anymore.<br />
<br />
=== Getting to a U-Boot prompt ===<br />
<br />
You can get to a U-Boot prompt by:<br />
<br />
# Holding Ctrl-C while the display panel initializes.<br />
# Wiping the "boot" partition.<br />
<br />
=== Using sysboot ===<br />
<br />
<code>extlinux.conf</code> should have the following contents:<br />
<br />
<pre><br />
timeout 10<br />
default MAINLINE<br />
menu title boot prev kernel<br />
<br />
label MAINLINE<br />
kernel /vmlinuz<br />
fdt /rk3566-pinenote.dtb<br />
initrd /initramfs<br />
append earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off PMOS_NO_OUTPUT_REDIRECT<br />
</pre><br />
<br />
At the u-boot console, run the following command to boot your mainline kernel:<br />
<br />
<pre><br />
sysboot ${devtype} ${devnum}:9 any ${scriptaddr} extlinux.conf<br />
</pre><br />
<br />
=== Booting with individual commands ===<br />
<br />
Booting with individual commands can be useful when you need to temporarily add some kernel command line arguments. Use these or similar commands at the U-Boot shell:<br />
<br />
load mmc 0:b ${kernel_addr_r} boot/Image<br />
load mmc 0:b ${fdt_addr_r} boot/rk3566-pinenote.dtb<br />
setenv bootargs ignore_loglevel root=/dev/mmcblk0p11 rootwait init=/bin/bash<br />
booti ${kernel_addr_r} - ${fdt_addr_r}</div>Smaeulhttps://wiki.pine64.org/index.php?title=RK3566_EBC_Reverse-Engineering&diff=12193RK3566 EBC Reverse-Engineering2022-01-08T04:51:26Z<p>Smaeul: /* Datasheets */ Add references to EBC TCON and waveform file formats</p>
<hr />
<div>The RK3566 SoC, used in the [[Quartz64]] SBC by PINE64, contains an eInk interface. This is referred to as <code>ebc</code> by Rockchip apparently.<br />
<br />
Unfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it.<br />
<br />
= Sources =<br />
<br />
== Downstream ==<br />
<br />
The ebc driver source is [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/gpu/drm/rockchip/ebc-dev available from the quartz-bsp repository].<br />
<br />
The files of interest are <code>ebc_dev_v8.S</code>, which implements a DRM (Direct Rendering Manager) driver for the eInk panel, and the waveform files in the <code>epdlut</code> subdirectory.<br />
<br />
There's also a simple driver for u-boot: [https://github.com/JeffyCN/rockchip_mirrors/tree/u-boot/drivers/video/rk_eink drivers/video/rk_eink at JeffyCN/rockchip_mirrors]<br />
<br />
These two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in "LUT mode": it writes the waveform LUT to registers in the TCON's MMIO space, and passes buffers of ''pixel'' data to the TCON. The Linux driver operates in "direct mode" uses the LUTs to compute waveforms in software, and passes buffers of ''waveform'' data to the TCON.<br />
<br />
Some reversing of the downstream Linux driver has been done here: https://github.com/Ralim/ebc-dev-reverse-engineering<br />
<br />
== Reimplementation ==<br />
<br />
A human-readable C reimplementation of the LUT and pixel data path [https://gitlab.com/smaeul/ebc-dev is available from smaeul here]. This provides everything needed to convert a framebuffer and a waveform data file into a series of "frames" for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver.<br />
<br />
== In-Development Driver ==<br />
<br />
[https://github.com/smaeul/linux/commits/rk356x-ebc-dev rk356x-ebc-dev] is the branch used for developing an upstreamable DRM driver based on mainline kernel sources. The driver currently functions well enough to get a virtual console and Xorg running, but it does not support features like multiple waveforms.<br />
<br />
= Documentation =<br />
<br />
== Datasheets ==<br />
<br />
=== EBC ===<br />
<br />
The EBC TCON is documented in part 2 of the RK356x TRM.<br />
<br />
=== TI TPS65185x ===<br />
<br />
This is the PMIC used to drive the e-Ink panel, for which the downstream sources also implement a driver.<br />
<br />
https://www.ti.com/lit/ds/symlink/tps65185.pdf<br />
<br />
=== Waveform ===<br />
<br />
The format of the waveform file is documented here:<br />
<br />
https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declaration.pdf<br />
<br />
https://www.waveshare.net/w/upload/archive/c/c4/20190611032540!E-paper-mode-declaration.pdf<br />
<br />
== Assembly Syntax and Semantics ==<br />
<br />
The Syntax is GNU Assembler (GAS) syntax. [https://modexp.wordpress.com/2018/10/30/arm64-assembly/ This modexp article] provides a good introduction to the syntax, calling convention, semantics and some often used instructions.<br />
<br />
The [https://developer.arm.com/documentation/ddi0487/gb/ ARM Architecture Reference Manual for ARMv8] should be used as reference for any instructions.<br />
<br />
At the very least, you should read up on the registers and calling convention used.<br />
<br />
= Various Findings =<br />
<br />
The driver isn't really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions.<br />
<br />
* It's technically a DRM subsystem driver, but doesn't really utilise what DRM provides at all.<br />
* It seems to register a new ioctl to set buffer attributes like width and height, despite DRM more than likely having a way for clients to tell a driver what size the framebuffer should be.<br />
* It directly interacts with the PMIC instead of going through regulators/hwmon.<br />
<br />
However, reverse engineering to know how it works provides a good baseline from which we can rewrite it in a more sensible manner.<br />
<br />
= Debug Information =<br />
<br />
Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage.<br />
<br />
== <code>.file ''file-number'' ''file-path''</code> ==<br />
<br />
Specifies a number to reference a file by, and its path. All following code until the next <code>.file</code> or <code>.loc</code> statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available.<br />
<br />
== <code>.loc ''file-number'' ''line-number'' 0</code> ==<br />
<br />
Specifies that the following code is generated from <code>''line-number''</code> stemming from file number <code>''file-number''</code>. See the <code>.file</code> directive for this file number to understand which source file it came from.<br />
<br />
== <code>.type ''function-name'', %function</code> ==<br />
<br />
This tells us that the following code belongs to function <code>''function-name''</code>. You'll usually see a <code>.cfi_startproc</code>, which signifies the start of the function code, until the matching <code>.cfi_endproc</code>.<br />
<br />
A quick grep for <code>%function</code> shows that we are dealing with 30 functions in this file.<br />
<br />
== <code>.type ''struct-name'', %object</code> ==<br />
<br />
This seems to signify a definition of a C struct named <code>''struct-name''</code>.<br />
<br />
A quick grep for <code>%object</code> shows that we are dealing with around 27 structs in this file.<br />
<br />
== <code>.Ldebug_info0:</code> ==<br />
<br />
'''TODO:''' This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures.<br />
<br />
= Finding Structs and Function Signatures =<br />
<br />
First, we'll need to assemble the file:<br />
<br />
<code>aarch64-linux-gnu-gcc -c -o ebc_dev_v8.o ebc_dev_v8.S</code><br />
<br />
This gives us a <code>ebc_dev_v8.o</code> which we can feed into analysis tools.<br />
<br />
For both of these, keep in mind that we're only interested in stuff from ebc_dev.c, or any other files for which we don't have the source. There's no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such.<br />
<br />
Also make sure that if you are looking up known struct accesses, that you use struct definitions from the BSP kernel, not from mainline. The kernel has no internal ABI for drivers!<br />
<br />
== Faster and Easier - Ghidra ==<br />
<br />
Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the "Data Type Manager" marked with an S icon. You'll also find functions in the symbol tree.<br />
<br />
== Slow and Painful - readelf/objdump ==<br />
<br />
Use this if you want to manually look up dwarf symbols for some reason.<br />
<br />
<code>readelf --debug-dump ebc_dev_v8.o</code><br />
<br />
This will produce a lot of output, but we're mainly concerned with the start of the dump. We'll find things like:<br />
<nowiki><br />
&lt;2&gt;&lt;101f8&gt;: Abbrev Number: 0<br />
&lt;1&gt;&lt;101f9&gt;: Abbrev Number: 79 (DW_TAG_subprogram)<br />
&lt;101fa&gt; DW_AT_name : (indirect string, offset: 0xa2b4): ebc_open<br />
&lt;101fe&gt; DW_AT_decl_file : 1<br />
&lt;101ff&gt; DW_AT_decl_line : 1377<br />
&lt;10201&gt; DW_AT_prototyped : 1<br />
&lt;10201&gt; DW_AT_type : &lt;0xc6&gt;<br />
&lt;10205&gt; DW_AT_low_pc : 0x0<br />
&lt;1020d&gt; DW_AT_high_pc : 0xc<br />
&lt;10215&gt; DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)<br />
&lt;10217&gt; DW_AT_GNU_all_call_sites: 1<br />
&lt;10217&gt; DW_AT_sibling : &lt;0x1023a&gt;<br />
&lt;2&gt;&lt;1021b&gt;: Abbrev Number: 88 (DW_TAG_formal_parameter)<br />
&lt;1021c&gt; DW_AT_name : (indirect string, offset: 0x1153): inode<br />
&lt;10220&gt; DW_AT_decl_file : 1<br />
&lt;10221&gt; DW_AT_decl_line : 1377<br />
&lt;10223&gt; DW_AT_type : &lt;0x1c54&gt;<br />
&lt;10227&gt; DW_AT_location : 0xd63 (location list)<br />
&lt;2&gt;&lt;1022b&gt;: Abbrev Number: 106 (DW_TAG_formal_parameter)<br />
&lt;1022c&gt; DW_AT_name : (indirect string, offset: 0x8b06): file<br />
&lt;10230&gt; DW_AT_decl_file : 1<br />
&lt;10231&gt; DW_AT_decl_line : 1377<br />
&lt;10233&gt; DW_AT_type : &lt;0x551f&gt;<br />
&lt;10237&gt; DW_AT_location : 1 byte block: 51 (DW_OP_reg1 (x1))</nowiki><br />
<br />
This essentially tells us the full function signature of <code>ebc_open</code>:<br />
<br />
<code>DW_TAG_subprogram</code> tells us of a function, with <code>DW_AT_name</code> letting us know that this is <code>ebc_open</code>. <code>DW_AT_type</code> of <code>0xc6</code> let's us know, once we jump to <code>&lt;c6&gt;</code>, that this function's return type is a signed 32-bit integer.<br />
<br />
The <code>DW_TAG_formal_parameter</code> that follow tell us of each of the parameter the function takes. The first one is called <code>inode</code> and is of type <code>0x1c54</code>. Referencing what this type is, we find:<br />
<br />
<nowiki><br />
<1><1c54>: Abbrev Number: 7 (DW_TAG_pointer_type)<br />
<1c55> DW_AT_byte_size : 8<br />
<1c56> DW_AT_type : <0x1970></nowiki><br />
<br />
which in of itself goes on to reference <code>0x1970</code>, and looking this one up, we'll find a struct definition:<br />
<br />
<nowiki><br />
<1><1970>: Abbrev Number: 26 (DW_TAG_structure_type)<br />
<1971> DW_AT_name : (indirect string, offset: 0x1153): inode<br />
<1975> DW_AT_byte_size : 672<br />
<1977> DW_AT_decl_file : 31<br />
<1978> DW_AT_decl_line : 611<br />
<197a> DW_AT_sibling : <0x1c4f><br />
<2><197e>: Abbrev Number: 27 (DW_TAG_member)<br />
<197f> DW_AT_name : (indirect string, offset: 0x7d00): i_mode<br />
[etc etc...]</nowiki><br />
<br />
= Reverse-Engineered Stuff =<br />
<br />
== Structs ==<br />
<br />
=== ebc_info ===<br />
<br />
<!-- I don't know why mediawiki scuffs the formatting here --><br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== ebc ===<br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== rkf_waveform ===<br />
<br />
Note: all known waveform data files are the "PVI" variant, not the "RKF" variant.<br />
<br />
<source lang="c"><br />
struct rkf_waveform {<br />
int length,<br />
char[16] format,<br />
char[16] version,<br />
char[16] timeandday,<br />
char[16] panel_name,<br />
char[16] panel_info,<br />
char[64] full_version,<br />
char[64] reset_temp_list,<br />
char[64] gc16_temp_list,<br />
char[64] gl16_temp_list,<br />
char[64] glr16_temp_list,<br />
char[64] gld16_temp_list,<br />
char[64] du_temp_list,<br />
char[64] a2_temp_list,<br />
uint[64] reset_list,<br />
uint[64] gc16_list,<br />
uint[64] gl16_list,<br />
uint[64] glr16_list,<br />
uint[64] gld16_list,<br />
uint[64] du_list,<br />
uint[64] a2_list<br />
}<br />
</source><br />
<br />
== Enums ==<br />
<br />
=== rkf_waveform_type ===<br />
<source lang="c"><br />
enum rkf_waveform_type {<br />
RKF_WF_RESET = 0,<br />
RKF_WF_DU = 1,<br />
RKF_WF_GC16 = 2,<br />
RKF_WF_GL16 = 3,<br />
RKF_WF_GLR16 = 4,<br />
RKF_WF_GLD16 = 5,<br />
RKF_WF_A2 = 6<br />
}<br />
</source><br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=RK3566_EBC_Reverse-Engineering&diff=12192RK3566 EBC Reverse-Engineering2022-01-08T04:48:34Z<p>Smaeul: /* In-Development Driver */ Update info about mainline driver</p>
<hr />
<div>The RK3566 SoC, used in the [[Quartz64]] SBC by PINE64, contains an eInk interface. This is referred to as <code>ebc</code> by Rockchip apparently.<br />
<br />
Unfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it.<br />
<br />
= Sources =<br />
<br />
== Downstream ==<br />
<br />
The ebc driver source is [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/gpu/drm/rockchip/ebc-dev available from the quartz-bsp repository].<br />
<br />
The files of interest are <code>ebc_dev_v8.S</code>, which implements a DRM (Direct Rendering Manager) driver for the eInk panel, and the waveform files in the <code>epdlut</code> subdirectory.<br />
<br />
There's also a simple driver for u-boot: [https://github.com/JeffyCN/rockchip_mirrors/tree/u-boot/drivers/video/rk_eink drivers/video/rk_eink at JeffyCN/rockchip_mirrors]<br />
<br />
These two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in "LUT mode": it writes the waveform LUT to registers in the TCON's MMIO space, and passes buffers of ''pixel'' data to the TCON. The Linux driver operates in "direct mode" uses the LUTs to compute waveforms in software, and passes buffers of ''waveform'' data to the TCON.<br />
<br />
Some reversing of the downstream Linux driver has been done here: https://github.com/Ralim/ebc-dev-reverse-engineering<br />
<br />
== Reimplementation ==<br />
<br />
A human-readable C reimplementation of the LUT and pixel data path [https://gitlab.com/smaeul/ebc-dev is available from smaeul here]. This provides everything needed to convert a framebuffer and a waveform data file into a series of "frames" for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver.<br />
<br />
== In-Development Driver ==<br />
<br />
[https://github.com/smaeul/linux/commits/rk356x-ebc-dev rk356x-ebc-dev] is the branch used for developing an upstreamable DRM driver based on mainline kernel sources. The driver currently functions well enough to get a virtual console and Xorg running, but it does not support features like multiple waveforms.<br />
<br />
= Documentation =<br />
<br />
== Datasheets ==<br />
<br />
=== TI TPS65185x ===<br />
<br />
This is the PMIC used to drive the e-Ink panel, for which the downstream sources also implement a driver.<br />
<br />
https://www.ti.com/lit/ds/symlink/tps65185.pdf<br />
<br />
== Assembly Syntax and Semantics ==<br />
<br />
The Syntax is GNU Assembler (GAS) syntax. [https://modexp.wordpress.com/2018/10/30/arm64-assembly/ This modexp article] provides a good introduction to the syntax, calling convention, semantics and some often used instructions.<br />
<br />
The [https://developer.arm.com/documentation/ddi0487/gb/ ARM Architecture Reference Manual for ARMv8] should be used as reference for any instructions.<br />
<br />
At the very least, you should read up on the registers and calling convention used.<br />
<br />
= Various Findings =<br />
<br />
The driver isn't really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions.<br />
<br />
* It's technically a DRM subsystem driver, but doesn't really utilise what DRM provides at all.<br />
* It seems to register a new ioctl to set buffer attributes like width and height, despite DRM more than likely having a way for clients to tell a driver what size the framebuffer should be.<br />
* It directly interacts with the PMIC instead of going through regulators/hwmon.<br />
<br />
However, reverse engineering to know how it works provides a good baseline from which we can rewrite it in a more sensible manner.<br />
<br />
= Debug Information =<br />
<br />
Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage.<br />
<br />
== <code>.file ''file-number'' ''file-path''</code> ==<br />
<br />
Specifies a number to reference a file by, and its path. All following code until the next <code>.file</code> or <code>.loc</code> statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available.<br />
<br />
== <code>.loc ''file-number'' ''line-number'' 0</code> ==<br />
<br />
Specifies that the following code is generated from <code>''line-number''</code> stemming from file number <code>''file-number''</code>. See the <code>.file</code> directive for this file number to understand which source file it came from.<br />
<br />
== <code>.type ''function-name'', %function</code> ==<br />
<br />
This tells us that the following code belongs to function <code>''function-name''</code>. You'll usually see a <code>.cfi_startproc</code>, which signifies the start of the function code, until the matching <code>.cfi_endproc</code>.<br />
<br />
A quick grep for <code>%function</code> shows that we are dealing with 30 functions in this file.<br />
<br />
== <code>.type ''struct-name'', %object</code> ==<br />
<br />
This seems to signify a definition of a C struct named <code>''struct-name''</code>.<br />
<br />
A quick grep for <code>%object</code> shows that we are dealing with around 27 structs in this file.<br />
<br />
== <code>.Ldebug_info0:</code> ==<br />
<br />
'''TODO:''' This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures.<br />
<br />
= Finding Structs and Function Signatures =<br />
<br />
First, we'll need to assemble the file:<br />
<br />
<code>aarch64-linux-gnu-gcc -c -o ebc_dev_v8.o ebc_dev_v8.S</code><br />
<br />
This gives us a <code>ebc_dev_v8.o</code> which we can feed into analysis tools.<br />
<br />
For both of these, keep in mind that we're only interested in stuff from ebc_dev.c, or any other files for which we don't have the source. There's no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such.<br />
<br />
Also make sure that if you are looking up known struct accesses, that you use struct definitions from the BSP kernel, not from mainline. The kernel has no internal ABI for drivers!<br />
<br />
== Faster and Easier - Ghidra ==<br />
<br />
Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the "Data Type Manager" marked with an S icon. You'll also find functions in the symbol tree.<br />
<br />
== Slow and Painful - readelf/objdump ==<br />
<br />
Use this if you want to manually look up dwarf symbols for some reason.<br />
<br />
<code>readelf --debug-dump ebc_dev_v8.o</code><br />
<br />
This will produce a lot of output, but we're mainly concerned with the start of the dump. We'll find things like:<br />
<nowiki><br />
&lt;2&gt;&lt;101f8&gt;: Abbrev Number: 0<br />
&lt;1&gt;&lt;101f9&gt;: Abbrev Number: 79 (DW_TAG_subprogram)<br />
&lt;101fa&gt; DW_AT_name : (indirect string, offset: 0xa2b4): ebc_open<br />
&lt;101fe&gt; DW_AT_decl_file : 1<br />
&lt;101ff&gt; DW_AT_decl_line : 1377<br />
&lt;10201&gt; DW_AT_prototyped : 1<br />
&lt;10201&gt; DW_AT_type : &lt;0xc6&gt;<br />
&lt;10205&gt; DW_AT_low_pc : 0x0<br />
&lt;1020d&gt; DW_AT_high_pc : 0xc<br />
&lt;10215&gt; DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)<br />
&lt;10217&gt; DW_AT_GNU_all_call_sites: 1<br />
&lt;10217&gt; DW_AT_sibling : &lt;0x1023a&gt;<br />
&lt;2&gt;&lt;1021b&gt;: Abbrev Number: 88 (DW_TAG_formal_parameter)<br />
&lt;1021c&gt; DW_AT_name : (indirect string, offset: 0x1153): inode<br />
&lt;10220&gt; DW_AT_decl_file : 1<br />
&lt;10221&gt; DW_AT_decl_line : 1377<br />
&lt;10223&gt; DW_AT_type : &lt;0x1c54&gt;<br />
&lt;10227&gt; DW_AT_location : 0xd63 (location list)<br />
&lt;2&gt;&lt;1022b&gt;: Abbrev Number: 106 (DW_TAG_formal_parameter)<br />
&lt;1022c&gt; DW_AT_name : (indirect string, offset: 0x8b06): file<br />
&lt;10230&gt; DW_AT_decl_file : 1<br />
&lt;10231&gt; DW_AT_decl_line : 1377<br />
&lt;10233&gt; DW_AT_type : &lt;0x551f&gt;<br />
&lt;10237&gt; DW_AT_location : 1 byte block: 51 (DW_OP_reg1 (x1))</nowiki><br />
<br />
This essentially tells us the full function signature of <code>ebc_open</code>:<br />
<br />
<code>DW_TAG_subprogram</code> tells us of a function, with <code>DW_AT_name</code> letting us know that this is <code>ebc_open</code>. <code>DW_AT_type</code> of <code>0xc6</code> let's us know, once we jump to <code>&lt;c6&gt;</code>, that this function's return type is a signed 32-bit integer.<br />
<br />
The <code>DW_TAG_formal_parameter</code> that follow tell us of each of the parameter the function takes. The first one is called <code>inode</code> and is of type <code>0x1c54</code>. Referencing what this type is, we find:<br />
<br />
<nowiki><br />
<1><1c54>: Abbrev Number: 7 (DW_TAG_pointer_type)<br />
<1c55> DW_AT_byte_size : 8<br />
<1c56> DW_AT_type : <0x1970></nowiki><br />
<br />
which in of itself goes on to reference <code>0x1970</code>, and looking this one up, we'll find a struct definition:<br />
<br />
<nowiki><br />
<1><1970>: Abbrev Number: 26 (DW_TAG_structure_type)<br />
<1971> DW_AT_name : (indirect string, offset: 0x1153): inode<br />
<1975> DW_AT_byte_size : 672<br />
<1977> DW_AT_decl_file : 31<br />
<1978> DW_AT_decl_line : 611<br />
<197a> DW_AT_sibling : <0x1c4f><br />
<2><197e>: Abbrev Number: 27 (DW_TAG_member)<br />
<197f> DW_AT_name : (indirect string, offset: 0x7d00): i_mode<br />
[etc etc...]</nowiki><br />
<br />
= Reverse-Engineered Stuff =<br />
<br />
== Structs ==<br />
<br />
=== ebc_info ===<br />
<br />
<!-- I don't know why mediawiki scuffs the formatting here --><br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== ebc ===<br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== rkf_waveform ===<br />
<br />
Note: all known waveform data files are the "PVI" variant, not the "RKF" variant.<br />
<br />
<source lang="c"><br />
struct rkf_waveform {<br />
int length,<br />
char[16] format,<br />
char[16] version,<br />
char[16] timeandday,<br />
char[16] panel_name,<br />
char[16] panel_info,<br />
char[64] full_version,<br />
char[64] reset_temp_list,<br />
char[64] gc16_temp_list,<br />
char[64] gl16_temp_list,<br />
char[64] glr16_temp_list,<br />
char[64] gld16_temp_list,<br />
char[64] du_temp_list,<br />
char[64] a2_temp_list,<br />
uint[64] reset_list,<br />
uint[64] gc16_list,<br />
uint[64] gl16_list,<br />
uint[64] glr16_list,<br />
uint[64] gld16_list,<br />
uint[64] du_list,<br />
uint[64] a2_list<br />
}<br />
</source><br />
<br />
== Enums ==<br />
<br />
=== rkf_waveform_type ===<br />
<source lang="c"><br />
enum rkf_waveform_type {<br />
RKF_WF_RESET = 0,<br />
RKF_WF_DU = 1,<br />
RKF_WF_GC16 = 2,<br />
RKF_WF_GL16 = 3,<br />
RKF_WF_GLR16 = 4,<br />
RKF_WF_GLD16 = 5,<br />
RKF_WF_A2 = 6<br />
}<br />
</source><br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=Quartz64_Development&diff=12191Quartz64 Development2022-01-08T04:46:21Z<p>Smaeul: Update PineNote and EBC status</p>
<hr />
<div>This page documents the current status of software support for the [[Quartz64]] single-board computer, and provides links to resources to help prospective contributors get started. Information is kept current on a best-effort basis as various patches get accepted into the kernel.<br />
<br />
== Overview ==<br />
<br />
=== Upstreaming Status ===<br />
<br />
{| class="wikitable plainrowheaders" border="1"<br />
! scope="col" | Function<br />
! scope="col" colspan="2" | Status<br />
! scope="col" | Component<br />
! scope="col" | Notes<br />
! scope="col" | Applies To<br />
|-<br />
! scope="row" rowspan="2" | Video Output<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=598177]</sup><br />
| <code>rockchipdrm/VOP2</code><br />
|<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>rockchip-edpphy-naneng</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/phy/rockchip/phy-rockchip-naneng-edp.c] Coordinate any porting with Rockchip first<br />
|-<br />
! scope="row" | 3D Acceleration <br />
| style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=586441]</sup><br />
| style="background:PaleGreen; text-align:center;"|Upstream Mesa<br />
| <code>panfrost</code><br />
| GPU is basically already supported in mainline but needs some device tree changes for this particular SoC<br />
|-<br />
! scope="row" | Video Decode <br />
| style="background:LightYellow; text-align:center;"|Linux Staging<br />
| style="background:#F99; text-align:center;"|Not in ffmpeg<sup>[https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898]</sup><br />
| <code>hantro-vpu</code>, using <code>v4l2-requests</code><br />
| Necessary device tree changes [https://patchwork.kernel.org/project/linux-rockchip/patch/20210719225806.26680-1-ezequiel@collabora.com/ in review]<br />
|-<br />
! scope="row" rowspan="3" | Audio <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-i2s-tdm</code><br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43b058698f723e3c2087af7069c0da082a3ecbe1]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-spdif</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dac825b6a6bdca41347e25f07354ad94fdc97445]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk817-codec</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d6a04da9b25b9a7cf2cac5f5079e3296d3bee0f]</sup>.<br />
| Quartz64 Model A/B<br />
|-<br />
! scope="row" | u-boot<br />
| colspan="2" style="background:#F99; text-align:center;"|Waiting on ATF sources<br />
|<br />
|<br />
|-<br />
! scope="row" rowspan="4" | Device Tree<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| Quartz64 Model A<br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b33a22a1e7c4248608e533fc4fa524258b3fae84]</sup><br />
| Quartz64 Model A<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| Quartz64 Model B<br />
|<br />
| Quartz64 Model B<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| SOQuartz<br />
|<br />
| SOQuartz<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| PineNote<br />
| [[User:smaeul]] wrote a device tree using mainline bindings [https://github.com/smaeul/linux/commits/rk356x-ebc-dev here].<br />
|-<br />
! scope="row" rowspan="2"| Gigabit Ethernet<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3566-gmac</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb3d6b1c1957e88bfc5e77a4557f7e6ba761fe3]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>yt8511-phy</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48e8c6f1612b3d2dccaea2285231def830cc5b8e]</sup><br />
|-<br />
! scope="row" | IOMMU<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-iommu</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c55356c534aa651ccc3053ef2d5d8d810adacf5f]</sup><br />
|-<br />
! scope="row" | GPIO<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>gpio-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936ee2675eee1faca0dcdfa79165c7990422e0fc]</sup><br />
|-<br />
! scope="row" | pinctrl<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
|<br />
|<br />
|-<br />
! scope="row" | Thermal Regulation<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-thermal</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4b14c055a6f644cbeb1156ba24647e92fe51ec69]</sup><br />
|-<br />
! scope="row" | PCIe<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>pcie-dw-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e898eb8df4e34c7b129452444eb7cef68a11f43]</sup><br />
|-<br />
! scope="row" | Power Management<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-pm-domains</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1782c87b44a0b1a527f01a6a184677c58ccbf9c7]</sup><br />
|-<br />
! scope="row" | Voltage Control<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3568-pmu-io-voltage-domain</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28b05a64e47cbceebb8a5f3f643033148d5c06c3]</sup><br />
|-<br />
! scope="row" | SPI <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>spi-rockchip</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d74d99229f4d48f42d674f7a8a1137179efd67ac]</sup>. Necessary device tree changes [https://patchwork.kernel.org/project/linux-rockchip/list/?series=586691 in review].<br />
|-<br />
! scope="row" | Battery<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=536233]</sup><br />
| <code>rk817-charger</code><br />
| In the BSP tree this is handled by [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_battery.c rk817_battery.c] and [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_charger.c rk817_charger.c].<br />
| Quartz64 Model A<br />
|-<br />
! scope="row" | Microphone<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-saradc</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7786da3b5ae167c17f35e22ba35e06006338c2f6]</sup>. Headphone jack mic seems to connect to <code>SARADC_VIN2_HP_HOOK</code>, so I'm pretty sure that the dtsi and driver changes are needed for that mic to work<br />
|-<br />
! scope="row" | USB 2.0<br />
| colspan="2" style="background:LightYellow; text-align:center;"|linux-next<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git/commit/?h=next&id=42b559727a45d79c811f493515eb9b7e56016421]</sup><br />
| <code>rockchip-usb2phy</code><br />
|<br />
|-<br />
! scope="row" | e-Ink<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| <code>rockchip-ebc</code><br />
| A DRM driver is available [https://github.com/smaeul/linux/commits/rk356x-ebc-dev here]; also see [[RK3566 EBC Reverse-Engineering]]<br />
|-<br />
! scope="row" | Combo PHY<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=601993]</sup><br />
| <code>naneng-combphy</code><br />
|<br />
|-<br />
! scope="row" | RGA<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs fixing<br />
| <code>rockchip-rga</code><br />
| [[User:CounterPillow]] experimentally enabled it<sup>[https://gist.github.com/CounterPillow/6bea809f15ada7ddd3a3d7a4994fdc4e]</sup> in the device tree and ran gstreamer's v4l2convert through it to test, resulting in a completely garbled output.<br />
|-<br />
! scope="row" | Fan Controller<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>emc2301</code><br />
| Previous attempts at mainlining: [http://lkml.iu.edu/hypermail/linux/kernel/1306.1/02473.html] and [https://lore.kernel.org/all/20200928104326.40386-1-biwen.li@oss.nxp.com/]. Latest iteration: [https://gitlab.traverse.com.au/ls1088firmware/traverse-sensors/-/commit/1cdec49171ebafcf32b347e7701224144de8620b]<br />
| SOQuartz Blade<br />
|-<br />
! scope="row" | CIF (CSI Camera)<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>video_rkcif</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/media/platform/rockchip/cif]<br />
|<br />
|}<br />
<br />
== Current Status ==<br />
<br />
The following sections give an overview over the current status of different parts of the board. Some parts are waiting on a driver to be written or ported, others only need various adjustments.<br />
<br />
According to pgwipeout, I/O device performance is within expected ranges now.<br />
<br />
=== Working ===<br />
<br />
* eMMC<br />
* SDMMC0 (SD cards)<br />
* GMAC (Gigabit Ethernet)<br />
* USB 2.0<br />
* SATA 2<br />
* SATA 3<br />
* UART<br />
** UART 0 (Pi-bus)<br />
** UART 1 (Bluetooth)<br />
** UART 2 (Pi-bus, debug)<br />
* Video Decode<br />
** VP8<br />
* Battery<br />
* GPU<br />
* Audio<br />
** Analog audio works<br />
** SPDIF works<br />
** HDMI works<br />
* SPI &mdash; works, user needs to modify device tree to add devices<br />
* I<sup>2</sup>C &mdash; works, user needs to modify device tree to add devices<br />
<br />
=== Partially Working ===<br />
<br />
* PCI-Express Controller &mdash; everything but devices that need cache coherency (e.g. dGPUs) should work<br />
** [[User:CounterPillow]] noticed some weirdness with NVMe devices disconnecting during heavy write operations, likely down due to power draw on one of the rails as the same sustained bandwidth could be achieved with a different PCIe device with no issue.<br />
* SDMMC1 (Wi-Fi) &mdash; AP6256 working, BL602 needs some work to make it flash firmware<br />
* [https://developer.arm.com/architectures/system-architectures/system-components/arm-generic-interrupt-controller GIC] &mdash; needs errata published by Rockchip to get upstream to add device-specific workarounds<sup>[https://lore.kernel.org/linux-rockchip/CAMdYzYrQ5f-mv_VmTq_CRf9tR=j3mwRpKHNLmPFgCF9whsGFRw@mail.gmail.com/]</sup><br />
* Video Output &mdash; only at 1920x1080p60 and nothing else, very buggy and rough around more than just the edges<br />
<br />
=== Confirmed Broken ===<br />
<br />
* USB 3.0 &mdash; only works with very short cables and depends on the device. This is due to a hardware design issue relating to the coupling capacitors needed for SATA, which shares the same lines as USB 3.0.<br />
** Hardware design changes have been suggested to engineers, it's in their hands now.<br />
* Module autoloading for the Ethernet PHY. The Motorcomm PHY does not have a vendor ID written into the appropriate hardware block, so there is no canonical way to identify the device.<br />
<br />
=== Needs Testing ===<br />
<br />
* E-Paper &mdash; needs EBC driver<br />
* Microphone Input<br />
* CSI &mdash; needs CIF driver<br />
<br />
== TODO ==<br />
<br />
=== ebc-dev Reverse Engineering and Development ===<br />
<br />
The [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/tree/rk356x-ebc-dev driver for the eInk panel] needs to both be reverse engineered and then rewritten as C. In its current form, it is mostly an assembly dump produced by gcc with debug symbols. See [[RK3566 EBC Reverse-Engineering]] for details.<br />
<br />
=== Investigate MCU ===<br />
<br />
The RK3566 comes with an integrated RISC-V microcontroller (MCU). It communicates with the A55 host through the Mailbox system driven by the rockchip-mailbox driver. Since this MCU would be quite useful for things such as low power standby mode, investigating how it can be turned on and have firmware flashed to it should greatly enhance the power saving features of the PineNote.<br />
<br />
=== Mainline U-Boot Work ===<br />
<br />
Currently, mainline U-Boot does not have support for the RK3566 SoC used on the Quartz64. That's why we currently use the "downstream" Rockchip U-Boot, which is based on an old version of U-Boot and contains vendor specific patches that have not undergone the same level of code review as they'd have done had they been submitted upstream.<br />
<br />
While the lack of ATF sources means that using mainline U-Boot would still require the use of Rockchip provided binaries for the firmware, the mainline U-Boot works needs to be done eventually anyway, and even with Rockchip blobs, a more modern version of U-Boot will be much nicer to use.<br />
<br />
Someone needs to get on the task of investigating what minimally needs to be ported to get the board booting with mainline U-Boot, port those changes, and submit them for review.<br />
<br />
==== Things that need to be done ====<br />
<br />
This list is non-exhaustive as we don't exactly know how much is missing<br />
<br />
* Do the <code>rk3568.dtsi</code> refactoring into <code>rk356x.dtsi</code>/<code>rk3568.dtsi</code>/<code>rk3566.dtsi</code> that the kernel did, probably just port the kernel dtsi files for this<br />
* Bring the kernel's Quartz64 DTS into the tree<br />
* Write a <code>quartz64-rk3566_defconfig</code> based on <code>evb-rk3568_defconfig</code><br />
<br />
Stretch Goals:<br />
<br />
* Port the Naneng Combo PHY driver to u-boot so we can SATA, USB 3 and PCIe boot<br />
* Look into SPI<br />
* Port the Motorcomm PHY driver to u-boot for networking?<br />
* Port a basic VOP2 driver to get a framebuffer from u-boot<br />
<br />
==== List of Useful Resources for this Task ====<br />
* Downstream Rockchip U-Boot repository with Quartz64 specific patches: https://gitlab.com/pgwipeout/u-boot-rockchip/-/tree/quartz64<br />
* Mainline Rockchip custodian U-Boot repository: https://source.denx.de/u-boot/custodians/u-boot-rockchip<br />
* U-Boot Mailing List: https://lists.denx.de/listinfo/u-boot<br />
<br />
== Linux Kernel Config Options ==<br />
<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_I2S_TDM</code><br />
** for Analog and (in the future) HDMI audio<br />
* <code>CONFIG_SND_SOC_RK817</code><br />
** for Analog audio on the Model A<br />
* <code>CONFIG_STMMAC_ETH</code><br />
** Ethernet<br />
* <code>CONFIG_DWMAC_ROCKCHIP</code><br />
** Ethernet<br />
* <code>CONFIG_MOTORCOMM_PHY</code><br />
** Ethernet, set this one to Y, m won't work out of the box as module autoloading does not work for this specific PHY (the vendor ID is zeroed out), alternatively tell users in board-specific setup instructions to force loading the <code>motorcomm</code> module if you set it to m.<br />
* <code>CONFIG_MMC_DW</code><br />
** MMC/SD<br />
* <code>CONFIG_MMC_DW_ROCKCHIP</code><br />
** MMC/SD<br />
* <code>CONFIG_PCIE_ROCKCHIP_DW_HOST</code><br />
** PCIe<br />
* <code>CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY</code><br />
** PHY for PCIe/SATA/USB3, not yet upstream<br />
* <code>CONFIG_DRM_PANFROST</code><br />
** GPU<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_SPDIF</code><br />
** SPDIF audio<br />
* <code>CONFIG_ROCKCHIP_DW_HDMI</code><br />
** HDMI PHY<br />
* <code>CONFIG_ROCKCHIP_VOP2</code><br />
** Video output, not yet upstream<br />
* <code>CONFIG_ARCH_ROCKCHIP</code><br />
** General SoC support<br />
* <code>CONFIG_ROCKCHIP_PHY</code><br />
** General SoC support<br />
* <code>CONFIG_PHY_ROCKCHIP_INNO_USB2</code><br />
** USB 2<br />
* <code>CONFIG_RTC_DRV_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_COMMON_CLK_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_MFD_RK808</code><br />
** Various things relating to the RK817 chip<br />
* <code>CONFIG_REGULATOR_RK808</code><br />
** Voltage regulators<br />
* <code>CONFIG_ROCKCHIP_PM_DOMAINS</code><br />
** Power management domains<br />
* <code>CONFIG_GPIO_ROCKCHIP</code><br />
** GPIO support<br />
* <code>CONFIG_PINCTRL_ROCKCHIP</code><br />
** GPIO and general SoC support<br />
* <code>CONFIG_PWM_ROCKCHIP</code><br />
** PWM support<br />
* <code>CONFIG_ROCKCHIP_IOMMU</code><br />
** IOMMU support<br />
* <code>CONFIG_ROCKCHIP_MBOX</code><br />
** Mailbox support (for communication with MCU)<br />
* <code>CONFIG_ROCKCHIP_SARADC</code><br />
** Analog-to-digital conversion support, for e.g. microphones<br />
* <code>CONFIG_ROCKCHIP_THERMAL</code><br />
** Temperature sensor and thermal throttling support<br />
* <code>CONFIG_SPI_ROCKCHIP</code><br />
** SPI support<br />
* <code>CONFIG_VIDEO_HANTRO_ROCKCHIP</code><br />
** Hardware video decoder support<br />
* <code>CONFIG_ROCKCHIP_IODOMAIN</code><br />
** General SoC support so your I/O pins have the right voltage<br />
* <code>CONFIG_COMMON_CLK_ROCKCHIP</code><br />
** Common clock support<br />
<br />
== Resources ==<br />
=== Repositories ===<br />
<br />
* pgwipeout's kernel tree<br />
** https://gitlab.com/pgwipeout/linux-next/-/tree/quartz64-v5.15-rc1<br />
* BSP based development effort for SPL/U-Boot and Linux<br />
** https://gitlab.com/pine64-org/quartz-bsp<br />
* Image CI pipeline aimed at developers<br />
** https://gitlab.com/pgwipeout/quartz64_ci/<br />
* Rockchip U-Boot<br />
** https://github.com/rockchip-linux/u-boot<br />
* Downstream rockchip-linux kernel tree<br />
** https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux<br />
* Tianocore EDK II port for UEFI on Quartz64<br />
** https://github.com/jaredmcneill/quartz64_uefi<br />
* Mainline U-Boot Port by pgwipeout<br />
** https://gitlab.com/pgwipeout/u-boot-quartz64<br />
<br />
=== Other ===<br />
<br />
* Rockchip-SoC Patchwork Page<br />
** https://patchwork.kernel.org/project/linux-rockchip/list/<br />
* Rockchip Kernel Mailing List Archive<br />
** https://lore.kernel.org/linux-rockchip/<br />
<br />
== Board/SoC Documentation ==<br />
=== Booting ===<br />
==== Boot Order ====<br />
The RK3566 boot ROM will search for a valid ID BLOCK in the following order on the support boot media:<br />
<br />
* SPI NOR flash<br />
* SPI NAND flash<br />
* SD-Card<br />
* eMMC<br />
<br />
... if this fails, the boot ROM will initialize the USB0 port and wait for a connection from the Rockchip<br />
flash/boot tools.<br />
<br />
==== Bootloader Flashing ====<br />
<br />
As per pgwipeout's [https://gitlab.com/pine64-org/quartz-bsp/u-boot/-/commit/12d102b86813378af08b086f3b9c13ed8010754c commit message]:<br />
* Make a partition named <code>uboot</code> as partition number 1 at 8 MiB to 16 MiB<br />
* <code>dd if=idblock.bin of=/dev/''<mmc/sd>'' seek=64</code><br />
* <code>dd if=uboot.img of=/dev/''<mmc/sd>''1</code><br />
<br />
==== BSP Image Layout ====<br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=Quartz64_Development&diff=11866Quartz64 Development2021-11-26T00:06:06Z<p>Smaeul: Add pinenote device tree</p>
<hr />
<div>This page documents the current status of software support for the [[Quartz64]] single-board computer, and provides links to resources to help prospective contributors get started. Information is kept current on a best-effort basis as various patches get accepted into the kernel.<br />
<br />
== Overview ==<br />
<br />
=== Upstreaming Status ===<br />
<br />
{| class="wikitable plainrowheaders" border="1"<br />
! scope="col" | Function<br />
! scope="col" colspan="2" | Status<br />
! scope="col" | Component<br />
! scope="col" | Notes<br />
! scope="col" | Applies To<br />
|-<br />
! scope="row" | Video Output<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=581709]</sup><br />
| <code>rockchipdrm/VOP-v2</code><br />
| Also needs the DTS changes by mriesch<sup>[https://patchwork.kernel.org/project/linux-rockchip/patch/20211117154429.2274443-1-michael.riesch@wolfvision.net/]</sup><br />
|-<br />
! scope="row" | 3D Acceleration <br />
| style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=526661]</sup><br />
| style="background:PaleGreen; text-align:center;"|Upstream Mesa<br />
| <code>panfrost</code><br />
| GPU is basically already supported in mainline but needs some device tree changes for this particular SoC<br />
|-<br />
! scope="row" | Video Decode <br />
| style="background:LightYellow; text-align:center;"|Linux Staging<br />
| style="background:#F99; text-align:center;"|Not in ffmpeg<sup>[https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2898]</sup><br />
| <code>hantro-vpu</code>, using <code>v4l2-requests</code><br />
| Necessary device tree changes [https://patchwork.kernel.org/project/linux-rockchip/patch/20210719225806.26680-1-ezequiel@collabora.com/ in review]<br />
|-<br />
! scope="row" rowspan="3" | Audio <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-i2s-tdm</code><br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43b058698f723e3c2087af7069c0da082a3ecbe1]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-spdif</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dac825b6a6bdca41347e25f07354ad94fdc97445]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk817-codec</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0d6a04da9b25b9a7cf2cac5f5079e3296d3bee0f]</sup>.<br />
| Quartz64 Model A/B<br />
|-<br />
! scope="row" | u-boot<br />
| colspan="2" style="background:#F99; text-align:center;"|Waiting on ATF sources<br />
|<br />
|<br />
|-<br />
! scope="row" rowspan="4" | Device Tree<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| Quartz64 Model A<br />
| As of 5.16<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b33a22a1e7c4248608e533fc4fa524258b3fae84]</sup><br />
| Quartz64 Model A<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| Quartz64 Model B<br />
|<br />
| Quartz64 Model B<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| SOQuartz<br />
|<br />
| SOQuartz<br />
|-<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs submitting<br />
| PineNote<br />
| [[User:smaeul]] wrote a device tree using mainline bindings [https://github.com/smaeul/linux/commit/03b7cfe39a119ecf50a23c67f0e4dc1cae24b370 here].<br />
|-<br />
! scope="row" rowspan="2"| Gigabit Ethernet<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3566-gmac</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb3d6b1c1957e88bfc5e77a4557f7e6ba761fe3]</sup><br />
|-<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>yt8511-phy</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48e8c6f1612b3d2dccaea2285231def830cc5b8e]</sup><br />
|-<br />
! scope="row" | IOMMU<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-iommu</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c55356c534aa651ccc3053ef2d5d8d810adacf5f]</sup><br />
|-<br />
! scope="row" | GPIO<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>gpio-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=936ee2675eee1faca0dcdfa79165c7990422e0fc]</sup><br />
|-<br />
! scope="row" | pinctrl<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
|<br />
|<br />
|-<br />
! scope="row" | Thermal Regulation<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-thermal</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4b14c055a6f644cbeb1156ba24647e92fe51ec69]</sup><br />
|-<br />
! scope="row" | PCIe<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>pcie-dw-rockchip</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e898eb8df4e34c7b129452444eb7cef68a11f43]</sup><br />
|-<br />
! scope="row" | Power Management<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-pm-domains</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1782c87b44a0b1a527f01a6a184677c58ccbf9c7]</sup><br />
|-<br />
! scope="row" | Voltage Control<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rk3568-pmu-io-voltage-domain</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28b05a64e47cbceebb8a5f3f643033148d5c06c3]</sup><br />
|-<br />
! scope="row" | SPI <br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>spi-rockchip</code><br />
| As of 5.14<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d74d99229f4d48f42d674f7a8a1137179efd67ac]</sup><br />
|-<br />
! scope="row" | Battery<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=536233]</sup><br />
| <code>rk817-charger</code><br />
| In the BSP tree this is handled by [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_battery.c rk817_battery.c] and [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/blob/quartz64/drivers/power/supply/rk817_charger.c rk817_charger.c].<br />
| Quartz64 Model A<br />
|-<br />
! scope="row" | Microphone<br />
| colspan="2" style="background:PaleGreen; text-align:center;"|Linux Mainline<br />
| <code>rockchip-saradc</code><br />
| As of 5.15<sup>[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7786da3b5ae167c17f35e22ba35e06006338c2f6]</sup>. Headphone jack mic seems to connect to <code>SARADC_VIN2_HP_HOOK</code>, so I'm pretty sure that the dtsi and driver changes are needed for that mic to work<br />
|-<br />
! scope="row" | USB 2.0<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=530823]</sup><br />
| <code>rockchip-usb2phy</code><br />
|<br />
|-<br />
! scope="row" | e-Ink<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs reversing<br />
| <code>ebc-dev</code>?<br />
| See [[RK3566 EBC Reverse-Engineering]]<br />
|-<br />
! scope="row" | Combo PHY<br />
| colspan="2" style="background:LightYellow; text-align:center;"|In review<sup>[https://patchwork.kernel.org/project/linux-rockchip/list/?series=569391]</sup><br />
| <code>naneng-combphy</code><br />
|<br />
|-<br />
! scope="row" | RGA<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs fixing<br />
| <code>rockchip-rga</code><br />
| [[User:CounterPillow]] experimentally enabled it<sup>[https://gist.github.com/CounterPillow/6bea809f15ada7ddd3a3d7a4994fdc4e]</sup> in the device tree and ran gstreamer's v4l2convert through it to test, resulting in a completely garbled output.<br />
|-<br />
! scope="row" | Fan Controller<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>emc2301</code><br />
| Previous attempts at mainlining: [http://lkml.iu.edu/hypermail/linux/kernel/1306.1/02473.html] and [https://lore.kernel.org/all/20200928104326.40386-1-biwen.li@oss.nxp.com/]. Latest iteration: [https://gitlab.traverse.com.au/ls1088firmware/traverse-sensors/-/commit/1cdec49171ebafcf32b347e7701224144de8620b]<br />
| SOQuartz Blade<br />
|-<br />
! scope="row" | CIF (CSI Camera)<br />
| colspan="2" style="background:#F99; text-align:center;"|Needs porting<br />
| <code>video_rkcif</code><br />
| Downstream: [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/media/platform/rockchip/cif]<br />
|<br />
|}<br />
<br />
== Current Status ==<br />
<br />
The following sections give an overview over the current status of different parts of the board. Some parts are waiting on a driver to be written or ported, others only need various adjustments.<br />
<br />
According to pgwipeout, I/O device performance is within expected ranges now.<br />
<br />
=== Working ===<br />
<br />
* eMMC<br />
* SDMMC0 (SD cards)<br />
* GMAC (Gigabit Ethernet)<br />
* USB 2.0<br />
* SATA 2<br />
* SATA 3<br />
* UART<br />
** UART 0 (Pi-bus)<br />
** UART 1 (Bluetooth)<br />
** UART 2 (Pi-bus, debug)<br />
* Video Decode<br />
** VP8<br />
* Battery<br />
* GPU<br />
* Audio<br />
** Analog audio works<br />
** SPDIF works<br />
** HDMI works<br />
<br />
=== Partially Working ===<br />
<br />
* PCI-Express Controller &mdash; everything but devices that need cache coherency (e.g. dGPUs) should work<br />
** [[User:CounterPillow]] noticed some weirdness with NVMe devices disconnecting during heavy write operations, likely down due to power draw on one of the rails as the same sustained bandwidth could be achieved with a different PCIe device with no issue.<br />
* SDMMC1 (Wi-Fi) &mdash; AP6256 working, BL602 needs some work to make it flash firmware<br />
* I<sup>2</sup>C &mdash; works but is not yet exposed to the Pi-bus<br />
* [https://developer.arm.com/architectures/system-architectures/system-components/arm-generic-interrupt-controller GIC] &mdash; needs errata published by Rockchip to get upstream to add device-specific workarounds<sup>[https://lore.kernel.org/linux-rockchip/CAMdYzYrQ5f-mv_VmTq_CRf9tR=j3mwRpKHNLmPFgCF9whsGFRw@mail.gmail.com/]</sup><br />
* Video Output &mdash; only at 1920x1080p60 and nothing else, very buggy and rough around more than just the edges<br />
<br />
=== Confirmed Broken ===<br />
<br />
* USB 3.0 &mdash; only works with very short cables and depends on the device. This is due to a hardware design issue relating to the coupling capacitors needed for SATA, which shares the same lines as USB 3.0.<br />
** Hardware design changes have been suggested to engineers, it's in their hands now.<br />
* Module autoloading for the Ethernet PHY. The Motorcomm PHY does not have a vendor ID written into the appropriate hardware block, so there is no canonical way to identify the device.<br />
<br />
=== Needs Testing ===<br />
<br />
* E-Paper &mdash; needs EBC driver<br />
* SPI<br />
* Microphone Input<br />
* CSI &mdash; needs CIF driver<br />
<br />
== TODO ==<br />
<br />
=== ebc-dev Reverse Engineering and Development ===<br />
<br />
The [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/tree/rk356x-ebc-dev driver for the eInk panel] needs to both be reverse engineered and then rewritten as C. In its current form, it is mostly an assembly dump produced by gcc with debug symbols. See [[RK3566 EBC Reverse-Engineering]] for details.<br />
<br />
=== Investigate MCU ===<br />
<br />
The RK3566 comes with an integrated RISC-V microcontroller (MCU). It communicates with the A55 host through the Mailbox system driven by the rockchip-mailbox driver. Since this MCU would be quite useful for things such as low power standby mode, investigating how it can be turned on and have firmware flashed to it should greatly enhance the power saving features of the PineNote.<br />
<br />
=== Mainline U-Boot Work ===<br />
<br />
Currently, mainline U-Boot does not have support for the RK3566 SoC used on the Quartz64. That's why we currently use the "downstream" Rockchip U-Boot, which is based on an old version of U-Boot and contains vendor specific patches that have not undergone the same level of code review as they'd have done had they been submitted upstream.<br />
<br />
While the lack of ATF sources mean that using mainline U-Boot would still require the use of Rockchip provided binaries for the firmware, the mainline U-Boot works needs to be done eventually anyway, and even with Rockchip blobs, a more modern version of U-Boot will be much nicer to use.<br />
<br />
Someone needs to get on the task of investigating what minimally needs to be ported to get the board booting with mainline U-Boot, port those changes, and submit them for review.<br />
<br />
==== List of Useful Resources for this Task ====<br />
* Downstream Rockchip U-Boot repository with Quartz64 specific patches: https://gitlab.com/pgwipeout/u-boot-rockchip/-/tree/quartz64<br />
* Mainline Rockchip custodian U-Boot repository: https://source.denx.de/u-boot/custodians/u-boot-rockchip<br />
* U-Boot Mailing List: https://lists.denx.de/listinfo/u-boot<br />
<br />
== Linux Kernel Config Options ==<br />
<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_I2S_TDM</code><br />
** for Analog and (in the future) HDMI audio<br />
* <code>CONFIG_SND_SOC_RK817</code><br />
** for Analog audio on the Model A<br />
* <code>CONFIG_STMMAC_ETH</code><br />
** Ethernet<br />
* <code>CONFIG_DWMAC_ROCKCHIP</code><br />
** Ethernet<br />
* <code>CONFIG_MOTORCOMM_PHY</code><br />
** Ethernet, set this one to Y, m won't work as module autoloading does not work for this specific PHY (the vendor ID is zeroed out)<br />
* <code>CONFIG_MMC_DW</code><br />
** MMC/SD<br />
* <code>CONFIG_MMC_DW_ROCKCHIP</code><br />
** MMC/SD<br />
* <code>CONFIG_PCIE_ROCKCHIP_DW_HOST</code><br />
** PCIe<br />
* <code>CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY</code><br />
** PHY for PCIe/SATA/USB3, not yet upstream<br />
* <code>CONFIG_DRM_PANFROST</code><br />
** GPU<br />
* <code>CONFIG_SND_SOC_ROCKCHIP_SPDIF</code><br />
** SPDIF audio<br />
* <code>CONFIG_ROCKCHIP_DW_HDMI</code><br />
** HDMI PHY<br />
* <code>CONFIG_ROCKCHIP_VOP2</code><br />
** Video output, not yet upstream<br />
* <code>CONFIG_ARCH_ROCKCHIP</code><br />
** General SoC support<br />
* <code>CONFIG_ROCKCHIP_PHY</code><br />
** General SoC support<br />
* <code>CONFIG_PHY_ROCKCHIP_INNO_USB2</code><br />
** USB 2<br />
* <code>CONFIG_RTC_DRV_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_COMMON_CLK_RK808</code><br />
** Real-time Clock<br />
* <code>CONFIG_MFD_RK808</code><br />
** Various things relating to the RK817 chip<br />
* <code>CONFIG_REGULATOR_RK808</code><br />
** Voltage regulators<br />
* <code>CONFIG_ROCKCHIP_PM_DOMAINS</code><br />
** Power management domains<br />
<br />
== Resources ==<br />
=== Repositories ===<br />
<br />
* pgwipeout's kernel tree<br />
** https://gitlab.com/pgwipeout/linux-next/-/tree/quartz64-v5.15-rc1<br />
* BSP based development effort for SPL/U-Boot and Linux<br />
** https://gitlab.com/pine64-org/quartz-bsp<br />
* Image CI pipeline aimed at developers<br />
** https://gitlab.com/pgwipeout/quartz64_ci/<br />
* Rockchip U-Boot<br />
** https://github.com/rockchip-linux/u-boot<br />
* Downstream rockchip-linux kernel tree<br />
** https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux<br />
<br />
=== Other ===<br />
<br />
* Rockchip-SoC Patchwork Page<br />
** https://patchwork.kernel.org/project/linux-rockchip/list/<br />
* Rockchip Kernel Mailing List Archive<br />
** https://lore.kernel.org/linux-rockchip/<br />
<br />
== Board/SoC Documentation ==<br />
=== Booting ===<br />
==== Boot Order ====<br />
The RK3566 boot ROM will search for a valid ID BLOCK in the following order on the support boot media:<br />
<br />
* SPI NOR flash<br />
* SPI NAND flash<br />
* SD-Card<br />
* eMMC<br />
<br />
... if this fails, the boot ROM will initialize the USB0 port and wait for a connection from the Rockchip<br />
flash/boot tools.<br />
<br />
==== Bootloader Flashing ====<br />
<br />
As per pgwipeout's [https://gitlab.com/pine64-org/quartz-bsp/u-boot/-/commit/12d102b86813378af08b086f3b9c13ed8010754c commit message]:<br />
* Make a partition named <code>uboot</code> as partition number 1 at 8 MiB to 16 MiB<br />
* <code>dd if=idblock.bin of=/dev/''<mmc/sd>'' seek=64</code><br />
* <code>dd if=uboot.img of=/dev/''<mmc/sd>''1</code><br />
<br />
==== BSP Image Layout ====<br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=PineNote_Development&diff=11714PineNote Development2021-10-25T05:10:23Z<p>Smaeul: How to boot mainline without wiping anything; link to more up-to-date kernel branch</p>
<hr />
<div>This article seeks to provide general development information for the [[PineNote]]<br />
<br />
= Flashing Software =<br />
<br />
Currently, the only ways to flash software are from the factory Android installation (UART shell, adb, or fastboot) or by using rkdeveloptool.<br />
<br />
== Side-by-side setup ==<br />
<br />
It is possible to set up a partition for mainline development without disturbing the factory Android installation. This allows updating a mainline kernel, DTB, and initramfs over Wi-Fi until WiFi or USB OTG is working in mainline Linux.<br />
<br />
The recommended partition for this is <tt>mmcblk0p11</tt> aka <tt>/cache</tt>. It is large and already formatted as <tt>ext4</tt>, so it is readable from U-Boot. Here are some general steps:<br />
<br />
# From the UART or adb shell, set up your chroot in <tt>/cache</tt>. I used the Alpine Linux rootfs tarball.<br />
# Copy in your kernel and DTB, using for example <tt>scp</tt> or <tt>wget</tt> inside the chroot.<br />
# Finally, create and boot an <code>extlinux.conf</code> as described below.<br />
<br />
== Using rkdeveloptool ==<br />
<br />
rkdeveloptool is a command line utility built on libusb.<br />
<br />
=== Downloading and Building rkdeveloptool ===<br />
<br />
PINE64 develops [https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool its own updated fork of rkdeveloptool on GitLab].<br />
<br />
You will need to have libusb 1.0 and its development headers installed.<br />
<br />
<pre><br />
git clone https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool.git<br />
cd rkdeveloptool<br />
mkdir build<br />
cd build<br />
cmake ..<br />
</pre><br />
<br />
This sets up all the build files. You can then compile with <code>make</code> inside the build directory.<br />
<br />
After you're done, you'll likely also need to install the udev rules, or else your user won't have permission to access the USB devices:<br />
<br />
<pre><br />
sudo cp 99-rk-rockusb.rules /etc/udev/rules.d/<br />
sudo udevadm --control reload<br />
</pre><br />
<br />
=== Building Downstream U-Boot ===<br />
<br />
While in maskrom mode, we need to have a u-boot to download onto the device for any of the other commands to work.<br />
<br />
<pre><br />
git clone -b quartz64 https://gitlab.com/pgwipeout/u-boot-rockchip.git<br />
git clone -b rkbin https://github.com/JeffyCN/rockchip_mirrors.git rkbin<br />
cd u-boot-rockchip<br />
export CROSS_COMPILE=aarch64-none-linux-gnu-<br />
make rk3566-quartz64_defconfig<br />
./make.sh<br />
</pre><br />
<br />
=== Entering Maskrom Mode ===<br />
<br />
# Flip the device around so that the display faces down<br />
# Lay the pen on the right side, with its tip pointing towards the speaker grill, and its magnet pointing towards the upper right corner of the label on the back.<br />
# Turn the device on and wait for it to show up in <code>lsusb</code>. It should now be in Loader mode, according to <code>rkdeveloptool list-devices</code><br />
# Unplug the device and plug it back in. It should now be in maskrom mode.<br />
<br />
This can be a bit fiddly to get right, and may need a few tries.<br />
<br />
=== Running rkdeveloptool ===<br />
<br />
First, you'll want to make sure the device you've connected is in maskrom mode:<br />
<br />
<pre><br />
./rkdeveloptool list<br />
</pre><br />
<br />
It should output something like <code>DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=202 Maskrom</code>. If it doesn't, see [[PineNote Development#Entering Maskrom Mode]].<br />
<br />
You can now download u-boot onto it:<br />
<pre><br />
./rkdeveloptool boot ../u-boot-rockchip/rk356x_spl_loader_v1.08.111.bin<br />
</pre><br />
<br />
This should output <code>Downloading bootloader succeeded.</code>.<br />
<br />
We can now verify that this worked using e.g. the "read flash info" command:<br />
<br />
<pre><br />
./rkdeveloptool read-flash-info<br />
</pre><br />
<br />
'''TODO:''' finish this section<br />
<br />
=== Creating a mainline boot image ===<br />
<br />
You can create a filesystem image that replaces the Android boot or recovery partition by doing roughly the following:<br />
<br />
# Erase boot and dtbo with rkdeveloptool or fastboot (back them up first!!!)<br />
# Create an ext2 partition image and mount it (fallocate, mkfs.ext2)<br />
# Build your mainline kernel<br />
# Copy the kernel, dtb and an initramfs to the root of the mounted image (use any old postmarketOS initramfs)<br />
# Create a file in the root of the mounted image called <code>extlinux.conf</code> as described below<br />
# Unmount the image and then use rkdeveloptool to flash it to the "recovery" partition on the pinenote (it's about the right size until we get around to replacing the partition layout).<br />
<br />
== Using fastboot ==<br />
<br />
Follow the steps for "Creating a mainline boot.img", but instead of flashing it with rkdeveloptool, use fastboot. You can enter fastboot in either of two ways:<br />
<br />
# Use "reboot bootloader" from adb or a UART console.<br />
# Get a U-Boot prompt and run <code>fastboot usb 0</code>.<br />
<br />
= Mainline development =<br />
<br />
== Status ==<br />
<br />
Some work happening here: https://gitlab.com/calebccff/linux, the idea is to import the parts of the eink/ebc drivers which are open source and use the downstream u-boot framebuffer driver as a reference to create a basic framebuffer driver.<br />
<br />
Currently mainline struggles to boot due to weird issues while probing fixed regulators (?). It also fails to detect eMMC.<br />
<br />
Further work is being done here: https://github.com/smaeul/linux/commits/rk356x-ebc-dev. This has a complete device tree, with working eMMC. Pen input also works out of the box. Wi-Fi and BT work with firmware copied from the factory Android image.<br />
<br />
== How to boot mainline ==<br />
<br />
UART is currently REQUIRED for this to work! We depend on u-boot falling back to console. Once we have a prebuilt u-boot which will use extlinux by default, UART won't be needed anymore.<br />
<br />
=== Getting to a U-Boot prompt ===<br />
<br />
You can get to a U-Boot prompt by:<br />
<br />
# Holding Ctrl-C while the display panel initializes.<br />
# Wiping the "boot" partition.<br />
<br />
=== Using sysboot ===<br />
<br />
<code>extlinux.conf</code> should have the following contents:<br />
<br />
<pre><br />
timeout 10<br />
default MAINLINE<br />
menu title boot prev kernel<br />
<br />
label MAINLINE<br />
kernel /vmlinuz<br />
fdt /rk3566-pinenote.dtb<br />
initrd /initramfs<br />
append earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off PMOS_NO_OUTPUT_REDIRECT<br />
</pre><br />
<br />
At the u-boot console, run the following command to boot your mainline kernel:<br />
<br />
<pre><br />
sysboot ${devtype} ${devnum}:9 any ${scriptaddr} extlinux.conf<br />
</pre><br />
<br />
=== Booting with individual commands ===<br />
<br />
Booting with individual commands can be useful when you need to temporarily add some kernel command line arguments. Use these or similar commands at the U-Boot shell:<br />
<br />
load mmc 0:b ${kernel_addr_r} boot/Image<br />
load mmc 0:b ${fdt_addr_r} boot/rk3566-pinenote.dtb<br />
setenv bootargs ignore_loglevel root=/dev/mmcblk0p11 rootwait init=/bin/bash<br />
booti ${kernel_addr_r} - ${fdt_addr_r}</div>Smaeulhttps://wiki.pine64.org/index.php?title=RK3566_EBC_Reverse-Engineering&diff=11512RK3566 EBC Reverse-Engineering2021-09-27T00:41:56Z<p>Smaeul: remove typo</p>
<hr />
<div>The RK3566 SoC, used in the [[Quartz64]] SBC by PINE64, contains an eInk interface. This is referred to as <code>ebc</code> by Rockchip apparently.<br />
<br />
Unfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it.<br />
<br />
= Sources =<br />
<br />
== Downstream ==<br />
<br />
The ebc driver source is [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/gpu/drm/rockchip/ebc-dev available from the quartz-bsp repository].<br />
<br />
The files of interest are <code>ebc_dev_v8.S</code>, which implements a DRM (Direct Rendering Manager) driver for the eInk panel, and the waveform files in the <code>epdlut</code> subdirectory.<br />
<br />
There's also a simple driver for u-boot: [https://github.com/JeffyCN/rockchip_mirrors/tree/u-boot/drivers/video/rk_eink drivers/video/rk_eink at JeffyCN/rockchip_mirrors]<br />
<br />
These two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in "LUT mode": it writes the waveform LUT to registers in the TCON's MMIO space, and passes buffers of ''pixel'' data to the TCON. The Linux driver operates in "direct mode" uses the LUTs to compute waveforms in software, and passes buffers of ''waveform'' data to the TCON.<br />
<br />
Some reversing of the downstream Linux driver has been done here: https://github.com/Ralim/ebc-dev-reverse-engineering<br />
<br />
== Reimplementation ==<br />
<br />
A human-readable C reimplementation of the LUT and pixel data path [https://gitlab.com/smaeul/ebc-dev is available from smaeul here]. This provides everything needed to convert a framebuffer and a waveform data file into a series of "frames" for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver.<br />
<br />
== In-Development Driver ==<br />
<br />
[https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/tree/rk356x-ebc-dev rk356x-ebc-dev] is the branch on the pine64 linux-next repository used for developing an upstreamable driver based on mainline kernel sources.<br />
<br />
= Documentation =<br />
<br />
== Datasheets ==<br />
<br />
=== TI TPS65185x ===<br />
<br />
This is the PMIC used to drive the e-Ink panel, for which the downstream sources also implement a driver.<br />
<br />
https://www.ti.com/lit/ds/symlink/tps65185.pdf<br />
<br />
== Assembly Syntax and Semantics ==<br />
<br />
The Syntax is GNU Assembler (GAS) syntax. [https://modexp.wordpress.com/2018/10/30/arm64-assembly/ This modexp article] provides a good introduction to the syntax, calling convention, semantics and some often used instructions.<br />
<br />
The [https://developer.arm.com/documentation/ddi0487/gb/ ARM Architecture Reference Manual for ARMv8] should be used as reference for any instructions.<br />
<br />
At the very least, you should read up on the registers and calling convention used.<br />
<br />
= Various Findings =<br />
<br />
The driver isn't really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions.<br />
<br />
* It's technically a DRM subsystem driver, but doesn't really utilise what DRM provides at all.<br />
* It seems to register a new ioctl to set buffer attributes like width and height, despite DRM more than likely having a way for clients to tell a driver what size the framebuffer should be.<br />
* It directly interacts with the PMIC instead of going through regulators/hwmon.<br />
<br />
However, reverse engineering to know how it works provides a good baseline from which we can rewrite it in a more sensible manner.<br />
<br />
= Debug Information =<br />
<br />
Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage.<br />
<br />
== <code>.file ''file-number'' ''file-path''</code> ==<br />
<br />
Specifies a number to reference a file by, and its path. All following code until the next <code>.file</code> or <code>.loc</code> statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available.<br />
<br />
== <code>.loc ''file-number'' ''line-number'' 0</code> ==<br />
<br />
Specifies that the following code is generated from <code>''line-number''</code> stemming from file number <code>''file-number''</code>. See the <code>.file</code> directive for this file number to understand which source file it came from.<br />
<br />
== <code>.type ''function-name'', %function</code> ==<br />
<br />
This tells us that the following code belongs to function <code>''function-name''</code>. You'll usually see a <code>.cfi_startproc</code>, which signifies the start of the function code, until the matching <code>.cfi_endproc</code>.<br />
<br />
A quick grep for <code>%function</code> shows that we are dealing with 30 functions in this file.<br />
<br />
== <code>.type ''struct-name'', %object</code> ==<br />
<br />
This seems to signify a definition of a C struct named <code>''struct-name''</code>.<br />
<br />
A quick grep for <code>%object</code> shows that we are dealing with around 27 structs in this file.<br />
<br />
== <code>.Ldebug_info0:</code> ==<br />
<br />
'''TODO:''' This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures.<br />
<br />
= Finding Structs and Function Signatures =<br />
<br />
First, we'll need to assemble the file:<br />
<br />
<code>aarch64-linux-gnu-gcc -c -o ebc_dev_v8.o ebc_dev_v8.S</code><br />
<br />
This gives us a <code>ebc_dev_v8.o</code> which we can feed into analysis tools.<br />
<br />
For both of these, keep in mind that we're only interested in stuff from ebc_dev.c, or any other files for which we don't have the source. There's no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such.<br />
<br />
Also make sure that if you are looking up known struct accesses, that you use struct definitions from the BSP kernel, not from mainline. The kernel has no internal ABI for drivers!<br />
<br />
== Faster and Easier - Ghidra ==<br />
<br />
Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the "Data Type Manager" marked with an S icon. You'll also find functions in the symbol tree.<br />
<br />
== Slow and Painful - readelf/objdump ==<br />
<br />
Use this if you want to manually look up dwarf symbols for some reason.<br />
<br />
<code>readelf --debug-dump ebc_dev_v8.o</code><br />
<br />
This will produce a lot of output, but we're mainly concerned with the start of the dump. We'll find things like:<br />
<nowiki><br />
&lt;2&gt;&lt;101f8&gt;: Abbrev Number: 0<br />
&lt;1&gt;&lt;101f9&gt;: Abbrev Number: 79 (DW_TAG_subprogram)<br />
&lt;101fa&gt; DW_AT_name : (indirect string, offset: 0xa2b4): ebc_open<br />
&lt;101fe&gt; DW_AT_decl_file : 1<br />
&lt;101ff&gt; DW_AT_decl_line : 1377<br />
&lt;10201&gt; DW_AT_prototyped : 1<br />
&lt;10201&gt; DW_AT_type : &lt;0xc6&gt;<br />
&lt;10205&gt; DW_AT_low_pc : 0x0<br />
&lt;1020d&gt; DW_AT_high_pc : 0xc<br />
&lt;10215&gt; DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)<br />
&lt;10217&gt; DW_AT_GNU_all_call_sites: 1<br />
&lt;10217&gt; DW_AT_sibling : &lt;0x1023a&gt;<br />
&lt;2&gt;&lt;1021b&gt;: Abbrev Number: 88 (DW_TAG_formal_parameter)<br />
&lt;1021c&gt; DW_AT_name : (indirect string, offset: 0x1153): inode<br />
&lt;10220&gt; DW_AT_decl_file : 1<br />
&lt;10221&gt; DW_AT_decl_line : 1377<br />
&lt;10223&gt; DW_AT_type : &lt;0x1c54&gt;<br />
&lt;10227&gt; DW_AT_location : 0xd63 (location list)<br />
&lt;2&gt;&lt;1022b&gt;: Abbrev Number: 106 (DW_TAG_formal_parameter)<br />
&lt;1022c&gt; DW_AT_name : (indirect string, offset: 0x8b06): file<br />
&lt;10230&gt; DW_AT_decl_file : 1<br />
&lt;10231&gt; DW_AT_decl_line : 1377<br />
&lt;10233&gt; DW_AT_type : &lt;0x551f&gt;<br />
&lt;10237&gt; DW_AT_location : 1 byte block: 51 (DW_OP_reg1 (x1))</nowiki><br />
<br />
This essentially tells us the full function signature of <code>ebc_open</code>:<br />
<br />
<code>DW_TAG_subprogram</code> tells us of a function, with <code>DW_AT_name</code> letting us know that this is <code>ebc_open</code>. <code>DW_AT_type</code> of <code>0xc6</code> let's us know, once we jump to <code>&lt;c6&gt;</code>, that this function's return type is a signed 32-bit integer.<br />
<br />
The <code>DW_TAG_formal_parameter</code> that follow tell us of each of the parameter the function takes. The first one is called <code>inode</code> and is of type <code>0x1c54</code>. Referencing what this type is, we find:<br />
<br />
<nowiki><br />
<1><1c54>: Abbrev Number: 7 (DW_TAG_pointer_type)<br />
<1c55> DW_AT_byte_size : 8<br />
<1c56> DW_AT_type : <0x1970></nowiki><br />
<br />
which in of itself goes on to reference <code>0x1970</code>, and looking this one up, we'll find a struct definition:<br />
<br />
<nowiki><br />
<1><1970>: Abbrev Number: 26 (DW_TAG_structure_type)<br />
<1971> DW_AT_name : (indirect string, offset: 0x1153): inode<br />
<1975> DW_AT_byte_size : 672<br />
<1977> DW_AT_decl_file : 31<br />
<1978> DW_AT_decl_line : 611<br />
<197a> DW_AT_sibling : <0x1c4f><br />
<2><197e>: Abbrev Number: 27 (DW_TAG_member)<br />
<197f> DW_AT_name : (indirect string, offset: 0x7d00): i_mode<br />
[etc etc...]</nowiki><br />
<br />
= Reverse-Engineered Stuff =<br />
<br />
== Structs ==<br />
<br />
=== ebc_info ===<br />
<br />
<!-- I don't know why mediawiki scuffs the formatting here --><br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== ebc ===<br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== rkf_waveform ===<br />
<br />
Note: all known waveform data files are the "PVI" variant, not the "RKF" variant.<br />
<br />
<source lang="c"><br />
struct rkf_waveform {<br />
int length,<br />
char[16] format,<br />
char[16] version,<br />
char[16] timeandday,<br />
char[16] panel_name,<br />
char[16] panel_info,<br />
char[64] full_version,<br />
char[64] reset_temp_list,<br />
char[64] gc16_temp_list,<br />
char[64] gl16_temp_list,<br />
char[64] glr16_temp_list,<br />
char[64] gld16_temp_list,<br />
char[64] du_temp_list,<br />
char[64] a2_temp_list,<br />
uint[64] reset_list,<br />
uint[64] gc16_list,<br />
uint[64] gl16_list,<br />
uint[64] glr16_list,<br />
uint[64] gld16_list,<br />
uint[64] du_list,<br />
uint[64] a2_list<br />
}<br />
</source><br />
<br />
== Enums ==<br />
<br />
=== rkf_waveform_type ===<br />
<source lang="c"><br />
enum rkf_waveform_type {<br />
RKF_WF_RESET = 0,<br />
RKF_WF_DU = 1,<br />
RKF_WF_GC16 = 2,<br />
RKF_WF_GL16 = 3,<br />
RKF_WF_GLR16 = 4,<br />
RKF_WF_GLD16 = 5,<br />
RKF_WF_A2 = 6<br />
}<br />
</source><br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=RK3566_EBC_Reverse-Engineering&diff=11511RK3566 EBC Reverse-Engineering2021-09-27T00:40:56Z<p>Smaeul: Add links to reversing efforts</p>
<hr />
<div>The RK3566 SoC, used in the [[Quartz64]] SBC by PINE64, contains an eInk interface. This is referred to as <code>ebc</code> by Rockchip apparently.<br />
<br />
Unfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it.<br />
<br />
= Sources =<br />
<br />
== Downstream ==<br />
<br />
The ebc driver source is [https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux/-/tree/quartz64/drivers/gpu/drm/rockchip/ebc-dev available from the quartz-bsp repository].<br />
<br />
The files of interest are <code>ebc_dev_v8.S</code>, which implements a DRM (Direct Rendering Manager) driver for the eInk panel, and the waveform files in the <code>epdlut</code> subdirectory.<br />
<br />
There's also a simple driver for u-boot: [https://github.com/JeffyCN/rockchip_mirrors/tree/u-boot/drivers/video/rk_eink drivers/video/rk_eink at JeffyCN/rockchip_mirrors]<br />
<br />
These two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in "LUT mode": it writes the waveform LUT to registers in the TCON's MMIO space, and passes buffers of ''pixel'' data to the TCON. The Linux driver operates in "direct mode" uses the LUTs to compute waveforms in software, and passes buffers of ''waveform'' data to the TCON.<br />
<br />
Some reversing of the downstream Linux driver has been done here: https://github.com/Ralim/ebc-dev-reverse-engineering<br />
<br />
== Reimplementation ==<br />
<br />
A human-readable C reimplementation of the LUT and pixel data path [https://gitlab.com/smaeul/ebc-dev is available from smaeul here]. This provides everything needed to convert a framebuffer and a waveform data file into a series of "frames" for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver.<br />
<br />
== In-Development Driver ==<br />
<br />
[https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/tree/rk356x-ebc-dev rk356x-ebc-dev] is the branch on the pine64 linux-next repository used for developing an upstreamable driver based on mainline kernel sources.<br />
<br />
= Documentation =<br />
<br />
== Datasheets ==<br />
<br />
=== TI TPS65185x ===<br />
<br />
This is the PMIC used to drive the e-Ink panel, for which the downstream sources also implement a driver.<br />
<br />
https://www.ti.com/lit/ds/symlink/tps65185.pdf<br />
<br />
== Assembly Syntax and Semantics ==<br />
<br />
The Syntax is GNU Assembler (GAS) syntax. [https://modexp.wordpress.com/2018/10/30/arm64-assembly/ This modexp article] provides a good introduction to the syntax, calling convention, semantics and some often used instructions.<br />
<br />
The [https://developer.arm.com/documentation/ddi0487/gb/ ARM Architecture Reference Manual for ARMv8] should be used as reference for any instructions.<br />
<br />
At the very least, you should read up on the registers and calling convention used.<br />
<br />
= Various Findings =<br />
<br />
The driver isn't really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions.<br />
<br />
* It's technically a DRM subsystem driver, but doesn't really utilise what DRM provides at all.<br />
* It seems to register a new ioctl to set buffer attributes like width and height, despite DRM more than likely having a way for clients to tell a driver what size the framebuffer should be.<br />
* It directly interacts with the PMIC instead of going through regulators/hwmon.<br />
<br />
However, reverse engineering to know how it works provides a good baseline from which we can rewrite it in a more sensible manner.<br />
<br />
= Debug Information =<br />
<br />
Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage.<br />
<br />
== <code>.file ''file-number'' ''file-path''</code> ==<br />
<br />
Specifies a number to reference a file by, and its path. All following code until the next <code>.file</code> or <code>.loc</code> statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available.<br />
<br />
== <code>.loc ''file-number'' ''line-number'' 0</code> ==<br />
<br />
Specifies that the following code is generated from <code>''line-number''</code> stemming from file number <code>''file-number''</code>. See the <code>.file</code> directive for this file number to understand which source file it came from.<br />
<br />
== <code>.type ''function-name'', %function</code> ==<br />
<br />
This tells us that the following code belongs to function <code>''function-name''</code>. You'll usually see a <code>.cfi_startproc</code>, which signifies the start of the function code, until the matching <code>.cfi_endproc</code>.<br />
<br />
A quick grep for <code>%function</code> shows that we are dealing with 30 functions in this file.<br />
<br />
== <code>.type ''struct-name'', %object</code> ==<br />
<br />
This seems to signify a definition of a C struct named <code>''struct-name''</code>.<br />
<br />
A quick grep for <code>%object</code> shows that we are dealing with around 27 structs in this file.<br />
<br />
== <code>.Ldebug_info0:</code> ==<br />
<br />
'''TODO:''' This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures.<br />
<br />
= Finding Structs and Function Signatures =<br />
<br />
First, we'll need to assemble the file:<br />
<br />
<code>aarch64-linux-gnu-gcc -c -o ebc_dev_v8.o ebc_dev_v8.S</code><br />
<br />
This gives us a <code>ebc_dev_v8.o</code> which we can feed into analysis tools.<br />
<br />
For both of these, keep in mind that we're only interested in stuff from ebc_dev.c, or any other files for which we don't have the source. There's no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such.<br />
<br />
Also make sure that if you are looking up known struct accesses, that you use struct definitions from the BSP kernel, not from mainline. The kernel has no internal ABI for drivers!<br />
<br />
== Faster and Easier - Ghidra ==<br />
<br />
Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the "Data Type Manager" marked with an S icon. You'll also find functions in the symbol tree.<br />
<br />
== Slow and Painful - readelf/objdump ==<br />
<br />
Use this if you want to manually look up dwarf symbols for some reason.<br />
<br />
<code>readelf --debug-dump ebc_dev_v8.o</code><br />
<br />
This will produce a lot of output, but we're mainly concerned with the start of the dump. We'll find things like:<br />
<nowiki><br />
&lt;2&gt;&lt;101f8&gt;: Abbrev Number: 0<br />
&lt;1&gt;&lt;101f9&gt;: Abbrev Number: 79 (DW_TAG_subprogram)<br />
&lt;101fa&gt; DW_AT_name : (indirect string, offset: 0xa2b4): ebc_open<br />
&lt;101fe&gt; DW_AT_decl_file : 1<br />
&lt;101ff&gt; DW_AT_decl_line : 1377<br />
&lt;10201&gt; DW_AT_prototyped : 1<br />
&lt;10201&gt; DW_AT_type : &lt;0xc6&gt;<br />
&lt;10205&gt; DW_AT_low_pc : 0x0<br />
&lt;1020d&gt; DW_AT_high_pc : 0xc<br />
&lt;10215&gt; DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)<br />
&lt;10217&gt; DW_AT_GNU_all_call_sites: 1<br />
&lt;10217&gt; DW_AT_sibling : &lt;0x1023a&gt;<br />
&lt;2&gt;&lt;1021b&gt;: Abbrev Number: 88 (DW_TAG_formal_parameter)<br />
&lt;1021c&gt; DW_AT_name : (indirect string, offset: 0x1153): inode<br />
&lt;10220&gt; DW_AT_decl_file : 1<br />
&lt;10221&gt; DW_AT_decl_line : 1377<br />
&lt;10223&gt; DW_AT_type : &lt;0x1c54&gt;<br />
&lt;10227&gt; DW_AT_location : 0xd63 (location list)<br />
&lt;2&gt;&lt;1022b&gt;: Abbrev Number: 106 (DW_TAG_formal_parameter)<br />
&lt;1022c&gt; DW_AT_name : (indirect string, offset: 0x8b06): file<br />
&lt;10230&gt; DW_AT_decl_file : 1<br />
&lt;10231&gt; DW_AT_decl_line : 1377<br />
&lt;10233&gt; DW_AT_type : &lt;0x551f&gt;<br />
&lt;10237&gt; DW_AT_location : 1 byte block: 51 (DW_OP_reg1 (x1))</nowiki><br />
<br />
This essentially tells us the full function signature of <code>ebc_open</code>:<br />
<br />
<code>DW_TAG_subprogram</code> tells us of a function, with <code>DW_AT_name</code> letting us know that this is <code>ebc_open</code>. <code>DW_AT_type</code> of <code>0xc6</code> let's us know, once we jump to <code>&lt;c6&gt;</code>, that this function's return type is a signed 32-bit integer.<br />
<br />
The <code>DW_TAG_formal_parameter</code> that follow tell us of each of the parameter the function takes. The first one is called <code>inode</code> and is of type <code>0x1c54</code>. Referencing what this type is, we find:<br />
<br />
<nowiki><br />
<1><1c54>: Abbrev Number: 7 (DW_TAG_pointer_type)<br />
<1c55> DW_AT_byte_size : 8<br />
<1c56> DW_AT_type : <0x1970></nowiki><br />
<br />
which in of itself goes on to reference <code>0x1970</code>, and looking this one up, we'll find a struct definition:<br />
<br />
<nowiki><br />
<1><1970>: Abbrev Number: 26 (DW_TAG_structure_type)<br />
<1971> DW_AT_name : (indirect string, offset: 0x1153): inode<br />
<1975> DW_AT_byte_size : 672<br />
<1977> DW_AT_decl_file : 31<br />
<1978> DW_AT_decl_line : 611<br />
<197a> DW_AT_sibling : <0x1c4f><br />
<2><197e>: Abbrev Number: 27 (DW_TAG_member)<br />
<197f> DW_AT_name : (indirect string, offset: 0x7d00): i_mode<br />
[etc etc...]</nowiki><br />
<br />
= Reverse-Engineered Stuff =<br />
<br />
Some C source is avaia<br />
<br />
== Structs ==<br />
<br />
=== ebc_info ===<br />
<br />
<!-- I don't know why mediawiki scuffs the formatting here --><br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== ebc ===<br />
<br />
See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on [https://gitlab.com/pine64-org/quartz-bsp/linux-next/-/commits/2de5fb11a888c37f366642544e5a53ec2faae32d the v1.04 BSP Linux driver].<br />
<br />
=== rkf_waveform ===<br />
<br />
Note: all known waveform data files are the "PVI" variant, not the "RKF" variant.<br />
<br />
<source lang="c"><br />
struct rkf_waveform {<br />
int length,<br />
char[16] format,<br />
char[16] version,<br />
char[16] timeandday,<br />
char[16] panel_name,<br />
char[16] panel_info,<br />
char[64] full_version,<br />
char[64] reset_temp_list,<br />
char[64] gc16_temp_list,<br />
char[64] gl16_temp_list,<br />
char[64] glr16_temp_list,<br />
char[64] gld16_temp_list,<br />
char[64] du_temp_list,<br />
char[64] a2_temp_list,<br />
uint[64] reset_list,<br />
uint[64] gc16_list,<br />
uint[64] gl16_list,<br />
uint[64] glr16_list,<br />
uint[64] gld16_list,<br />
uint[64] du_list,<br />
uint[64] a2_list<br />
}<br />
</source><br />
<br />
== Enums ==<br />
<br />
=== rkf_waveform_type ===<br />
<source lang="c"><br />
enum rkf_waveform_type {<br />
RKF_WF_RESET = 0,<br />
RKF_WF_DU = 1,<br />
RKF_WF_GC16 = 2,<br />
RKF_WF_GL16 = 3,<br />
RKF_WF_GLR16 = 4,<br />
RKF_WF_GLD16 = 5,<br />
RKF_WF_A2 = 6<br />
}<br />
</source><br />
<br />
[[Category:Quartz64]][[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=PineNote&diff=11110PineNote2021-08-20T04:13:30Z<p>Smaeul: /* Unresolved */</p>
<hr />
<div>[[File:PineNote-1.jpg|frame]]<br />
<br />
The PineNote is the first hybrid notepad computer device combination of notebook, tablet and e-reader using an e-ink panel. It is derived from the Quartz64 model A SBC and powered by a Rockchip RK3566 quad-core ARM Cortex A55 64-bit processor with a MALI G-52 GPU.<br />
<br />
== Specification ==<br />
<br />
[[File:PineNote_Pen_function.jpg|300px|right]]<br />
[[File:PineNote_Cover-1.jpg|300px|right]]<br />
<br />
=== General Information ===<br />
* Dimensions: 191.1x232.5x7.4mm<br />
* Weight: 438g<br />
<br />
=== Core ===<br />
* CPU: RK3566 1.8GHz 64-bit quad-core A55<br />
* GPU: MALI G52 2EE<br />
* System memory: 4GB LPDDR4<br />
* Flash: 128GB eMMC<br />
<br />
=== E-ink Display ===<br />
* Size: 10.3"<br />
* Resolution: 1404x1872<br />
* DPI: 227<br />
* Grayscale: 16<br />
* Front Light: 36 level cold and warm <br />
* Capacitive multi-touch panel<br />
* EMR pen digitizer<br />
<br />
=== Network ===<br />
* WiFi: 2.4/5GHz 802.11a/b/g/n/ac<br />
* Bluetooth: 5.0<br />
<br />
=== Audio ===<br />
* Built in stereo speakers<br />
* 4 x DMIC microphone<br />
<br />
=== Sensor ===<br />
* G-Sensor for portrait and landscape sensing<br />
<br />
=== Power ===<br />
* 4000mAH LiPo battery<br />
* DC 5V @ 3A USB-C connector<br />
<br />
=== Accessories ===<br />
* Optional EMR pen with magnetic attachment (included in the first production batch)<br />
* Optional Cover (included in the first production batch)<br />
<br />
<br />
== Software and OS Image Downloads ==<br />
<br />
* Not yet available<br />
<br />
<br />
== SoC and Memory Specifications ==<br />
* Based on [https://www.rock-chips.com/a/en/products/RK35_Series/2021/0113/1274.html Rockchip RK3566]<br />
[[File:RK3566_icon.png|right]]<br />
<br />
=== CPU Architecture ===<br />
* [https://developer.arm.com/ip-products/processors/cortex-a/cortex-a55 Quad-core ARM Cortex-A55@1.8GHz]<br />
* AArch32 for full backwards compatibility with ARMv7<br />
* ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation<br />
* Includes VFP hardware to support single and double-precision operations<br />
* ARMv8 Cryptography Extensions<br />
* Integrated 32KB L1 instruction cache and 32KB L1 data cache per core<br />
* 512KB unified system L3 cache<br />
* [https://developer.arm.com/ip-products/security-ip/trustzone TrustZone] technology support<br />
* [https://www.cnx-software.com/2020/12/01/rockchip-rk3568-processor-to-power-edge-computing-and-nvr-applications 22nm process, believed to be FD-SOI]<br />
<br />
=== GPU (Graphics Processing Unit) Capabilities ===<br />
* [https://developer.arm.com/ip-products/graphics-and-multimedia/mali-gpus/mali-g52-gpu Mali-G52 2EE Bifrost GPU@800MHz]<br />
* 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop <br />
* 128KB L2 Cache configurations<br />
* Supports OpenGL ES 1.1, 2.0, and 3.2<br />
* Supports Vulkan 1.0 and 1.1<br />
* Supports OpenCL 2.0 Full Profile<br />
* Supports 1600 Mpix/s fill rate when at 800MHz clock frequency<br />
* Supports 38.4 GLOP/s when at 800MHz clock frequency <br />
<br />
=== NPU (Neural Processing Unit) Capabilities ===<br />
* Neural network acceleration engine with processing performance of up to 0.8 TOPS<br />
* Supports integer 8 and integer 16 convolution operations<br />
* Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet<br />
<br />
=== System Memory ===<br />
* RAM Memory : 4GB LPDDR4.<br />
* Flash Memory: 128GB eMMC<br />
<br />
== PineNote Information, Schematics, and Certifications ==<br />
* The early release schematic just for reference only and used by developers who received the prototype. <br />
** [https://files.pine64.org/doc/PineNote/PINENOTE_MAIN-V1R1%20-%20Schematic-20210726.pdf PineNote early released Schematic ver 1.1 20210726 PDF file]<br />
** [https://files.pine64.org/doc/PineNote/PINENOTE_MAIN-V1R1-REF-TOP-20210726.pdf PineNote early released ver 1.1 20210726 PCB Connector placement PDF file]<br />
<br />
* Certifications:<br />
** Not yet available<br />
<br />
== Datasheets for Components and Peripherals ==<br />
* Rockchip RK3566 SoC information:<br />
** [https://files.pine64.org/doc/quartz64/Rockchip%20RK3566%20Datasheet%20V1.0-20201210.pdf Rockchip RK3566 ver 1.0 datasheet, already got release permission from Rockchip]<br />
* Rockchip RK817 PMU (Power Management Unit) Information:<br />
** [https://www.rockchip.fr/RK817%20datasheet%20V1.01.pdf Rockchip RK817 ver 1.01 datasheet]<br />
* LPDDR4 (200 Balls) SDRAM:<br />
** ---<br />
* eMMC information:<br />
** [https://en.biwin.com.cn/product/detail/6 Biwin 128GB eMMC model: BWCTASC41P128G] <br />
* E-ink Panel information:<br />
** [https://files.pine64.org/doc/quartz64/Eink%20P-511-828-V1_ED103TC2%20Formal%20Spec%20V1.0_20190514.pdf E-Ink 10.3" 1872x1404 ES103TC2 Glass Panel Specification]<br />
** [https://files.pine64.org/doc/datasheet/PineNote/TI%20PMU-TPS651851.pdf TPS65185x PMIC for E-Ink Enabled Electronic Paper Display Datasheet]<br />
* Touch Screen information:<br />
** [https://files.pine64.org/doc/datasheet/PineNote/CYTMA448_Summary_RevC_5-26-16.pdf Cypress CYTMA448 multi-Point Capacitive Touch Controller Datasheet]<br />
** Wacom Pen Digitizer Unit Model: SUDE-10S15MI-01X for 10.3" Display Module<br />
* WiFi/BT module info:<br />
** [https://files.pine64.org/doc/datasheet/rockpro64/AW-CM256SM_DS_DF_V1.9_STD.pdf Azurewave CM256SM 11AC WiFi + Bluetooth5.0 Datasheet]]<br />
* G Sensor info:<br />
** [http://www.silan.com.cn/en/product/details/47.html#app01 Silan SC7A20 3-Axis MEMS Accelerometer]<br />
* Audio Amplifier information:<br />
** [https://files.pine64.org/doc/datasheet/PineNote/Awinic%20AW87318%20Class-K%20Audio%20Amp%20Datasheet.pdf Awinic AW87318 Class-K Audio Amp Datasheet]<br />
<br />
<br />
== Development Efforts ==<br />
<br />
=== Software ===<br />
<br />
* [[Quartz64 Development]] for the mainlining status of various functions on the Rockchip RK3566 SoC<br />
* [[RK3566 EBC Reverse-Engineering]] for the EBC (eInk Panel) driver<br />
<br />
=== Hardware ===<br />
<br />
This section includes discussions and their results regarding hardware changes to the PineNote.<br />
<br />
The following topics have resolved:<br />
<br />
* [[PineNote/Hardware_Changes/Closed_Case_UART]]<br />
* '''Could the USB-C port support USB 3.1 5Gbps?''' Yes and no. The RK3566 only has a host-mode 5Gbps controller, meaning it can only negotiate such a high data rate with a device such as a flash drive. When the RK3566 is acting as a device, it only supports 480Mbps transfer rates. The hardware required to switch between these modes would raise the PineNote's price unreasonably. Therefore, the USB-C port will remain at USB 2.0 speeds for Host and Device mode.<br />
* '''Could the USB-C port output DisplayPort?''' Yes and no. The hardware required to support such a feature would raise the PineNote's price unreasonably. Therefore, DisplayPort output will not be possible through the USB-C port.<br />
* '''Where is the microSD card slot?''' The case design of the PineNote is fixed, making physical changes like adding a microSD card slot would raise the cost unreasonably. However, revisions of the PineNote motherboard after 1.1 will feature an internal ribbon cable connector where a microSD card slot may be attached. Attaching such a device will require taking the PineNote apart.<br />
* '''How will I install software to the PineNote?''' This is a hardware and software question. If the software on your PineNote is completely broken and cannot boot to a recoverable state, a Hall (magnet) sensor was fitted to the PineTab motherboard as U9009. This sensor is attached to SARADC_VIN0_KEY/RECOVERY on the RK3566. With the device powered off, holding a magnet over U9009 and plugging in a USB-C cable causes the device to boot into [http://opensource.rock-chips.com/wiki_Rockusb|"rockusb"] flash mode. With proper flashing software and drivers, it should be possible to load a new operating system using rockusb if the system is soft-bricked. Of course, software vendors will need to be more careful with flashing firmware and providing useful "recovery" options on this device due to this process's relative difficulty to other PINE64 devices.<br />
<br />
==== Unresolved ====<br />
<br />
The following concerns have been brought up as open, unanswered topics:<br />
<br />
* Does [https://en.wikipedia.org/wiki/USB-C#Audio_Adapter_Accessory_Mode_2|USB-C Audio Adapter Accessory Mode] work? It appears that the Headphone output of the audio codec was routed to the USB-C audio+USB switch, but it's unclear whether CC lines are hooked up correctly for detection of such a device. The PineNote hardware team will be testing this functionality soon (as of August 19, 2021). Note that Audio Accessory mode is detectable by reading the I2C registers of the WUSB3801Q. So connecting ASEL to a GPIO would be enough to get this working if it is not working already.<br />
* Why is the Headphone output of the audio codec routed to the speakers? HPL_OUT is routed from the RK817 PMIC and audio codec to U9010 (the USB-C switch) and U6 (the audio amplifier). SPK_OUT is unused. It seems like SPK_OUT should be routed to U6 and HPL_OUT to U9010.<br />
* Nitpick: The cold white charging LED bleeds through the gap between the rear case and the device's face. It does not bleed onto the screen, but it is jarring in low-light conditions or when the screen is amber. Could be resolved in software by turning off the charge LED when the screen is on.<br />
* Is there any way to indicate when the device is in rockusb mode, such as connecting a certain magic pin to the power LED?<br />
* The modem/4G connector (J6010) has its I2C and UART pins unconnected. Could those be connected to the SoC?<br />
<br />
== BSP Linux SDK ==<br />
<br />
=== BSP Linux SDK ver 4.19 for PineNote and Quart64 model A SBC ===<br />
* [http://files.pine64.org/SDK/Quartz64/QUARTZ64-model-A_BSP%20Linux.tar.gz Direct Download from pine64.org]<br />
** MD5 (TAR-GZip file): 24554419aec29700add97167a3a4c9ed<br />
** File Size: 32.67.00GB<br />
<br />
== Android SDK ==<br />
<br />
=== Android 11 eink SDK for PineNote and Quart64 model A SBC ===<br />
* This is the Android SDK build for 10.3" eink panel on Quartz64 model A SBC. <br />
* [http://files.pine64.org/SDK/Quartz64/QUARTZ64-model-A_eink.android11_SDK.tar.gz Direct Download from pine64.org]<br />
** MD5 (TAR-GZip file): 293a550584298de4fb95ceae18103672<br />
** File Size: 72.88GB<br />
** Just the boot blobs (<1MB): [[File:Rk35-blobs.tar.gz]]<br />
<br />
== Hardware troubleshooting guide ==<br />
At present, nothing is available.<br />
<br />
[[Category:PineNote]] [[Category:Rockchip RK3566]]</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5543PinePhone v1.1 - Braveheart2020-05-06T19:04:12Z<p>Smaeul: /* WiFi module cannot be disabled or reset in software */</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone that shipped in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
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.<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''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.''<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled or reset in software ===<br />
<br />
''Resolved in v1.2 by connecting PL2 to the WiFi module's WiFi reset pin.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''Resolved in v1.2 by connecting the magnetometer's <tt>DRDY</tt> pin to PB1.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''Resolved in v1.2 by connecting <tt>LINEOUTP</tt> to the speaker amplifier's <tt>INP</tt> input.''<br />
<br />
Using a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''Resolved in v1.2 by connecting PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''Resolved in v1.2 by connecting <tt>RI</tt> to PL6.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''Resolved in v1.2 by connecting PL9 and <tt>VBUS_CTRL</tt> on the ANX7688 to <tt>N_VBUSEN</tt> on the PMIC.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''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.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''Resolved in v1.2 by separating the modem <tt>PWRKEY</tt> (PB3) and <tt>STATUS</tt> (PH9) signals.''<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''Resolved in v1.2 by disconnecting the modem's I2C port.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''Not resolved in v1.2 -- would have required moving several other GPIOs.''<br />
<br />
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).<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''Not resolved in v1.2 -- assumption is that USB will be used for high-bandwidth modem I/O.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''Not resolved in v1.2 -- this has minimal impact.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''Further investigation determined that the hardware is correct as-is in v1.1, so no change was made.''<br />
<br />
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.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolved in software by reprogramming the one of the cameras' I2C addresses at boot.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''No hardware change suggested, to maintain accessory compatibility.''<br />
<br />
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.</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.2&diff=5542PinePhone v1.22020-05-06T19:02:25Z<p>Smaeul: Created page with "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 P..."</p>
<hr />
<div>The PinePhone v1.2 is a hardware revision of the PinePhone that shipped in 2020.<br />
<br />
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]].<br />
<br />
<!--== Schematic ==<br />
<br />
To Be Released--><br />
<br />
== Changes from v1.1 ==<br />
<br />
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).<br />
<br />
# 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.<br />
# PL2 is now connected to the WiFi module's reset pin, allowing the WiFi to be turned off or reset in software.<br />
# The magnetometer's <tt>DRDY</tt> pin is now connected to PB1, allowing interrupt-driven periodic sensor readings.<br />
# <tt>LINEOUTP</tt> is again connected to the speaker amplifier's INP input (like in v1.0), increasing the SNR of the rear speaker.<br />
# 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.<br />
# 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.<br />
# 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.<br />
# As part of the previous change, the ANX7688's reset input was moved to PD6; this pin previously controlled the USB OTG power.<br />
# 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.<br />
# As part of the previous change, PD11 now controls the ANX7688's 1v0 digital power domain.<br />
# 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.<br />
# The modem no longer has access to the I2C bus containing the sensors.<br />
# <tt>HBIAS</tt> is now connected to the headphone jack.</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5541PinePhone v1.1 - Braveheart2020-05-06T18:37:14Z<p>Smaeul: Update resolution notes for v1.2</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone that shipped in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
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.<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''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.''<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled or reset in software ===<br />
<br />
''Resolved in v1.2 by connecting PL2 to the WiFi module's <tt>CHIP_EN</tt> pin.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''Resolved in v1.2 by connecting the magnetometer's <tt>DRDY</tt> pin to PB1.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''Resolved in v1.2 by connecting <tt>LINEOUTP</tt> to the speaker amplifier's <tt>INP</tt> input.''<br />
<br />
Using a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''Resolved in v1.2 by connecting PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''Resolved in v1.2 by connecting <tt>RI</tt> to PL6.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''Resolved in v1.2 by connecting PL9 and <tt>VBUS_CTRL</tt> on the ANX7688 to <tt>N_VBUSEN</tt> on the PMIC.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''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.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''Resolved in v1.2 by separating the modem <tt>PWRKEY</tt> (PB3) and <tt>STATUS</tt> (PH9) signals.''<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''Resolved in v1.2 by disconnecting the modem's I2C port.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''Not resolved in v1.2 -- would have required moving several other GPIOs.''<br />
<br />
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).<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''Not resolved in v1.2 -- assumption is that USB will be used for high-bandwidth modem I/O.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''Not resolved in v1.2 -- this has minimal impact.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''Further investigation determined that the hardware is correct as-is in v1.1, so no change was made.''<br />
<br />
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.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolved in software by reprogramming the one of the cameras' I2C addresses at boot.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''No hardware change suggested, to maintain accessory compatibility.''<br />
<br />
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.</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5299PinePhone Power Management2020-03-14T20:02:33Z<p>Smaeul: /* Regulators */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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, and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to ANX1.8V<br />
# <strike>Move ANX7688 ANX1.8V from GPIO1-LDO to ALDO2</strike><br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) from DLDO1 to a GPIO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. Since the A64 needs to drive this pin high (no pull-up on the modem side), this uses the level shifter channel previously used by RI (U1503 channel 4).<br />
# Swap <tt>DTR</tt> (was at PL6, now at PB2 with U1503 channel 3 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''<br />
# Connect the modem <tt>STATUS</tt> to PH9. This is an open-drain signal, so it needs a pull-up on the A64 side. ''bugfix''<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# <strike>Connect the modem debug UART TX/RX to PD0-1.</strike><br />
# <strike>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.</strike><br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).<br />
## <strike>Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.</strike><br />
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.<br />
## <strike>Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.</strike><br />
# 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.)<br />
# <strike>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>.</strike><br />
<br />
'''Note:'''<br />
Changes 1-7 and 11 are high priority.<br />
Changes 12-13 are medium priority.<br />
Changes 8-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?<br />
* 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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5197PinePhone Power Management2020-03-01T19:53:24Z<p>Smaeul: /* Suggested GPIO Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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, and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to ANX1.8V<br />
# <strike>Move ANX7688 ANX1.8V from GPIO1-LDO to ALDO2</strike><br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) from DLDO1 to a GPIO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. Since the A64 needs to drive this pin high (no pull-up on the modem side), this uses the level shifter channel previously used by RI (U1503 channel 4).<br />
# Swap <tt>DTR</tt> (was at PL6, now at PB2 with U1503 channel 3 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''<br />
# Connect the modem <tt>STATUS</tt> to PH9. This is an open-drain signal, so it needs a pull-up on the A64 side. ''bugfix''<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# <strike>Connect the modem debug UART TX/RX to PD0-1.</strike><br />
# <strike>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.</strike><br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).<br />
## <strike>Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.</strike><br />
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.<br />
## <strike>Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.</strike><br />
# 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.)<br />
# <strike>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>.</strike><br />
<br />
'''Note:'''<br />
Changes 1-7 and 11 are high priority.<br />
Changes 12-13 are medium priority.<br />
Changes 8-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?<br />
* 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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5196PinePhone Power Management2020-03-01T19:52:56Z<p>Smaeul: /* ANX7688 */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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, and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to ANX1.8V<br />
# <strike>Move ANX7688 ANX1.8V from GPIO1-LDO to ALDO2</strike><br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) from DLDO1 to a GPIO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. Since the A64 needs to drive this pin high (no pull-up on the modem side), this uses the level shifter channel previously used by RI (U1503 channel 4).<br />
# Swap <tt>DTR</tt> (was at PL6, now at PB2 with U1503 channel 3 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''<br />
# Connect the modem <tt>STATUS</tt> to PH9. This is an open-drain signal, so it needs a pull-up on the A64 side. ''bugfix''<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# <strike>Connect the modem debug UART TX/RX to PD0-1.</strike><br />
# <strike>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.</strike><br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).<br />
## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.<br />
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.<br />
## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# <strike>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>.</strike><br />
<br />
'''Note:'''<br />
Changes 1-7 and 11 are high priority.<br />
Changes 12-13 are medium priority.<br />
Changes 8-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?<br />
* 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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5184PinePhone Power Management2020-03-01T06:48:23Z<p>Smaeul: /* Suggested GPIO Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. Since the A64 needs to drive this pin high (no pull-up on the modem side), this uses the level shifter channel previously used by RI (U1503 channel 4).<br />
# Swap <tt>DTR</tt> (was at PL6, now at PB2 with U1503 channel 3 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''<br />
# Connect the modem <tt>STATUS</tt> to PH9. This is an open-drain signal, so it needs a pull-up on the A64 side. ''bugfix''<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# <strike>Connect the modem debug UART TX/RX to PD0-1.</strike><br />
# <strike>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.</strike><br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).<br />
## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.<br />
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.<br />
## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# <strike>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>.</strike><br />
<br />
'''Note:'''<br />
Changes 1-7 and 11 are high priority.<br />
Changes 12-13 are medium priority.<br />
Changes 8-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?<br />
* 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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5170PinePhone Power Management2020-02-24T03:43:15Z<p>Smaeul: /* Suggested GPIO Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# 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.<br />
# 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''<br />
# 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 on the A64 side. ''bugfix''<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).<br />
## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.<br />
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.<br />
## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-7 and 11 are high priority.<br />
Changes 12-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?<br />
* 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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5162PinePhone Power Management2020-02-24T00:39:29Z<p>Smaeul: /* Suggested GPIO Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# 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.<br />
# 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526).<br />
# 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.<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).<br />
## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.<br />
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.<br />
## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 and 11 are high priority.<br />
Changes 12-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5139PinePhone v1.1 - Braveheart2020-02-19T07:13:56Z<p>Smaeul: /* Known issues */ sort</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.<br />
<br />
=== See here for fixes ===<br />
* Regulators: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Regulator_Hardware_Changes<br />
* GPIO/other pins: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_GPIO_Hardware_Changes<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''Possibly resolved by PL6 (BB-RI) being pulled high (GPIO change #5). May depend on which other changes are made.''<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled or reset in software ===<br />
<br />
''This would be resolved by applying suggested GPIO change #1.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''This would be resolved by applying suggested GPIO change #2.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''This would be resolved by applying suggested GPIO change #3.''<br />
<br />
Using a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''This would be resolved by applying suggested GPIO change #4.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''This would be resolved by applying suggested GPIO change #5.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''This would be resolved by applying suggested GPIO change #11.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''This issue would be resolved by applying suggested regulator changes #1-3.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''This would be resolved by applying suggested GPIO changes #6 and #7.''<br />
<br />
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 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''This would be resolved by applying suggested GPIO change #8.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''This would be resolved by applying suggested GPIO change #9.''<br />
<br />
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).<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''This would be resolved by applying suggested GPIO change #10.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''This would be resolved by applying suggested GPIO change #12.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''This would be resolved by applying suggested GPIO change #13.''<br />
<br />
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.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''No hardware change suggested, to maintain accessory compatibility.''<br />
<br />
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.</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5138PinePhone Power Management2020-02-19T07:05:26Z<p>Smaeul: /* Suggested GPIO Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# 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.<br />
# 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# 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.<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).<br />
## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.<br />
## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.<br />
## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 and 11 are high priority.<br />
Changes 12-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5137PinePhone Power Management2020-02-19T06:43:30Z<p>Smaeul: /* Suggested GPIO Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# 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.<br />
# 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# 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.<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 and 11 are high priority.<br />
Changes 12-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5136PinePhone Power Management2020-02-19T06:39:28Z<p>Smaeul: /* ANX7688 */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
These are all medium priority.<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# 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.<br />
# 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# 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.<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5135PinePhone v1.1 - Braveheart2020-02-19T06:35:53Z<p>Smaeul: /* See here for fixes: */</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.<br />
<br />
=== See here for fixes ===<br />
* Regulators: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Regulator_Hardware_Changes<br />
* GPIO/other pins: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_GPIO_Hardware_Changes<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''Possibly resolved by PL6 (BB-RI) being pulled high (GPIO change #5). May depend on which other changes are made.''<br />
<br />
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.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''This would be resolved by applying suggested GPIO change #11.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''This would be resolved by applying suggested GPIO change #4.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''This would be resolved by applying suggested GPIO change #5.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''This would be resolved by applying suggested GPIO changes #6 and #7.''<br />
<br />
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 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''This would be resolved by applying suggested GPIO change #10.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''This would be resolved by applying suggested GPIO change #8.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled in software ===<br />
<br />
''This would be resolved by applying suggested GPIO change #1.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''This would be resolved by applying suggested GPIO change #2.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''No hardware change suggested, to maintain accessory compatibility.''<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''This issue would be resolved by applying suggested regulator changes #1-3.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* The main 3v3 input, to AVDD33, should always be on. 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* The DVDD18 input should also always be on. 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''This would be resolved by applying suggested GPIO change #12.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''This would be resolved by applying suggested GPIO change #13.''<br />
<br />
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.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''This would be resolved by applying suggested GPIO change #3.''<br />
<br />
If a differential connection to the speaker amplifier doesn't cause any issues, using it would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''This would be resolved by applying suggested GPIO change #9.''<br />
<br />
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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5134PinePhone Power Management2020-02-19T06:35:26Z<p>Smaeul: /* Suggested GPIO Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# 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.<br />
# 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''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# 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.<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5133PinePhone Power Management2020-02-19T06:33:17Z<p>Smaeul: /* Assignments after Suggested Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
=== Assignments after Suggested Changes ===<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up on the modem side.<br />
# 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 on the A64 side*). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5132PinePhone Power Management2020-02-19T06:31:50Z<p>Smaeul: /* Suggested Regulator Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up on the modem side.<br />
# 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 on the A64 side*). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5131PinePhone v1.1 - Braveheart2020-02-19T06:29:25Z<p>Smaeul: /* Known issues */</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.<br />
<br />
=== See here for fixes: ===<br />
* Regulators: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Regulator_Hardware_Changes<br />
* GPIO/other pins: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_GPIO_Hardware_Changes<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''Possibly resolved by PL6 (BB-RI) being pulled high (GPIO change #5). May depend on which other changes are made.''<br />
<br />
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.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''This would be resolved by applying suggested GPIO change #11.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''This would be resolved by applying suggested GPIO change #4.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''This would be resolved by applying suggested GPIO change #5.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''This would be resolved by applying suggested GPIO changes #6 and #7.''<br />
<br />
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 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''This would be resolved by applying suggested GPIO change #10.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''This would be resolved by applying suggested GPIO change #8.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled in software ===<br />
<br />
''This would be resolved by applying suggested GPIO change #1.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''This would be resolved by applying suggested GPIO change #2.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''No hardware change suggested, to maintain accessory compatibility.''<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''This issue would be resolved by applying suggested regulator changes #1-3.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* The main 3v3 input, to AVDD33, should always be on. 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* The DVDD18 input should also always be on. 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''This would be resolved by applying suggested GPIO change #12.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''This would be resolved by applying suggested GPIO change #13.''<br />
<br />
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.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''This would be resolved by applying suggested GPIO change #3.''<br />
<br />
If a differential connection to the speaker amplifier doesn't cause any issues, using it would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''This would be resolved by applying suggested GPIO change #9.''<br />
<br />
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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5130PinePhone v1.1 - Braveheart2020-02-19T06:28:56Z<p>Smaeul: /* Known issues */</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.<br />
<br />
For suggested changes, see:<br />
* Regulators: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Regulator_Hardware_Changes<br />
* GPIO/other pins: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_GPIO_Hardware_Changes<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''Possibly resolved by PL6 (BB-RI) being pulled high (GPIO change #5). May depend on which other changes are made.''<br />
<br />
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.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''This would be resolved by applying suggested GPIO change #11.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''This would be resolved by applying suggested GPIO change #4.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''This would be resolved by applying suggested GPIO change #5.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''This would be resolved by applying suggested GPIO changes #6 and #7.''<br />
<br />
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 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''This would be resolved by applying suggested GPIO change #10.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''This would be resolved by applying suggested GPIO change #8.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled in software ===<br />
<br />
''This would be resolved by applying suggested GPIO change #1.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''This would be resolved by applying suggested GPIO change #2.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''No hardware change suggested, to maintain accessory compatibility.''<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''This issue would be resolved by applying suggested regulator changes #1-3.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* The main 3v3 input, to AVDD33, should always be on. 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* The DVDD18 input should also always be on. 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''This would be resolved by applying suggested GPIO change #12.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''This would be resolved by applying suggested GPIO change #13.''<br />
<br />
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.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''This would be resolved by applying suggested GPIO change #3.''<br />
<br />
If a differential connection to the speaker amplifier doesn't cause any issues, using it would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''This would be resolved by applying suggested GPIO change #9.''<br />
<br />
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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5129PinePhone Power Management2020-02-19T06:28:36Z<p>Smaeul: /* Suggested Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Regulator Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up on the modem side.<br />
# 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 on the A64 side*). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5128PinePhone Power Management2020-02-19T06:28:22Z<p>Smaeul: /* Suggested Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested GPIO Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up on the modem side.<br />
# 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 on the A64 side*). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5127PinePhone Power Management2020-02-19T06:26:24Z<p>Smaeul: /* Suggested Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) to <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up on the modem side.<br />
# 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 on the A64 side*). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5126PinePhone v1.1 - Braveheart2020-02-19T06:20:14Z<p>Smaeul: /* Need a way to distinguish v1.1 from v1.2 from U-Boot SPL */</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.<br />
<br />
For suggested changes, see:<br />
* Regulators: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Hardware_Changes<br />
* GPIO/other pins: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Hardware_Changes_2<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''Possibly resolved by PL6 (BB-RI) being pulled high (GPIO change #5). May depend on which other changes are made.''<br />
<br />
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.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''This would be resolved by applying suggested GPIO change #11.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''This would be resolved by applying suggested GPIO change #4.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''This would be resolved by applying suggested GPIO change #5.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''This would be resolved by applying suggested GPIO changes #6 and #7.''<br />
<br />
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 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''This would be resolved by applying suggested GPIO change #10.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''This would be resolved by applying suggested GPIO change #8.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled in software ===<br />
<br />
''This would be resolved by applying suggested GPIO change #1.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''This would be resolved by applying suggested GPIO change #2.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''No hardware change suggested, to maintain accessory compatibility.''<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''This issue would be resolved by applying suggested regulator changes #1-3.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* The main 3v3 input, to AVDD33, should always be on. 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* The DVDD18 input should also always be on. 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''This would be resolved by applying suggested GPIO change #12.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''This would be resolved by applying suggested GPIO change #13.''<br />
<br />
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.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''This would be resolved by applying suggested GPIO change #3.''<br />
<br />
If a differential connection to the speaker amplifier doesn't cause any issues, using it would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''This would be resolved by applying suggested GPIO change #9.''<br />
<br />
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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5125PinePhone Power Management2020-02-19T06:19:06Z<p>Smaeul: </p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) and <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up on the modem side.<br />
# 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 on the A64 side*). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
'''Note:'''<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
&#42; 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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5124PinePhone v1.1 - Braveheart2020-02-19T06:13:29Z<p>Smaeul: </p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.<br />
<br />
For suggested changes, see:<br />
* Regulators: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Hardware_Changes<br />
* GPIO/other pins: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Hardware_Changes_2<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''Possibly resolved by PL6 (BB-RI) being pulled high. Depends on which changes are made.''<br />
<br />
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.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''This would be resolved by applying suggested GPIO change #11.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''This would be resolved by applying suggested GPIO change #4.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''This would be resolved by applying suggested GPIO change #5.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''This would be resolved by applying suggested GPIO changes #6 and #7.''<br />
<br />
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 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''This would be resolved by applying suggested GPIO change #10.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''This would be resolved by applying suggested GPIO change #8.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled in software ===<br />
<br />
''This would be resolved by applying suggested GPIO change #1.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''This would be resolved by applying suggested GPIO change #2.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''No hardware change suggested, to maintain accessory compatibility.''<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''This issue would be resolved by applying suggested regulator changes #1-3.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* The main 3v3 input, to AVDD33, should always be on. 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* The DVDD18 input should also always be on. 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''This would be resolved by applying suggested GPIO change #12.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''This would be resolved by applying suggested GPIO change #13.''<br />
<br />
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.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''This would be resolved by applying suggested GPIO change #3.''<br />
<br />
If a differential connection to the speaker amplifier doesn't cause any issues, using it would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''This would be resolved by applying suggested GPIO change #9.''<br />
<br />
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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5123PinePhone Power Management2020-02-19T06:11:25Z<p>Smaeul: /* Suggested Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) and <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. I think this needs a pull-up on the modem side.<br />
# 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 on the A64 side*). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
*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.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5122PinePhone Power Management2020-02-19T05:26:45Z<p>Smaeul: /* Suggested Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) and <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Replace <tt>WAKEUP_IN</tt> with <tt>AP_READY</tt> at PH8.<br />
# Swap <tt>DTR</tt> (PL6, '''no level shift''') and <tt>RI</tt> (PB2, level shift). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# 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.)<br />
# 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>.<br />
<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5117PinePhone v1.1 - Braveheart2020-02-18T15:26:15Z<p>Smaeul: /* Known issues */</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.<br />
<br />
For suggested changes, see:<br />
* Regulators: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Hardware_Changes<br />
* GPIO/other pins: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Hardware_Changes_2<br />
<br />
=== Need a way to distinguish v1.1 from v1.2 from U-Boot SPL ===<br />
<br />
''Not yet resolved.''<br />
<br />
To load the correct device tree, there needs to be some hardware feature that can distinguish the two versions.<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''This would be resolved by applying suggested GPIO change #11.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''This would be resolved by applying suggested GPIO change #4.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''This would be resolved by applying suggested GPIO change #5.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''This would be resolved by applying suggested GPIO changes #6 and #7.''<br />
<br />
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 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''This would be resolved by applying suggested GPIO change #10.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''This would be resolved by applying suggested GPIO change #8.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled in software ===<br />
<br />
''This would be resolved by applying suggested GPIO change #1.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''This would be resolved by applying suggested GPIO change #2.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''This issue would be resolved by applying suggested regulator changes #1-3.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* The main 3v3 input, to AVDD33, should always be on. 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* The DVDD18 input should also always be on. 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''This would be resolved by applying suggested GPIO change #12.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''This would be resolved by applying suggested GPIO change #13.''<br />
<br />
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.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''This would be resolved by applying suggested GPIO change #3.''<br />
<br />
If a differential connection to the speaker amplifier doesn't cause any issues, using it would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''This would be resolved by applying suggested GPIO change #9.''<br />
<br />
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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5112PinePhone Power Management2020-02-18T07:27:45Z<p>Smaeul: /* Suggested Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) and <tt>WL-PMU-EN</tt> (WiFi). ''bugfix''<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Replace <tt>WAKEUP_IN</tt> with <tt>AP_READY</tt> at PH8.<br />
# Swap <tt>DTR</tt> (PL6, '''no level shift''') and <tt>RI</tt> (PB2, level shift). ''partly a bugfix''<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)<br />
# 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>.<br />
<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5111PinePhone Power Management2020-02-18T07:24:51Z<p>Smaeul: /* Sensors */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
<!--==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
--><br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) and <tt>WL-PMU-EN</tt> (WiFi).<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Replace <tt>WAKEUP_IN</tt> with <tt>AP_READY</tt> at PH8.<br />
# Swap <tt>DTR</tt> (PL6, '''no level shift''') and <tt>RI</tt> (PB2, level shift).<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)<br />
# 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>.<br />
<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_v1.1_-_Braveheart&diff=5110PinePhone v1.1 - Braveheart2020-02-18T07:18:00Z<p>Smaeul: /* Modem RI signal routing prevents wakeup */</p>
<hr />
<div>The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.<br />
<br />
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]].<br />
<br />
== Schematic ==<br />
<br />
[http://files.pine64.org/doc/PinePhone/PinePhone_Schematic_v1.1_20191031.pdf Hardware schematic]<br />
<br />
== Changes from 1.0 ==<br />
<br />
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.<br />
<br />
# Added CPU shielding and cover plate<br />
# Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed<br />
# Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot<br />
# Connect WiFi enable to VD33<br />
# Set the EG25G's PWRKEY on by default (see resistor R1526)<br />
# Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.<br />
# 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.<br />
# A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential<br />
<br />
== Known issues ==<br />
<br />
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.<br />
<br />
For suggested changes, see:<br />
* Regulators: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Hardware_Changes<br />
* GPIO/other pins: https://wiki.pine64.org/index.php/PinePhone/Power_Management#Suggested_Hardware_Changes_2<br />
<br />
=== Excess power usage while driving VBUS ===<br />
<br />
''This would be resolved by applying suggested GPIO change #11.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem AP_READY signal is not connected ===<br />
<br />
''This would be resolved by applying suggested GPIO change #4.''<br />
<br />
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).<br />
<br />
=== Modem RI signal routing prevents wakeup ===<br />
<br />
''This would be resolved by applying suggested GPIO change #5.''<br />
<br />
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>).<br />
<br />
'''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.<br />
<br />
=== Modem PWR_KEY signal resistor population ===<br />
<br />
''This would be resolved by applying suggested GPIO changes #6 and #7.''<br />
<br />
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 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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem UART flow control is broken ===<br />
<br />
''This would be resolved by applying suggested GPIO change #10.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Modem has access to sensors on I2C1 ===<br />
<br />
''This would be resolved by applying suggested GPIO change #8.''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== WiFi module cannot be disabled in software ===<br />
<br />
''This would be resolved by applying suggested GPIO change #1.''<br />
<br />
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.<br />
<br />
=== Magnetometer's IRQ signal is routed to the wrong pin ===<br />
<br />
''This would be resolved by applying suggested GPIO change #2.''<br />
<br />
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.<br />
<br />
Software workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.<br />
<br />
=== Cameras have the same default I2C address ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== USB Power issue preventing charge and battery-less operation (one-off HW issue ?) ===<br />
<br />
''Seems to be a one-time hardware issue, no change needed?''<br />
<br />
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.<br />
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<br />
<br />
Investigations:<br />
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!).<br />
<br />
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.<br />
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.<br />
<br />
I decided to bypass OVP to try fixing my PinePhone:<br />
<br />
<gallery mode="traditional"><br />
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".<br />
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 !<br />
File:Braveheart_bypass_OVP_U102_AW338XX.jpg|The wire passing behind the battery.<br />
</gallery><br />
<br />
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.<br />
<br />
=== Pogo Pins supply 5v0, not 3v3 ===<br />
<br />
''Resolution for this issue is unknown.''<br />
<br />
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.<br />
<br />
=== ANX7688 power supply situation is problematic ===<br />
<br />
''This issue would be resolved by applying suggested regulator changes #1-3.''<br />
<br />
ANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).<br />
* The main 3v3 input, to AVDD33, should always be on. 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.<br />
* HDMI_VT is only needed during video transmission, and should remain connected to DLDO1.<br />
* 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.<br />
* The DVDD18 input should also always be on. 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.<br />
* 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.)<br />
* 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.<br />
<br />
=== ANX7688 power/reset control pulled the wrong way ===<br />
<br />
''This would be resolved by applying suggested GPIO change #12.''<br />
<br />
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.<br />
<br />
=== VCONN_EN signals are possibly inverted ===<br />
<br />
''This would be resolved by applying suggested GPIO change #13.''<br />
<br />
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.<br />
<br />
=== Speaker output could be differential ===<br />
<br />
''This would be resolved by applying suggested GPIO change #3.''<br />
<br />
If a differential connection to the speaker amplifier doesn't cause any issues, using it would significantly lower the noise floor of the speaker, and would allow doubling the max volume.<br />
<br />
=== Allow access the modem debug UART ===<br />
<br />
''This would be resolved by applying suggested GPIO change #9.''<br />
<br />
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).</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5109PinePhone Power Management2020-02-18T07:17:09Z<p>Smaeul: /* Suggested Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) and <tt>WL-PMU-EN</tt> (WiFi).<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Replace <tt>WAKEUP_IN</tt> with <tt>AP_READY</tt> at PH8.<br />
# Swap <tt>DTR</tt> (PL6, '''no level shift''') and <tt>RI</tt> (PB2, level shift).<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)<br />
# 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>.<br />
<br />
Changes 1-5 are high priority.<br />
Changes 11-13 are medium priority.<br />
Changes 6-10 are low priority.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5108PinePhone Power Management2020-02-18T07:01:10Z<p>Smaeul: /* Open Questions */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) and <tt>WL-PMU-EN</tt> (WiFi).<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Replace <tt>WAKEUP_IN</tt> with <tt>AP_READY</tt> at PH8.<br />
# Swap <tt>DTR</tt> (PL6, '''no level shift''') and <tt>RI</tt> (PB2, level shift).<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)<br />
# 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>.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeulhttps://wiki.pine64.org/index.php?title=PinePhone_Power_Management&diff=5107PinePhone Power Management2020-02-18T06:36:35Z<p>Smaeul: /* Suggested Hardware Changes */</p>
<hr />
<div>The data on this page is based on the the [[PinePhone v1.1 - Braveheart]].<br />
<br />
== Regulators ==<br />
<br />
=== Current Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN<br />
|-<br />
| DCDC2<br />
| DVFS<br />
| No<br />
| Yes<br />
| VDD-CPUX<br />
|-<br />
| DCDC3<br />
| DVFS<br />
| N/A<br />
| N/A<br />
| VDD-CPUX (polyphase with DCDC2)<br />
|-<br />
| DCDC4<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| DCDC5<br />
| 1.2V<br />
| No<br />
| Yes (future)<br />
| VCC-DRAM; DRAM<br />
|-<br />
| DCDC6<br />
| 1.1V<br />
| No<br />
| Yes (future)<br />
| VDD-SYS<br />
|-<br />
| DC1SW<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ALDO1<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; Pogo INT<br />
|-<br />
| ALDO3<br />
| 3.0V<br />
| No<br />
| No (KEYADC)<br />
| AVCC, KEYADC, VCC-PLL<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| No<br />
| No (ANX7688 AVDD33)<br />
| 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<br />
|-<br />
| DLDO2<br />
| 1.8V? 3.3V?<br />
| Yes<br />
| Yes<br />
| MIPI-DSI VIO<br />
|-<br />
| DLDO3<br />
| 2.8V<br />
| Yes<br />
| Yes<br />
| Camera AVDD<br />
|-<br />
| DLDO4<br />
| 1.8V-3.3V<br />
| Yes<br />
| Yes<br />
| VCC-PG; VQMMC1<br />
|-<br />
| ELDO1<br />
| 1.8V<br />
| No<br />
| No (DRAM)<br />
| CPVDD; DRAM<br />
|-<br />
| ELDO2<br />
| N/A<br />
| Yes<br />
| Yes<br />
| Not used<br />
|-<br />
| ELDO3<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| Camera DVDD<br />
|-<br />
| FLDO1<br />
| 1.2V<br />
| Yes<br />
| Yes<br />
| HSIC-VCC (not used)<br />
|-<br />
| FLDO2<br />
| 1.1V<br />
| No<br />
| No (VDD-CPUS)<br />
| VDD-CPUS<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| No<br />
| No (ANX7688 DVDD1V8)<br />
| ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up]<br />
|-<br />
| PD6<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| USB OTG<br />
|-<br />
| PD8<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| Pogo supply, USB OTG via PD6<br />
|-<br />
| PD9<br />
| 5.0V<br />
| Yes<br />
| Yes<br />
| VCONN (USB Type C)<br />
|-<br />
| PH10<br />
| PWM<br />
| Yes<br />
| Yes<br />
| Backlight<br />
|-<br />
| PL7<br />
| VBAT<br />
| Yes<br />
| Yes<br />
| Modem<br />
|-<br />
| ANX-V1.0<br />
| 1.0V<br />
| Yes<br />
| Yes<br />
| ANX7688 [AVDD1V0, DVDD1V0]<br />
|}<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
==== ANX7688 ====<br />
<br />
# 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<br />
# Move ANX7688 DVDD1V8 (the chip input only, not the other things labeled DVDD1V8) from GPIO1-LDO to ALDO2<br />
# Move ANX7688 ANX-V1.0 Regulator Enable and ANX7688 VCONN_EN Disable Pull-up from DLDO1 to GPIO1-LDO<br />
<br />
The result of these changes would be that:<br />
# The always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered<br />
# 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)<br />
# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in<br />
<br />
==== Sensors ====<br />
<br />
# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).<br />
<br />
==== Assignments after Suggested Changes ====<br />
<br />
Note: Only regulators that were modified are included here.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name/GPIO<br />
! Output Voltage<br />
! Can disable at runtime?<br />
! Can disable in suspend?<br />
! Consumers (internal/external separated by semicolon)<br />
|-<br />
| DCDC1<br />
| 3.3V<br />
| No<br />
| No (VCC-IO)<br />
| 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<br />
|-<br />
| ALDO2<br />
| 1.8V<br />
| No<br />
| No (VCC-PL)<br />
| VCC-PL; ANX7688 [DVDD1V8], Pogo INT<br />
|-<br />
| DLDO1<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD<br />
|-<br />
| GPIO0-LDO<br />
| 3.3V<br />
| Yes<br />
| Yes<br />
| Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC]<br />
|-<br />
| GPIO1-LDO<br />
| 1.8V<br />
| Yes<br />
| Yes<br />
| ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up]<br />
|}<br />
<br />
=== Open Questions ===<br />
<br />
* How is ANX1.8V actually powered? from GPIO1-LDO or PS or both?<br />
* Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places.<br />
** From LCD and LCD controller datasheets, this should be 1.8V.<br />
* If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?<br />
** Looks like this is N/A, because DLDO2 should be 1.8V.<br />
<br />
=== Software Updates Needed ===<br />
<br />
==== Drivers that Need Regulator Consumers ====<br />
<br />
* LCD Panel for VCC-LCD<br />
* MIPI-DSI/DPHY/Panel for MIPI-DSI VIO<br />
* STK3311-A<br />
<br />
==== Drivers that Need to Suspend Regulators ====<br />
<br />
* STK3311-A<br />
* LIS3MDL<br />
* MPU6050<br />
* Goodix touchscreen<br />
* sunxi pinctrl (maybe)<br />
* USB PHY<br />
<br />
== GPIO ==<br />
<br />
=== Current Modem Pin Assignments ===<br />
<br />
Note: only pins relevant to power management are included in this table.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction (as modem)<br />
! Needed in suspend?<br />
! Connected to<br />
|-<br />
| 1<br />
| <tt>WAKEUP_IN</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PH7 (active high)<br />
|-<br />
| 2<br />
| <tt>AP_READY</tt><br />
| Drive high/low to signal the A64 is ready to receive URCs<br />
| I<br />
| No (if held)<br />
| NC<br />
|-<br />
| 4<br />
| <tt>W_DISABLE#</tt><br />
| Drive low to enter Airplane Mode<br />
| I<br />
| No (if held/tristate)<br />
| PH8 (active high)<br />
|-<br />
| 20<br />
| <tt>RESET_N</tt><br />
| Drive low to reset the modem<br />
| I<br />
| No (if held/tristate)<br />
| PC4 (active high)<br />
|-<br />
| 21<br />
| <tt>PWRKEY</tt><br />
| Drive low to turn the modem on/off<br />
| I<br />
| No (if held/tristate)<br />
| PB3 (active high)<br />
|-<br />
| 61<br />
| <tt>STATUS</tt><br />
| Open drain output, pulled low when the modem is on<br />
| O<br />
| No<br />
| PB3<br />
|-<br />
| 62<br />
| <tt>RI</tt><br />
| Pulled low to request host wakeup<br />
| O<br />
| Yes<br />
| PB2<br />
|-<br />
| 66<br />
| <tt>DTR</tt><br />
| Drive low to wake up the modem<br />
| I<br />
| No<br />
| PL6 (active low)<br />
|}<br />
<br />
=== Current Port L Pin Assignments ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin<br />
! Signal Name<br />
! Description<br />
! Direction<br />
! Needed in suspend?<br />
|-<br />
| PL0<br />
| <tt>PMU-SCK</tt><br />
| AXP803 I2C/RSB Clock<br />
| O<br />
| Yes<br />
|-<br />
| PL1<br />
| <tt>PMU-SDA</tt><br />
| AXP803 I2C/RSB Data<br />
| I/O<br />
| Yes<br />
|-<br />
| PL2<br />
| <tt>WL-REG-ON</tt><br />
| Not Connected<br />
| N/A<br />
| N/A<br />
|-<br />
| PL3<br />
| <tt>WL-WAKE-AP</tt><br />
| Wake-on-WLAN Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL4<br />
| <tt>BT-RST-N</tt><br />
| Bluetooth Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL5<br />
| <tt>BT-WAKE-AP</tt><br />
| Wake-on-BT Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL6<br />
| <tt>DTR</tt><br />
| Modem DTR (Wakeup Request)<br />
| O<br />
| No<br />
|-<br />
| PL7<br />
| <tt>4G-PWR-BAT</tt><br />
| Modem Power Supply Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL8<br />
| <tt>ANX7688-CABLE_DET</tt><br />
| ANX7688 Cable Detection Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL9<br />
| <tt>ANX_RESET</tt><br />
| ANX7688 Reset Control<br />
| O<br />
| No (if held)<br />
|-<br />
| PL10<br />
| <tt>LCD-PWM</tt><br />
| LCD Backlight PWM Brightness Control<br />
| O<br />
| No<br />
|-<br />
| PL11<br />
| <tt>ANX7688-INT</tt><br />
| ANX7688 Alert Interrupt<br />
| I<br />
| Yes<br />
|-<br />
| PL12<br />
| <tt>POGO-INT</tt><br />
| Pogo Pin Interrupt<br />
| I<br />
| Yes<br />
|}<br />
<br />
=== Pins Held During Suspend ===<br />
<br />
=== Pins Active During Suspend ===<br />
<br />
=== Suggested Hardware Changes ===<br />
<br />
# Connect <tt>WL-REG-ON</tt> (PL2) and <tt>WL-PMU-EN</tt> (WiFi).<br />
# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1<br />
# Reconnect <tt>LINEOUTN</tt> to make the line output differential.<br />
# Replace <tt>WAKEUP_IN</tt> with <tt>AP_READY</tt> at PH8.<br />
# Swap <tt>DTR</tt> (PL6, '''no level shift''') and <tt>RI</tt> (PB2, level shift).<br />
# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt><!-- or DCDC1 (depopulate R1526)-->.<br />
# Connect the modem <tt>STATUS</tt> to a GPIO input (any pin bank is fine; this can reuse the level shifter previously connected to PL6).<br />
# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).<br />
# Connect the modem debug UART TX/RX to PD0-1.<br />
# 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.<br />
# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6). The signal would be driven by either PD6 or the ANX7688. If this is not possible, then prefer to at least connect AXP803 <tt>USB-DRVVBUS</tt>.<br />
# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)<br />
# 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>.<br />
<br />
=== Open Questions ===<br />
<br />
* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?</div>Smaeul