chrisf

Don't worry, Google is only a gold member of the Linux Foundation.
Microsoft is a Platinum member...

You have to make a choice with the shared SERDES lanes.
Espressobin has already made that for you with it's PCB layout - one lane goes to SATA, one to USB3 and one to PCIe.
There is only one lane on the PCIe slot, which is also apparently limited to 2.5Gb in early boards due issues running at PCI 2 speeds.
The switch is connected via a 1Gb link to the 3270.
 
Your physical limitations will be 2.5* or 5Gb on the PCIe slot and 3Gb on the SATA 2 connection. The 3Gb link uses 8b/10b encoding, so it's limited to 300MB/s.
 
 
* OpenWRT has reduce PCIe speed to 1.0 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=772258044b48036699302840abf96cd34c4e5078
 

Isn't a pi-hole just a DNS server? You don't need multiple interfaces for that, nor do you need gigabit speeds to serve a local network.
All you'd need to do would be update the DHCP settings in your router to set the DNS server to that of the pi-hole. 
 

Have you got a tool to check the latency to compare USB2 and USB3? Or CPU usage when doing the same workload?
My understanding of the difference between USB2 and 3 is USB2 is polled, while USB3 is interrupt driven.
 
Assuming you haven't done something wrong and your numbers are an accurate representation, maybe at the hardware level USB3 requires more resources, all the interrupts could be causing excessive context switching. Or the drivers aren't as optimised yet.
would be interesting to compare between different hardware USB3 implementations.

You've bunged up the link somehow, there's a unicode byte order marker between i and / in cjbassi/gotop
If you copy/paste into a url bar you'll get a 404 and scratch your head because it looks identical to a url with %EF%BB%BF in it
 

5V with a 1R load is 5A, 25W
5V with a 0.5R loan is 10A and 50W
 
For a 2A load on 5.1V, the calculation is 5.1/2 = 2.55 ohms

I can only assume the load is not enough to keep ondemand at a high enough frequency, so it keeps scaling up and down. Maybe the CPU needs to wait between interrupts and that's causing the scaling. Maybe the process that's doing the work is low priority.
While the frequency changes, the CPU can do no work. You lose tens of microseconds each time it happens.
You might be able to keep using ondemand if you tweak its settings, but if performance fixes your problems and works well, probably no need to change it.

I had a quick look over the diff for 4.16-rc1 and it looks like there's progress on support for DVFS too

Looks like that module has a UART (serial) interface, not I2C
 
The aliexpress page doesn't say anything about how it communicates over the serial connection.
 
There's a forum thread here about it: https://forum.arduino.cc/index.php?topic=359707.0

Apparently yes
 
Not sure if it's a matter of a simple PCIe cable or not (it implies that's the case for "local networking" between two PC's, a PCIe switch for a network of more than two) but if you scroll down just past half way here, it mentions it
https://www.onestopsystems.com/blog-post/pcie-over-cable-goes-mainstream
 
The PCI Express bus has direct access to system memory, I don't see why either side of the point-to-point connection can't be the initiator.

Just connect your 5V to pins 2 and 4 and ground to pin 6 of the GPIO header.
 
This goes straight to the power input of the RK808. It bypasses the input over voltage protection and current limit. Make sure you don't put in more than 5.5V
 
