Product Idea: USB Flash Drives

[barray]

Hi Pine64'ers

Update: There is now a wiki where ideas from this thread are consolidated: https://wiki.pine64.org/wiki/PineFlash

I had a crazy random idea, but I think it is worth exploring. Open to some feedback.

I propose Pine64 looks into creating custom open-source flash drives. I think these are devices we all use regularly and I think there is some great opportunity to improve on them!

# Why?

Currently, flash drives are almost exclusively closed-source. This poses a few major problems:

1. Security: You have zero idea what is running on the drive. It would be exceptionally easy for example to change a file at will. Imagine this happening to an SSH key for example, which is quite easily recognizable.

2. Corruption: We've all been in this scenario where a flash drive suddenly fails without warning.

3. Encryption: Some drives offer "encryption", but this rarely includes the memory itself and if it does, it's all done client side. And then you have to trust this is actually robust and trust the implementation.

4. Planned Obsolescence: In theory a drive could purposely give out after so many writes or reads, forcing you to go out and buy another.

# Opportunities

I think there are tonnes of opportunities to improve on existing designs:

1. RAID: If you were to use several lower-capacity flash chips (which could also end up cheaper), the community could explore RAID to increase either speed, redundancy or both! This would need a minimum of two chips, ideally four.

2. Cache: It could be possible to do some intelligent caching - for example if you know a particular format is being used, you could cache the file table.

3. Encryption: Of course the big one could be some form of encryption. This could make this an attractive option for people who travel or want some protection! You may even want the drive to display something entirely different until some password is provided to reveal the real contents.

One way this could be done is to have it first present a small blank file system, where either the user or some script copies a key (possibly in response to some content already there) to the drive. The drive could then unmount and remount as the full drive and use this to decrypt the rest of the contents.

4. Wear Leveling: Just because companies claim to have really good wear-leveling, doesn't mean they actually do.

5. Compression: It might be possible to compress certain types of data. There are a few algorithms, such as LZ4 that don't really add too much overhead if they are unable to compress some data, but could yield large returns on compress-able data.

6. SMART: The drive could provide a SMART table to provide information about disk wear (the same thing SSDs do). This could even be calibrated to temperature and time for example.

7. Type A & Type C USB: Type C is likely the future, but there is also tonnes of devices still using type A. It would be cool to have a device that is robust for both.

8. Casing: A nice little piece of positive PR with the Pine64 logo

# Expectations

I imagine the first version will realistically only support USB 2 speeds at most, possibly USB 1, but I expect this community to be capable of getting up to USB 3 speeds after a few iterations.

There are some flash chips and USB controllers that already do most of the work, so this could greatly reduce the risk of v1 not working at all and to work on one problem at a time.

# Long-term

I suggest this could lay some ground-work for a custom M.2. drive, something some current Pine64 devices support and something I think future Pine64 devices will make more use of.

Open to ideas!

[Arwen]

In someways the current crop of USB flash drives have, as the FreeNAS / TrueNAS forums have found out, "raced to the bottom". Meaning they have tried to go as cheap as possible, with the end result they are not very reliable.

If such a project exists, my wish list would include;

• Preferably an open source processor, like RISC-V, as the controller
  
• Obviously open source firmware
  
• A careful design of one type of firmware, that has 2 sets of flash, (logical or physical). One for data, and one for the error detection and correction code. Like hard drives have today. That way we can use real error detection and correction.
  
• Another firmware feature of copy on write. Flash have to do it anyway because of erasing a block before writing.
  
• Yet another firmware feature. (Humor)We don't need no stinking TRIM.(/Humor) The flash firmware should simply erase any block that has been freed up and put it in the spares pool to be used for wear leveling and writes. So TRIM ends up being un-needed.
  
• USB attached SCSI, (aka UASP)
  
• SMART support, via UASP, so we can see when we are getting low on spare blocks
  
