Product Idea: USB Flash Drives

[dsimic]

Well, if people are asking the same question over and over, it seems like it's a good time to invest some time to automate the handling of such queries. I think they now have a Telegram chat or something that advises when products are about to drop, but I guess they really need something else too.

That's all fine, but I'm still hearing nothing from Pine64, and I haven't asked about product availability.

Well I was initially looking at using NAND SPI flash with quad SPI: https://nz.mouser.com/datasheet/2/949/w2...608377.pdf

That gives you up to 50MB/s and you could then pick up some extra speed with the RAID format. I suspect the latency between read request and reply to be constant for example (and most of these devices support artificial delay in the worst case), so you would just need to be smart about chip select and could multiplex whilst each chip is busy. If you were doing mirroring for example, I wonder if you could even chip select two identical flash units at the same time.

That would be really neat!   For a USB 2.0 storage device, using quad-SPI flash should provide more than enough speed, and would allow rather easy implementation of different RAID levels, while keeping the price of device low.  Is there enough documentation available for the BL602?

What about the USB interface, required for exposing the storage to the host?  I cannot see that available in the BL602?

I would try to stay away from this, I imagine this will just end up being a headache in the long run. There's no reason why a flash drive company might not run several revisions based on what parts are cheapest at the time, so components may not even match up even if we buy the same device.

On second thought, I agree with you.  There's no way to know in advance what's actually inside an off-the-shelf USB flash drive, regardless of the actual make and model, which invalidates the whole idea about "harvesting" the parts.

Right, and it's the project that most people point towards when you suggest 'open source storage'. This is why I think this project is so important - because there really isn't anything out there being actively worked on.

Furthermore, no open storage device is easily and inexpensively available to pretty much anyone, which is the key, if you agree.  I wonder where and how could I buy one of the referenced OpenSSD development boards?  Even if buying those boards is actually possible, it would surely cost an arm and a leg, effectively rendering them unavailable.

[barray]

That would be really neat!   For a USB 2.0 storage device, using quad-SPI flash should provide more than enough speed, and would allow rather easy implementation of different RAID levels, while keeping the price of device low.

Yeah, I think it's quite feasible using the QSPI interface you suggest - it even mentions supporting up to four slaves. That should be more that enough to begin tests. For full speed QSPI we may run into problems with signals, etc, but we'll run into that when we get there.

Is there enough documentation available for the BL602?

@lupyuen has done some epic work in this space: https://lupyuen.github.io/articles/book

I can't tell if he got QSPI working, but there is certainly more than enough to get going there.

What about the USB interface, required for exposing the storage to the host?  I cannot see that available in the BL602?

Me neither, we might be looking at USB-SPI interface chip initially: https://ww1.microchip.com/downloads/en/D...22288A.pdf

We should in theory be using something with USB support already, but the BL602 is nice simply because the community already works on it and it has everything else we need, as well as being RISC-V. Developing hardware for the BL602 should be as simple as just developing a 'hat' PCB - which makes it quite attractive as a starting platform: https://files.pine64.org/doc/Pinenut/NUT...%201.0.pdf

On second thought, I agree with you.  There's no way to know in advance what's actually inside an off-the-shelf USB flash drive, regardless of the actual make and model, which invalidates the whole idea about "harvesting" the parts.

Not to mention how difficult some of those chips may be to solder without damaging them in some way.

Furthermore, no open storage device is easily and inexpensively available to pretty much anyone, which is the key, if you agree.  I wonder where and how could I buy one of the referenced OpenSSD development boards?  Even if buying those boards is actually possible, it would surely cost an arm and a leg, effectively rendering them unavailable.

I'm not sure you can buy them - and the added complexity overhead with all the crazy stuff it is able to do for the purpose of debugging.

[dsimic]

@lupyuen has done some epic work in this space: https://lupyuen.github.io/articles/book
I can't tell if he got QSPI working, but there is certainly more than enough to get going there.

I've already seen that, great work!

Me neither, we might be looking at USB-SPI interface chip initially: https://ww1.microchip.com/downloads/en/D...22288A.pdf

We should in theory be using something with USB support already, but the BL602 is nice simply because the community already works on it and it has everything else we need, as well as being RISC-V. Developing hardware for the BL602 should be as simple as just developing a 'hat' PCB - which makes it quite attractive as a starting platform: https://files.pine64.org/doc/Pinenut/NUT...%201.0.pdf

