Difference between revisions of "PineNote"

From PINE64
Jump to navigation Jump to search
m (forgot a bit of the quote :))
Line 136: Line 136:
This decision requires the PineNote motherboard to be able to detect an AND condition between CC1 and CC2 and connect one of the SOC's UARTs to pins on the USB-C connector. In all other cases, the UART should be disconnected. It also requires the PINE64 Store ship a simple one-sided (no magical flipping here, sorry) connector board which breaks out USB 2.0 and UART.
This decision requires the PineNote motherboard to be able to detect an AND condition between CC1 and CC2 and connect one of the SOC's UARTs to pins on the USB-C connector. In all other cases, the UART should be disconnected. It also requires the PINE64 Store ship a simple one-sided (no magical flipping here, sorry) connector board which breaks out USB 2.0 and UART.


There were concerns that cheap USB-C cables have both CC1 and CC2 shorted together to save a wire. This may cause the PineNote to output 3.3v UART to a device that isn't expecting it, assuming the two are plugged together with a nonstandard cable. This seems unfounded (or not enough of a problem to worry about on a large scale), since the USB-C specification states in section B.2.3.1, "The general concept for setting up a valid connection between a DTS and TS is based on being able to detect the typical USB Type-C termination resistances.  However, detecting a Debug Accessory Mode connection requires that both CC pins must detect a pull-up (Rp) or pull-down (Rd) termination.  A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection"
There were concerns that cheap USB-C cables have both CC1 and CC2 shorted together to save a wire. This may cause the PineNote to output 3.3v UART to a device that isn't expecting it, assuming the two are plugged together with a nonstandard cable. This seems unfounded (or not enough of a problem to worry about on a large scale), since the USB-C specification states in section B.2.3.1, "The general concept for setting up a valid connection between a DTS and TS is based on being able to detect the typical USB Type-C termination resistances.  However, detecting a Debug Accessory Mode connection requires that both CC pins must detect a pull-up (Rp) or pull-down (Rd) termination.  A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection cannot be detected."


There were concerns that checking CC1 and CC2 being pulled high was not strictly to USB-C standard, as detecting them being pulled low is mentioned in the standard. However, detecting a pull-up condition is all that is required. According to the USB-C spec, 'B.2.4.1.5.1 ("UnattachedDeb.SRC Requirements"), a Debug and Test System (DTS) that is a power source must pull CC1/CC2 up, while the Target System (TS) in Unattached.SNK is supposed to pull them low.' In English, this means that we'd only need to detect a pull-up condition on CC1 and CC2, meaning a logical AND between them is a sane solution.
There were concerns that checking CC1 and CC2 being pulled high was not strictly to USB-C standard, as detecting them being pulled low is mentioned in the standard. However, detecting a pull-up condition is all that is required. According to the USB-C spec, 'B.2.4.1.5.1 ("UnattachedDeb.SRC Requirements"), a Debug and Test System (DTS) that is a power source must pull CC1/CC2 up, while the Target System (TS) in Unattached.SNK is supposed to pull them low.' In English, this means that we'd only need to detect a pull-up condition on CC1 and CC2, meaning a logical AND between them is a sane solution.

Revision as of 04:13, 19 August 2021

PineNote-1.jpg

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.

Specification

PineNote Pen function.jpg
PineNote Cover-1.jpg

General Information

  • Dimensions: 191.1x232.5x7.4mm
  • Weight: 438g

Core

  • CPU: RK3566 1.8GHz 64-bit quad-core A55
  • GPU: MALI G52 2EE
  • System memory: 4GB LPDDR4
  • Flash: 128GB eMMC

E-ink Display

  • Size: 10.3"
  • Resolution: 1404x1872
  • DPI: 227
  • Grayscale: 16
  • Front Light: 36 level cold and warm
  • Capacitive multi-touch panel
  • EMR pen digitizer

Network

  • WiFi: 2.4/5GHz 802.11a/b/g/n/ac
  • Bluetooth: 5.0

Audio

  • Build in stereo speaker
  • 4x DMIC microphone

Sensor

  • G-Sensor for portrait and landscape sensing

Power

  • 4000mAH LiPo battery
  • DC 5V @ 3A USB-C connector

Accessories

  • Optional EMR pen with magnetic attachment (included in the first production batch)
  • Optional Cover (included in the first production batch)


