ROCK64

[Xalius]

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

 

 

[tkaiser]

Ah, totally forgot... 'Add support proposal' threads like this (or Github issues if we decide to better use those) should be used later if we came to the conclusion that it's not worth the efforts to support a specific device to list this device on a 'not supported' page similar to download page today with a link to the thread so that

• users might be able to understand the reasons why specific devices aren't supported
• discussion might continue once conditions changed

[jernej]

@tkaiser

yes, my board should be on the way, but it has same USB3 issue.

[martinayotte]

Has TLLim provided the list of developpers ?

 

[hmartin]

@tkaiser nice start!

 

• Has pricing been announced?
• What about availability? Is there sufficient supply that users can buy it? (Or what is the expected release date)
• Any armbian developers committing to getting the board included into nightly releases?

 

Any thoughts on an appropriate benchmark to test GbE and USB3? It would be great if we could standardize on something so people can use the test results to compare before purchasing.

[jernej]

I know that Rockchip doesn't usually provide full user manuals, but is there a chance to get them anyway?

[tkaiser]

1 hour ago, martinayotte said:

Has TLLim provided the list of developpers ?

 

Nope, I only know I'm on the list since I received an email from him (which I responded to somewhat off-topic collecting a lot of weird proposals for a potential next Pine design). While I think Pine folks have no objections sending out few more dev samples IMO we should try to focus on what 'we' want: board bring up adventures or focus again on what Armbian has been in the past: a reliable distro with secure and optimized defaults (so me receiving an early pre-production sample is already somewhat wrong since I'm too stupid to read schematics or fix USB3 issues on my prototype with solder iron...)

1 hour ago, hmartin said:

Has pricing been announced?

Not really but by looking at Pine64 price-list you get the idea (maybe already add a few bucks more since DRAM prices increased a lot and I don't think Pine Inc does any good selling a loss-leader). They'll decide within next 2 weeks and then I'll believe information will be leaked anyway even if official ROCK64 announcement will be delayed a bit. But from an end user perspective shipping costs are also important so let's wait and see with what they come up.

 

Wrt availability: Currently Pine Inc gets some bad press regarding 11" Pinebook shipments due to display shortage (BTW: I would fully understand if that's no real display shortage since I can't imagine how they make any money with the $89 variant since they defined prices long ago and both DRAM and eMMC increased BOM costs a lot in the meantime) but I don't think that will be an issue with ROCK64. TBC.

 

I'll only do some initial testing and maybe attend improving settings but I neither have the time nor skills/patience to add a new $LINUXFAMILY so someone else is needed as maintainer if we want to add this board to Armbian. 

 

Benchmarks are always a problem. Simple example: https://forum.armbian.com/index.php?/topic/1285-nanopi-m3-cheap-8-core-35/&do=findComment&comment=14623 (you need to understand relationship between cpufreq behaviour and numbers, then need to tweak settings so benchmark scores look better but in reality that's not important at all!). Network benchmarks on slow ARM devices are currently more or less benchmarks for cpufreq scaling and compiler settings (a lot is CPU bound even with appropriate settings) and the same is true for storage --> choose wrong cpufreq settings and storage performance sucks: https://tinkerboarding.co.uk/forum/thread-310.html

 

If we want to behave like IT protozoons just collecting numbers without meaning it's easy (passive benchmarking, that's what Phoronix is about) but if we want to do benchmarking to improve things it gets complicated since then benchmarking is not a process of collecting numbers but improving them with focus on real world workloads and NOT synthetic benchmarks. In other words: Not that easy to come up with some sort of standard tests since on those low performing ARM devices with settings optimized for totally different use cases the most important thing is to identify and understand all the various bottlenecks to get the idea where to improve stuff.

 

[tkaiser]

ROCK64 product page online with links to various resources/documentation: https://www.pine64.org/?page_id=7175

[clarkss12]

