tkaiser

Of course. You need to fix this otherwise everything you do is just a waste of time. And it's under-VOLTAGE and not under-current so as long as you ignore Ohm's law you're getting nowhere. The problem is high resistance and most probably (and as usual) the cable between PSU and device is to blame.

Nope. Needs 3.9 or above.

### boot environment: # $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PAT usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x2323:u Smells like filesystem corruption. If the contents of /boot/armbianEnv.txt really look like this garbage you should immediately check installation integrity using armbianmonitor -v.

What should change as long as you keep 'Armbian' your personal project?

Great way to communicate project details. I guess this (keeping this whole thing your private pet) is key to success.

@Igor certificate for www.armbian.com expired. @Tido good luck with this sort of poll (no idea why contents of the 'board details' page is now part of download page -- but you might start similar polls for two other totally uninteresting boards: ODROID-C2 and C1)

If you don't provide information what's utilizing the CPU how should anyone here help you or at least get an idea what's going on? Check and provide 'htop' and 'armbianmonitor -u' output.

Depends. Though in all my tests blowing air laterally performed best (see here or here). With NanoPi M4 just some airflow through the heatsink fins is already sufficient (tested it behind a server PSU's 'hot air' outlet). But of course you can easily conduct your own tests. Simply use sbc-bench's thermal testing mode and if you want to adjust your fan setup interactively then use the installed cpuminer application in /usr/local/src/ (but please keep in mind that with the huge thermal mass of NanoPi M4's heatsink it's very easy too fool yourself and that's why I would always recommend a combined sbc-bench -t/-T test run) I recommended the 88SE9235 for a reason and @mindee said they would use this chip. I hope you're aware that there exist RK3399 boards with full PCIe slots already? PCIe functionality is only a kernel thing (drivers and device-tree settings) and a board design issue (PCB trace lengths/routing and signal quality)

100% meaningless numbers now since they do not provide any insights any more (you can not differentiate what's throttling and what's -- potentially inappropriate -- cpufreq scaling behavior). For two simple reasons: allowing very low cpufreq OPP trashes performance (on your Tinkerboard it's storage performance due to the clockspeeds not increasing fast enough) the way DVFS works at the lower end of the scale the differences in consumption and generated heat are negligible between silly ultra low MHz values and a reasonable lower limit (we in Armbian TEST for stuff like this with every new SoC family!) Closed your issue right now spending additional time to explain: https://github.com/ThomasKaiser/sbc-bench/issues/4

When I did some tests with the RTL8153 on ODROID HC1 the consumption increase caused by the chip alone was always below 1W.

Read the script and don't just skim through. This script (initially written by Igor and not me -- there's also a commit history which helps you understand what stuff is dealt with here) sets up things that need to work on any of the kernels Armbian supports (we're not just dealing with the few devices you seem to use) and does a couple of different stuff. Of course we're not using filesystems for swap and you might even look into the Changelog to understand why mkfs.ext4 is used there.. @Igor certificate for docs.armbian.com has expired

Sure, feel free to create an 'USB-C powered boards -- important information' thread or something like that. If those cables were not 30$ and the cheap fakes destroyed the phone.  How is that different with USB-C? See https://www.makeuseof.com/tag/best-usb-c-chargers-whats-safe-whats-dangerous/ or https://www.theverge.com/2016/2/4/10916264/usb-c-russian-roulette-power-cords for example.

Count the patches and search for NEO2 there: https://github.com/armbian/build/tree/master/patch/kernel/sunxi-next

They're there already: Firefly RK3399, Vim, Vim2, RockPro64, NanoPC-T4, NanoPi M4, Ficus, Renegade Elite and soon also NanoPi NEO4, Khadas Edge and Edge-V are equipped with USB-C. Some of these boards use USB-C as power input. Here we need to differentiate between 'dumb mode' and 'USB PD compliant' (USB PD --> USB Power delivery specs): With the boards that use just an USB-C receptacle to be fed with 5V (Vim, Vim2, NanoPi M4, NanoPi NEO4) problems are to be expected since real USB-C chargers won't provide enough current (here me citing the specs) and dumb 5V PSUs combined with high currents result in the usual voltage drop With boards that implement USB-C powering also being USB PD compliant you need an extremely expensive USB-C charger So as long as there are not real USB-C chargers lying around in every household and all SBC are USB PD compliant USB-C for powering SBC is simply either a mess or an expensive adventure. You're talking about some Apple smartphones and tablets still using their Lightning connector and not USB-C? Most probably related to the count of peripherals that already use Lightning (Docking Stations and stuff like that). Apple was the company pushing hard for USB market adoption 20 years ago (giving up on their own proprietary ADB bus standard which resulted in a lot of users like me having to buy adapters for expensive ADB peripherals like graphics tablets and such stuff) and they also sent truckloads of engineers to USB Implementers Forum years ago when USB-C and USB PD were defined. Most probably to prevent USB-IF ever doing something silly as Micro USB again (so that they had to invent something own as Lightning since Micro USB already sucked back then).

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?

'Like all the other boards' is not true since Allwinner boards for example can be flashed using FEL mode (directly accessing the board's eMMC as USB storage). If you have an eMMC to SD card adapter you can burn an Armbian image directly to eMMC, if not it's just calling nand-sata-install and you're done.

Sure. Just read the review.

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?

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

Check 'SMB_Options' here https://github.com/armbian/build/blob/master/config/templates/customize-image.sh.template

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.

'Cooking'? The 'performance' cpufreq governor is chosen, that's all. On an otherwise idle system there's not much consumption and temperature difference between idling at lowest or highest cpufreq OPP anyway.

That's how craftsmen did it 120 years ago! All I did was removing ugly carpets decades ago 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?

Sorry, you lost me here. I'm not talking about stupid things like swapping to disk but ZRAM! Too much time wasted dealing with all this madness already. I need a break.

No. You need circuitry to measure this in the first place (only some old and boring Allwinner A20 devices provide this and the infamous Raspberry Pi has some circuitry to detect when input voltage drops below 4.63V +/- 10%)), then a driver interpreting the ADC data appropriately. If those two prerequisits are met the tool of choice to display this as a voltage value is close to irrelevant. But that's not the problem. The hardware is simply missing on majority of boards.