Igor

Librecomputer Renegade RK3328

Recommended Posts

I just received mine today, having a hard time getting the image downloader (etcher based) to work, keeps failing out.  Not that I wasn't going to try to build something anyway...

 

@tkaiser https://github.com/FireflyTeam/kernel/commit/b989ade19312ecf57f993120b9668b9d1d3fd380

https://github.com/FireflyTeam/u-boot/commit/3f87b0c622e246f138d4d32c599fa087b880cade

 

Mainline I haven't looked at/for yet.

 

@JMCC I'm not 100% on the differences, but my understanding is the Rock64 is DDR3 and does not support UHS modes on the microSD.  It has also been out a while and has decent support.  The Rock64 is friendlier to the wallet and comes with a (small) barrel jack and SPI flash for housing uboot, something I can always support.  ;-)  Memory and SD throughput would be the major benefits on the Renegade, although I'd have to question why someone that concerned wouldn't just us a USB3 storage medium for the rootfs at that point, on either board, to be honest.  I believe the Rock64 can boot a USB media from the SPI flash.  (correct me if wrong, anyone, I haven't tried it)

Share this post


Link to post
Share on other sites
2 hours ago, TonyMac32 said:

 

This one is funny. The Kconfig talks about 'eMMC module socket, MicroSD Card slot, Pi-2 Bus, Pi-P5+ Bus, USB 3.0 and many others peripheral devices interface for makers'. Weird language and there's no 'Pi-P5+ Bus' on this board but ROCK64 is providing another 22 pin header inspired by the old RPi P5 header. The Kconfig text for this Renegade board is simply copy&paste of Rock64 product page typos included B)

 

Also I asked 5 weeks ago for the necessary blobs but to no avail. Obviously having the device vendor 'on board' here doesn't help that much with Libre Computer hardware :(

 

The only real difference is DDR4 vs. DDR3 memory but as we already learned DDR4 is not automagically faster, also often higher memory bandwidth is accompanied by higher latency so I wouldn't call DDR4 automatically an advantage (only for media streaming use cases -- using an SBC as TV box). For obvious reasons I do not trust in the memory bandwidth numbers published here any more (also there's only memcpy/memset mentioned but no word about latency).

 

And then there's Micro USB for DC-IN... how should this work with a connected USB3 disk that wants to be powered by the host (many popular external 2.5" USB3 disks do this)?

Share this post


Link to post
Share on other sites

hi guy's, pay attention when looking for a emmc module for Renegade-cc, the socket is not the same as the one of Rock64 and OdroidXU4.

Here two links perhaps you haven't seen yet:

 

https://forum.armbian.com/topic/6850-document-about-compiling-a-kernel-and-rootfs-for-the-firefly-boards/

 

http://forum.loverpi.com/discussion/62/no-iptables-support-and-vpn-connections-dont-work-and-no-linux-image-installed

the_rig
April 29

The ubuntu image provided by Libre/Firefly is crap, it misses a lot of kernel modules. I use Armbian now, they more-or-less support the ROK-RK3328-CC.

You can try the Armbian build I made, it's prepared for ipsec. https://www.dropbox.com/s/a2pqliuc2oyc7p3/Armbian_5.41_Roc-rk3328-cc_Ubuntu_xenial_default_4.4.120.img?dl=0

Share this post


Link to post
Share on other sites

When searching for rock64 in kernel folder you will find two files: rk3328-rock64.dts and rk3328-rock64-android.dts

git clone https://github.com/FireflyTeam/kernel.git
git clone https://github.com/FireflyTeam/build.git
git clone https://github.com/FireflyTeam/rkbin.git
git clone https://github.com/FireflyTeam/u-boot.git

 

Edit: Button on Renegade-cc is not for power, it's a recovery button, used to enter loader mode http://en.t-firefly.com/doc/product/info/id/381.html#Loader20mode0A

Edited by ces

Share this post


Link to post
Share on other sites

Now that the Rock64 has achieved the "supported" status, there is a free seat in the WIP section. Any chance that this board can make it into WIP soon?