Most if not all of this conversation is way over my head, but all I want/need to know, as a practical user, can it TRANSCODE on the fly.  In the last 4 or 5 years, I have had several of these Rockchip based devices, and have always been disappointed, because Rockchip does not seem to support the OEM's.  I have one of the Pine 64, 2 gig version  boards, and it is running your Armbain Ubuntu on it's $5 Alwinner SoC.  I use it for Emby, Plex and tvheadend servers, but it does not have enough CPU power to transcode on the fly.

 

I am also running Ubuntu on a Rockchip Rk3288 SoC device, and using it as a Emby, Plex and tvheadend servers, again, not enough CPU power to transcode on the fly.

 

I am also running Ubuntu on a couple of Amlogic devices and again, not enough CPU power to transcode on the fly.

 

I would love to see a test on this board running either Emby or Plex servers and being able to transcode several live TV streams on the fly.

 

[jernej]

17 minutes ago, clarkss12 said:

it does not have enough CPU power to transcode on the fly.

 

Usually, when you talk about SoCs like those from Rockchip or Allwinner, transcoding is only doable when you using both, HW decoding and encoding. H3 supports only H264 and VP8 encoding, for example. I'm not sure what is the situation with Rockchip... And appropriate code examples are also hard to come by.

[bozden]

Well, as a end-application developer I find this board and its power very promising. But if only HARDWARE ACCELERATED VIDEO drivers exist... If not, it is not so useful for me... I don't want to be stuck in legacy Ubuntu desktop with a lot of bloatware...

 

 

[Xalius]

The situation for hardware video acceleration at least for the 4.4.x BSP  looks a lot better compared to Pine64 if you look at Rockchip's open source github, but since I havent got my prototype yet and also haven't anyone seen booting Linux images so far I am only cautiously optimistic.

[Da Alchemist]

I must admit that I was excited when I first saw this board with an old Raspi Soundboard hooked on it. The RK3328 Specs sounded so good, that I could not resist buying a cheap TV Box, a Z28 for 27€ Shipping included from Gearbest. Now I can say I am healed.

The Box is set down to 1280x720p Resolution, the Android Kernel is 3.10.104...

 

I doubt that it is easy to get a Mainline Kernel with Hardware Video Acceleration running on it. The only real unique Feature of this Board I can see at this Moment is USB3.

 

I will sit back and relax to see what is comming, my expectations are cut down and if the price is more than 30€ for the 1GB Board shipping included to Europe, I will not jump this Train.

 

Regards

[Xalius]

Yeah the Android that is shipped with those RK3328 boxes is pretty abysmal, ayufan just got his board out of the mail and started working on Android sources

 

But why is the box limited to 720P?

[jernej]

1 hour ago, Da Alchemist said:

I doubt that it is easy to get a Mainline Kernel with Hardware Video Acceleration running on it.

That may be hard, but I just checked mpp source (Rockchip HW video acceleration library) and it mentions that RK3328 is fully supported. Rockchip kernel 4.4 also has initial support for video decoding. I would say that future is bright.

[Da Alchemist]

34 minutes ago, Xalius said:

But why is the box limited to 720P?

I don´t know...it is reported here too.

@jernej, I wish you good luck and don´t forget to implant 8 Channel PCM Output via HDMI for me..

[jernej]

2 minutes ago, Da Alchemist said:

@jernej, I wish you good luck and don´t forget to implant 8 Channel PCM Output via HDMI for me..

 

I will probably wait a little until it becomes clear what is the best approach to deal with those things. mpp is a complex library and it takes some time to figure it out. However, there is also a libva interface, which is standarized, but it doesn't support all codecs (if I understand correctly). If I will go in OE direction again, libva would be immensely preferred.

 

BTW, I think that HDMI core is similar as on H3, but at least Rockchip 8 ch audio implementation seems to better follow standards. Unfortunately, I don't have any HW to test this functionality.

[Kwiboo]

The RK3328 seems like a very nice SoC, but the support in mainline linux is currently very limited and there are still a few issues with Rockchip's LSK 4.4 kernel.

We are currently tracking a few RK3328 issues at https://github.com/Kwiboo/linux-rockchip/issues for our LibreELEC endeavor.

 

@Xalius @Da Alchemist Android is most likely limited to 720p due to the weak GPU, we are planing on doing the same for LibreELEC/Kodi/PMP, limit gles to 720p/1080p but allow video frames to be shown in 2160p.

