Pi 3 sata controller

[vision2000]

Is there any news on how to be able to get a sata controller to work on a pi 3?

Understand there are fast secondary pins on the interface but no documentation for them??

The pi 3 in theory should make a really useful NAS

David

[rpdom]

Us a USB->SATA adaptor. It is the fastest and easiest way to do it.

[W. H. Heydt]

While I agree that a fast bus available for mass storage would be an excellent addition to the Pi, one does not exist at present. Or--at least--not one that anyone outside of the RPF knows about.

My own feeling is that a fast mass storage bus is the last significant component missing from the Pi...and most (but not all) other boards. Should such a thing be added, there are a number of possibilities. Among them are SATA (preferably at least SATA-II), M.2 (PCIe, which is very, very unlikely), or USB 3.0. Part of the problem is, if an HDD/SSD bus connector were added to the Pi, where could it be put?

If you really HAVE to have a fast mass storage bus, there are a few choices that I know of in the inexpensive SBC market. The boards based on the Allwinner A20 (e.g. Cubieboard 2, Banana Pi) generally expose a SATA-II port. There is at least one board with a USB 3.0 port (the Roseapple Pi). The problem is that the SoCs are all back at least one "generation" of Pi. The A20 is a dual-core A7 at 1GHz with 1GB RAM (basically, 1/2 of a Pi2B) and the Roseapple Pi is a quad-core A9 at 1.1GHz with 2GB RAM, which makes it about a Pi2.5B. However, you won't get the kind of software or community support with those boards that you get with a Pi.

My big hope is that in the future--probably about 3 years--the next major Pi iteration--call it the "Pi4"--will at least have USB 3 on the SoC, even if it is not initially exposed. And then at some point, the USB ports on the board can be changed to be USB 3.

[mikronauts]

"SMI" ie Secondary Memory Interface bus is there on all A+/B+/2/3/Zero Pi's, but for some unknown reason the RPF is not releasing information on how to use it.

I've asked a number of times in the last couple of years, and the most encouraging reply I ever got is "we will consider documenting it in the future". I even tried to get the information from a Broadcom FAE, and was told "ask the foundation, they have the info you need"

What I know so far:

- 16 bit data bus
- 16 bit address bus
- an ALE like signal
- perhaps eight low order memory address bits on eight pins

It seems to have been made for attaching a small (<16MB) amount of static ram / flash, but I can think of MANY uses for it!

I'd love to play with it, but at the very least I'd need control register documentation, exact pin/function, and how to enable it (with the registers).

While I agree that a fast bus available for mass storage would be an excellent addition to the Pi, one does not exist at present. Or--at least--not one that anyone outside of the RPF knows about.

My own feeling is that a fast mass storage bus is the last significant component missing from the Pi...and most (but not all) other boards. Should such a thing be added, there are a number of possibilities. Among them are SATA (preferably at least SATA-II), M.2 (PCIe, which is very, very unlikely), or USB 3.0. Part of the problem is, if an HDD/SSD bus connector were added to the Pi, where could it be put?

If you really HAVE to have a fast mass storage bus, there are a few choices that I know of in the inexpensive SBC market. The boards based on the Allwinner A20 (e.g. Cubieboard 2, Banana Pi) generally expose a SATA-II port. There is at least one board with a USB 3.0 port (the Roseapple Pi). The problem is that the SoCs are all back at least one "generation" of Pi. The A20 is a dual-core A7 at 1GHz with 1GB RAM (basically, 1/2 of a Pi2B) and the Roseapple Pi is a quad-core A9 at 1.1GHz with 2GB RAM, which makes it about a Pi2.5B. However, you won't get the kind of software or community support with those boards that you get with a Pi.

My big hope is that in the future--probably about 3 years--the next major Pi iteration--call it the "Pi4"--will at least have USB 3 on the SoC, even if it is not initially exposed. And then at some point, the USB ports on the board can be changed to be USB 3.

[adun]

Actually there are two fast data buses on the soc.

1. SMI: The pins are available on the GPIO header as alt function. As mikronauts has mentioned there is still no documentation available for it. However an overlay exists to talk to NAND flash https://github.com/raspberrypi/linux/bl ... verlay.dts. This overlay uses GPIO 0 to 15. As seen SMI will eat up a lot of GPIOs.
   
   
2. HOST: The host Interface is a 8/16-bit data bus that can be configured to do DMA transfers. Unfortunately the pins are not brought out (internally connected to GND) on any of the RPi versions including CM. I still hope that one day we will get access to those pins on an new CM or revision. As those pins are additional to the GPIO banks.
   