Share this post


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

Now that the Rock64 has achieved the "supported" status, there is a free seat in the WIP section. Any chance that this board can make it into WIP soon?


Yes, it's almost Rock64 ...  but what are those small diffs,  who wants to be in charge? I can build images (when we merge stable and development branches) and leave it this way: https://www.armbian.com/z28-pro/ as an alternative/for a while.

Share this post


Link to post
Share on other sites
11 hours ago, Igor said:

I can build images (when we merge stable and development branches) and leave it this way: https://www.armbian.com/z28-pro/ as an alternative/for a while.

IMO downloads for .csc boards is a bit 'questionable'... People will ask why we provide images for *random csc board* but not for *random other csc board*. This should IMO only be possible with a "csc Maintainer" - has not to be part of 'GitHub Project Team' but at lest 'more or less' active on the forum to handle questions related to this boards/images.

Share this post


Link to post
Share on other sites
49 minutes ago, chwe said:

downloads for .csc boards is a bit 'questionable'...

Agreed.  Do we have enough information to move forward with a build?  

Share this post


Link to post
Share on other sites
15 hours ago, chwe said:

IMO downloads for .csc boards is a bit 'questionable'... People will ask why we provide images for *random csc board* but not for *random other csc board*. This should IMO only be possible with a "csc Maintainer" - has not to be part of 'GitHub Project Team' but at lest 'more or less' active on the forum to handle questions related to this boards/images.

Sorry for asking about the basics:

  • What does exactly "csc" mean? I know boards with that status have no official support, but they have a ".csc" file associated file in the Armbian build system. What does the acronym "CSC" stand for? What is required for a board to get "csc" status?
  • What would exactly be the role of that "csc Maintainer"? Would it be something like staying up to date about the new ".csc" incorporations, and answering people's questions about those board's status?

Share this post


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

What does exactly "csc" mean?

Community supported configuration. This means that somebody wanted to have a target for building kernels and/or images for this device, but the core team does not have this device and does not have interest in obtaining and supporting this device (otherwise this would be a stable or Work-In-Progress configuration).

 

4 hours ago, JMCC said:

What is required for a board to get "csc" status?

Adding its support into the build system, preferably without breaking anything for other existing boards. :) I think the only real requirement is that it must not be a custom/private design.

 

4 hours ago, JMCC said:
  • What would exactly be the role of that "csc Maintainer"? Would it be something like staying up to date about the new ".csc" incorporations, and answering people's questions about those board's status?

Yes, making sure that everything that should work still works, adjusting build related configuration and testing resulting packages and images.

Share this post


Link to post
Share on other sites
30 minutes ago, zador.blood.stained said:

making sure that everything that should work still works, adjusting build related configuration and testing resulting packages and images.

So, if I understand, there can be a maintainer for some specific board, not necessarily for all the csc boards at once, correct? Well, if that's the case, I already ordered my Renegade, so I can give a try to the image when I get it, and report how it is working. Depending on that, maybe it can became a community (un)supported board, and I can take care of those updates.

Share this post


Link to post
Share on other sites

@zador.blood.stained was faster, but I don't clean the text below.. :P 

 

CSC =  community supported configuration, sometimes a bit misleading due to most csc board are initially pushed by someone of the maintainers.. :P CSC Imaged can be build when you switch to <Show CSC/WIP/EOS> and agree on the following warning:

 

4 hours ago, JMCC said:

What would exactly be the role of that "csc Maintainer"? Would it be something like staying up to date about the new ".csc" incorporations, and answering people's questions about those board's status?

Since this concept of a "csc Maintainer" isn't defined yet and I'm not a 'maintainer', I can only bring up my opinions how this role should look like. 