Edit: Further reading of the schematic (providing it's accurate) shows you should be able to power it directly from a single lipo battery. Obviously this won't put 5V out to any USB devices you connect though.

I haven't had any problems with my XU4 (or HC1)
 
Tinkerboard has micro-usb power input, which would give stability issues.  Powering via GPIO headers bypasses its power input protections.

I found all the firmware with 800mhz ram speed is dodgy. It must be a marginal board layout issue of the ram won't run stable at its rated speed.
 
We just have to put up with lower memory bandwidth on a board that already wasn't all that fast (single channel 16 bit memory interface).
Isn't it similar to the first ever DDR PC's 15 years ago? They had 64 bit bus width, 200mhz.

Completely wrong it turns out.
Turns out the RK805 PMIC needs the voltage increased in 12.5mV steps and the frequency needs to be specific values too, they're defined in drivers/clk/rockchip/clk-rk3328.c.
They're defined up to 1.8GHz, but I didn't get any above 1.488 to work, cpufreq wouldn't load them.
It does run stable at 1.488GHz though, if you increase the voltage. I'm using 1.4375V, haven't tested any lower.
Done testing stability: Frequency: 1392000 Voltage: 1350000 Success: 1 Result: 0.0048034 Frequency: 1416000 Voltage: 1375000 Success: 1 Result: 0.0048034 Frequency: 1488000 Voltage: 1437500 Success: 1 Result: 0.0048034 I had to edit the script for min, max and cooldown freq as well as the Vcore regulator
Peaks around 78 degrees, with idle @408MHz 40 to 45C
 
minerd --benchmark reports 4.61khash/s (or 4.58 while armbianmonitor -M is running)
after a few minutes it's sitting around 79C

I've compared the kernel config for mainline and Marvell's 4.4 and one thing that stands out in regards to the SD card issue is:
CONFIG_MMC_SDHCI_XENON
In the linux-mvebu64-default.config it is set to y, in linux-mvebu64-next.config is it not set
 
That could explain why it works to @umiddelb, his defconfig has it enabled too. I'll try it myself when I get the chance but that could be a few days away.
 
Edit:
I've just tried it on next and it works, just need to update fdt_name env var to point to the correct DTB
# uname -a Linux ebin 4.14.0-mvebu64 #4 SMP PREEMPT Mon Nov 20 08:02:32 UTC 2017 aarch64 GNU/Linux # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 1.4T 0 disk └─sda1 8:1 1 1.4T 0 part mtdblock0 31:0 0 4M 0 disk mmcblk0 179:0 0 29.8G 0 disk └─mmcblk0p1 179:1 0 29.5G 0 part /  

root@raspberrypi:~# modprobe i2c-dev root@raspberrypi:~# modprobe rtc-pcf8563 root@raspberrypi:~# echo pcf8563 0x51 > /sys/class/i2c-adapter/i2c-0/new_device the first command makes sure the i2c-dev driver is loaded
the second command loads the pcf8563 driver
the third one tells the kernel to use the pcf8563 driver for the device with addres 0x51 on i2c-0. You'll want to change i2c-0 to i2c-1 as that's the i2c port with your rtc device.
 
This is from http://www.susa.net/wordpress/2012/06/raspberry-pi-pcf8563-real-time-clock-rtc/

I think it's going to be many years before you can find an SBC with both excellent IO bandwidth and a high performance GPU.
 
You currently get to choose between the two.
 
I guess the reason for this is there are only really three markets for the SoC's:
Android tablets and phones. Needs decent GPU. Nothing more than SD/eMMC is required. TV box. Needs decent GPU, still doesn't need high IO bandwidth. Wifi runs over SDIO, still doesn't need a full 1GBe network connection. NAS/home server boxes. Goesn't needs a GPU at all. Needs decent SATA and NIC. High end soho expect 200MB/s with dual gbe. Mavell have this market pretty much covered. CPU doesn't need to be that great either, if they put in hardware acceleration for network/ssl/etc I'm also not aware of any mPCIe video cards, so you'd need to go down the route of an external PCI-E enclosure. Getting ARM drivers for an AMD or nVidia card would be interesting too. I was under the assumption that if you want proper drivers for these, they come as binary blobs.

I2C is not susceptible to timing issues, it's a two wire protocol with and clock and data line (it's also known as TWI)
I2C could be done over GPIO, but the Tinkerboard (and every other SoC) has hardware to do the I2C communication independent of the CPU. Most PMIC chips are connected to the SoC by an I2C bus. 
I2C is designed for communication between chips on a single board though, not for long wire lengths. A metre shouldn't be too bad though, if you don't try high-speed I2C (keep it at 100kHz, not 400)
You can use multiple i2C devices on a single bus, provided they have different addresses. The Tinkerboard has two I2C buses on its GPIO header, you'll need the right device tree to enable them. You can also buy I2C multiplexers.
 
For temperature sensors on my old Cubieboard I used a DS2482 which is a 1-wire controller with an I2C interface. Made communication a lot more reliable than using the 1wire GPIO driver.
 
Longer distance would be easier with lower pull-up resisters. 4.7K is typical, 2.2K is probably about as low as you can go
 

I2C is not susceptible to timing issues, it's a two wire protocol with and clock and data line (it's also known as TWI)
I2C could be done over GPIO, but the Tinkerboard (and every other SoC) has hardware to do the I2C communication independent of the CPU. Most PMIC chips are connected to the SoC by an I2C bus. 
I2C is designed for communication between chips on a single board though, not for long wire lengths. A metre shouldn't be too bad though, if you don't try high-speed I2C (keep it at 100kHz, not 400)
You can use multiple i2C devices on a single bus, provided they have different addresses. The Tinkerboard has two I2C buses on its GPIO header, you'll need the right device tree to enable them. You can also buy I2C multiplexers.
 
For temperature sensors on my old Cubieboard I used a DS2482 which is a 1-wire controller with an I2C interface. Made communication a lot more reliable than using the 1wire GPIO driver.
 
Longer distance would be easier with lower pull-up resisters. 4.7K is typical, 2.2K is probably about as low as you can go
 

I had another look at DHTXXD and it uses another library called pigpiod, which in turn directly access the GPIO registers, so is probably not worth porting to another SoC.
I would go the route of using different sensors, like the BMP085 or BMP280, which offer a standard I2C interface instead of a proprietary one that requires bit-banging - which is always a bad idea to do on a non-real-time OS.
There is many libraries that work with those sensors and they all use the standard /dev/i2c interfaces. Here's one that supports the Tinkerboard: https://github.com/mattjlewis/diozero

I mean it shouldn't be too hard to add configfs support patches to these kernels, but you will still need to write overlays for each platform from scratch since base DT configuration will be different.

It's in the RK808 datasheet
You can set shutdown to 140c or 170C
You can set hot die to 85, 95, 105 or 115C
 
The RK808 driver can then read the shutdown status or the hot die status
http://rockchip.fr/RK808 datasheet V0.8.pdf

Just connect your 5V to pins 2 and 4 and ground to pin 6 of the GPIO header.
 
This goes straight to the power input of the RK808. It bypasses the input over voltage protection and current limit. Make sure you don't put in more than 5.5V
 
Edit: Further reading of the schematic (providing it's accurate) shows you should be able to power it directly from a single lipo battery. Obviously this won't put 5V out to any USB devices you connect though.

Yes, with kernel 4.4.67, I built it from git two days ago. I could see it throttling fine for a few minutes on rpimonitor
 
Edit: After replacing the heatsink it hasn't shut down. It may have been due to low thermal mass and slow temperature polling frequency. It's still throttling but the temperature is much more stable in the low 70's.
 
Looking back over the rpimonitor stats, with the old heatsink it peaked at 85+ 3 times before the shutdown

I had this problem. I was using an SD card in an SD -> uSD adapter. Worked fine loading the image to the card from my laptop. Worked fine on a pine64 board. Worked fine on a RPi2. Did not work on a Tinkerboard. Bought a new SanDisk Ultra 16Gb and it works fine.