3 3
tkaiser

ROC-RK3399-PC (Renegade Elite)

Recommended Posts

On 9/9/2018 at 11:30 AM, gounthar said:

Still a few days to go, and there only one choice for eMMC, which is the 128GB.

They probably think that if you want it, you want the maximum amount. Quite similar to high-end phones now.

 

That said, I hope for Armbian support soon. I bit the bullet and bought one, maybe I sell my old Firefly RK3399 instead.

Share this post


Link to post
Share on other sites
On 9/9/2018 at 11:30 AM, gounthar said:

only one choice for eMMC, which is the 128GB

 

Honestly: if I have a RK3399 device and want 128 GB storage I choose something different. I ordered a cheap DRAM less NVMe SSD for 40€ (VAT/shipping included),  inserted it into the M.2 slot, transferred the rootfs as easy as always with nand-sata-install and now my NanoPC-T4 runs directly off the NVMe SSD.

 

I've no doubt that the eMMC performs nicely. But I doubt it's as fast as an NVMe SSD and what I like the most with SSDs: the good ones tell you when they start to wear out:

root@nanopct4:/home/tk# smartctl -x /dev/nvme0n1
smartctl 6.6 2016-05-31 r4324 [aarch64-linux-4.4.153-rk3399] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       TS128GMTE110S
Serial Number:                      AC2153AAE531202E0165
Firmware Version:                   R0515A0
PCI Vendor/Subsystem ID:            0x126f
IEEE OUI Identifier:                0x000000
Controller ID:                      1
Number of Namespaces:               1
Namespace 1 Size/Capacity:          128,035,676,160 [128 GB]
Namespace 1 Formatted LBA Size:     512
Local Time is:                      Mon Sep 10 18:38:24 2018 UTC
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0006):   Format Frmw_DL
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat *Other*
Maximum Data Transfer Size:         64 Pages
Warning  Comp. Temp. Threshold:     70 Celsius
Critical Comp. Temp. Threshold:     80 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     9.00W       -        -    0  0  0  0        0       0

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02, NSID 0x1)
Critical Warning:                   0x00
Temperature:                        28 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    110,342 [56.4 GB]
Data Units Written:                 289,050 [147 GB]
Host Read Commands:                 11,897,227
Host Write Commands:                22,892,268
Controller Busy Time:               126
Power Cycles:                       10
Power On Hours:                     1
Unsafe Shutdowns:                   4
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

 

The 'Percentage Used' line is the important one. As long as this is below 90 everything's fine. An eMMC will die suddenly without any prior warning...

Share this post


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

That said, I hope for Armbian support soon.

We would need the hardware to do that, and the time.  That said it looks like a board with promise, I think it would be a nice addition.

Share this post


Link to post
Share on other sites

As I bought it, I may run some tests to help...
But for building and all, I have already proved I am useless for the time being (AllWinner H6 for example).

Share this post


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

I may run some tests to help...

 

Well, if Libre Computer is interested in getting Armbian on their boards at least some developers need samples. And wrt testing: It's a RK3399 thing so almost everything is already known.

 

Only interesting: how fast is memory access (are different DRAM initialization BLOBs used or not?), how fast is the eMMC and how well works heat dissipation. So iozone and sbc-bench and done.

 

To me Renegade Elite looks more like an ARM device for a couple of professional use cases (mainly dealing with cameras and imaging) running Android. But it seems enthousiasts are not scared away by costs and want to run Linux for whatever reasons...

 

Almost forgot: Of course compatibility testing with various USB-C PSUs might be interesting as well. @gounthar which USB-C chargers do you own? 'Good' ones from this list?

Share this post


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

Well, if Libre Computer is interested in getting Armbian on their boards at least some developers need samples. And wrt testing: It's a RK3399 thing so almost everything is already known.

 

Only interesting: how fast is memory access (are different DRAM initialization BLOBs used or not?), how fast is the eMMC and how well works heat dissipation. So iozone and sbc-bench and done.

 

To me Renegade Elite looks more like an ARM device for a couple of professional use cases (mainly dealing with cameras and imaging) running Android. But it seems enthousiasts are not scared away by costs and want to run Linux for whatever reasons...

  

