Z11ntal33r

  • Posts

    48
  • Joined

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Posts posted by Z11ntal33r

  1. I receive "No end-user support: built from trunk" at MoTD even though I used a stable and recommended img: Armbian_21.05.4_Odroidn2_buster_current_5.10.43.img. Is that correct given it's a stable build?

     

    Furthermore, I've received a kernel panick - not syncing: kernel stack overflow "Insufficient stack space to handle exception!".  Are the logs saved a place? Can't find it in journalctl. 

     

     

  2. This is a minor issue, but I'm hoping to get it solved as I've enjoyed the welcome screen for so long. For whatever reason after running my installation script which I've been using for years, the welcome screen changes when logging in over ssh. This happened some months ago. Any ideas on how or where I should look?
     

    Spoiler
    
    
    FROM:
      ___      _           _     _   _   _ ____ 
     / _ \  __| |_ __ ___ (_) __| | | \ | |___ \ 
    | | | |/ _` | '__/ _ \| |/ _` | |  \| | __) |
    | |_| | (_| | | | (_) | | (_| | | |\  |/ __/ 
     \___/ \__,_|_|  \___/|_|\__,_| |_| \_|_____|
                                                                                    
    Welcome to Armbian 20.08.17 Focal with Linux 5.8.16-meson64
    
    System load:   2%           	Up time:       7 min		
    Memory usage:  4% of 3.55G  	IP:            192.168.0.28
    CPU temp:      27°C           	Usage of /:    1% of 480G    	
    
    [ General system configuration (beta): armbian-config ]
    
    To run a command as administrator (user "root"), use "sudo <command>".
    See "man sudo_root" for details.
    
    To:
    Last login: Tue Oct 27 23:17:54 2020 from MYIP
    USER@HOSTNAME:~$

     

  3. I think I found the root of the issue I had. It seems to be related to resolvconf and particularly resolvconf-pull-resolved where I had systemd-resolved installed and handling resolv.conf with a symlink. Removing the resolvconf package did the trick. I'll let the server run for some days, yet it seems fine some far. I'm going to make sure that I remove resolvconf in my installation script to prevent this mess from happening again... This is something to be aware of as others might be a victim of the issue as well. It's a quite serious one too.

     

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968015

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967906

     

  4. Thanks again for a great reply! I'll stay put to mainline and use 5.7 until 5.8 has matured. 

    I do not have high expectations or hope for a extremely stable experience with N2, but if it can somewhat give me a decent experience that will be more than enough. I bet I've changed my arm device in a year or two. Out of couriosity, do you have any similar boards you would recommend for NAS usage in the $100-150 price range?


  5. Odroid-N2 using Armbian_20.08.1_Odroidn2_focal_current_5.8.5

    I've recently got a "Connection timed out" issue. For instance, I can open files with nano, use htop, armbian-config, update and upgrade packages, but I can't reboot (everything over ssh). I'm having a feeling that the issue started when I tried to figure out if it's possible to get HDMI to work with my 4K TV when the HDMI cable is not plugged in at boot. In that case, I booted several times and chaged boot.ini with setenv display_autodetect "false", setenv hdmimode "1080p60hz" and  setenv disablehpd "true" without success. armbianmonitor -u information is attached at the end in my post where this line might be of interest: "[    0.000000] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!".

    Conection timed out message:

    Spoiler
    
    $ sudo systemctl reboot
    Failed to set wall message, ignoring: Connection timed out
    Failed to reboot system via logind: Connection timed out
    Failed to start reboot.target: Connection timed out
    See system logs and 'systemctl status reboot.target' for details.
    It is possible to perform action directly, see discussion of --force --force in man:systemctl(1).
    $ sudo systemctl reboot --force
    Failed to execute operation: Connection timed out
    It is possible to perform action directly, see discussion of --force --force in man:systemctl(1).
    $ sudo systemctl status reboot.target
    Failed to get properties: Connection timed out

     


    Running  armbianmonitor -v:

    Spoiler
    
    $ sudo armbianmonitor -v
    Starting package integrity check. This might take some time. Be patient please...
    
    It appears you may have corrupt packages.
    
    This is usually a symptom of filesystem corruption caused by SD cards or eMMC
    dying or burning the OS image to the installation media went wrong.
    
    The following changes from packaged state files were detected:
    
    /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf

     

    Does armbianmonitor -v give any useful information? It detects corrupted pacakges, but which? The 10-globally-managed-devices.conf does not seem to exist. At least I can't read it with cat or nano.

    sysctl --system

    Spoiler
    
    $ sudo sysctl --system
    * Applying /etc/sysctl.d/10-console-messages.conf ...
    kernel.printk = 4 4 1 7
    * Applying /etc/sysctl.d/10-ipv6-privacy.conf ...
    net.ipv6.conf.all.use_tempaddr = 2
    net.ipv6.conf.default.use_tempaddr = 2
    * Applying /etc/sysctl.d/10-kernel-hardening.conf ...
    kernel.kptr_restrict = 1
    * Applying /etc/sysctl.d/10-link-restrictions.conf ...
    fs.protected_hardlinks = 1
    fs.protected_symlinks = 1
    * Applying /etc/sysctl.d/10-magic-sysrq.conf ...
    kernel.sysrq = 176
    * Applying /etc/sysctl.d/10-network-security.conf ...
    net.ipv4.conf.default.rp_filter = 2
    net.ipv4.conf.all.rp_filter = 2
    * Applying /etc/sysctl.d/10-ptrace.conf ...
    kernel.yama.ptrace_scope = 1
    * Applying /etc/sysctl.d/10-zeropage.conf ...
    vm.mmap_min_addr = 32768
    * Applying /usr/lib/sysctl.d/50-default.conf ...
    net.ipv4.conf.default.promote_secondaries = 1
    sysctl: setting key "net.ipv4.conf.all.promote_secondaries": Invalid argument
    net.ipv4.ping_group_range = 0 2147483647
    net.core.default_qdisc = fq_codel
    fs.protected_regular = 1
    fs.protected_fifos = 1
    * Applying /usr/lib/sysctl.d/50-pid-max.conf ...
    kernel.pid_max = 4194304
    * Applying /etc/sysctl.d/99-sysctl.conf ...
    kernel.printk = 3 4 1 3
    vm.swappiness = 30
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    kernel.sysrq = 0
    net.ipv4.tcp_sack = 0
    net.ipv4.tcp_timestamps = 0
    net.ipv4.icmp_echo_ignore_all = 1
    net.ipv6.icmp.echo_ignore_all = 1
    kernel.randomize_va_space = 2
    fs.suid_dumpable = 0
    kernel.dmesg_restrict = 1
    kernel.yama.ptrace_scope = 1
    kernel.unprivileged_bpf_disabled = 1
    net.core.bpf_jit_enable = 1
    net.core.bpf_jit_harden = 1
    net.ipv4.tcp_syncookies = 1
    net.ipv4.tcp_syn_retries = 2
    net.ipv4.tcp_synack_retries = 2
    net.ipv4.tcp_max_syn_backlog = 4096
    net.ipv4.ip_forward = 0
    net.ipv4.conf.all.forwarding = 0
    net.ipv4.conf.default.forwarding = 0
    net.ipv6.conf.all.forwarding = 0
    net.ipv6.conf.default.forwarding = 0
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.default.accept_redirects = 0
    net.ipv4.conf.all.secure_redirects = 0
    net.ipv4.conf.default.secure_redirects = 0
    net.ipv6.conf.all.accept_redirects = 0
    net.ipv6.conf.default.accept_redirects = 0
    net.ipv4.conf.all.send_redirects = 0
    net.ipv4.conf.default.send_redirects = 0
    net.ipv4.conf.all.accept_source_route = 0
    net.ipv4.conf.default.accept_source_route = 0
    net.ipv6.conf.all.accept_source_route = 0
    net.ipv6.conf.default.accept_source_route = 0
    net.ipv4.conf.all.bootp_relay = 0
    net.ipv4.conf.all.proxy_arp = 0
    net.ipv4.conf.all.arp_ignore = 1
    net.ipv4.conf.all.arp_announce = 2
    net.ipv4.tcp_rfc1337 = 1
    net.ipv4.conf.default.log_martians = 0
    net.ipv4.conf.all.log_martians = 0
    net.ipv4.icmp_ignore_bogus_error_responses = 1
    net.ipv4.icmp_echo_ignore_broadcasts = 1
    net.ipv4.route.flush = 1
    net.ipv6.route.flush = 1
    * Applying /usr/lib/sysctl.d/protect-links.conf ...
    fs.protected_fifos = 1
    fs.protected_hardlinks = 1
    fs.protected_regular = 2
    fs.protected_symlinks = 1
    * Applying /etc/sysctl.conf ...
    kernel.printk = 3 4 1 3
    vm.swappiness = 30
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    kernel.sysrq = 0
    net.ipv4.tcp_sack = 0
    net.ipv4.tcp_timestamps = 0
    net.ipv4.icmp_echo_ignore_all = 1
    net.ipv6.icmp.echo_ignore_all = 1
    kernel.randomize_va_space = 2
    fs.suid_dumpable = 0
    kernel.dmesg_restrict = 1
    kernel.yama.ptrace_scope = 1
    kernel.unprivileged_bpf_disabled = 1
    net.core.bpf_jit_enable = 1
    net.core.bpf_jit_harden = 1
    net.ipv4.tcp_syncookies = 1
    net.ipv4.tcp_syn_retries = 2
    net.ipv4.tcp_synack_retries = 2
    net.ipv4.tcp_max_syn_backlog = 4096
    net.ipv4.ip_forward = 0
    net.ipv4.conf.all.forwarding = 0
    net.ipv4.conf.default.forwarding = 0
    net.ipv6.conf.all.forwarding = 0
    net.ipv6.conf.default.forwarding = 0
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.default.accept_redirects = 0
    net.ipv4.conf.all.secure_redirects = 0
    net.ipv4.conf.default.secure_redirects = 0
    net.ipv6.conf.all.accept_redirects = 0
    net.ipv6.conf.default.accept_redirects = 0
    net.ipv4.conf.all.send_redirects = 0
    net.ipv4.conf.default.send_redirects = 0
    net.ipv4.conf.all.accept_source_route = 0
    net.ipv4.conf.default.accept_source_route = 0
    net.ipv6.conf.all.accept_source_route = 0
    net.ipv6.conf.default.accept_source_route = 0
    net.ipv4.conf.all.bootp_relay = 0
    net.ipv4.conf.all.proxy_arp = 0
    net.ipv4.conf.all.arp_ignore = 1
    net.ipv4.conf.all.arp_announce = 2
    net.ipv4.tcp_rfc1337 = 1
    net.ipv4.conf.default.log_martians = 0
    net.ipv4.conf.all.log_martians = 0
    net.ipv4.icmp_ignore_bogus_error_responses = 1
    net.ipv4.icmp_echo_ignore_broadcasts = 1
    net.ipv4.route.flush = 1
    net.ipv6.route.flush = 1

     


    armbianmonitor -u

    Spoiler

    Full log: https://pastebin.com/MeJdigT8
    Snippets:

    
    [    0.000000] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!
    ...
    [    1.977141] thermal thermal_zone0: binding zone cpu-thermal with cdev thermal-cpufreq-0 failed:-17
    [    1.977817] cpufreq: cpufreq_online: CPU2: Running at unlisted freq: 999999 KHz
    [    1.977878] cpufreq: cpufreq_online: CPU2: Unlisted initial frequency changed to: 1000000 KHz
    [    1.978854] thermal thermal_zone0: binding zone cpu-thermal with cdev thermal-cpufreq-1 failed:-17
    ...

     


    I guess the only way to reboot is to pull the plug? Or could it be done without pulling the plug if I connect to the N2 with UART? I'm thinking about doing a new fresh install, but before that, is it worth trying to use the legacy kernel (4.9)? Thanks for the awesome work with Armbian! It has truly been a blessing since I first discovered it!

  6. I've done multiple installations on VIM3 using a clean SD card with both Armbian_19.11.5_Arm-64_buster_current_5.5.0-rc6_20200127 and Armbian_20.02.0-rc1.030_Arm-64_buster_current_5.5.0-rc6_20200129. The color issue appear on both of the images as well as earlier and the simple fix by swapping u-boot files fixes it.

     

    My main concern is the following error which I've never seen before and apply to both images. There are thousands of the same error message in journalctl.

    Spoiler
    
    Feb 03 21:17:46 aml agetty[1689]: /dev/ttyS2: not a tty
    Feb 03 21:17:50 aml systemd[1]: systemd-fsckd.service: Succeeded.
    Feb 03 21:17:53 aml systemd[1]: systemd-hostnamed.service: Succeeded.
    Feb 03 21:17:56 aml systemd[1]: serial-getty@ttyS2.service: Succeeded.
    Feb 03 21:17:57 aml systemd[1]: serial-getty@ttyS2.service: Service RestartSec=100ms expired, scheduling restart.
    Feb 03 21:17:57 aml systemd[1]: serial-getty@ttyS2.service: Scheduled restart job, restart counter is at 3.
    Feb 03 21:17:57 aml systemd[1]: Stopped Serial Getty on ttyS2.
    Feb 03 21:17:57 aml systemd[1]: Started Serial Getty on ttyS2.

     

    Update:
    Running systemctl disable serial-getty@ttyS2.service && systemctl disable serial-getty@ttyS2.service fixed it.

  7. I'm getting the following error after normal upgrade with apt from a clean install earlier in January on a VIM3. Never encountered this issue before. I'm thinking about doing a new clean install after overwriting the whole SD card with zeros. @balbes150, are you going to do new builds for kernel 5.5.* in the next 2-3 days for current? Otherwise I'll use Armbian_20.02.0-rc1.030_Arm-64_*_current_5.5.0-rc6_20200129.img. I guess there isn't much of a change between latest rc6 to final.

    mount: /boot: wrong fs type , bad option , bad superblock, missing codepage or helper program, or other error

     

  8. @bxm, In both functions, syncToDisk () and syncFromDisk (), it should be "sync /" instead of only "sync" (without the quotes) and the issue is fixed? If that's the case, could you add a PR request on Github for the change?

     

    Update

    I can confirm that changing "sync" to both "sync /" or "sync /var" did not wake up my hdds or trigger any hdd-spinup logging according to "systemctl status hd-idle". Thanks!:)

  9. On 9/19/2019 at 10:22 AM, balbes150 said:

    This text is outdated and it is not necessary to pay attention to it.

    Good to know! Choosing "default" worked perfectly and I built kernel 5.3.0 with the latest commit v20190918. I can see from GH source that you did include the patch dwc3/core: xHCI host not responding to stop endpoint command into commit v20190918. Thanks! :)

    For meson-g12 users: If you want to upgrade kernel to 5.3.0 with balbes150 v20190918 patches, the .deb files can be downloaded at: Armbian 5.96 and kernel 5.3.0 for meson-g12 devices (v.20190918)

  10. 14 hours ago, balbes150 said:

    Build version NEXT is very naughty and is intended for experienced users who know the process of kernel build and the build Armbian (used source code directly from GIT Linux), also requires additional manual operations to configure a shared build (disable wireguard, etc.).  You'd better use the "default" option.

     

    Current fixes address only a few model specific errors.

    The reason for why I did not choose "default" was that it states: "Vendor provided / legacy". I do not want a vendor kernel, I want to update my 5.3RC6 kernel to 5.3.0.

    I ask again: Your build Armbian_5.96_Aml-g12_Ubuntu_bionic_dev_5.3.0_20190917 you uploaded fixed the IO errors over USB3.0 interface for g12 devices. Did you actually include the patch i referred to into this build or is it pure kernel 5.3.0?

  11. 13 hours ago, balbes150 said:

    Use the DTB from the previous image. There is an error in the current DTB for VIM3.

     

    Yeah, that did the trick! With the build Armbian_5.96_Aml-g12_Ubuntu_bionic_dev_5.3.0_20190917 you uploaded, I'm finally able to copy/move files over the USB3.0 interface without any IO errors. Did you actually include the patch i referred to into this build or is it pure kernel 5.3.0?

    One more thing. I tried to build the kernel files by following your guide at https://github.com/150balbes/Build-Armbian, but when I was building, I faced an error as seen from the picture attached. I've only followed your guide and selected "U-boot and kernel packages" -> "Do not change the kernel configuration" -> "aml-g12" -> "next". I want to upgrade my current installed build to the latest kernel with the patch. Any ideas why it fails? Let me know if you want the whole output or any logs.

    Spoiler

     

    Screenshot 2019-09-18 at 20.41.18.png

     

    Thanks for the great help BTW! It's awesome when someone from the community aid much more support than the actually support team who released the SBC...

  12. 6 hours ago, balbes150 said:

    Try this version, it has a kernel with all the latest changes.

    https://yadi.sk/d/ixLCvgeXlW4-1w

    Unfortunately, with the build above I'm in a boot loop. I tried both booting from mSD slot and booting from a USB 3.0 mSD card reader. The latest line I can see on my TV is "OK Mounted /tmp." before it boots again. So I guess that the next line where it fails is "Found device /dev/...." etc. 

    This is what I did:

    1. Installed the build to a brand new mSD card and changed both /extlinux/extlinux.conf and uEnv.ini to meson-g12b-a311d-khadas-vim3.dtb.
    2. Activated multi-boot and booted to mSD card. No other devices were connected expect from a keyboard.

    PS: Which means that both Android VIM3_Pie_V190907 and my current Armbian_5.95_Aml-g12_Debian_buster_default_5.3.0-rc6_20190904 build is installed to eMMC.

    I think it's easier to just upgrade kernel with my current system, so I will build the latest kernel files tomorrow both with and without the patch. I'll let you know when I've tested this, balbes150:)

  13. 19 minutes ago, balbes150 said:

    This patch is for an old kernel, I don't work with this old kernel.

     

    I understand. It's an unfortunate situation as the USB3.0 interface for meson-g12b devices is broken and neither Amlogic or Hardkernel devs want to send the patch upstream to mainline and follow it up (https://forum.odroid.com/viewtopic.php?f=176&t=33993&p=268688#p268598)...  One should absolutely avoid using meson-g12b devices if you want to use USB3 then. At the current state, my VIM3 is pointless as I can't move files between my micro SD and USB Harddrives. So I guess I've to build my own kernel and include this patch

  14. Is anyone else getting "Input/output error" when transferring data between two external drives? I thought the issues regarding IO errors were fixed in kernel 5.3... I'm on 5.3.0-rc6-aml-g12 so perhaps I should give the final version a try.

     

    Update:

    Changing /sys/class/block/?d?/queue/max_sectors_kb from the value of 1024 to 32 still trigger the error.
     

    My setup is as follows: A VIM3 with a ORICO Mini USB 3.0 HUB 4 Port Power Supply OTG with Micro USB Power Interface connected to a Rocketek usb 3.0 multi Smart memory card reader with a mSD card inserted and a Seagate Expansion Desktop. Both the ORICO USB HUB and Seagate HDD are powered with an external power supply.


    Update 2:

    This is the patch I need which Amlogic worked out for g12 devices: dwc3/core: xHCI host not responding to stop endpoint command
    I can't seem to find the patch in Kernel 5.3 patch notes... So I suppose it isn't merged yet. Could you please add the patch to your next build, @balbes150? The patch is groundbreaking as it fixes the IO nightmare g12 devices (especially ODROID-N2) have faced for the past months (as seen here: https://forum.odroid.com/viewtopic.php?f=181&t=35031)...

  15. 3 hours ago, balbes150 said:

    Recently was added to test the possibility of upgrading the kernel (up to version 5.3.0-rc6)  from the online repository Armbian.


    Awesome!

    Everything is working as expected on VIM3 with latest Android build (VIM3 Android Pie V190907) including increased RAM (from 3451MB to 3696MB) and installation to eMMC. The complete step-by-step guide is as follows:

    1. Burn latest Android to eMMC with USB burning tool (full erase of flash and bootloader) by Upgrade via a USB-C cable. *
    2. Burn latest Armbian to mSD card / USB with Etcher.
    3. Change dtb filename in both /extlinux/extlinux.conf and uEnv.ini to meson-g12b-a311d-khadas-vim3.dtb
    4. Insert mSD card / USB and boot into Android.
    5. Activate multi-boot by using
      Quote

      Keys Mode (U-Boot is Running Normally)

      1. Power on VIM3.
      2. Long press the POWER key without releasing it.
      3. Short press the ‘Reset’ key and release it.
      4. Count for 2 to 3 seconds, then release the POWER key to enter into Upgrade Mode. You will see the sys-led turn ON when you’ve entered Upgrade Mode.
    6. Log in with root, change root password and add new user.
    7. Run sudo ./install.sh with root and shutdown after successful installation to eMMC.
    8. Activate multi-boot again by using Keys Mode (see step 5) (Remember to have mSD card / USB inserted).
    9. Shutdown, unplug mSD card / USB and power on. You should now be running Armbian from eMMC :)

    * If you have preinstalled any other OS than Android on eMMC, wipe eMMC before burning Android on it by running dd if=/dev/zero of=/dev/mmcblk<number_eMMC> from an OS on mSD / USB.

  16. 3 hours ago, niabi said:

    Thank you for the reply, is there any particular reason?

    The box is a completely mess. Just read up on different forums about ppl whom have plenty of problems with one thing or the other. In addition, it's an oven with temperatures around 70C without stress testing and it's thermal throttling and reducing cpu frequency in the manner of how often people breath...  I'm sad to say that you get what you pay for :/ 

  17. 30 minutes ago, balbes150 said:

    When using Khadas Ubuntu in eMMC (using Ubuntu's option to write to eMMC via USB Burn Tool) is a bad option for General use with external systems (which run from SD card and USB flash drive). All versions of Khadas Ubuntu to write to eMMC, have an error in u-boot, which does not properly run external systems. If you want to run Armbian with external media, the eMMC should be strictly firmware with regular Android. I have explained this problem many times on the Khadas forum.

     

    The only reason I burned Ubuntu and not Android was because the Ubuntu build was newer and I was hoping that the latest u-boot patches was present. For me it doesn't really matter as I'm regardless going to install Armbian to eMMC and never use either Ubuntu or Android. Thanks for the tip btw:)

     

    I'll burn the next Android build when it arrive to see if RAM is increased. How much available RAM do you have with the build you are testing on your VIM3?

  18. 12 minutes ago, balbes150 said:

    I checked the image on my VIM3, everything works correctly, there is no problem with the color or clarity of the text.

    If you run coreelec, for proper operation of other systems after it, you need to full erase the eMMC and restore the standard firmware.


    I've attached a picture so you can see the issue I faced when I tested Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821.img.

    Spoiler

     

    IMG_0297.jpg

     


    I did a full erase of eMMC and burned latest Ubuntu (VIM3_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20190813) with USB Upgrade Tool before installing Armbian to eMMC the last time. How much RAM do you have with VIM3 with the build you are using?

  19. 27 minutes ago, balbes150 said:

    The new kernel reserves memory for video.

    So the new kernel reserves almost 350 MB of RAM for video? Which means the latest patches for Khadas VIM3 u-boot (which is not present in theirs latest Android og Ubuntu builds) won't increase the amount available RAM if I start over by burning Android/Ubuntu to eMMC with latest u-boot and then install latest version of Armbian (Armbian_5.94_Aml-g12_Debian_buster_dev_5.3.0-rc5_20190825) to eMMC again?

  20. Feedback - VIM3
    HDMI problems with Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821.img as the screen is white and blurry...

    Armbian_5.94_Aml-g12_Debian_buster_dev_5.3.0-rc5_20190823.img on the other hand is working good so far. The only issue I've encountered is the amount of RAM available, which is 3354MB - far from ≈3700MB which is normal for 4GB RAM. 

     

    VIM3_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20190813 is showing a little more with 3451MB of available RAM, but it's still much lower than it should be (≈3700MB). What's your take on this @balbes150? I can see from Khadas uboot (Github) that there have been some RAM allocation commits for uboot, but it seems that it only increases available RAM with around 128 MB.

    Update 1:
    I had no luck with LibreELEC regarding increasing RAM, but installing CoreELEC and upgrading bootloader fixed this as I now have 3696MB of available RAM :)

    Update 2:
    Obviously install to eMMC is not working with CE's custom bootloader, so installing VIM3_Ubuntu-server-bionic_Linux-4.9_arm64_EMMC_V20190813 to eMMC, Armbian_5.94_Aml-g12_Debian_buster_dev_5.3.0-rc5_20190823.img to mSD and running install to eMMC still gives 3354MB of available RAM... So using Armbian instead of VIM3_Ubuntu* decreases RAM even further - almost 350MB less than with CoreELEC's bootloader.