• The ability to shrink a drive, (though not with real data), so you can add more spares and make a drive last longer.
  
• In my opinion, if done, target reliability over density or speed. I want my data to survive!
  

As for the physical connector, perhaps using Type C with a Type C to Type A converter included.

Adding a type of internal RAID for even higher reliability sounds interesting. Using RAID-5 on 64GBytes worth of flash chips, would only use up 13GB or so. (Not including any overhead.)

[Julius_GU]

When I saw the headline, I was skeptical, but the way you laid it out has definitively convinced me .
This could be a very cool device. If it had a programmable controller inside, you could turn it into a rubber duckey, for example. Only for fun, not to do any harm, of course.
I think that something like this would be a good starting point.
When it comes to encryption, from what I understood you wanted to have some hardware wise encryption without a client program. This means that there will have to be an embedded controller, that can decrypt the storage when something like a password. There won't be a keyboard connected to the stick and inputting one from the computer requires client side software - which is unhandy in my opinion - since it isn't built into the HID standard. My proposal would thus be to have the decryption done once an on-usb-stick-fingerprint-scanner recognizes the fingerprint. A quick search on Amazon has shown parts from 5€ (about 5$) which seems like a fair price to me for an - in my humble opinion - amazing feature. What do you think?
Best Regards, Julius

[Julius_GU]

Here is what I have in mind, what do you think?

[barray]

@Julius_GU There are several idea I like in that PDF:

1. The Pine logo being lit and being a status LED. Perhaps it could be RGB to allow feedback of lots of different things.

2. I quite like the idea of the fingerprint scanner, I didn't even consider it! My brain went to a keypad when I was first thinking about this, but a scanner is a real no brainer. It could also be an input button for example.

3. Regarding the RiscV controller - it of course makes sense, it just needs to be fast enough. The good thing with this application is that we could likely get away within minimal additions to the RiscV chip if it already contains a small amount of RAM and some storage.

4. RAID I think *really* makes this stand out from anything else out there (apart from being open source). If you are using it to run a live distro from USB - you want it to boot each time without fail and be encrypted!

Additionally I think it could be cool to leave space for some headers on the PCB itself, so people can create hats for it. The fingerprint sensor itself for example could be on a hat rather than the main PCB.

Regarding the USB connectors, @Arwen made the point of shipping with a type C and a Type C to A adapter. Also ideally you want both ports on the same side (if you do have two).

In terms of total memory, I think ideally you are aiming for at least 8GB after RAID to end up with something that you could flash Linux onto and install some programs. In terms of which chips to use, whatever works out cheapest per GB - you could always load the PCB both sides with 512MB NAND.

---

I really suspect that there is space here to make a serious impact in open source. From what I could tell there is no open source memory. From a security and integrity perspective, you have to entirely trust that various manufacturers have done their jobs correctly.

And in the long run I think we could be looking at a feasible path towards building M.2. storage for future Pine devices. Once we're up to about USB 2 speeds we are already about the speed of the eMMc currently shipped (hell some HDDs don't reach this), but if we can get to USB 3 speeds then I think it'll be quite future proof. I imagine a future where Pine devices ship with their own storage solution that can be entirely controlled through software!

---

I think the BL602 could be a great way to start exploring this [0]. It's a $2 32 bit RiscV which the community is already working on. It has 128kB ROM, 276kB SRAM and 2MB embedded flash [1].

I'm thinking we could design a hat for this device to explore adding NAND and a USB A connector?

Having a look online, we should be able to pick up 4 512Mb NAND flash chips (with pins that can be soldered) for $3 a piece at low volume.

PCB way will do 10 boards for $30 USD (delivered), although it seems pick and place is also quite cheap if eventually we wanted to look at BGA parts.

[0] https://pine64.com/product/pinenut-model...e5-module/

[1] https://wiki.pine64.org/wiki/Nutcracker

[barray]