Almost forgot: Of course compatibility testing with various USB-C PSUs might be interesting as well. @gounthar which USB-C chargers do you own? 'Good' ones from this list?

It wouldn't hurt to ask Libre Computer and point out that their not-so-successful campaign (around 68% of target reached) might have been successful if they would have broad and stable support from Armbian. 

 

That was the main road block for me - the software. The fact that they promise mainline kernel, starting from 4.19, actually made me buy it. All ARM devices are sketchy in this regard. With mainline support, I can use the device as long as I like, without falling behind and stuck with old kernels.

Share this post


Link to post
Share on other sites
6 minutes ago, emk2203 said:

The fact that they promise mainline kernel, starting from 4.19, actually made me buy it. All ARM devices are sketchy in this regard.

 

Well, depends solely on the SoC used. I just did some benchmarks with 4.19 on one of my RK3399 devices yesterday: https://forum.armbian.com/topic/8161-swap-on-sbc/?do=findComment&comment=61637

 

Wrt features I'm not that much interested in (anything that requires adding a display to the boards) I wouldn't count on every feature available with mainline Linux (or Linux at all) regardless of SoC. But honestly I don't know enough about these areas and even managed to spread BS already.

 

Share this post


Link to post
Share on other sites
On 7/14/2018 at 6:59 PM, codnoscope said:

Hey I've seen some reports that the on board XOR flash will be flashed with GUI enabled uEFI firmware, is this true?

That might be true, since there's already an RK3399Pkg (haven't tried myself), but I'd still recommend u-boot, unless you are interested in one of the following use cases:

1. CentOS/Fedora/openSUSE, based on UEFI and grub on ARM64. These distros are mostly made for servers, instead of IoT stuff, so if you want something like KVM on ARM64, you could try to use them. But I doubt RK3399's 4G RAM could ever handle virtual machines. If you really want an ARM64 server, I recommend more serious solutions like Qualcomm centriq or Cavium ThunderX. If you just want to isolate your own code into different environments, use lxc/lxd or docker on (u-boot based) Armbian.

2. Windows on ARM64, requires UEFI and ACPI. I'd admit it's quite attractive lightweight desktop solution, and it can even handle simple x86 programs as well. There's already someone made this for Raspberry Pi 3, but just forget it, that's definitely unusable, considering the horribly slow IO of RPi and the crazy (heavily IO bounded) background tasks of the most bloated desktop OS on the earth. On RK3399, yes, I think it is possible to handle Windows' crazy background IO with a USB or SATA or even NVMe SSD (actually a good eMMC could handle that as well), but you'll need to write a lot of Windows drivers to bring up a new platform, including SDIO, eMMC, USB, GMAC, PCIe, and the most difficult part, display drivers (like Rockchip DRM on Linux) on your own or you have to use the (probably slow as hell) UEFI GOP for display. GPU is actually not needed to run Windows desktop, and probably not possible unless you are an employee of ARM Holdings and has the source code of the Mali GPU Windows drivers which has never been released before but actually does exist. The assumptions above are all based on the fact that ACPI was implemented properly, and I don't think this would be true. You can implement ACPI on your own, though.

 

I don't have any other idea to convince myself that UEFI would be useful on this platform. What's the exact use case you're expecting to do with UEFI?

 

4 minutes ago, emk2203 said:

It wouldn't hurt to ask Libre Computer and point out that their not-so-successful campaign (around 68% of target reached) might have been successful if they would have broad and stable support from Armbian.  

IMO The biggest and only problem so far for all RK3399 boards is pricing. And this was the reason that I was excited about NanoPi M4, since it had a much lower price while keeping the essential components on board (like WiFi/BT). Unfortunately, people around me still think $65 is a little too high for an SBC when I recommend the board to them. For most people, purchasing a $99 (or higher) SBC is really a crazy idea, even if Armbian has great support for it.

 

Share this post


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

Almost forgot: Of course compatibility testing with various USB-C PSUs might be interesting as well. @gounthar which USB-C chargers do you own? 'Good' ones from this list?

