1 1
mjsmall

Why shouldn't I buy ROCK64?

Recommended Posts

Hi everyone.

 

I'm starting a project to learn about Big Data processing. Roughly, I'll be following the example set by Michael at http://diybigdata.net/odroid-xu4-cluster/ . From other posts he has made, some extra RAM could be useful, so I am interested in the 4GB ROCK64.

 

My basic configuration will be ROCK64/64Gb eMMC/Pine USB3-SATA cable/HDD. I'm looking to buy 4 of these to start the project and do my development and testing before adding extra nodes to the cluster.

 

It seems that the Pine USB-SATA cable performs well, but the SD card reader does not. I'd like to configure remote power cycling using GPIO from a monitoring SBC and a relay card, but someone posted on Pine64 forum that the reset button must be pressed to boot the board. Is that so? It's not a show stopper, but I will have to rethink my strategy.

 

In any case, those are the only possible issues I have noticed so far with using this board as a server. Am I missing something important? I'm fairly new to the SBC ecosystem, but not to electronics or Linux.

 

Thanks!

 

Matt.

Share this post


Link to post
Share on other sites

For some various thoughts from several people.  it's got a good power option (meaning not micro-USB), lots of RAM, GbE/USB3, an additional fast ethernet if you can wire it up (is there a "hat" for that now?)

 

Cons:  not any real Armbian support yet.  ;-)  There were some GbE and USB3 issues, but I believe those have all been resolved.

Share this post


Link to post
Share on other sites
6 hours ago, mjsmall said:

It seems that the Pine USB-SATA cable performs well, but the SD card reader does not. I'd like to configure remote power cycling using GPIO from a monitoring SBC and a relay card, but someone posted on Pine64 forum that the reset button must be pressed to boot the board. Is that so? It's not a show stopper, but I will have to rethink my strategy.

I cannot confirm this behaviour. My Rock64 board does not need that manual interaction in order to boot.

Share this post


Link to post
Share on other sites
7 hours ago, mjsmall said:

It seems that the Pine USB-SATA cable performs well, but the SD card reader does not. I'd like to configure remote power cycling using GPIO from a monitoring SBC and a relay card, but someone posted on Pine64 forum that the reset button must be pressed to boot the board. Is that so? It's not a show stopper, but I will have to rethink my strategy.

 

I do not have this behavior either, I forgot to mention.

Share this post


Link to post
Share on other sites

My Rock64s boot fine so far without pushing any buttons, booting from USB or network via SPI flash works too... if you look for community built images check out ayufan's github ... GbE issues have been fixed by tuning RGMII delays, SD card is limited to 25Mhz since it is wired up at fixed 3.3V  (might change in future board revision, needs more evaluation), eMMC runs at 1.8V and supports higher speeds

 

https://github.com/ayufan-rock64

https://github.com/ayufan-rock64/linux-build/releases

Share this post


Link to post
Share on other sites
4 hours ago, Xalius said:

My Rock64s boot fine so far without pushing any buttons, booting from USB or network via SPI flash works too... if you look for community built images check out ayufan's github ... GbE issues have been fixed by tuning RGMII delays, SD card is limited to 25Mhz since it is wired up at fixed 3.3V  (might change in future board revision, needs more evaluation), eMMC runs at 1.8V and supports higher speeds

 

https://github.com/ayufan-rock64

https://github.com/ayufan-rock64/linux-build/releases

so it might change in future, meaning rk3328 is able to deal with 1.8V speed modes? And when I was asking that, you said that this is a bullshit. :) So you admit, it's a board design flaw? (I am not even close to electronic engineering).

Share this post


Link to post
Share on other sites

Thanks everyone. Good to know about the button push. Makes it easy to run the power feed via relay contacts. Network booting could be useful, especially with a cluster. I'm not too concerned about the SD card performance. The eMMC is relatively cheap, and I guess I can save a few dollars on not buying expensive SD cards for this batch. Not quite ready Armbian support is definitely a down side. There seems to be so few affordable (<$100) SBCs with 4GB RAM/USB 3/GbE. The only other that caught my eye is the Firefly/Libre Computing ROC-RK3328-CC, but I gather I'm in the same position. I'd be open to other suggestions, if there are any?

 

