zador.blood.stained

Super moderator
  • Content count

    3530
  • Joined

  • Last visited

About zador.blood.stained

  • Rank
    Embedded member

Profile Information

  • Gender
    Male

Recent Profile Visitors

3191 profile views
  1. zador.blood.stained

    Any desktop image for Orange Pi Zeo Plus 2 [Allwinner H5] ?

    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.
  2. zador.blood.stained

    Mainline kernel on Odroid XU4

    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".
  3. 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
  4. zador.blood.stained

    Librecomputer Tritium H3

    And producing a generic 💩 Pi as a result in some cases
  5. zador.blood.stained

    [OPi Plus 2] SPI1 pins

    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.
  6. zador.blood.stained

    Librecomputer Tritium H3

    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.
  7. zador.blood.stained

    git arrangement

    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.
  8. zador.blood.stained

    BananaPi R2 (.csc)

    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.
  9. zador.blood.stained

    git arrangement

    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
  10. zador.blood.stained

    Sopine module failure mitigation with underclocking.

    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.
  11. zador.blood.stained

    /var/log file fills up to 100% using pihole

    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.
  12. zador.blood.stained

    Odroid C2 - Loosing conection after 5 minutes work

    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)
  13. zador.blood.stained

    solved Pushing the I2C SSD1306 OLED to its limits

    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".
  14. zador.blood.stained

    solved Pushing the I2C SSD1306 OLED to its limits

    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
  15. zador.blood.stained

    git arrangement

    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.