zador.blood.stained

Don't use "dev" branch images because they have broken overlays. Only "next" branch images with kernel 4.14 may work.

We decided to not provide desktop builds for 64bit devices with 512MB RAM so we will not release any prebuilt desktop images for this board. It is still possible to install necessary packages and configure them manually.

There are a lot of ways to improve the current situation if we don't care about maintaining easy upgrades and backwards compatibility. I.e. instead of hardcoded kernel branch names "default", "next" and "dev" and an artificial 3 branch limit we could have more than 3 branches with unique names, i.e. "hardkernel-4.9", "lts-4.14", "mainline", "hardkernel-3.10".

Possibly your CA certificate is malformed or invalid. The file size looks too large for a usual CA certificate. Please try to open it in a text editor and check if it looks like this -----BEGIN CERTIFICATE----- <several lines of characters> -----END CERTIFICATE----- or try to verify it with openssl openssl verify -CAfile /etc/openvpn/client/ca.crt /etc/openvpn/client/ca.crt

And producing a generic ? Pi as a result in some cases

In theory - yes, but keep in mind that the bus bandwidth will be split between 3 devices so you'll get lower FPS and worse touch screen responsiveness than if they were connected to dedicated SPI controllers. You will need to add extra GPIO chip selects using this as an example and add 3 slave SPIdev devices like here.

RK3399? At least from more or less cheap and common ones, obviously things like Armada 8040 can be also exciting but expensive and thus less popular.

I would prefer to freeze the development branch. If there are immediate bugfixes - push them straight to master (except for Bionic compatibility tweaks), for other things create different topic branches. Otherwise we will never sort out the "development" branch mess.

You may want to play with the u-boot environment - particularly with the fdt_high value. Check the README in the u-boot sources for details.

He meant a separate branch in armbian/build. And since I started to sort it we already had commits that touch kernel/u-boot config and patches

I has similar shutdowns with the SoPine module + baseboard. As far as I could tell this was due to undervoltage - the SODIMM socket is not exactly designed for high currents (even when multiple pins are used for powering), and PMIC cut off the power to prevent undervoltage (easy to distinguish from kernel crashes because it also turns off the on-module LED). In my case sometimes it was enough to remove and reinsert the module or use a different power supply.

Just not syncing compressed logs back might help, but we need to test how this behaves with logrotate deleting old compressed logs. This has some rough edges so I would prefer to rework this first (or do tests without this) before pushing this.

Not a surprise. We don't have any supported Bionic builds so there may be issues with beta/testing builds (since they are made only for testing and not for everyday use). They need to be compared to Xenial builds with the same kernel before claiming kernel issues. And I don't see any useful logs (dmesg, armbianmonitor -u / armbianmonitor -U, ifconfig, ethtool -S, route) that could help diagnose the problem (especially since Bionic images are still testing and testing without providing logs won't help us find problems if there are any)

No. If you are using, for example, a H3 based device, a recent enough Armbian image and want to change frequency of the I2C controller 1, you need to install kernel headers, create a file (i.e. "i2c1-change-frequency.dts") /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&i2c1>; __overlay__ { clock-frequency = <200000>; }; }; }; and add it via "armbian-add-overlay" Or for testing purposes just decompile, change and recompile the DT in /boot/dtb using dtc. Since there will be no node labels you'll have to check the original DT for node names, i.e. I2C 1 node would be named "i2c@1c2b000".

You could try using an overlay to add a "clock-frequency" property to the I2C controller node: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt

They are not even. I just merged everything that was merged directly to "master" into "development" so we won't undo changes by doing manual merges. We should merge everything that can be considered tested to master. I started cleaning up things to a new branch, if these changes are OK (since I don't have these devices) they can be merged to "master" and I will do more of this splitting later.

Based on my work yesterday I have to make an additional remark: if "development" can't be rebased on "master" without a significant number of conflicts then we are doing something wrong

This was changed several times in the past, the proper name for arm64 kernel is Image but for backwards compatibility with old boot scripts it is set to zImage. In the "next" branch it is consistent, and "dev" still has the intermediate name and related patches.

Why should we? To you? Maybe. To others? Maybe not. Especially for people who may need to do development and not just use images already made by others. And why should we work on improving that? But why don't you try this also? Since we received more support requests than actual board bring up threads I'm locking the "Board Bring Up" subforum. If somebody posts a proper bring up worthy thread any moderator or developer should be able to move the thread there.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/rk3288.dtsi?id=4e943a890cef42e90f43ce6be64728a290b97c55 We are talking about mainline (next branch), right?

I see a button labeled "Recover" on the picture in the first post, so it is possible that this button can be used to boot into the maskrom (aka "load stuff from USB") mode.

I wasn't really surprised when I found a big chunk of metal in S912 based Beelink GT1. Though these devices were designed for specific multimedia use cases, and metal plates are added by device vendors (who may not have sources for firmware that controlls DVFS), so it's the STB vendors who decided to cheat in benchmark numbers (in addition to Amlogic who decided to cheat in reported clockspeeds). At least Allwinner DVFS (on mainline) is fully open source, though the reverse-engineered DRAM init code may create an artificial memory throughput bottleneck.

According to this C2 has 3.3V logic, it's the XU4 family that has 1.8V logic. Edit: also this: https://wiki.odroid.com/accessory/development/usb_uart_kit#port_description_of_uart_connector

It's not a feature, it's just an independent package with a dedicated maintainer (in upstream Ubuntu), similar to other packages in Ubuntu that don't exist in standard Debian repositories.

Because zram-config package exists only in Ubuntu by default, and for reasons I don't remember (probably version numbering / potential repository priority issues?) we decided to not copy it to our repository to be available for all releases. It's not set up for multi-user scenario yet (VM guests for different tasks and users instead of one shared space otherwise manual build tasks may conflict with automated ones) I meant this specific thread: https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/ Recent examples to add to that - there is no purpose in recently added "development" branch if "master" is completely abandoned as a result and suggesting to "switch to beta" to fix any issues defeats the purpose of "beta" - fixes should be immediately pushed to the stable branch and beta should be left for non-production ready stuff.