In any case, I'll keep an eye on Armbian support. You guys look to have a good community here and I've been a Debian user since the Hamm days.

 

Matt.

Share this post


Link to post
Share on other sites
9 hours ago, valant said:

so it might change in future, meaning rk3328 is able to deal with 1.8V speed modes? And when I was asking that, you said that this is a bullshit. :) So you admit, it's a board design flaw? (I am not even close to electronic engineering).

 

Most boards I know of just wire sdcard to 3.3V only, supporting 1.8V/3.3V dual mode requires support in the SoC and software since you need to do that dynamically during training and in operation, so I guess a lot of designs just avoid that. You could wire up the sdcard in 1.8V only probably like the eMMC but that breaks backwards compatibility to older cards. On some SoC is is also not easy since when you switch the mmc bus to 1.8V on that port, the whole port is using 1.8V and depending what else is on there this causes more issues...

Share this post


Link to post
Share on other sites

The tinker has 3.3/1.8, and so does Le Potato.  That said, it is the source of the reboot bugs on the Tinker, and requires messy workarounds. (I had to add the device tree checks because of the MiQi crashing and burning with those hacks in place).  Now, for all of that, the Rock64 has SPI flash, so U-boot can live there and boot your system from USB3 if you wish, which could be faster than any option discussed here.

 

Oh, in case anyone thinks of running some 1.8v lines for a custom board or anything else:

 

https://www.sdcard.org/developers/overview/low_voltage_signaling/index.html

 

Any card predating these "LV" cards requires 3.3 volts to start, then a voltage switch is negotiated with the SD card.

Share this post


Link to post
Share on other sites
On February 6, 2018 at 11:29 PM, mjsmall said:

I'd like to configure remote power cycling using GPIO from a monitoring SBC and a relay card, but someone posted on Pine64 forum that the reset button must be pressed to boot the board. Is that so? It's not a show stopper, but I will have to rethink my strategy.

I've been thinking about making a watchdog (using a STM32 as monitor/power manager) for my server (CubieBoard2)

-I think you could make a similar 'work-around'.

 

Since you're monitoring the board from another board, you could actually solder two wires onto the reset button's terminals ... Eg one to the GND and one to the actual RESET signal.

The other end of those two wires could simply be soldered to a relay, which is "normally open".

The relay can be controlled by a transistor, which is controlled by an opto-coupler, which in turn is controlled by the monitoring SBC.

 

This solution can definitely be optimized to include just a few components (something like a transistor, resistors and a diode), but I made a suggestion of using the relay so that it'd be easy to catch on what's going on, plus if you're using an opto-coupler, you should be able to separate the boards electrically from any accidents. ;)

 

You could have the Rock64 charge a capacitor, which is slowly discharged over a resistor.

The monitoring SBC could then poll this capacitor (measure the voltage using one of the ADC pins), to find out whether it's running or not.

 

Share this post


Link to post
Share on other sites

@Jens Bauer, thanks, yes, I had similar thoughts. I'm interested in full power off. Sometimes it is useful compared to a reset, and I can also script the cluster to fully shutdown after a job finishes. If I did have to push the reset button to boot, I could have simulated that with some wiring and a momentary action switch. Not having to do that means less complexity and I don't have to take a soldering iron to my boards. :)

 

I will probably use something like these for the relays. I can buy them cheaper from China than I could make them myself. Thanks again for the suggestions. They'll be helpful for anyone else looking to do something like this, too. :beer:

Share this post


Link to post
Share on other sites
1 hour ago, mjsmall said:

@Jens Bauer, thanks, yes, I had similar thoughts. I'm interested in full power off. Sometimes it is useful compared to a reset, and I can also script the cluster to fully shutdown after a job finishes. If I did have to push the reset button to boot, I could have simulated that with some wiring and a momentary action switch. Not having to do that means less complexity and I don't have to take a soldering iron to my boards. :)

