tkaiser Posted September 29, 2018 Posted September 29, 2018 Latest RK3399 arrival in the lab. For now just some q&d photographs: @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 4
wtarreau Posted September 29, 2018 Posted September 29, 2018 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.
hjc Posted September 30, 2018 Posted September 30, 2018 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).
tkaiser Posted September 30, 2018 Author Posted September 30, 2018 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
tkaiser Posted September 30, 2018 Author Posted September 30, 2018 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: 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) 1
Superkoning Posted September 30, 2018 Posted September 30, 2018 Hey tkaiser ... you have a nice parquet floor! And thanks for the review ... it looks like a nice board.
tkaiser Posted September 30, 2018 Author Posted September 30, 2018 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?
tkaiser Posted October 1, 2018 Author Posted October 1, 2018 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. 1
fossxplorer Posted October 1, 2018 Posted October 1, 2018 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.
codnoscope Posted October 1, 2018 Posted October 1, 2018 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.
tkaiser Posted October 1, 2018 Author Posted October 1, 2018 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
tkaiser Posted October 1, 2018 Author Posted October 1, 2018 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?
codnoscope Posted October 1, 2018 Posted October 1, 2018 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.
tkaiser Posted October 1, 2018 Author Posted October 1, 2018 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?
hipboi Posted October 8, 2018 Posted October 8, 2018 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.
TonyMac32 Posted October 8, 2018 Posted October 8, 2018 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...
Recommended Posts