I suppose one reason why the informations are kept back is that original all the interfaces (GPIO, etc) were only available for the GPU, that (we all know) is closed source. So the common known interfaces like uart,i2c,spi had to be made accessible from the ARM.
Probably this is not so trivial for SMI/Host or would require the leak of some proprietary broadcom code.

[vision2000]

IMHO the foundation have really boobed by not building in a solution for fast sata.

There are so many applications which require sata for which USB 3 is not a viable solution.

An add on board with at least two esata ports (and perhaps some buffer ram) would be the way to go with sata 3 the main target.

David

[6by9]

"SMI" ie Secondary Memory Interface bus is there on all A+/B+/2/3/Zero Pi's, but for some unknown reason the RPF is not releasing information on how to use it.

I've asked a number of times in the last couple of years, and the most encouraging reply I ever got is "we will consider documenting it in the future". I even tried to get the information from a Broadcom FAE, and was told "ask the foundation, they have the info you need"

What I know so far:

- 16 bit data bus
- 16 bit address bus
- an ALE like signal
- perhaps eight low order memory address bits on eight pins

It seems to have been made for attaching a small (<16MB) amount of static ram / flash, but I can think of MANY uses for it!

I'd love to play with it, but at the very least I'd need control register documentation, exact pin/function, and how to enable it (with the registers).

Not sure if you'd caught my post on the last thread that SMI seemed to be mentioned on - viewtopic.php?f=41&t=130574&p=945237#p945237
"I don't know much about what/how they got used, but had you noticed:
https://github.com/raspberrypi/linux/bl ... 2835_smi.c
https://github.com/raspberrypi/linux/bl ... _smi_dev.c
https://github.com/raspberrypi/linux/bl ... smi_nand.c
and device tree bindings in Documentation/devicetree/bindings/misc/brcm,bcm2835-smi-dev.txt and Documentation/devicetree/bindings/misc/brcm,bcm2835-smi.txt ..."

[mikronauts]

THANK YOU!!!

I have had the flu for ~2 weeks (almost over now), and I missed your other post.

I've grabbed the files, and will study them - this should be fun.

Thanks again,

Bill

"SMI" ie Secondary Memory Interface bus is there on all A+/B+/2/3/Zero Pi's, but for some unknown reason the RPF is not releasing information on how to use it.

I've asked a number of times in the last couple of years, and the most encouraging reply I ever got is "we will consider documenting it in the future". I even tried to get the information from a Broadcom FAE, and was told "ask the foundation, they have the info you need"

What I know so far:

- 16 bit data bus
- 16 bit address bus
- an ALE like signal
- perhaps eight low order memory address bits on eight pins

It seems to have been made for attaching a small (<16MB) amount of static ram / flash, but I can think of MANY uses for it!

I'd love to play with it, but at the very least I'd need control register documentation, exact pin/function, and how to enable it (with the registers).

Not sure if you'd caught my post on the last thread that SMI seemed to be mentioned on - viewtopic.php?f=41&t=130574&p=945237#p945237
"I don't know much about what/how they got used, but had you noticed:
https://github.com/raspberrypi/linux/bl ... 2835_smi.c
https://github.com/raspberrypi/linux/bl ... _smi_dev.c
https://github.com/raspberrypi/linux/bl ... smi_nand.c
and device tree bindings in Documentation/devicetree/bindings/misc/brcm,bcm2835-smi-dev.txt and Documentation/devicetree/bindings/misc/brcm,bcm2835-smi.txt ..."

[jdb]

Actually there are two fast data buses on the soc.

HOST: The host Interface is a 8/16-bit data bus that can be configured to do DMA transfers. Unfortunately the pins are not brought out (internally connected to GND) on any of the RPi versions including CM. I still hope that one day we will get access to those pins on an new CM or revision. As those pins are additional to the GPIO banks.

The host port is primarily a slave port. It requires external processor attention to read/write data to/from BCM2835. In theory you could use FPGA glue to come up with a bidirectional data path, but adding any sort of decent-speed FPGA puts 10s of dollars of cost on a board.

SMI Linux drivers are available but the hardware itself isn't documented. A proof-of-concept that talks to NAND flash devices provides a skeleton framework for using the device. I believe Luke had high-speed digital data acquisition running with DMA in a hacky way, so this peripheral can certainly do 16-bit transfers at >25MHz.