I understand (that's what I intended to do with my CubieBoard2).

My CubieBoard2 has a power-button that requires a push-and-hold in order to turn on or off. The "hold" time must be longer than 1 second, otherwise it ignores it. You might face similar issues, but it would still be possible to solve it without too much trouble.

 

1 hour ago, mjsmall said:

I will probably use something like these for the relays. I can buy them cheaper from China than I could make them myself. Thanks again for the suggestions. They'll be helpful for anyone else looking to do something like this, too. :beer:

A fairly good price - I think they'll do just fine for this task. :)

Share this post


Link to post
Share on other sites
On 2/8/2018 at 2:26 AM, Xalius said:

Most boards I know of just wire sdcard to 3.3V only, supporting 1.8V/3.3V dual mode requires support in the SoC and software since you need to do that dynamically during training and in operation, so I guess a lot of designs just avoid that. You could wire up the sdcard in 1.8V only probably like the eMMC but that breaks backwards compatibility to older cards. On some SoC is is also not easy since when you switch the mmc bus to 1.8V on that port, the whole port is using 1.8V and depending what else is on there this causes more issues...

By the way, Xalius, don't you know, what the situation is with Pine H64 with this respect? I see H6 supports UHS-I I/O voltages/speed modes. Does the board provide the support (on the harware level, not linux support)?

 

Share this post


Link to post
Share on other sites

As far as I can see the PineH64 only uses 3.3V for SD-card,  and 1.8V for the SDIO on the WIFI socket and the eMMC. I guess that is because the SD-card mmc bus on Port F has no extra VCC-IO and so the whole SoC would need to be switched to 1.8V and the rest shifted back to 3.3V... and the eMMC bus is shared with the SPI Flash at 3.3V as well as the PCIe control lines and the GMAC. I think Allwinner's rational for that is that set top boxes with H6 will either use USB3 or PCIe for fast storage....

 

Edit: They actually shifted the rest of the port the eMMC bus is on, misread the schematics...

 

So you have: SD-card 3.3V/4bit, SDIO 1.8V/4bit, eMMC 1.8V/8bit

Share this post


Link to post
Share on other sites
15 minutes ago, Bibikits said:

I can't find the answer if the emmc what the Rock64 deliver is faster than a SD card like Samsung Pro?

 

I haven't checked, but this is almost universally true of eMMC, there are several reasons, including the data bus typically being twice as wide, and eMMC is set up for application use, so usualy faster random I/O.  

Share this post


Link to post
Share on other sites
31 minutes ago, Bibikits said:

if the emmc what the Rock64 deliver is faster than a SD card like Samsung Pro?

 

The SD card interface on ROCK64 is limited to DDR50 which not just limits sequential transfer speeds to around 23 MB/s but also affects random IO performance with data chunks of 16KB or more: https://forum.armbian.com/topic/954-sd-card-performance/?page=3&tab=comments#comment-49811 (search for SDR104 there)

 

So even the slower FORESEE eMMC modules should always be faster than a high performing SD card on Rock64 (since DDR50 mode is the bottleneck). This is not true for other SBC, we support a few boards that come with pretty slow soldered eMMC where good SD cards can outperform the eMMC at least with sequential writes.

 

Share this post


Link to post
Share on other sites

Is it correct that what Pin64 website offers for the Rock64 emmc storage that is faster than any SD card what is available because of the 25mb/s limit?

 

I Only want OMV on it and a separate hdd to connect.

 

Read/write performance off a HDD is also still limited to 25 mb's?

Share this post


Link to post
Share on other sites
14 minutes ago, Bibikits said:

I Only want OMV on it and a separate hdd to connect.

 

Then any SD card will do since performance of the rootfs is not relevant at all. Buy one of the great SanDisk A1 cards and don't skip the necessary tasks to check for counterfeit/fake SD cards, then do a TRIM and then write the OMV image with Etcher. On the OMV ARM images the 'flashmemory plugin' is already active so your SD card will last most probably indefinitely.

 

HDDs are on either USB2 or USB3 so there's no 25MB/s limitation. Simply take care that you get a good USB-to-SATA bridge (eg. those referenced here)

Share this post


Link to post
Share on other sites
1 hour ago, Bibikits said:

But emmc is faster, why SD Card?

 

You were talking about OMV? It's irrelevant how 'fast' the installation media is since with our ARM OMV images this simply doesn't matter. If you want to spend more money on more expensive storage, that's fine too. Though my personal recommendation for this use case if you can get SanDisk Ultra A1 would be the 32GB variant (since best capacity/price ratio)

Share this post


Link to post
Share on other sites
3 hours ago, Bibikits said:

For OMV is 4GB Ram Required or 2GB is enough?

 

OMV runs on boards with 256 MB RAM or less. Filesharing daemons aren't RAM hungry and usually all this RAM ends up as filesystem buffers/caches anyway so in home/SOHO situations it's usually just wasted.

 

Therefore it only depends on what you're trying to achieve. Tons of Docker containers --> more RAM. Software that eats RAM for no reason (e.g. some torrent stuff) --> more RAM. But for a simple NAS even 1 GB is more than sufficient.

Share this post


Link to post
Share on other sites

I am hessitating between 2 ARM devices.

Rock64 4GB or 2GB

Odroid XU4Q 2GB

 

One is for OMV with SanDisk Ultra A1 32GB 

Fast file transmit what is faster for file transfer through NFS/Samba/Plex?

 

One is for Android TV -> Kodi or Plex for 4K Encoding. 

What is better to use emmc or Micro SD?

 

I want the best performance, at home there is a gigabit network

 

 

Share this post


Link to post
Share on other sites

There you find answers to your questions:

search.jpg.5549006196a9e503c95455e89ff022a5.jpg

 

2 hours ago, Bibikits said:

One is for OMV with SanDisk Ultra A1 32GB 

Fast file transmit what is faster for file transfer through NFS/Samba/Plex?

 

 

2 hours ago, Bibikits said:

One is for Android TV -> Kodi or Plex for 4K Encoding. 

What is better to use emmc or Micro SD?

the decision between 4GB ram and 2GB ram is the smallest 'issue' you'll have.  You need a board which supports 4k hardware accelerated video decoding and an image which can benefit from it, means that the drivers to use the VPU must work and that's where it gets complicated since only a few people here care about 4k decoding and most of them care about 4k on linux and not android (keep in mind that this forum is mostly about armbian, not android). 

Share this post


Link to post
Share on other sites

Thanks for the information, but is a ready to use usb harddrive a speedy solution. Or better to buy the adapter at pine64 with a hdd. I want one hdd like 2tb. 2,5 inch what specs does it must have?

Share this post


Link to post
Share on other sites

If you read a bit through the provided threads, you should be able to answer this question by your own. 

 

45 minutes ago, Bibikits said:

Or better to buy the adapter at pine64 with a hdd

even for this one we have a review which can be found... :P 

 

with this adapter, you know what you get.. By buying a *random USB enclosure* you've to do the research on your own if there's a suitable USB Sata controller inside... I'm not a fan of USB3 cables cause as @tkaiser mentions multiple time, chances that the connections can fail is just another possibility of failure. I prefer solutions with native Sata or boards like the HC1/HC2 where it goes over USB3 but not with a cable... 

 

Share this post


Link to post
Share on other sites

I have two options for 32GB:

-   Sandisk Ultra microSDHC Class 10 UHS-I A1 UHS Class 1 32GB + SD-adapter €12

- Sandisk microSDHC UHS Class 3, UHS-I, A1, V30 32GB €27

 

One for OMV

 

One for a mediaplayer.

 

If more GB needed, than I need to buy.

 

The problem is the prices. I can two of the first one for the price of the second.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
1 1