chrisf

You'll find in general lots of SBC's have poor power management. What should be happening is the CPU needs to send the RK808 PMIC the right power off commands before it enters it's halt state. That's probably series of i2c commands and gpio1_a5. If it keeps the power on, it may just be sitting there with the SoC fully powered up, wasting your power. The board vendors don't seem to care much about the problem. If it powers up when you apply power, they think their job is done. In theory there's nothing stopping these systems from entering sleep mode, like your phone or tablet does. They'll last weeks if you set them on airplane mode to disable the wireless and leave them alone. The Raspberry Pi for example, uses almost as much power while "off" as it does then it's idle. The VideoCore CPU in it is fully awake waiting for you to turn it back on with a gpio.

I currently run an Odroid XU4, Odroid HC1 and Rock64 all 24x7. I never have any problems with them. They all run from decent power supplies though, connected to a UPS. The only board I've have stability issues with is an Espressobin. I've also got a Tinkerboard, a couple of Pine64's, Raspberry Pi 2 and 3 and an old Cubietruck. They've all been stable too. Sounds like you need to sort out your power supply problems first.

How about the MCP2515 CAN controller?

It should be possible to use a SPI CAN module, as long as you can get the SPI interface enabled and the kernel driver loaded. I imagine you'll need to do something with the device tree to enable it. I don't know if the default kernel has the mcp2515 driver built in though. You may need to compile your own kernel module or kernel. Edit: I see Igor has already posted how to enable SPI

I had kernel panic issues with my Espressobin, when it was functional. It worked best with the 1200/750 firmware. It's probably something to do with memory timing/board layout.

Most SBC's don't have proper power management. As an example of the Raspberry Pi, when you do a software shutdown, the main VideoCore processor is still running, waiting for you to wake it back up with the GPIO pin. When you first apply power, it's not in that state. There is no non-volatile memory to remember the previous state. Power consumption in the soft-off state isn't much lower than idle. In PC's this is stored in the BIOS's battery backed SRAM. The motherboards controller chip (usually some kind of microcontroller, Apple call theirs the "SMC") is what manages the power for the whole system. monitoring the power button, enabling and disabling power rails and resetting the CPU. SBC's don't tend to have that. They just have a PMIC chip and the SoC.

No, but I would start by comparing the DVFS config between the two images. Also the cpufreq governor being used.

I've used it with the original tinkerboard. I just plugged it in to the DSI connector and it worked straight away.

@Jbobspants I think the switch ports are dependent on the eth0 port being up first, maybe it has something to do with timing/ordering?

Why are you trying to bond two ports? There is only a 1Gb link between the switch and the SoC, you're not going to get any more bandwidth

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

The system is fine, cpuinfo shows 4 cores of 0xc0f and 4 of 0xc07 0xc07 is a Cortex-A7 and 0xc0f is a Cortex-A15 What version of htop is it?

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.

If you have a proper crimping tool for the pin, crimping alone is better than soldering or crimping and soldering. The solder wicks up the stranded wire and creates a point where all the flexing will happen, resulting in easily broken connections.

Have you tried looking at /proc/interrupts to see which cores are actually handling the interrupts?

To me that load log says one core is maxed out due to IRQ activity. You've got a single core doing all the network stuff and it can't handle any more load. Do you need IP masquerading? Is it possible to distribute network IRQ handling to both cores? If you can that may increase bandwidth, but may also slightly increase latency?

You could mount a different volume at the place those directories are. Might even work with a symlink

It's my understanding that Allwinner GPIO's have configurable output drive levels. They're configured with the Px_DRVx_REG registers. There are 4 levels, from Level 0 to Level 3. The default is Level 1. I don't know what current corresponds to each level, it used to be 10mA, 20mA, 30mA and 40mA with the A20's. Level 1 is 20mA, which as the default for the register, matches the data sheet maximum drive strength. Personally, I'd put my own buffer on a GPIO if it's driving more than a few mA.

The GPU's in these SoC's can usually do h264. Older ones can't do hardware acceleration for h265. It requires kernel driver support for the GPU that's built in. This usually gets done for Android kernels, so phones and tablets have good performance. No one is paying to have this done in the mainline Linux kernel, it's left up to volunteers. The Exynos 5422 in the XU4 has hardware for encoding and decoding h.264 video. The C2's soc, the Amlogic S905 has hardware for h264 and h265. Hardkernel advertises that too, so you'd probably have better luck getting it working. You might need to use their kernel to get something working "out the box".

A benefit of the x86 based ones would be hardware video decoding driver support. The XU4 does have h264 hardware decoding support. The problem is getting it working in Chrome for YouTube. Apparently it worked with the Flash plugin, but it requires effort to enable to HTML5 video.

It's still on jessie. I've had no reason to change anything. Jessie is still a supported version. In terms of "go into production", it's an SBC in my garage...

The risk of fire for unprotected cells is tall of you over charge them. They catch on fire when there is an internal short circuit. Over charging is one way to break down the insulation inside.

You kind of have to trust your ISP, all your internet traffic goes through them, regardless of the router. If you don't use its built-in switch and simply connect the ISP router to another switch, it doesn't have the ability to see any local traffic, other than what the switch directs to it. Even if you do use its built in switch, not all routers have the capability to sniff other traffic. It depends on what chip they use for the switch.

If I were you I'd measure the battery with a multimeter. If it really is above 4.2v it is a fire risk. If the board has calibration issues, that's not so bad.

I have unifi running on an hc1 and I dont recall any issues. When I get home I'll see if I have time to post how I did it. This is the apt source I used # cat 100-ubnt-unifi.list deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti The only other sources I have is armbian Edit: my mongodb-server package is from debian # apt-cache showpkg mongodb-server Package: mongodb-server Versions: 1:2.4.10-5+deb8u1 (/var/lib/apt/lists/httpredir.debian.org_debian_dists_jessie_main_binary-armhf_Packages)