On the Z28 box we are only able to have a smooth gui at 720p, at 1080p there are noticeable frame rate drops at times.

 

@jernej there was a ffmpeg mpp decoder submitted earlier today, see https://patchwork.ffmpeg.org/patch/3904/

Multi-channel PCM via HDMI should work very similar as other SoCs with 8ch I2S and a DesignWare HDMI TX IP, works great on Rockchip's LSK 4.4 kernel at least.

The Rockchip RK3399TRM V1.3 Part2.pdf from Firefly-RK3399 docs is very interesting if you want more details about the HDMI TX IP and its registers.

[Xalius]

2 minutes ago, Kwiboo said:

The RK3328 seems like a very nice SoC, but the support in mainline linux is currently very limited and there are still a few issues with Rockchip's LSK 4.4 kernel.

We are currently tracking a few RK3328 issues at https://github.com/Kwiboo/linux-rockchip/issues for our LibreELEC endeavor.

 

@Xalius @Da Alchemist Android is most likely limited to 720p due to the weak GPU, we are planing on doing the same for LibreELEC/Kodi/PMP, limit gui to 720p/1080p but allow video frames to be shown in 2160p.

On the Z28 box we are only able to have a smooth gui at 720p, at 1080p there are noticeable frame rate drops at times.

 

@jernej there was a ffmpeg mpp decoder submitted to earlier today, see https://patchwork.ffmpeg.org/patch/3904/

Multi-channel PCM via HDMI should work very similar as other SoCs with 8ch I2S and a DesignWare HDMI TX IP, works great on Rockchip's LSK 4.4 kernel at least.

The Rockchip RK3399TRM V1.3 Part2.pdf from Firefly-RK3399 docs is very interesting if you want more details about the HDMI TX IP and its registers.

 

Thanks for the info! One more github to keep track of :-)

 

We'll see how ayufan's first Android experiments turn out, but even on AW A64 / Pine64 Android 6/7 ran pretty well @1080p after some tweaking, a lot better than the SDK based stock images at least, 4K for video playing is more or less possible, but acccelerated 3D with Mali400 not so much... as far as I could see all of those RK3328 Android boxes run on an older 3.10.x kernel too instead of 4.4.x...

 

At the moment there is a very early Debian image for Rock64 based on https://github.com/rock64-linux and ayufan already set up his CI magic to build consistent images at https://github.com/ayufan-rock64 , https://github.com/ayufan-rock64/linux-build/releases , https://jenkins.ayufan.eu/job/linux-build-rock-64/ .

 

One issue we ran into is that there seems to be a problem with DRAM settings for Rock64 atm, the image is not running stable at least on the 4GB board, probably because the DRAM settings are from either the 1GB or 2GB board and RK has not yet released the u-boot spl and dram init code for RK3328, there are only two miniloaders with either 333Mhz or 768Mhz DRAM settings...

[jernej]

27 minutes ago, Kwiboo said:

our LibreELEC endeavor.

That looks very promising code-wise. I will get rock64 soon and definetly test your project. Do you have any issue tracker for Kodi related issues? Do you have zero copy rendering or do you render through GPU?

[Xalius]

I forgot to ask, @Kwiboo do you need Rock64 boards, maybe Tl can send out more samples?

[Kwiboo]

2 hours ago, Xalius said:

We'll see how ayufan's first Android experiments turn out, but even on AW A64 / Pine64 Android 6/7 ran pretty well @1080p after some tweaking, a lot better than the SDK based stock images at least, 4K for video playing is more or less possible, but acccelerated 3D with Mali400 not so much... as far as I could see all of those RK3328 Android boxes run on an older 3.10.x kernel too instead of 4.4.x...

 

On the Z28 box the GPU will run at 600Mhz, the CPU at 1296Mhz and DDR at 786Mhz and we are using performance cpu/gpu governor but we still do not have silky smooth 1080p.

I haven't received my ROCK64 dev board yet, but I hope the increased DDR speed will improve GPU performance a little bit.
 