[W. H. Heydt]

Actually there are two fast data buses on the soc.

HOST: The host Interface is a 8/16-bit data bus that can be configured to do DMA transfers. Unfortunately the pins are not brought out (internally connected to GND) on any of the RPi versions including CM. I still hope that one day we will get access to those pins on an new CM or revision. As those pins are additional to the GPIO banks.

The host port is primarily a slave port. It requires external processor attention to read/write data to/from BCM2835. In theory you could use FPGA glue to come up with a bidirectional data path, but adding any sort of decent-speed FPGA puts 10s of dollars of cost on a board.

SMI Linux drivers are available but the hardware itself isn't documented. A proof-of-concept that talks to NAND flash devices provides a skeleton framework for using the device. I believe Luke had high-speed digital data acquisition running with DMA in a hacky way, so this peripheral can certainly do 16-bit transfers at >25MHz.

This sounds rather like a HAT as a "smart bridge" (to SATA or some other high speed mass storage bus) *might* be a viable solution if the cost could be kept under control (say, < $40).

[W. H. Heydt]

IMHO the foundation have really boobed by not building in a solution for fast sata.

There are so many applications which require sata for which USB 3 is not a viable solution.

An add on board with at least two esata ports (and perhaps some buffer ram) would be the way to go with sata 3 the main target.

David