Attaching a USB 2.0 device interface over SPI may suffice, but we'd need something better than the MCP2210 you've linked above.  It runs at Full-Speed USB 2.0 (12 Mbit/s), which is very slow; we'd really need a High-Speed USB 2.0 (480 Mbit/s) interface.

It wouldn't be the greatest thing in the world, for sure, but I agree with you on leaning toward the BL602.  Basically, the new open storage device would be built on top of the already existing community work, increasing its value further.  Also, that approach should make it possible to develop and release the new device (i.e. a "hat") faster, which is always good.

Using the BL602 should also allow the new USB storage device to be somewhat easily turned into some sort of a barebone NAS accessed over WiFi or even Ethernet.  That would be another neat feature, if you agree.

Edit: One possible issue preventing the idea of making it as a "hat" could be the already present SPI flash on the BL602 "baseboard".  There has to be some SPI flash already on the "baseboard", which would in turn prevent quad-SPI flash from being used on the "hat".

[barray]

Attaching a USB 2.0 device interface over SPI may suffice, but we'd need something better than the MCP2210 you've linked above.  It runs at Full-Speed USB 2.0 (12 Mbit/s), which is very slow; we'd really need a High-Speed USB 2.0 (480 Mbit/s) interface.

Yeah, it was just the first example I found on a little search. The bottleneck would likely be the BL602 SPI bus speeds to be honest. I haven't found any good data on it yet.

It wouldn't be the greatest thing in the world, for sure, but I agree with you on leaning toward the BL602.  Basically, the new open storage device would be built on top of the already existing community work, increasing its value further.  Also, that approach should make it possible to develop and release the new device (i.e. a "hat") faster, which is always good.

Right. We have our own experts on the device within the community itself and any improvements will benefit the community too. Being able to release different hats should also reduce the costs a small amount.

Using the BL602 should also allow the new USB storage device to be somewhat easily turned into some sort of a barebone NAS accessed over WiFi or even Ethernet.  That would be another neat feature, if you agree.

Haha, it could very well also be some networked storage! It could also make the start of a really nice MP3 player (with a display and DAC) I guess the point is that the possibilities are really endless once you get some decent storage.

Edit: One possible issue preventing the idea of making it as a "hat" could be the already present SPI flash on the BL602 "baseboard".  There has to be some SPI flash already on the "baseboard", which would in turn prevent quad-SPI flash from being used on the "hat".

Where is it hiding? https://wiki.pine64.org/images/a/af/Pine...-small.jpg

I see the BL602 and clock crystal on the upper board, then some USB chip and power modulation on the lower board.

On the Wiki, when it talks about 2MB embedded flash, I think it means inside the BL602 itself? https://wiki.pine64.org/wiki/Nutcracker

[Julius_GU]

Edit: One possible issue preventing the idea of making it as a "hat" could be the already present SPI flash on the BL602 "baseboard".  There has to be some SPI flash already on the "baseboard", which would in turn prevent quad-SPI flash from being used on the "hat".

Where is it hiding? https://wiki.pine64.org/images/a/af/Pine...-small.jpg

Excuse me if I misunderstood your question, but I think it is on the IC itself

https://github.com/pine64/bl602-docs/blo...1.6_en.pdf   (PAGE 6)
(see attachement)

Using the BL602 should also allow the new USB storage device to be somewhat easily turned into some sort of a barebone NAS accessed over WiFi or even Ethernet.  That would be another neat feature, if you agree.

Love It

Ps. For some reason, the forum inserts newlines every time and I cant delete them, sorry
Edit: Thanks for the tip about edit source

[barray]

Excuse me if I misunderstood your question, but I think it is on the IC itself

https://github.com/pine64/bl602-docs/blo...1.6_en.pdf   (PAGE 6)

So on page 7 you have "XIP QSPI/SPI Flash with hardware decryption support" and "Embedded Flash (Optional)" - it's not obvious to me that the embedded flash operates through the XIP SPI section. I looked through the whole document, but couldn't see anything that for sure showed that the optional flash is on the XIP SPI bus.

If it was on the XIP SPI bus, that would raise different questions, like how it would boot up when there are up to four devices? Which one does it enable before it's loaded it's first byte of code?

By the way, I believe the limit of four XIP SPI devices could just be the four DMA buffers, in which case they could be remapped in realtime... With a given RAID configuration we could make guarantees about which flash device will be active when... Experiments would be needed of course.

