User:Barray/PineFlash

The following is the documentation draft for a proposed new PINE64 storage product, PineFlash. As such, PineFlash is proposed by the community and, as of April 2021, is neither endorsed nor acknowledged by PINE64 as a possible new official PINE64 product. This content is the result of initial discussions about this storage device, documented in this forum thread.

Please, consider joining us for discussion in IRC.

Goal

The aim of this project is to create an open-hardware USB flash drive, hence the name PineFlash, which can act as the basis of future projects in the area of open storage. An open-hardware flash device with open-source firmware would allow the community to address storage safety and information security. Additionally, issues such as speed, functionality and compatibility could also be addressed.

Requirements

Property	Minimum	Ideal
Read speed	12 Mbit/s (Full-Speed USB 1.x)	480 Mbit/s (High-Speed USB 2.0)
Write speed	12 Mbit/s (Full-Speed USB 1.x)	480 Mbit/s (High-Speed USB 2.0)

Road Map

This is intended to document the project direction towards a manufacturing-viable device.

Prototype

Hardware

The initial idea is for the storage device to be in form of a "hat" for one of the BL602 devices manufactured and sold by PINE64, such as the PineCone board.

The initial idea for the base device was the PineCone board. Whist being a great device and RISC-V, we have since decided to move towards a better supported, more capable board.

We now look towards using the Teensy 4.1, which offers 480Mb/s USB throughput out of the box.

TO-DO: Plan out hardware steps.

Software

1. USB 1.x speed mass storage device, no real storage. Get the controller presenting itself as a mass storage device. Data read and written will just be placeholder data to prove that the USB communication is working correctly.
2. Single flash chip selected for storage - quad-SPI. Prove out that we can select a single flash chip, store data to it and read it back. This proves our understanding of the quad-SPI interface and implement some basic interface for communicating with a single flash chip.
3. Multiple flash chips selected for storage - quad-SPI. Prove that we can communicate with multiple flash chips via quad-SPI.

Prototyping

This is the documentation of the initial prototype design.

Hardware

As mentioned on the Teensy 4.1 website, it offers the following:

• ARM Cortex-M7 at 600 MHz
• Float point math unit, 64 & 32 bits
• 7936K Flash, 1024K RAM (512K tightly coupled), 4K EEPROM (emulated)
• QSPI memory expansion, locations for 2 extra RAM or Flash chips
• USB device 480 Mbit/sec & USB host 480 Mbit/sec
• 55 digital input/output pins, 35 PWM output pins
• 18 analog input pins
• 8 serial, 3 SPI, 3 I2C ports
• 2 I2S/TDM and 1 S/PDIF digital audio port
• 3 CAN Bus (1 with CAN FD)
• 1 SDIO (4 bit) native SD Card port
• Ethernet 10/100 Mbit with DP83825 PHY
• 32 general purpose DMA channels
• Cryptographic Acceleration & Random Number Generator
• RTC for date/time
• Programmable FlexIO
• Pixel Processing Pipeline
• Peripheral cross triggering
• Power On/Off management

Despite not appearing to have dedicated quad-SPI, it should be possible to make use of the ~55 digital pins to implement any protocol required.

Schematic

TO-DO: The proposed schematic for the device.

BOM

TO-DO: BOM based on Teensy 4.1 board.

PCB

TO-DO: The PCB design for the device.

Software

For initial development it will be possible to use the Arduino IDE and eco-system to use existing libraries, extend functionality and test out initial ideas. It also provides a relatively fool-proof method for flashing new firmware to the device.

Libraries

TO-DO: Document the prototype's software stack.

• TinyUSB - An open source software stack for slave USB devices

Testing

TO-DO: Figure out exactly how the prototype will be tested to ensure robustness and performance.

Suggested Features

This is a list of suggested features, collated and attributed (where possible). This list is not meant to encapsulate every possible idea or suggestion, just a series of plausible ones that can be considered within the scope of this project.

• Type-A & Type-C USB interfaces (barray)
• RAID (barray)
• Dynamically adjusted wear leveling pool (Arwen)
• Keep 2 copies of the wear leveling & indirect table, with checksum, to avoid corruption (Arwen)
• USB Attached SCSI (UASP) (Arwen)
• SMART (probably requires UASP first) (Arwen)
• Ability to define and enforce write barriers (dsimic)
• Fingerprint scanner (Julius_GU)
• Lit Pine logo on casing (Julius_GU)

Additional Resources

• The PineDrive (Julius_GU)