Jump to content
  • 0

ROCK64


Xalius
 Share

Question

Moderator edit (pfeerick): I have modified this post to contextualise this split thread. It was initially intended to be a discussion of a board bring up procedure / proposal format, and has since evolved into discussion of the rock64 generally. 

 

Xalius originally said in this post: 

TODO-List sounds good to me, I will run some tests as soon as China Post/DHL actually deliver my package. I get a 4GB version with the suppressor diodes for USB3 already replaced...

 

This is what tkasier originally wrote in his first post, minus the disclaimer as was only relevant to that thread:

 

Quote

 

Let me introduce ROCK64:

 

  • RK3328 SoC: feature list
  • ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks)
  • Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit)
  • 1GB, 2GB or 4GB PC-18666 LPDDR3
  • eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper)
  • socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter)
  • 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever)
  • RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth)
  • Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked)
  • I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this)
  • Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)

 

Pros:

  • board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor)
  • board vendor provides dev samples and documents problems devs might run into (see below)
  • chip vendor actively supports mainline Linux and u-boot
  • chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC)
  • SDK/BSP not horribly outdated (RK relies currently on 4.4)
  • almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces)
  • No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook
  • Icenowy already received a dev sample ;)

 

Cons:

 

  • new platform (Rockchip 64-bit) needing more initial work

 

Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all)

 

My next steps planned:

 

  • Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks)
  • Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution)
  • ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering)
  • Present results to continue discussion

 

 

Link to comment
Share on other sites

Recommended Posts

  • 0
On 21.8.2017 at 4:26 PM, tkaiser said:

to get a more realistic idea about the AES encryption potential when more than one CPU core is involved I would suggest running:


tk@pinebook:~$ cat check-ssl-speed.sh
#!/bin/bash
while true; do
	for i in 0 1 2 3 ; do 
		openssl speed -elapsed -evp aes-256-cbc 2>/dev/null &
	done
	wait
done
tk@pinebook:~$ ./check-ssl-speed.sh | grep "^aes-256-cbc"

 

 

I repeated this test yesterday after I found why my H5 openssl benchmark scores were that low: since I was testing there with an armhf userland and not an arm64 one (32-bit vs. 64-bit but in this case more importantly: compiler switches forbid the use of ARMv8 crypto extensions when building armhf binaries).

 

I also set up my 'monitoring PSU' stuff (letting a Banana Pro provide power to ROCK64 to be able to measure consumption without PSU being involved) and get the following consumption/performance numbers (on a 4GB pre-production sample -- there are some significant changes on production boards so idle / Ethernet consumption might differ!):

 