2 hours ago, jernej said:

That looks very promising code-wise. I will get rock64 soon and definetly test your project. Do you have any issue tracker for Kodi related issues? Do you have zero copy rendering or do you render through GPU?

 

There is currently no issue tracker for Kodi related parts, the current code is pretty stable and upstreaming efforts have started at https://github.com/Kwiboo/plex-home-theater/commits/rockchip-leia

We use drm/kms rendering and have zero-copy for video, only the gles gui uses the GPU. There are still improvements to be made and the current use of set plane legacy drm api requires a kernel hack to prevent double vsync.

 

2 hours ago, Xalius said:

I forgot to ask, @Kwiboo do you need Rock64 boards, maybe Tl can send out more samples?

 

Thanks, we already have Rock64 boards incoming , very exited to test it out once it arrives

[Da Alchemist]

@Kwiboo is there something to test on the Z28 Box, I got the the small one 1/8?

[Kwiboo]

23 minutes ago, Da Alchemist said:

@Kwiboo is there something to test on the Z28 Box, I got the the small one 1/8?

 

The current state of the LibreELEC RK3328 build is rather unstable with occasional lockup or crash, there is also no working ethernet or wifi yet, making it very unusable and hard to test new builds.

I see great potential in RK3328 as Rockchip have been very supportive this far and are working on fixes for issues we have reported.

 

I have personally only tested on the Z28 2/16 box but you should be able to build an image using the build command on https://github.com/Kwiboo/LibreELEC.tv/tree/rockchip/projects/Rockchip/devices/RK3328 and flash the resulting image to a sd-card.

But in order to boot from the sd-card you will have to erase the current bootloader from emmc, and that is where it gets a little bit tricky unless you are familiar with rockchip maskrom/rockusb mode and have uart connected.

 

I am looking forward to switching to a ROCK64 board for continued RK3328 development

[Da Alchemist]

39 minutes ago, Kwiboo said:

 

.........and that is where it gets a little bit tricky unless you are familiar with rockchip maskrom/rockusb mode and have uart connected.....

So the tricky part is above my skills, but I am going to connect some wires to the UART Pins to be prepared when the fun starts early next spring.

[TonyMac32]

I was just about to post something, then decided to search first (Amazing, right?)  I'd love to get my hands on one of these, if I can/do I'll be happy to help out/test/etc.  There is a small mountain of mainline patches going through for the rk3328 and the rk805, so kernel support shouldn't be a problem for long.

[tkaiser]

This is ROCK64 specific. New board with correctly working USB3 arrived 10 minutes ago. Switched to performance governor and doing the usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' with the slowest SSD I have lying around (Intel 540):

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    10794    14075    18413    14337    12084    13125
          102400      16    38316    48250    58929    50123    33636    44383
          102400     512    85148   113573   217972   226149   209220   229556
          102400    1024   239054   254531   226798   261436   240226   213082
          102400   16384   271696   291983   316979   323006   282067   292218

In other words: this is the new single drive NAS board. Forget about overpriced fails or slow A20 boards or their R40/V40 successors currently only available from brain damaged retards.

[tkaiser]

I forgot:

root@rock64:/mnt/sda# uname -a
Linux rock64 4.4.66 #1 SMP Sun Jun 11 16:46:11 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
root@rock64:/mnt/sda# lsusb -t
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M

This is an outdated ayufan build from 2 weeks ago. UAS already working but maybe needing quirks (see ODROID-XU4)

 

Edit: Better SSD, better numbers: https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34185

 

[TonyMac32]

This isn't helping me not want one.  ;-)

 

I'm paging through the mainline kernel support, hopefully more of these make it out of the Rockhchip patchwork and into 4.12 (like RK805 support).  As it stands I think mainline support is possible, if not extremely convenient.

[pfeerick]

@TonyMac32 We're not that far away from mainline support already... at least the first digit is a 4 instead a 3!!  The rockchip folks have stated that they are committed to open source, and are working towards mainline support, so fingers crossed it happens. Making this board the (if not the, then one of) the best best linux supported SBCs for 2017 and with a reasonable hardware set?