PinePhone v1.1 - Braveheart
The PinePhone v1.1 "Braveheart" is a hardware revision of the PinePhone due to ship in January 2020.
This page contains resources which are exclusive to the 1.1 revision of the PinePhone. For other revisions, or for resources related to all PinePhone revisions, see PinePhone.
Schematic
Changes from 1.0
Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.
- Added CPU shielding and cover plate
- Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed
- Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot
- Connect WiFi enable to VD33
- Set the EG25G's PWRKEY on by default (see resistor R1526)
- Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software.
- Add voltage shift to Pogo pins I2C-CLK, I2C-DATA, and INT. The Pogo Pin specified voltage is 3.3v while the A64's I2C is 2.8V.
Known issues
This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision.
Excess power consumption while using USB OTG
The N_VBUSEN/DRIVEVBUS input on the AXP803 PMIC, labeled USB-DRVVBUS on the schematic, is not connected to the USB OTG boost regulator enable input, because R1300 is marked "NC". This prevents the AXP803 from automatically detecting when the USB port is being powered from the battery. Thus, the PMIC continues to draw power from the USB port, and this doubles the drain on the battery (since the whole phone is being powered by the USB OTG boost regulator).
This would be fixed by populating R1300.
There is a possible (but less reliable) software workaround, by setting a control bit to temporarily disable drawing power from the USB bus.
Modem Ring Indicator placement is not ideal
The EG25G's Ring Indicator pin is currently routed to GPIO pin PB2.
Ring Indicator is a configurable signaling pin capable of notifying the modem's host of incoming messages or calls. This makes it important to read the status of the pin during (ARISC / Super Standby) sleep, since incoming calls or text messages must wake the device.
Using the PB bank of GPIO on the A64 requires VCC-IO to be switched on. DCDC1, which powers VCC-IO, also powers most of the rest of the phone, including the eMMC, microSD, and USB controller, and enables the POGO pins, WiFi, modem sound, motor, headphone port, etc.
The only GPIO bank that works (can receive interrupts) while the A64 is suspended, and is independent from the regulators powering other periphherals, is Port L (on R_PIO).
Modem AP_READY signal is not connected
The 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 AP_READY signal needs to be connected. The modem needs that signal to know when the host is asleep (and the modem needs to queue its messages and wake it up), and when the host has finished waking up (and is ready to receive the queued messages).
Ideally, when the modem is communicating over USB, it can use the USB host suspend state to know when the host is active, and would not need the separate AP_READY signal. It is not known whether this is the case.
Modem PWR_KEY signal is not connected
On dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can't do anyhting to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).
It would be nice to also have access to the STATUS signal from the modem, so that the driver can detect whether the modem is on or off (userspace might have turned modem off already via AT commands). Given that PWR_KEY pulse will either turn the modem on or off, based on the current status, it's necessary to know the current status before sending the pulse.
There's a STATUS signal routed to PWR_KEY on BraveHeart, that keeps the PWRKEY deasserted when the modem is on and it's not possible to pull it up from PB3, even if R1516 would be optionally mounted. So after powerup you can't change PWR_KEY signal anymore from PB3 even if R1516 is mounted, and it's not possible to turn off the modem via PB3.
Modem UART flow control is broken
BB-TX and BB-RX are connected to UART3 (PD0/PD1). BB-RTS and BB-CTS are connected to UART4 (PD4/PD5). To use hardware flow control, TX/RX would need to be connected to UART4, swapping PD0/PD1 with the motor control and rear camera reset GPIOs at PD2/PD3. This would need a device tree change.
Hardware flow control can be disabled with the AT+IFC command, and USB can also be used for commands instead of the UART. So the impact of this problem is unclear.
Modem has access to sensors on I2C1
The modem is a master on the I2C1 bus. A malicious firmware on the modem would be able to read the phone's gravity/light/proximity sensors and prevent the main Linux OS from reading them. The modem's audio design note describes the AT+QIIC command which can be used to read and write registers on I2C devices.
According to the modem documentation, its I2C interface is only used for direct connection to a standalone audio codec. On the PinePhone, since the modem's audio is routed through the A64 SoC, the modem's I2C interface has no legitimate use.
The modem's I2C interface should be left floating. U1503 pins A1, A2, B1, and B2 can be disconnected, and R1527/R1528 can be removed.
WiFi module cannot be disabled in software
Neither the WL-REG-ON nor WL-PMU-EN signal is connected to anything, and the WiFi module's CHIP_EN 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.