I don't think that follows. Besides the cost issues, it is unclear that the original Pi could have handled SATA-II, let alone SATA-III. Come to that, I don't know of any cheap (<$50) SBCs that have SATA-III. There are some that have SATA-II, notably those based on the Alwinner A20 (dual A7 cores, typically at 1GHz). I'll grant you that even SATA-II on a 1GHz A20 runs pretty well (my read test on a SATA-II SSD hit 164MB/s, though the write speed was a rather more modest 44MB/s). I haven't--yet--been able to test the speed of an SSD connected to USB 3 (I'm waiting for the cables), but a PiDrive connected to an actual USB 3 port had an 80MB/s write speed, and a 73MB/s read speed, and those numbers are with a 4-core A9 1.1GHz CPU. To put those number in perspective, I have a SATA-III SSD attached (WD SATA Adapter) to a CM, which is the equivalent of an original Model B, runs at 26MB/s write and 25MB/s read. (I'm willing to share my test results, but I'd like to wait until I can include the tests with the USB3 to SATA cable and an SSD.)

I'm curious... Could you list some of those "many applications which require SATA", especially ones for which USB 3.0 is not viable?

The only application I know of for SATA is mass storage devices, and given the existence of inexpensive USB 3 to SATA adapters, it should be possible to transfer data fast enough for anything you'd really want to do with a Pi or Pi-like device. I can well imagine that, were USB 3.0 to appear on Pis, there would be an immediate lobby for USB 3.1 and *that* ought to handle even SATA-III at full speed with ease, but since I don't see USB 3.0 showing up on the PI any time soon, USB 3.1 is well past the horizon of any projection I can come up with. (Though I've got to admit that USB 3.1 on chip with USB 3.0 exposed and using the other 5Gb/s for other things would be interesting, indeed...)

[adun]

The host port is primarily a slave port. It requires external processor attention to read/write data to/from BCM2835. In theory you could use FPGA glue to come up with a bidirectional data path, but adding any sort of decent-speed FPGA puts 10s of dollars of cost on a board.

SMI Linux drivers are available but the hardware itself isn't documented. A proof-of-concept that talks to NAND flash devices provides a skeleton framework for using the device. I believe Luke had high-speed digital data acquisition running with DMA in a hacky way, so this peripheral can certainly do 16-bit transfers at >25MHz.

Thanks for those informations jdb.
So was the host port originally designed to let the BCM2835 act as a co-processor?

[6by9]

So was the host port originally designed to let the BCM2835 act as a co-processor?

Yup, from the co-pro days, providing the interface to/from the host processor to the co-processor.

With one customer that interface at IIRC 120Mbit/s was insufficient, so they used that interface from Apps processor to BCM co-pro, and had a CCP2(predecessor to CSI2) transmitter on BCM2708 streaming data back the other way at up to 650Mbit/s. I think was overclocked too for one use case! Ah, those were the days.

(Yes, the balls for the CCP2TX will be there somewhere under BCM283[5|6|7], but I very much doubt they'll ever be routed out, even on the Compute Module. I'm expecting that they're dedicated connections too, so no options for muxing them)

[adun]

Very interesting, thanks 6by9

(Yes, the balls for the CCP2TX will be there somewhere under BCM283[5|6|7], but I very much doubt they'll ever be routed out, even on the Compute Module. I'm expecting that they're dedicated connections too, so no options for muxing them)

I dont know if some of the "undocumented" GPIO ALT functions refer to CCP2TX but I also doubt they are only available on the dedicated pins. Not on the GPIO banks.
It would be very nice if at least the Compute Module would have the Host Port (and ev. CCP2TX) routed out. Even if this would require more layers. As the advantage over SMI is that they are on separated pins. So the GPIOs would left free.

It looks like the ball pins for CCP2TX on BCM283X are:

Code: Select all

V2:  CCP2TX_AGND1 (connected to GND)
N5:  CCP2TX_CN (floating)
P5:  CCP2TX_CP (floating)
N6:  CCP2TX_DN (floating)
P6:  CCP2TX_DP (floating)
P8:  CCP2TX_1V8 (connected to 1V8)
R13: CCP2TX_AGND2 (connected to GND)
R16: CCP2TX_AGND3 (connected to GND)

PS: So only 4 lanes would needed to be routed out. CCP2 could allow to have a third camera module attached..

[6by9]

It looks like the ball pins for CCP2TX on BCM283X are:

Code: Select all

V2:  CCP2TX_AGND1 (connected to GND)
N5:  CCP2TX_CN (floating)
P5:  CCP2TX_CP (floating)
N6:  CCP2TX_DN (floating)
P6:  CCP2TX_DP (floating)
P8:  CCP2TX_1V8 (connected to 1V8)
R13: CCP2TX_AGND2 (connected to GND)
R16: CCP2TX_AGND3 (connected to GND)

PS: So only 4 lanes would needed to be routed out. CCP2 could allow to have a third camera module attached..

Not sure where you got the ball data from, but quite possibly.
4 lines, not lanes (which has a specific meaning with camera comms). Same as CSI2 it's a clock differential pair (CP and CN), and a data differential pair (DP and DN). You can probably get around connecting all the specific grounds/power pads.

This is CCP2 TRANSMIT, not receiver, so no you can't attach a third camera. The two main camera receivers can support CCP2 as well as CSI2 should that be deemed necessary.

[adun]

A right that's why it's marked as CCP2TX.
I got ball data from the elinux.org and the connections from the CM schematics. Of course it might contain errors.

[6by9]

Yup, transmit
I wasn't aware of that page before - someone had some fun with the original Model B schematics and tracing the circuit. It just reminds me how tiny this chip is.

[lfreitas34]

Hi,

I wanted to confirm if someone already figured out how to connect something like this to the SMI port?

http://www.ebay.com/itm/IDE-to-SATA-ATA ... 1087390727

Regards,
Luis

[lfreitas34]

Hi,

No replies so far?

I looked into this a bit, the SMI interface seems to be an implementation of the ONFI specification, and that is a public standard.

It seems possible to translate the signals into something that would be compatible with pata, but for that to work it would be necessary to make the SMI output pata commands instead of flash commands.

But the kernel side of this seems very complicated to me, I don't know how/where to make a new block device to connect the smi driver to the kernel existing pata code.

Regards,
Luis

[Johnson-xu]

Hi, guys,
If any one who can confirm this boards some guys selling data? i means, i need somethings like that but i have no ideas about that.
https://www.aliexpress.com/store/produc ... 0.0.3FVxrE

Thanks any way.

[drgeoff]

Hi, guys,
If any one who can confirm this boards some guys selling data? i means, i need somethings like that but i have no ideas about that.
https://www.aliexpress.com/store/produc ... 0.0.3FVxrE

Thanks any way.

My impression is that the USB3.0 and SATA interfaces are connected to the RPi via one of the USB2.0 ports on the RPi. That isn't going to get data in and out of the RPi any faster than using a USB port on the RPi for a USB device or a USB to SATA interface for SATA drives. And there will still be the bottleneck that all USB2.0, USB3.0, SATA and ethernet traffic is on the single USB2.0 port of the Broadcom SoC.

Contrary to the wording, it does not provide a 'duplicated' HDMI output. It is repositioned.

[dkohen]

Most of these posts are pretty old but in case someone comes here looking: http://wdlabs.wd.com/category/wd-pidrive/ has a series of solutions. Ultimately they all seem to be USB2 based, unfortunately.