Software and OS Image Downloads

  • Not yet available


SoC and Memory Specifications

RK3566 icon.png

CPU Architecture

  • Quad-core ARM Cortex-A55@1.8GHz
  • AArch32 for full backwards compatibility with ARMv7
  • ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation
  • Includes VFP hardware to support single and double-precision operations
  • ARMv8 Cryptography Extensions
  • Integrated 32KB L1 instruction cache and 32KB L1 data cache per core
  • 512KB unified system L3 cache
  • TrustZone technology support
  • 22nm process, believed to be FD-SOI

GPU (Graphics Processing Unit) Capabilities

  • Mali-G52 2EE Bifrost GPU@800MHz
  • 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop
  • 128KB L2 Cache configurations
  • Supports OpenGL ES 1.1, 2.0, and 3.2
  • Supports Vulkan 1.0 and 1.1
  • Supports OpenCL 2.0 Full Profile
  • Supports 1600 Mpix/s fill rate when at 800MHz clock frequency
  • Supports 38.4 GLOP/s when at 800MHz clock frequency

NPU (Neural Processing Unit) Capabilities

  • Neural network acceleration engine with processing performance of up to 0.8 TOPS
  • Supports integer 8 and integer 16 convolution operations
  • Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet

System Memory

  • RAM Memory : 4GB LPDDR4.
  • Flash Memory: 128GB eMMC

PineNote Information, Schematics, and Certifications

  • Certifications:
    • Not yet available

Datasheets for Components and Peripherals


Development Efforts

Software

Hardware

This section includes discussions and their results regarding hardware changes to the PineNote.

Closed-Case UART

Developers usually don't like taking their devices apart to debug bootloaders. Therefore, it is important to provide resources to debug the PineNote's boot process such as a hardware UART. Recent PINE64 devices have included a hardware UART connected to their 3.5mm TRRS jacks through a hardware switch. However, the PineNote doesn't have an audio jack. It also doesn't have a convenient place to put a hardware switch which is accessible without taking the device apart. The case only has the affordance for a single USB-C port.

We decided to ask the PineNote product team to explore USB-C Debug Accessory Mode, where the product changes the USB-C port's personality when both CC1 and CC2 are pulled high. In normal usage, either CC1 or CC2 will be floating since these are the connector rotation pins. When both are detected, there is a very good chance that a debug harness is connected.

This decision requires the PineNote motherboard to be able to detect an AND condition between CC1 and CC2 and connect one of the SOC's UARTs to pins on the USB-C connector. In all other cases, the UART should be disconnected. It also requires the PINE64 Store ship a simple one-sided (no magical flipping here, sorry) connector board which breaks out USB 2.0 and UART.

There were concerns that cheap USB-C cables have both CC1 and CC2 shorted together to save a wire. This may cause the PineNote to output 3.3v UART to a device that isn't expecting it, assuming the two are plugged together with a nonstandard cable. This seems unfounded (or not enough of a problem to worry about on a large scale), since the USB-C specification states in section B.2.3.1, "The general concept for setting up a valid connection between a DTS and TS is based on being able to detect the typical USB Type-C termination resistances. However, detecting a Debug Accessory Mode connection requires that both CC pins must detect a pull-up (Rp) or pull-down (Rd) termination. A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection cannot be detected."

There were concerns that checking CC1 and CC2 being pulled high was not strictly to USB-C standard, as detecting them being pulled low is mentioned in the standard. However, detecting a pull-up condition is all that is required. According to the USB-C spec, 'B.2.4.1.5.1 ("UnattachedDeb.SRC Requirements"), a Debug and Test System (DTS) that is a power source must pull CC1/CC2 up, while the Target System (TS) in Unattached.SNK is supposed to pull them low.' In English, this means that we'd only need to detect a pull-up condition on CC1 and CC2, meaning a logical AND between them is a sane solution. IRC logs of this discussion can be found at PineNote/Debug_Accessory_Mode_Discussion.

It should be possible to make the UART connection and breakout cable magically flippable by connecting the UART multiple times to the USB-C port.

BSP Linux SDK

BSP Linux SDK ver 4.19 for PineNote and Quart64 model A SBC

Android SDK

Android 11 eink SDK for PineNote and Quart64 model A SBC

Retrieved from "https://wiki.pine64.org/index.php?title=PineNote&oldid=11097"