2 2
tkaiser

Quick Review of Rock960 Enterprise Edition AKA Ficus

Recommended Posts

Latest RK3399 arrival in the lab. For now just some q&d photographs:

 

Ficus_1.jpg

Ficus_2.jpg

Ficus_3.jpg

 

@wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here! :)

 

A quick preliminary specifications list:

  • RK3399 (performing identical to any other RK3399 thingy out there as long as no throttling happens)
  • 2 GB DDR3 RAM (in April Vamrs said they will provide 1GB, 2GB and 4GB variants for $99, $129 and $149)
  • Board size is the standard 160×120 mm 96Boards EE form factor. EE = Enterprise Edition, for details download 96Boards-EE-Specification.pdf (1.1MB)
  • Full size x16 PCIe slot as per EE specs (of course only x4 usable since RK3399 only provides 4 lanes at Gen2 speed)
  • Board can be powered with 12V through barrel plug, 4-pin ATX plug or via pin header (Vamrs sent a 12V/4A PSU with the board)
  • Serial console available via Micro USB (there's an onboard FTDI chip)
  • 2 SATA ports + 2 SATA power ports (5V/12V). SATA is provided by a JMS561 USB3 SATA bridge that can operate in some silly RAID modes or PM mode (with spinning rust this chip is totally sufficient -- for SSDs better use NVMe/PCIe)
  • Socketed eMMC and mechanical SD card adapter available (Vamrs sent also a SanDisk 8GB eMMC module as can be seen on the pictures)
  • SIM card slot on the lower PCB side to be combined with an USB based WWAN modem in the mPCIe slot (USB2 only)
  • 1 x SD card slot routed to RK3399, 1 x SD card slot for the BMC (Baseboard Management Controller)
  • Gigabit Ethernet and separate Fast Ethernet port for the BMC
  • Ampak AP6354 (dual-band and dual-antenna WiFi + BT 4.1)
  • USB-C port with USB3 SuperSpeed and DisplayPort available
  • eDP and HDMI 2.0
  • USB2 on pin headers and 2 type A receptacles all behind an internal USB2 hub
  • USB3 on one pin header and 2 type A receptacles all behind an internal USB3 hub
  • 96boards Low Speed Expansion connector with various interfaces exposed
  • 96boards High Speed Expansion connector with various interfaces exposed (e.g. the 2nd USB2 host port, see diagram below)
  • S/PDIF audio out
  • 'real' on/off switch to cut power. To really power on the board the translucent button next to it needs to be pressed

 

ficus_block_diagram.png

Share this post


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

 

@wtarreau my first 96boards thing so far (just like you I felt the standard being directed towards nowhere given that there's no Ethernet). And guess what: 2 x Ethernet here!

 

Hehe, that doesn't change my opinion of this standard which is only useful to build development boards and nothing looking even remotely like a usable prototype. The small form factor only exposes useless stuff and the large one requires access to both sides, thus imposing an enclosure size. But for development I'm totally fine with the EE form factor as it provides a rich set of connectors and standards in a reasonable size.

Share this post


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

2 x Ethernet (also no idea yet)

I remember that once in a YouTube interview video it is said that one of these Ethernet ports are for out of band management. Don't know if that's accurate, though. It is mentioned that the LTE (mPCIe) port is also for the management system, so remote access of the serial console is possible.

 

Out of band management are barely seen in the area of SBC, at least for Armbian supported ones. IMO if OOB management is usable, Armbian's software testing might even take place in the cloud. One developer maintains a lot of physical boards at his/her home, others connect in using VPN or other methods, and do all the image deployment & testing remotely or even automatically, just like how we do that on modern x86 systems (BMC, IPMI stuff, or some SoC embedded solutions like Intel Management Engine).

Share this post


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

I remember that once in a YouTube interview video it is said that one of these Ethernet ports are for out of band management. Don't know if that's accurate, though. It is mentioned that the LTE (mPCIe) port is also for the management system, so remote access of the serial console is possible

 

Yeah, if I understood correctly the M.2 slot is there to fit the 'Baseboard Management Controller' (BMC): an MCU that then controls power and has serial console access to RK3399 while also being interconnected to a WWAN modem in the mPCIe slot. Well, we'll see once documentation becomes publicly available.

 

In the meantime I had a start with vendor provided Ubuntu 16.04.3 'server' OS image (download link, logon credentials are rock:rock, the archive also contains a BLOB called rk3399_loader_v1.12.112.bin). I just checked some tunables (e.g. /sys/module/pcie_aspm/parameters/policy defaulting to powersave) and let sbc-bench run for the following two reasons:

  • getting a 'baseline' so when switching over to Armbian being able to spot areas where Armbian might perform worse than vendor OS image (especially tinymembench numbers interesting here)
  • getting an early idea about heat dissipation. The board does not come with a heatsink and there are also no mounting holes. On the other hand the board size is huge and the whole board acts as a heatsink itself

Quick look at the results (full output):

 

sbc-bench v0.6.1

Installing needed tools. This may take some time... Done.
Checking cpufreq OPP... Done.
Executing tinymembench. This will take a long time... Done.
Executing OpenSSL benchmark. This will take 3 minutes... Done.
Executing 7-zip benchmark. This will take a long time... Done.
Executing cpuminer. This will take 5 minutes... Done.
Checking cpufreq OPP... Done.

ATTENTION: Throttling might have occured on CPUs 0-3. Check the log for details.

ATTENTION: Throttling might have occured on CPUs 4-5. Check the log for details.

Memory performance (big.LITTLE cores measured individually):
memcpy: 1439.4 MB/s (0.2%)
memset: 4771.3 MB/s (0.3%)
memcpy: 2876.7 MB/s 
memset: 4902.2 MB/s (0.5%)

Cpuminer total scores (5 minutes execution): 6.77,6.76,6.73,6.66,6.63,6.60,6.59,6.57,6.56,6.55,6.53,6.52,6.51,6.50,6.49,6.48,6.47,6.46,6.45,6.44,6.43,6.42,6.41 kH/s

7-zip total scores (3 consecutive runs): 5444,5300,5265

OpenSSL results (big.LITTLE cores measured individually):
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     177074.76k   473539.43k   791910.23k   984429.57k  1059487.74k
aes-128-cbc     363947.66k   785832.70k  1179533.91k  1285858.65k  1345047.21k
aes-192-cbc     165413.53k   407764.10k   632680.28k   752687.45k   796715.69k
aes-192-cbc     389359.64k   802071.27k  1059886.51k  1140258.82k  1188118.53k
aes-256-cbc     158442.61k   367502.10k   541234.60k   626816.68k   657066.67k
aes-256-cbc     434718.62k   765007.34k   944500.74k   992573.78k  1020420.10k

Full results uploaded to http://ix.io/1nUC. Please check the log for anomalies (e.g. swapping
or throttling happenend) and otherwise share this URL.

 

  • Throttling happened with demanding loads as expected (I'll look into this later in detail. Just as a related information: there's a 3 pin power header for a fan on the board)
  • Vamrs is using the conservative 1800/1400 MHz settings for the CPU cores
  • Memory performance exactly as ODROID N1 (also DDR3 equipped, little core result, big core result to compare). So memory performance slightly lower as those other RK3399 designs using LPDDR3 and LPDDR4 RAM
  • 7-zip and cpuminer scores are irrelevant since binaries built with GCC 5.4 (the provided image is a Xenial)

 

Since I'm running off the provided 8GB SanDisk eMMC module I quickly measured the performance (amazingly fast for an 8 GB module):

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    22385    24709    43605    45137    20742    25053
          102400      16    40426    40611   115123   116118    65446    40031
          102400     512    40390    40806   260663   263373   244410    41262
          102400    1024    40824    41244   276769   281198   267166    41219
          102400   16384    41095    41109   276685   276525   277313    41240
         1024000   16384

When running the last test with 1000M test size, an interruption occurred since 'filesystem full'. The vendor provided OS image does no automatic rootfs resize. I think it's time to stop now, create a ficus.csc config and continue the tests with Armbian...

 

Edit: idle consumption with vendor OS image (12V/4A PSU included): 6.1W

Share this post


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

I think it's time to stop now, create a ficus.csc config and continue the tests with Armbian...

 

Nope, lazy mode won (thanks to parted and resize2fs now using the eMMC's full capacity, then did do-release-upgrade to upgrade Vamrs' Xenial image to 18.04 LTS, then quickly checked partition 5 whether latest DT changes are present -- they are).  Then I took two SATA SSDs and one NVMe SSD (in Pine's PCIe to M.2 adapter), threw everything in a corner, connected the stuff and fired it up again:

 

Ficus_4.jpg

 

The huge fan is there to generate sbc-bench numbers now almost without throttling. Numbers here: http://ix.io/1nVS -- performance (not so) surprisingly identical to all other RK3399 thingies around but DDR3 memory results in slightly lower memory performance (negligible with almost every use case) and of course those RK3399 boards where we allowed 2000/1500 MHz so far show ~5% better CPU performance. The better cpuminer scores compared to RockPro64 with same 4.4. kernel here are just due to testing with Bionic on Ficus (GCC 7.3) vs. Debian Stretch there (GCC 6.3 -- with some tasks simply updating GCC you end up with whopping performance improvements for free)

 

Not able to test the PCIe SSD since 'rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!' (full dmesg output). I guess there's still some work needed to get DT bits correctly for PCIe? Ok, let's forget about PCIe now (there won't be anything new anyway since PCIe lives inside RK3399 so as long as trace routing on the PCB is ok this RK3399 will perform 100% identical to every other RK3399 thingy out there)

 

Now let's check USB situation. I'm a bit excited to have a look at the USB3 SATA implementation here since on the PCB itself there's a JMS561 controller (USB3-to-SATA bridge with support for 2 SATA ports, providing some silly RAID functionality but also PM mode. PM --> port multiplier). The two SSDs when connected with the JMS561 in PM mode appear as one device on the USB bus:

root@rock960:~# lsusb
Bus 004 Device 003: ID 1058:0a10 Western Digital Technologies, Inc. 
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 003: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
Bus 005 Device 002: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@rock960:~# lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/7p, 480M
        |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
        |__ Port 2: Dev 3, If 1, Class=Vendor Specific Class, Driver=ftdi_sio, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
  • The JMS561 appears as '1058:0a10 Western Digital Technologies, Inc' device which is an indication that the chip runs with WD branded firmware (I'm not that excited). This chipset can be found in a lot of dual drive external USB3 thingies from various drive manufacturers but I thought we would see it here running with original JMicron firmware
  • There's a Genesys Logic USB3 hub on the board connected to RK3399's USB3 host port (the hub appears twice, once with product ID 0616 -- that's SuperSpeed most people call USB3 -- and once with ID 0610 -- that's Hi-Speed or incorrectly called 'USB2')
  • The JMS561 is behind the internal hub :(
  • We also have a 7-port Terminus Technology USB2 hub on the PCB
  • One FTDI UART adapter is internally connected to this hub (no idea what's that for -- maybe access to the 'MCU' that can be added to the board?)
  • I then used a 4th SSD in a VIA VL716 enclosure (USB-C) connected to the USB-C port just to end up with the same symptoms I already ran into when testing with USB-C on NanoPC-T4 and RockPro64 a while ago. Tons of error messages in the logs (updated dmesg). In the kernel messages the question 'Maybe the USB cable is bad?' appears and I would believe the kernel is right (I have 2 USB-C cables, the good one from Apple somewhere where I don't find it, the el cheapo providing those messages. I need to buy another one)

The good news: there is SuperSpeed (USB3) on the USB-C connector and it's not behind the internal USB3 hub (BTW: Schematics for the board are here: https://dl.vamrs.com/products/ficus/docs/hw/). The bad news: all USB receptacles are behind one of the two internal USB hubs.

 

So let's focus now on the 2 SATA ports provided by the JMS561.

 

1) Samsung EVO840 connected to one of the SATA ports. Testing methodology exactly identical as outlined here: https://forum.armbian.com/topic/8097-nanopi-m4-performance-and-consumption-review/?do=findComment&comment=61783. Only some minor slowdowns compared to NanoPi M4 (there the JMS567 USB-to-SATA bridge also being behind an internal USB3 hub). In other words: When HDDs are attached this is just fine since then the HDD is the bottleneck but neither the JMS561 nor the USB3 connection:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4    23192    26619    20636    20727    20633    26177
          102400      16    79214    89381    78784    79102    78889    88974
          102400     512   292661   295840   271486   277983   277481   300712
          102400    1024   321196   322169   305092   312765   312185   329470
          102400   16384   356091   356179   350200   360167   359817   357583
         2048000   16384   371761   374096   361612   361590   361724   374401

 

2) Another Samsung added to 2nd 'SATA' port (now 2 disks connected to the JMS561). Running two independent iozone tests with 2GB test size at the same time. As expected we now run into 'shared bandwidth' and bus contention issues since both SSD are connected to the same JMS561 that is bottlenecked by the upstream connection to the SoC (one single SuperSpeed line that has to go through the USB3 hub). If we would talk about HDD the below numbers are still excellent since HDD are still the bottleneck with such a '2 disk' setup.

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
PM851    2048000   16384   131096   132075   161149   162122   161282   131273
EVO840   2048000   16384   151916   157295   176928   183874   186000   178285

3) Now adding another Samsung SSD in an JMS567 enclosure to one of the USB3 receptacles (also behind the hub). As expected 'shared bandwidth' and bus contention issues matter even more now with 3 parallel iozone benchmarks running on each SSD in parallel. But the newly added Samsung EVO750 in an external enclosure finished way earlier:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
PM851    2048000   16384   112897   130875   125697   171855   175661   134626
EVO840   2048000   16384   113541   132846   127664   172124   174311   137836
EVO750   2048000   16384   214842   164890   328764   326065   197740   154398

TL;DR: The 2 available SATA ports provided by a JMS561 in PM fashion are totally sufficient when you want to attach one or two HDDs. In case you need highest random IO or sequential IO performance exceeding the USB3 limit (with this 'behind a hub' topology this means ~365 MB/s) then your only choice is the PCIe slot once it works (either by using a PCIe based SSD there or a SATA or even SAS adapter)

 

Share this post


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

you have a nice parquet floor!

 

That's how craftsmen did it 120 years ago! :) All I did was removing ugly carpets decades ago ;)

 

2 hours ago, Superkoning said:

it looks like a nice board

 

Let's wait until pricing is confirmed.

 

This is definitely a server board which rises a couple of questions:

  • Enclosure? Especially if someone wants to use the PCIe slot (looking at this from above makes absolutely no sense at all)
  • Heat Dissipation? The huge PCB acts as a passive heatsink but what about demanding workloads? We all know that a fan alone is a joke compared to a good heatsink (then combined with just a little airflow)
  • What about the MCU stuff and the M.2 and mPCIe slots at the bottom?

Share this post


Link to post
Share on other sites

Another look at the 2 SATA ports provided by the JMS561.

 

The same IC is inside Hardkernel's Cloudshell 2 thingy where users face serious SMART related issues. So let's do a quick check with an SSD connected to each SATA port:

root@rock960:~# for i in a b ; do smartctl -d sat -x /dev/sd${i}; smartctl -l devstat /dev/sd${i} -d sat,12; echo -e "\n\n\n\n\n" ; done | curl -F 'f:1=<-' ix.io
http://ix.io/1o0p
root@rock960:~# dmesg | tail -n5
[   10.090856] rk_gmac-dwmac fe300000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   89.067105] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
[   89.067959] xhci-hcd xhci-hcd.7.auto: @000000007bc32a30 00000000 00000000 1b000000 03078001
[   89.162393] xhci-hcd xhci-hcd.7.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring
[   89.163274] xhci-hcd xhci-hcd.7.auto: @000000007bc32ac0 00000000 00000000 1b000000 03078001

As http://ix.io/1o0p clearly shows the issue is still there. For the disk connected to the 'SATA1' port only bogus SMART data is returned. Shutting down the board, exchanging SATA cables so that now the EVO840 is connected to 'SATA1' and again: SMART readouts broken for the disk connected to this port: http://ix.io/1o0t

 

I then wanted to create a btrfs mirror to test the same with drives busy but to my surprise Vamrs' kernel has no btrfs support enabled. Then tried an mdraid-1 (which I personally consider the most stupid disk setup ever but hey, it's only about a load test) but also no mdraid support in this kernel :(

 

Ok, then continuing with individual ext4 filesystems on each SSD, running iozone -e -I -a -s 20000M -r 16384k -i 0 -i 1 -i 2 on each SSD and then again doing the smartctl queries.  No USB bus resets, performance also not affected but of course still bogus SMART readouts for one SSD and the above xhci error messages in the log.

 

So both SATA ports still are fine from a performance point of view when combined with HDDs (since all HDDs are that slow that they are the bottleneck and not the JMS561 provided SATA port) but unfortunately there are functional limitations wrt the disk connected to the 'SATA1' port (no SMART health queries, you can start SMART selftests but since SMART status can not be queried no way to get selftest results without exchanging disks/cables).

 

That being said Ficus with just one HDD connected to the 'SATA2' port is a great combination. I hope Vamrs looks into this, gets in touch with JMicron and checks whether this can be resolved with a firmware update.

Share this post


Link to post
Share on other sites

Nice to see a low cost ARM SBC with BMC, pretty amazing. If the BMC will be reviewed working, i'll get one. Also, the I/O ability on this board seems fantastic!

Seems $149 for the 4GB version.

Share this post


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

Nice to see a low cost ARM SBC with BMC, pretty amazing. If the BMC will be reviewed working, i'll get one. Also, the I/O ability on this board seems fantastic!

Seems $149 for the 4GB version.

Don't get too excited about the BMC, the board itself do not have one, you need their daughter board on the M2 slot to act as an out of band management controller (no idea how much that would cost), the 4G modem is routed to the M2 daughter board. So if you spent the money you could have out of band management over cellular network.

 

Source: https://www.youtube.com/watch?v=2UYcmhbKyP4 around the 7min mark.

Share this post


Link to post
Share on other sites
18 hours ago, codnoscope said:

Don't get too excited about the BMC, the board itself do not have one, you need their daughter board on the M2 slot to act as an out of band management controller

 

That's how Tom described it half a year ago. Hopefully we get some more details soon. But all this 'BMC' seems to provide is serial console access and remote power cycling (something I use dirt cheap SBC with USB hubs and USB-UART adapters for combined with my two USB controlled EnerGenie power outlets). Standard in x86 world in the meantime is full graphical console through BMC (usually using an ASpeed controller that appears as a PCIe GPU to the host).

 

I'm a believer into 'use case first' and have still a hard time finding such a use case for this board. If the pricing back from April is still valid the board with just 1 GB RAM might be available for $99. An RK3399 thingy also with just 1 GB DRAM (though single channel config so lower memory bandwidth) might be available soon for less than 60 bucks (NanoPi NEO4). So why choosing the Ficus then?

  • Compatible to 96boards Mezzanines? Nope, I don't need any of them (the PoE thingy looked interesting until I found out that here Gigabit Ethernet is attached via USB2 and they use the same crappy chip as on the new RPi 3 B+ which is a total fail for more than one reason)
  • 2 SATA ports? Well, performance of the JMS561 implementation is ok for HDDs but there's the SMART issue (and for me as a storage professional disks that can't be monitored can not be used). And then 2 disks need powering (probably solved here since there's DC-DC circuitry on the board and 2 SATA power ports with both 5V and 12V. But this setup with 2 x 3.5" HDD and just a 12V/4A PSU might be asking for troubles due to HDD spin-up peak consumption requirements). And 2 disks also need housing. So where's an enclosure appropriate to fit the board and 2 disks (either 2.5" or 3.5")?
  • But there's a full size PCIe slot? Sure but if my use case requires PCIe then there's a way cheaper RK3399 alternative (RockPro64) and honestly the board layout sucks (96board EE specs). Any PCIe card when inserted into this slot protrudes 25mm over the board. And with a PCIe card I also want something like an enclosure to fixate the card and protect the whole setup. But with the weird PCIe slot placement and the proprietary form factor there aren't inexpensive enclosures available. This 96boards EE form factor is both too huge and too small at the same time. I think Mini ITX would've been a better idea

 

Share this post


Link to post
Share on other sites

Almost forgot: in case someone wants to add this device to Armbian as CSC (community supported config -- for official support a 'Board Bring-Up' thread/discussion is needed). I would believe starting with a ficus.csc like this would be a good idea:

# RK3399 hexa core 1-4GB GBE eMMC USB3 USB-C WiFi PCIe
BOARD_NAME="Ficus"
BOARDFAMILY="rk3399"
BOOTCONFIG="nanopi4_defconfig"
#
MODULES=""
MODULES_NEXT=""
#
KERNEL_TARGET="default,dev"
CLI_TARGET="stretch:default"
DESKTOP_TARGET="bionic:default"

CLI_BETA_TARGET=""
DESKTOP_BETA_TARGET=""

Then adding the 4.4 DT as u-boot and default kernel patch, the mainline DT as dev kernel patch and loading the specific DT similar to how we do it already. Open question: how to deal with rk3399_loader_v1.12.112.bin?

Share this post


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

But there's a full size PCIe slot? Sure but if my use case requires PCIe then there's a way cheaper RK3399 alternative (RockPro64) and honestly the board layout sucks (96board EE specs). Any PCIe card when inserted into this slot protrudes 25mm over the board. And with a PCIe card I also want something like an enclosure to fixate the card and protect the whole setup. But with the weird PCIe slot placement and the proprietary form factor there aren't inexpensive enclosures available. This 96boards EE form factor is both too huge and too small at the same time. I think Mini ITX would've been a better idea

 

Agree completely, EE board form factor should be compatible with Mini ITX. 96board have some very "creative" board layouts, the hikey960 for example, its NVMe slot is orientated outward, more than doubling the board footprint with SSD installed. :wacko:

Share this post


Link to post
Share on other sites
14 minutes ago, codnoscope said:

hikey960 for example, its NVMe slot is orientated outward

 

Isn't it the same with the normal Rock960? To me personally not a single 96boards specs compliant device looked appealing (unfortunately Ficus included). But it's the 'standard' itself that's the problem. Form factor, placement of connectors, interfaces exposed.

 

The PCIe connector placement on EE boards is simply moronic. But maybe I understood the whole 96boards approach wrong and this was never meant for end users but just for Android developers?

Share this post


Link to post
Share on other sites

Hi, this is Tom from Vamrs, I reply some of the questions you might want to know about Ficus board.

Quote

 

- what about PCIe situation? Did you test successfully 

 

PCIE x16 is working, we've tested PCIE to M.2 adapter with M.2 SSD and PCIE to dual SATA card, both works fine.

 

Quote

 

- Do you plan an enclosure? By looking at the position of the PCIe slot some very custom enclosure is needed since PCIe cards are protruding ~25mm over

 

Well, this is the not so good part I have complained to the author of 96boards Spec. Since the 96boards never considered the enclosure. I have also considered to change to PCIEx4 and indent ~25mm to fit the enclosure, I also suggested to change 96boards ee spec and add this option,  but it was not approved...

 

Quote

 

- no heatsink mounting holes. Why?

 

We think a small heatsink with glue is enough for the big board.

 

Quote

 

- Pricing of board and add-ons (like BMC)?

 

For the BMC, it must have the following feature:

* it has ethernet

* it has usb host, can port/run the rockchip firmware upgrade tool

* it has web interface development environment

* it must be stable and robust, and always boots

 

It doesn't leave us much choices so we choose the wifi router chip with openwrt for quick development with features we want, ie remote management and remote firmware upgrade. The current design is based on the module Wrtnode 2P.  It's around 10 to 14usd for retail.  

 

 

Btw, we need developers working on OpenWRT on WRTnode 2P, takes as below:

1. port rkdeveloptool on OpenWRT

2. test and verify the rk3399 power control, maskrom mode

3. simplify the web interface, remove all the router things

4. implement remote firmware upgrading function, basically download the firmware, make rk3399 in maskrom mode and run rkdeveloptool

5. optional get 4G module working(uart interface)

 

We are really lack of hands. If anyone is interested in tasks above, we are happy to send a set of kits to develop.

 

 

Share this post


Link to post
Share on other sites
On 9/30/2018 at 6:17 PM, tkaiser said:

That's how craftsmen did it 120 years ago! :) All I did was removing ugly carpets decades ago ;)

 

I did that in my home not long ago, I refinished the floor myself, quite pleased with the results.  :)

 

This board looks really cool, but for the life of me I don't want wires going every direction, I very much appreciate things having a front and a back when it comes to connectors.  A USB or 2 on the "front" is fine, but I'm trying to visualize actually using both ethernet ports without it looking like bad techno-spaghetti...  :lol:

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