Bildschirmfoto%202017-08-27%20um%2010.43

  • idle @ 408 MHz / legacy kernel: 1450 mW
  • When switching GbE to Fast Ethernet: 1100 mW (the usual 350mW drop)
  • after poweroff: 580 mW (so there's currently some stuff missing and the board does not really power off cleanly)

 

Testing with armhf userland walking through 408, 816 and 1200 MHz DVFS operating points:

armhf  408 MHz:    52,000k / 1360mW --> 260 mW
armhf  816 MHz:   104,000k / 1710mW --> 610 mW
armhf 1200 MHz:   153,000k / 2790mW --> 1690 mW

Now with arm64 (and Debian Stretch and different idle consumption since Gigabit is enabled):

arm64  408 MHz:   730,000k / 1730mW --> 280 mW
arm64  816 MHz: 1,508,000k / 2170mW --> 720 mW
arm64 1200 MHz: 2,200,000k / 3340mW --> 1890 mW

With ARMv8 crypto extensions active we see a slight increase in consumption (and temperature -- with armhf temp maxed out at 76"C at 1200 MHz while the arm64 tests triggered some throttling after 6 minutes since no heatsink applied to RK3328 and SoC temp exceeded 80°C at an ambient temp of 26°C). But the performance increase is massive (14 times faster).

Link to comment
Share on other sites

When discussing a problem make sure to provide full logs!

  • 0

And another update, this time on USB3 performance. Since today a small M.2 SSD arrived I immediately tested with native SATA on a Clearfog Pro and I also gave it a try in a tiny JMS578 enclosure now with ROCK64 (details for both SSD and enclosure).

 

Storage performance measured with the usual iozone call with SATA (to show the SSD's performance) and then attached to ROCK64's USB3 port, first with BSP kernel (4.4.77), then mainline 4.13-rc1:

TS120GMTS420 SATA Clearfog                                    random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    86865   124684   140973   140224    32522   101844
          102400      16   206105   251838   293776   282729    84623   202503
          102400     512   363707   377155   409380   401946   358966   372971
          102400    1024   364578   358095   402539   404249   387812   376067
          102400   16384   310808   407947   500231   497107   470879   398703
         3072000   16384   420958   403649   509368   507120   469027   405752

TS120GMTS420 JMS578 ROCK64 4.4.77 1296 MHz                    random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    25793    31181    36545    38058    19837    32840
          102400      16    74689    87314   127011   127494    62706    88478
          102400     512   298948   322459   323666   325943   304947   311285
          102400    1024   333159   343551   348576   351217   329950   344678
          102400   16384   369142   377884   377184   380461   362302   359235
         3072000   16384   374446   380254   382541   381844   363431   379725
         
TS120GMTS420 JMS578 ROCK64 4.13.0-rc1                         random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    18098    22215    22757    22750    17104    21932
          102400      16    61487    73079    75408    75522    56182    73369
          102400     512   287554   299840   281735   283843   283678   300074
          102400    1024   299159   314982   295748   297612   297422   305827
          102400   16384   249205   357761   341508   343535   343730   346455
         3072000   16384   350303   346587   346114   346187   346233   341654

As expected USB3 performance numbers lower compared to native SATA on the Clearfog Pro. But why do the mainline kernel results look that bad? Since no cpufreq scaling is working here and we're running the SoC with just 600 MHz set by u-boot. Now let's test again with BSP kernel limiting here cpufreq also to 600 MHz instead of 1296 MHz:

TS120GMTS420 JMS578 ROCK64 4.4.77 600 MHz                     random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    15937    21334    25571    25576    17430    21122
          102400      16    53353    65892    86114    85993    50773    65037
          102400     512   273837   288669   276365   278220   261956   290194
          102400    1024   296038   321502   309817   311969   293723   321893
          102400   16384   363437   374665   344870   350489   345225   372353
         3072000   16384   357195   367268   364944   365021   344555   367027

Now the above 4.13 numbers look a lot better! :)

Link to comment
Share on other sites

  • 0
On 8/22/2017 at 1:23 AM, tkaiser said:

Hmm... to summarize the 'OpenSSL 1.0.2g  1 Mar 2016' results for the 3 boards/SoC tested above with some more numbers added (on all A53 cores with crypto extensions enabled performance is directly proportional to CPU clockspeeds -- nice):

 

 

ROCK64 @ 1.488GHz

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     179760.41k   500823.06k   837207.72k  1040921.94k  1120367.96k
aes-192-cbc     166930.03k   430311.10k   668937.47k   795866.79k   842443.43k
aes-256-cbc     160133.98k   390004.61k   572388.78k   662836.57k   694777.17k

The little board that could has broken 1GB/s

 

Edit: According to this it should go all the way up to 1.5GHz without too much extra in the way of Vcore

Edited by chrisf
Link to comment
Share on other sites

  • 0
On 30.11.2017 at 3:50 AM, chrisf said:

Edit: According to this it should go all the way up to 1.5GHz without too much extra in the way of Vcore

 

Adding unreliable overclocking settings on Allwinner and Rockchip devices is unfortunately pretty easy (and the proposed patch looks wrong already in the first line since increasing cpufreq by 100 MHz without adjusting the voltage at all). That's why stuff like https://github.com/ehoutsma/StabilityTester exists. Feel free to try it out, @ErwinH used the tool to develop a sane DVFS OPP table last year for Orange Pi PC2 with this (since we found out that this highly optimized Linpack is a great way to check for DVFS undervoltage caused instabilities already before the board freezes/crashes. That lesson was learned when dealing with unreliable overclocking on Pine64 before)

Link to comment
Share on other sites

  • 0
11 hours ago, tkaiser said:

the proposed patch looks wrong already in the first line since increasing cpufreq by 100 MHz without adjusting the voltage at all

 

Completely wrong it turns out.

Turns out the RK805 PMIC needs the voltage increased in 12.5mV steps and the frequency needs to be specific values too, they're defined in drivers/clk/rockchip/clk-rk3328.c.

They're defined up to 1.8GHz, but I didn't get any above 1.488 to work, cpufreq wouldn't load them.

It does run stable at 1.488GHz though, if you increase the voltage. I'm using 1.4375V, haven't tested any lower.

Done testing stability:
Frequency: 1392000      Voltage: 1350000        Success: 1      Result:        0.0048034
Frequency: 1416000      Voltage: 1375000        Success: 1      Result:        0.0048034
Frequency: 1488000      Voltage: 1437500        Success: 1      Result:        0.0048034

I had to edit the script for min, max and cooldown freq as well as the Vcore regulator

Peaks around 78 degrees, with idle @408MHz 40 to 45C

 

minerd --benchmark reports 4.61khash/s (or 4.58 while armbianmonitor -M is running)

after a few minutes it's sitting around 79C

Link to comment
Share on other sites

  • 0

Would it be possible to get someone to confirm a current "dev" image build is bootable?  I'm not getting any UART output with SD inserted, my eMMC (my fault) at least ells me I broke it's contents.

 

[edit]  OK, the downloadable 4.4 boots, I'm building an unmodified Dev image (I was using a different kernel, shouldn't have broken u-boot though) to verify.

Link to comment
Share on other sites

  • 0

I think I found it, although I'm not sure why this would happen:

ccache: error: Could not find compiler "aarch64-linux-gnu-gcc" in PATH
ccache: error: Could not find compiler "aarch64-linux-gnu-gcc" in PATH

when compiling u-boot, so that build fails but doesn't crash the script, allowing you to build the image.

 

well then, that didn't repeat on a second try, stay posted.

 

 

 

Link to comment
Share on other sites

  • 0

Can You test docker container on rock64 on different storage - usb3, microsd, usb2 and ramdisk?

 

Primary test setup will be - install docker, setup ssl certs, use nginx with phpfpm docker ready to go container, run some php scripts with possible memcache access. 

 

Why docker? Because it is easy to pass storage path for test without affecting host os for needed software. And later to scale everything using GbE :)

 

Test area - real life test bench on ssl decr/encr, storage and ram perf and access timings. Some sort of php math calculations or use openssl library to load cpu cores. 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...