TonyMac32 Posted May 8, 2018 Posted May 8, 2018 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) 0 Quote
tkaiser Posted May 8, 2018 Posted May 8, 2018 2 hours ago, TonyMac32 said: https://github.com/FireflyTeam/u-boot/commit/3f87b0c622e246f138d4d32c599fa087b880cade 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 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)? 0 Quote
ces Posted May 10, 2018 Posted May 10, 2018 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 0 Quote
ces Posted May 10, 2018 Posted May 10, 2018 (edited) 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 May 11, 2018 by ces 0 Quote
JMCC Posted May 15, 2018 Posted May 15, 2018 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? 0 Quote
Igor Posted May 16, 2018 Author Posted May 16, 2018 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. 1 Quote
JMCC Posted May 16, 2018 Posted May 16, 2018 33 minutes 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. Sounds fair. 0 Quote
chwe Posted May 16, 2018 Posted May 16, 2018 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. 0 Quote
TonyMac32 Posted May 16, 2018 Posted May 16, 2018 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? 0 Quote
JMCC Posted May 17, 2018 Posted May 17, 2018 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? 0 Quote
zador.blood.stained Posted May 17, 2018 Posted May 17, 2018 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. 0 Quote
JMCC Posted May 17, 2018 Posted May 17, 2018 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. 0 Quote
chwe Posted May 17, 2018 Posted May 17, 2018 @zador.blood.stained was faster, but I don't clean the text below.. CSC = community supported configuration, sometimes a bit misleading due to most csc board are initially pushed by someone of the maintainers.. 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.. 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 ). 0 Quote
tkaiser Posted May 17, 2018 Posted May 17, 2018 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. 0 Quote
tkaiser Posted May 23, 2018 Posted May 23, 2018 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. 0 Quote
tkaiser Posted May 23, 2018 Posted May 23, 2018 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&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. 0 Quote
tkaiser Posted May 23, 2018 Posted May 23, 2018 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. 0 Quote
JMCC Posted May 23, 2018 Posted May 23, 2018 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. 0 Quote
tkaiser Posted May 23, 2018 Posted May 23, 2018 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. 0 Quote
blood Posted May 27, 2018 Posted May 27, 2018 For what it's worth, a Debian 9 image for this board was posted recently and is available at: http://share.loverpi.com/board/libre-computer-project/libre-computer-board-roc-rk3328-cc/image/debian/ I just threw it on an eMMC and booted up my board and it's working nicely now - though I'd prefer Armbian all the same. Since it's on my mind, I don't understand why they (Libre? Firefly? Rockchip?) chose 1.5mbps as the baud rate for the serial port. The only thing I can get to work with it is minicom and specifically minicom on Linux - on my MBP it won't let me use that speed, and even on Linux ckermit refuses to go that fast as well. It's a console... why not use a compatible speed? Also, not burning in a MAC address is lame too. I managed to get around that at least. On a positive note, I uninstalled network manager and lightdm and now it boots soup-to-nuts in under 10s. 0 Quote
hjc Posted June 3, 2018 Posted June 3, 2018 On 5/27/2018 at 9:05 AM, blood said: I don't understand why they (Libre? Firefly? Rockchip?) chose 1.5mbps as the baud rate for the serial port. It's the baud rate of rk33xx SoC. Though you can specify a different baud rate in kernel args, it will not affect the bootrom/spl/u-boot/etc. 0 Quote
JMCC Posted June 30, 2018 Posted June 30, 2018 Now you can build a default kernel image. There are for sure many things that will need to be tweaked, but the board boots and is fully functional (USB, HDMI display, ethernet). EMMC not tested (since I don't have one). @Igor Can you please have the build server make a Stretch-default desktop and server? My images have many bugs, due to this problem. 1 Quote
Igor Posted June 30, 2018 Author Posted June 30, 2018 5 minutes ago, JMCC said: Can you please have the build server make a Stretch-default desktop and server? My images have many bugs, due to this problem. Shell we change roc-rk3328-cc to renegade-rk3328 (or just renegade?) before making a test build? 0 Quote
tkaiser Posted June 30, 2018 Posted June 30, 2018 10 minutes ago, Igor said: Shell we change roc-rk3328-cc to renegade-rk3328 (or just renegade?) before making a test build? I would prefer 'speaking' names so renegade is IMO better than roc-???-cc. Soon there will be a "Renegade Elite" available based on RK3399... and renegade-rk3328 and renegade-rk3399 look almost the same. So maybe calling this now just renegade and the RK3399 board then renegade-elite? 2 Quote
Igor Posted June 30, 2018 Author Posted June 30, 2018 43 minutes ago, tkaiser said: So maybe calling this now just renegade @JMCC Done. https://www.armbian.com/renegade/ 2 Quote
switch Posted June 30, 2018 Posted June 30, 2018 No sun for me this summer! Huge thanks to everyone involved for making this available 0 Quote
JMCC Posted June 30, 2018 Posted June 30, 2018 23 minutes ago, Igor said: @JMCC Done. https://www.armbian.com/renegade/ Thanks! But you labeled it as "Stable" That was a risky bet! 0 Quote
switch Posted June 30, 2018 Posted June 30, 2018 The image isn't booting for me, is there anything that I've missed doing? Tried flashing using both dd and etcher 0 Quote
Igor Posted June 30, 2018 Author Posted June 30, 2018 4 hours ago, JMCC said: Thanks! But you labeled it as "Stable" Well, that is a kernel label ... which is (kind of) stable. Huh. Board is labeled as "no official support" ... I see that we will need to rework this logic a bit. 3 hours ago, switch said: The image isn't booting for me, ... and since I don't own this board, I have no idea if its working. 0 Quote
Recommended Posts
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.