I should have linked to the $4 evaluation board with the breakouts: https://pine64.com/product/pinecone-bl60...46c16e2e66

Page 7 of the BL602/4 documentation suggests it supports between 1MHz and 192MHz: https://raw.githubusercontent.com/pine64...1.6_en.pdf

What's nice is that we get some crypto functions on the chip itself, meaning we should be able to keep that aspect nice and speedy.

With one instruction per cycle, that should give us full-speed (12Mb/s) and get about half way towards high-speed (480Mb/s): https://en.wikipedia.org/wiki/USB

From what I understand, USB uses a multiplier to negotiate speed - so we can slowly increase it as the software gets better: https://usb.org/sites/default/files/usb_20g.pdf

I would need to look into this further, but from my understanding TinyUSB could be a viable method for implementing a slave mass storage device: https://github.com/hathach/tinyusb

I think there is a viable path forwards anyway. The NAND will likely be some form of serial (probably SPI). The Pine Cone has plenty of I/O, so we should be able to get something going.

[Arwen]

Their are companies producing 2Mbit & 4Mbit SPI flash chips. Don't know how much they cost, but obviously using something smaller would be cheaper. Giga Devices, which makes compatible 128Mbit SPI flash in the PineBook Pro, (and probably other devices), makes such. May be not fast enough...

Note that USB 2 speeds are 480Mbit per second, about 30MByte per second maximum throughput. That's because it's a half duplex protocol, accounts for USB overhead and the original USB Block-only transfer was not designed for high speed storage. That's where UASP comes in to play. UASP can improve storage throughput noticeably.

So, no, USB 2 is no where near 100Mbytes per second of a eMMC or very low end hard drive.

[barray]

Their are companies producing 2Mbit & 4Mbit SPI flash chips. Don't know how much they cost, but obviously using something smaller would be cheaper. Giga Devices, which makes compatible 128Mbit SPI flash in the PineBook Pro, (and probably other devices), makes such. May be not fast enough...

Note that USB 2 speeds are 480Mbit per second, about 30MByte per second maximum throughput. That's because it's a half duplex protocol, accounts for USB overhead and the original USB Block-only transfer was not designed for high speed storage. That's where UASP comes in to play. UASP can improve storage throughput noticeably.

So, no, USB 2 is no where near 100Mbytes per second of a eMMC or very low end hard drive.

I was thinking of something more like this: https://nz.mouser.com/ProductDetail/Winb...52Bg%3D%3D

Datasheet (page 6): https://nz.mouser.com/datasheet/2/949/w2...608377.pdf

If you see on page 8, the SOIC 300-mil should be hand solder-able - so quite viable for initial testing.

Apparently this can reach up to 50MB/s "continuous data transfer rate". Have a few of these and you can theoretically multiply the speed of the memory (as long as your controller can handle it) - so we should be able to max out USB 2.0 and look towards USB 3 speeds (in theory).

> Once we're up to about USB 2 speeds we are already about the speed of the eMMc currently shipped (hell some HDDs don't reach this), but if we can get to USB 3 speeds then I think it'll be quite future proof.

I was specifically thinking about something like the A64, which I believe can't really make use of 100MB/s. Even if it could - using USB 3 we should be able to beat that data rate anyway. And the goal would be to ultimately get the basics for an open source M.2 drive up and running (high speed comms, high speed memory management, etc).

[barray]

I should also add the disclaimer that this is really to get the ball rolling and will be a process of solving (many) problems. I think going for a USB storage device allows us to excuse a lack of speed on the first version of the device and still call it a success.

I am wondering how it is best to push forwards... Is Pine interested in the project? Will they offer support? Is this the best place to develop the project? It would be good to hear from somebody representing Pine and hear their thoughts.

[Julius_GU]

Unfortunately, I have very little knowledge related to this, but I'm quite interested in the subject.
I think that the most important thing to tackle first is to do the usb protocoll and raid.