[barray]

Additionally to my previous point about DMA buffers, there's nothing stopping us loading from internal into RAM what we need, then switching the four DMA buffers over to our external flash devices. As long as we can switch off the internal flash storage, I can't see a problem with this approach.

It *should* be possible to disable the internal flash if it's on the XIP SPI bus, if you can't then that effectively disables the adding of additional devices on that bus - which would be dumb. I can't imagine anybody doing such a thing. Also if you can disable the flash then you can run the flash in an ultra-low power saving mode, which you for sure would want on an IoT designed device.

[dsimic]

Yeah, it was just the first example I found on a little search. The bottleneck would likely be the BL602 SPI bus speeds to be honest. I haven't found any good data on it yet.

Well, you're right and unfortunately there's some bad news.   Here's a quotation from the BL602 feature list, found on page 6 of the BL602 datasheet:

One SPI master/slave with max clock 40Mbps

Consequently, even with the quad-SPI flash connected to a completely separate controller and interface (according to the block diagram on page 9 of the BL602 datasheet), anything going through the BL602's SPI bus would be limited to 40 Mbit/s, which includes the required USB interface.  Quite frankly, a storage device that provides about 4 MB/s at its USB interface would be rather pointless.

Strictly in theory, another approach might be to use the BL602's SDIO 2.0 interface to connect a USB interface.  It should provide reasonable speeds, but I really don't think that an appropriate SDIO-to-USB bridge device exists.  There are USB devices that provide an SDIO interface, but there's pretty much no reason for an SDIO device that provides a USB interface to exist.

Unfortunately, I'm no longer optimistic about using the BL602 for the new storaga device, it would be unusably slow.   Quite frankly, everything says that we should look for a better microcontroller choice for the new storage device.

As a side note, more information about the software side of the BL602's SPI interface is available here.

Where is it hiding? https://wiki.pine64.org/images/a/af/Pine...-small.jpg
I see the BL602 and clock crystal on the upper board, then some USB chip and power modulation on the lower board.
On the Wiki, when it talks about 2MB embedded flash, I think it means inside the BL602 itself? https://wiki.pine64.org/wiki/Nutcracker

You're right, according to the wiki page and the released schematic, the BL602 boards released by Pine64 provide 2 MB of embedded flash.   Furthermore, the IC on the board picture is labeled BL602L20, which additionally confirms that it contains 16 Mbit (2 MB) of embedded flash (see my comment below).

Excuse me if I misunderstood your question, but I think it is on the IC itself
https://github.com/pine64/bl602-docs/blo...1.6_en.pdf  (PAGE 6)

So on page 7 you have "XIP QSPI/SPI Flash with hardware decryption support" and "Embedded Flash (Optional)" - it's not obvious to me that the embedded flash operates through the XIP SPI section. I looked through the whole document, but couldn't see anything that for sure showed that the optional flash is on the XIP SPI bus.

If it was on the XIP SPI bus, that would raise different questions, like how it would boot up when there are up to four devices? Which one does it enable before it's loaded it's first byte of code?

According to the table on page 11 of the BL602 datasheet, the memory map includes space for 16 MB of XIP (execute in place) flash memory.  It is unclear whether those 16 MB present the liimit for the size of the external flash?  Probably not, but the XIP feature should require the flash to be part of the memory map?  Maybe only one part ("XIP window") of the flash is mapped at once?  Also, the memory map says nothing specific about the embedded flash.

Another interesting piece of information is available on page 29 of the BL602 datasheet.  When it comes to the embedded flash, there seem to be four variants of the BL602: no embedded flash, 8 Mbit (1 MB), 16 Mbit (2 MB) and 32 Mbit (4 MB) of embedded flash.

Ps. For some reason, the forum inserts newlines every time and I cant delete them, sorry

You can edit the source of your posts, by clicking on the rightmost button on the editor toolbar, and remove any erroneous newlines.  That's also how I write posts most of the time.

[barray]

Well, you're right and unfortunately there's some bad news.   Here's a quotation from the BL602 feature list, found on page 6 of the BL602 datasheet:

One SPI master/slave with max clock 40Mbps

Consequently, even with the quad-SPI flash connected to a completely separate controller and interface (according to the block diagram on page 9 of the BL602 datasheet), anything going through the BL602's SPI bus would be limited to 40 Mbit/s, which includes the required USB interface.  Quite frankly, a storage device that provides about 4 MB/s at its USB interface would be rather pointless.

