tkaiser
-
Posts
5455 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
On 12/12/2018 at 2:04 PM, kcn said:
I manualy uploaded some armbianmonitor logs: https://pastebin.com/VGrMddE5
### 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:uSmells like filesystem corruption. If the contents of /boot/armbianEnv.txt really look like this garbage you should immediately check installation integrity using armbianmonitor -v.
-
41 minutes ago, Igor said:
didn't have many choices
What should change as long as you keep 'Armbian' your personal project?
-
2 hours ago, Igor said:
moving to another server on the way
Great way to communicate project details. I guess this (keeping this whole thing your private pet) is key to success.
-
29 minutes ago, Tido said:
@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.
-
On 9/29/2018 at 5:48 AM, Jason Law said:
On a different note regarding the heat sink, are you better off with a fan blowing from the top down? Or from the side for heat dissipation?
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)
1 hour ago, Teal said:If it would be a Marvell based 4-port SATA - and omv compatible like this one for example
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)
-
10 hours ago, sfx2000 said:
Interesting numbers
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).
10 hours ago, sfx2000 said:RK3288 can do the limbo as low as 126MHz - right now with Armbian we're capped at the bottom at 600MHz
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
-
3 hours ago, TonyMac32 said:
unless the RTL8153 is unbelievably power hungry
When I did some tests with the RTL8153 on ODROID HC1 the consumption increase caused by the chip alone was always below 1W.
-
5 hours ago, sfx2000 said:
why mount the zram partion as ext4-journaled
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
-
4 minutes ago, chwe said:
maybe we should add 'dumb mode' to known issues for those boards?
Sure, feel free to create an 'USB-C powered boards -- important information' thread or something like that.
5 minutes ago, chwe said:3 hours ago, tkaiser said:You're talking about some Apple smartphones and tablets still using their Lightning connector and not USB-C?
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.
-
13 minutes ago, esbeeb said:
Maybe you already backport the 4.15 Ethernet-related code (for the H5) into that 4.14.y kernel?
Count the patches and search for NEO2 there: https://github.com/armbian/build/tree/master/patch/kernel/sunxi-next
-
8 hours ago, sfx2000 said:
just wait for USB-C connectors on SBC's
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.
8 hours ago, sfx2000 said:(perhaps the reason why the folks over on Cupertino decided with their recent HW releases to keep their proprietary connection)
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).
-
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?
-
21 minutes ago, RoroTiti said:
Does Armbian needs to be flashed from a SD card, like all other boards
'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.
-
31 minutes ago, RoroTiti said:
I want to know if the M4 with Armbian support eMMC module
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?
-
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
-
-
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 03078001As 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.
-
4 hours ago, sfx2000 said:
Once tests are done, looks like the cores are left on their own and cooking....
'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.
-
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?
-
2 hours ago, malvcr said:
the SWAP will have it on disk
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.
-
9 minutes ago, NicoD said:
Is there a command to display usb voltage in Linux?
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.
-
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 3744012) 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 1782853) 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 154398TL;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)
KSZ9031RNX Ethernet IC
in Advanced users - Development
Posted
Nope. Needs 3.9 or above.