For example, the build of BPi-M2-Zero csc images was broken for a long time, due to one needed patch which could be potential harmful for other boards war removed for good reasons by @tkaiser, having such csc configurations which are known non-working for a long time are somehow annoying due to the questions which came up in the forum (e.g. my bpi-m2-zero build doesn't boot? what should I do?).  For me, a "csc maintainer" would try to fix such issues, takes care to improve the build for this board (proper kernelconfig, applying patches related to this board etc.). For this, you don't have to be a maintainer on GitHub, you can solve this by sending PRs to fix issues. More or less similar to wip boards but done by someone of the community and not by a 'maintainer'. Probably some adjustments on the Build repo are needed so that those patches can not harm supported boards (e.g. having a patch subdirectory for csc board as discussed here).  This might need some testing (does the board still boot after kernel/u-boot updates for this linuxfamily etc.).

For me, there should a valid reason when we provide images for CSC boards (e.g. it's planed that a maintainer will level up it to wip soon or someone from the community keeps an eye on it). Otherwise we should only "allow" people to build such images but not not provide images for it, cause people expect that a provided image boots if it's in the downloadsection (no matter how many red flags are there that you've been warned)... 

Defining a new board on a existing kernel/ u-boot family isn't that hard (it actually only needs a new boardconfig file and probably some patches e.g. device tree as long as these are not available in the kernelsource repo we use for this SoC). 

 

8 minutes ago, JMCC said:

So, if I understand, there can be a maintainer for some specific board, not necessarily for all the csc boards at once, correct?

responsible for all csc boards would actually mean that you maintain  ~20 boards.. :P That might be a way to much to begin with.. Maintaining one could be a nice 'starting point' to dive into 'low-level' stuff (at least for me it was, even when I failed horribly with my first attempts :P).  

Share this post


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

For example, the build of BPi-M2-Zero csc images was broken for a long time

 

For no reason. No idea why the board has been added at all. It made absolutely no sense to add a broken and untested patch to the build system. One of the many reasons contributing to Armbian got so frustrating.

Share this post


Link to post
Share on other sites
On 5/8/2018 at 8:19 AM, tkaiser said:

The only real difference is DDR4 vs. DDR3 memory but as we already learned DDR4 is not automagically faster, also often higher memory bandwidth is accompanied by higher latency

 

Thanks to @ces who donated his RK3328-CC out of frustration the board is lying now on my desk. Tinymembench numbers with kernel 4.4.114, Debian 9 from Firefly and 1.4 GHz: https://pastebin.com/5CJ94dk6

 

OpenSSL numbers confirm the 1.4 GHz (same numbers as NanoPi Fire3 and slightly faster than Rock64 clocking at 1.3 GHz)

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      94490.89k   298985.71k   628713.13k   899772.07k  1029215.57k  1038346.92k
aes-192-cbc      90576.25k   270158.63k   520800.85k   699573.25k   776418.65k   781172.74k
aes-256-cbc      88150.68k   251416.41k   456345.09k   588011.52k   641419.95k   645251.07k

I would guess bootloader blobs (DRAM initialization) can be found here https://github.com/FireflyTeam/rkbin/tree/master/rk33?

 

Edit: decompiled rk3328-roc-cc.dtb, seems it's based on rk3328-roc-cc.dts and includes over there.

Share this post


Link to post
Share on other sites

Quick look at network, powering and USB situation (using Firefly OS image / kernel). We have the same annoying xhci messages as on Rock64 (full dmesg output) and also no UAS on USB2 ports.

 

Switching to performance cpufreq governor, mounting my usual EVO840 in a JMS567 enclosure running the usual iozone stuff:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    15831    23674    26796    26832    16945    23613    
          102400      16    49364    67209    74121    74910    58977    67366    
          102400     512   276872   286532   297002   306256   296619   301503    
          102400    1024   302448   315207   318405   329250   321060   320937    
          102400   16384   337756   340906   347968   359887   359601   339523    
         1024000   16384   355290   358703   359438   360631

Performance numbers with Rock64 with preliminary kernel support back then (!!) here: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&amp;comment=34185

 

I power the board through Micro USB as designed but using one of those great Micro USB cables from FriendlyELEC. PSU is 2A rated. A 2.5" HDD in an ASM1153 enclosure is connected to an USB2 port, the EVO840 SSD in the JMS567 enclosure is connected to the USB3 port. Both disks powered by the board. On each disk our usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' call is creating load from the USB consumers (9W), then I added a cpuburn-a53 task. Board rebooted when my Powermeter showed 13.7W consumption which is way beyond Micro USB specs (9W / 1.8A max) and my PSU's (10W / 2A). As expected the board rebooted after ~20 seconds due to underpowering (my PSU being too weak and/or voltage drop -- too lazy to measure for this since it's the vendor's job).

 

Fortunately the board can be powered through the GPIO header too (@ces did a great PSU mod allowing to use a 4A PSU with the GPIO header using pins 4/6 to power the board). Repeating the test my powermeter reported +16W with both disk benchmarks and cpuburn-a53 running in parallel but no problems occured at all.

 

Quick look at network performance: GbE can be fully saturated as expected:

 

macbookpro-tk:~ tk$ iperf3 -c 192.168.83.26
Connecting to host 192.168.83.26, port 5201
[  4] local 192.168.83.32 port 58995 connected to 192.168.83.26 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   109 MBytes   915 Mbits/sec                  
[  4]   1.00-2.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   3.00-4.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   4.00-5.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   6.00-7.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   7.00-8.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   8.00-9.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   9.00-10.00  sec   112 MBytes   940 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec                  sender
[  4]   0.00-10.00  sec  1.09 GBytes   937 Mbits/sec                  receiver

iperf Done.
macbookpro-tk:~ tk$ iperf3 -R -c 192.168.83.26
Connecting to host 192.168.83.26, port 5201
Reverse mode, remote host 192.168.83.26 is sending
[  4] local 192.168.83.32 port 59008 connected to 192.168.83.26 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   110 MBytes   919 Mbits/sec                  
[  4]   1.00-2.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   2.00-3.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   3.00-4.00   sec   112 MBytes   942 Mbits/sec                  
[  4]   4.00-5.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   5.00-6.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   6.00-7.00   sec   112 MBytes   942 Mbits/sec                  
[  4]   7.00-8.00   sec   112 MBytes   941 Mbits/sec                  
[  4]   8.00-9.00   sec   112 MBytes   940 Mbits/sec                  
[  4]   9.00-10.00  sec   112 MBytes   941 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver

iperf Done.

 

 

Share this post


Link to post
Share on other sites
On 5/17/2018 at 3:18 PM, JMCC said:

I already ordered my Renegade, so I can give a try to the image when I get it, and report how it is working. Depending on that, maybe it can became a community (un)supported board, and I can take care of those updates.

 

I would prefer to simply pull in the needed bits from Firefly repos but otherwise treat the Renegade just as another member of our rk3328 $BOARDFAMILY relying on ayufan's repos for everything else as we do it already with Rock64. The only differences between both boards are DRAM (initialization) and a few DT bits.

Share this post


Link to post
Share on other sites
2 hours ago, tkaiser said:

I would prefer to simply pull in the needed bits from Firefly repos but otherwise treat the Renegade just as another member of our rk3328 $BOARDFAMILY relying on ayufan's repos for everything else

Definitely, that's what I had in mind.  Bringing up a board from scratch is way out of my league! But, if by your post you mean that you'd rather do it yourself (and therefore giving it the WIP status), I will be more than happy.

One way or another, I think it is an interesting board to have at least as WIP, mostly because as you point out it seems like it would not be too difficult to add it to the RK3328 family. Plus, documentation seems pretty decent to me.

Share this post


Link to post
Share on other sites
25 minutes ago, JMCC said:

But, if by your post you mean that you'd rather do it yourself (and therefore giving it the WIP status), I will be more than happy

 

Nope, I won't spend time on this. But since the differences compared to Rock64 are negligible and the only potential Con (powering via Micro USB) can be addressed by adding a warning to the download page I vote for giving the board WIP and later supported status if someone wants to maintain it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now