Multiply that by four for quad SPI channels, so 12MB/s (or 96Mb/s) - still not great, but better. And yeah it's not ideal to share these with the USB interface too. We're also going to struggle to go much faster anyway if we're going through a header interface due to capacitance and interference.

Strictly in theory, another approach might be to use the BL602's SDIO 2.0 interface to connect a USB interface.  It should provide reasonable speeds, but I really don't think that an appropriate SDIO-to-USB bridge device exists.  There are USB devices that provide an SDIO interface, but there's pretty much no reason for an SDIO device that provides a USB interface to exist.

I think SPI is still the way to go, even if it means bit-bashing SPI to the USB interface for example (which should be able to clean it up ready for USB).

Unfortunately, I'm no longer optimistic about using the BL602 for the new storaga device, it would be unusably slow.   Quite frankly, everything says that we should look for a better microcontroller choice for the new storage device.

I never thought it would be the final controller, it would be much better to have something that supports USB without need for an interface chip - and offers more SPI channels. The entire point of using the BL602 is that we could concentrate on building the flash storage hat, then swap out the base-board later. It allows for incremental development. We can move to a different RISC-V chip at a later date. I think there is already tonnes of risk in this project, so starting with something known is much better.

A good candidate might be the RISC-V SBC mentioned here: https://www.pine64.org/2021/02/15/februa...-and-tell/

That could actually be way too powerful though...

Anyway, I suspect we will have our hands full with just getting the hat off the ground and working correctly - there's a lot of unknowns, such as interfacing with the flash chips and speaking USB, as well as RAID and storage integrity reporting. More than enough stuff to keep us busy.

According to the table on page 11 of the BL602 datasheet, the memory map includes space for 16 MB of XIP (execute in place) flash memory.  It is unclear whether those 16 MB present the liimit for the size of the external flash?  Probably not, but the XIP feature should require the flash to be part of the memory map?  Maybe only one part ("XIP window") of the flash is mapped at once?  Also, the memory map says nothing specific about the embedded flash.

I think the 16MB limitation is purely from that XIP limitation - but that shouldn't be a limitation for QSPI. Usually these 32 bit controllers will have some kind of memory address width of 24 bits (2^24 = 16777216). Then you memory map that in RAM at some offset. There is nothing stopping us sending any QSPI commands we want and address however much data we want to - it just can't be XIP.

[dsimic]

Multiply that by four for quad SPI channels, so 12MB/s (or 96Mb/s) - still not great, but better. And yeah it's not ideal to share these with the USB interface too. We're also going to struggle to go much faster anyway if we're going through a header interface due to capacitance and interference.

Unfortunately, that multiplication doesn't apply.   According to the feature list in the BL602 datasheet, the 40 Mbit/s limit applies to the general-purpose SPI interface that the SPI-to-USB bridge would be connected to.  Thus, whatever happens inside the storage device cannot leave it faster than about 4 MB/s, which is slow.  The datasheet actually provides no information about the maximum speed of the quad-SPI flash interface, but the general-purpose SPI already presents a bottleneck.

I never thought it would be the final controller, it would be much better to have something that supports USB without need for an interface chip - and offers more SPI channels. The entire point of using the BL602 is that we could concentrate on building the flash storage hat, then swap out the base-board later. It allows for incremental development. We can move to a different RISC-V chip at a later date. I think there is already tonnes of risk in this project, so starting with something known is much better.

Anyway, I suspect we will have our hands full with just getting the hat off the ground and working correctly - there's a lot of unknowns, such as interfacing with the flash chips and speaking USB, as well as RAID and storage integrity reporting. More than enough stuff to keep us busy.

I agree on the risk, with all that requiring a lot of work, and with many things still unknown.  The BL602 "baseboard" might be very well used as a stepping stone, with a clear intention to upgrade to a better "baseboard" down the road.  However, my primary concern is that a lot of work would be poured into creating a storage device that would hardly be much more than a proof of concept, so it might be good to plot a clear path for the "baseboard" upgrade from the beginning.

Please, don't get me wrong.  Crafting an open storage device that's built using open-source tools and provides about 4 MB/s through its USB interface is no small feat and I'd be happy to see it ticking.  However, I'm pretty sure that not many other people would share the excitement about those 4 MB/s.