I have nothing regarding USB-C. So I chose a perk which contained their USB-C charger to avoid any problem.

Share this post


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

IMO The biggest and only problem so far for all RK3399 boards is pricing

 

Couldn't agree more and still ask myself what I did the first time I heard of RK3399 boards: 'what's the use case for an ARM board that costs as much as a real Mini PC?' If the special capabilities of such devices (dual camera input, image processing, attaching a bunch of displays -- no idea what works with Linux and what only with Android) aren't used what's the point of spending huge amounts of money on these things?

 

But maybe it's only me. At least I don't want to spend ~40 bucks just on a PSU (USB-C PD compliant) for such a device or +20 bucks to get appropriate heat dissipation (applies to Khadas Edge/Edge-V -- ~60 bucks for 'basic' accessories but users seem happy)

 

1 hour ago, gounthar said:

So I chose a perk which contained their USB-C charger to avoid any problem.

 

Wow, 100 bucks (with a 20% Indiegogo discount) for 128GB storage and the PSU.

Share this post


Link to post
Share on other sites
4 minutes ago, tkaiser said:

no idea what works with Linux and what only with Android) aren't used what's the point of spending huge amounts of money on these things?

at least one camera should be possible with the ISP1 driver, going through the related issues on rockchips github, people did it. For sure it would involve some DT work and some kernelconfig work due to 'ISP1 is prone to crash your kernel'..  Why spend so much money? Hmm things I can imagine is power-consumption (to be clear, that's your domain, so you might compare it with some of this NUC or whatever minicomputer is on the market now). It your little computer runs 24/7 this might have an impact (especially when you're able to run your decoding stuff on it)...  For my desktop use-cases at home an RK3399 could probably replace an AMD64 machine mostly (I need 20 tabs in chrome, some simple editors and a console :lol:). For my professional needs, well different story, even something as simple as an editor to draw chemical structures isn't available for Linux (there are some, but development stopped mostly since years). Most professional applications are available for Windows/Mac (yeah, somehow chemists like mac... :D) and if there's a linux version, it's precompiled for x86, amd64 even it wouldn't be much efforts to build arm versions for it.. But you don't get sources for software which has an annual fee of >3000$... :rolleyes:

Share this post


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

Wow, 100 bucks (with a 20% Indiegogo discount) for 128GB storage and the PSU.

Yes, I know, I'm not proud of that.

I have tons of personal and professional uses for this board (video, Docker, ci...).

Share this post


Link to post
Share on other sites
On 9/12/2018 at 4:50 AM, hjc said:

That might be true, since there's already an RK3399Pkg (haven't tried myself), but I'd still recommend u-boot, unless you are interested in one of the following use cases:



I don't have any other idea to convince myself that UEFI would be useful on this platform. What's the exact use case you're expecting to do with UEFI?

Thanks for the github link, I should try it.

 

I don't have any UEFI specific use case, just want to tinker. ;)

Share this post


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

I don't have any UEFI specific use case, just want to tinker

 

With something that's broken by design? Adding tons of complexity for no real reason and allowing to backdoor your system at a level the OS can never detect? Ever done a simple web search for 'uefi security vulnerabilities issue' or something like that?

Share this post


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

 

With something that's broken by design? Adding tons of complexity for no real reason and allowing to backdoor your system at a level the OS can never detect? Ever done a simple web search for 'uefi security vulnerabilities issue' or something like that?

Speaking about firmware backdoor, x86 PC OEMs have never stopped doing that. Actually chip vendors and OEMs always have their methods to plant backdoors, regardless it's a UEFI system or not. on x86 they could use SMM, on ARMv8 nowadays, EL3 is used.

Although we love those boards with open source ATF implementation, most ARM devices don't open their firmware, like Qualcomm chips will never allow you to modify code running in EL3, and they only provide the firmware in the form of binary blobs.

 

But, well, I do agree that UEFI is a complex broken design. UEFI firmware nowadays is even more over-sized than regular operating systems in the good old days (when BIOS was used)

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
3 3