qstaq

Hi @balbes150 Just tried your new 5.97 image on an Odroid N2. All the basic hardware seems to work but Im getting a display saturated in green colour. It looks like the blue colour is missing from the RGB signal, the same as when you have a faulty display cable. Its not an X11 problem, the display is green coloured in the framebuffer too, infact its green right from the point the kernel initialises. Any ideas as to what might be causing this? I have not tried any previous versions of your G12 images yet or the official Armbian K4.9 build. The devices previously ran a buildroot based firmware of my own making with HK's 4.9 and there were no colour problems under framebuffer or wayland (no x11). Ive also just tried the Manjaro N2 release and that seems to work fine. armbianmonitor -u: http://ix.io/1WzE Thanks Update: Just tried the normal Armbian N2 build from the main download page and the colour problem is not there, the problem is only in your Yandisk images Normal Armbian: http://ix.io/1WAf Update 2: Just tried the 5.96 image and its fine. The colour problem is only with the 5.97 image

You would need to ask that question in an android forum somewhere Also what is your use case for the T95Z plus? It's not a great TV box, the S912 has lots of cores but they are not that fast, the GPU is barely adequate, it doesn't have usb3, it only has 2gb ram, it's expensive for what you get and it's a discontinued product

@SvenHz @gprovost There seems to be a problem with kernels newer than 4.14. I started investigating last night and tried a lot of different kernel / zfs-dkms versions. All my live deployments of ZFS are on rk3328 and rk3399 devices with kernel 4.4 and with 4.4 everything seems to work fine. I have not managed a successful, apt automated, build on a kernel newer than 4.14. Its not an arm specific issue, even on x86_64 Im having problems with more recent kernels. Im going to spend a couple of hours on it tonight and see if I can narrow down a cause

Im having the same problem on Buster right now but older versions of zfs-dkms on Ubuntu have no problems. I will have a proper look this evening when I dont have real work interrupting me

Which is the preferred menu to display in? In Softy (debian-software) or in the system software menu (debian-config-submenu)?

Awesome thanks. I hadnt performed an apt update for a while and Im still running 5.21 so I didnt see it

Hi @balbes150 Do you have a linux-headers package available for your AMLG12 and / or RK3399 kernels that you ship with your yandisk images? Thanks

@SvenHz try also installing spl-dkms first, after you have installed the linux-headers package for your kernel. Also make sure you have the backports repo enabled if you are on Buster

There are license incompatibility problems and patent risks with ZFS on linux. ZFS is CDDL licenses which risks potential patents lawsuits issues for anyone publishing ZFS code contributions with a GPL license. Thats why ZFS will not be in any mainline kernel any time soon. The CDDL license was seemingly designed by Sun to be incompatible with the GPL license. That doesnt mean you cant use ZFS on linux, you just have to use CDDL licensed ZFS to code to be granted Oracles patent protection / immunity. Debian, Ubuntu, etc get round this by shipping the ZFS module as a DKMS built out of tree module and not as part of the kernel I would suggest that there are currently too many problems with ZFS, both from a practical and legal viewpoint, to think about making ZFS a core part of Armbian. Most of Armbian's target hardware is under specified for a default setup of ZFS and proper storage management under ZFS requires much more knowledge than mdraid and ext4 or BTRFS. Its not complex, it just requires you to think and plan more at the deployment stage and have an awareness of some storage concepts that most users dont have knowledge of Now on to the positive news ZFS is an excellent filesystem and for certain use cases its way more powerful and flexible than BTRFS or any lvm / mdraid / ext4 combination, its also pretty simple to admin once you learn the basic concepts. Im sure there are a small portion of Armbian users that would get significant benefit from having ZFS available as a storage option. Even better news is that fundamentally every Armbian system already support ZFS at a basic level as both Debian and Ubuntu have the zfs-dkms package already available in the repos. It takes less than 5 minutes to enable ZFS support on any Armbian image just by installing the following packages with apt: zfs-dkms, zfs-initramfs & zfsutils-linux (probably zfsnap is also wanted but not required). The problem is that the default config will definitely not be suitable for a 1-2GB RAM SBC and we would need a more appropriate default config creating. I still wouldn't recommend ZFS use for the rootfs, if you want snapshots on your rootfs then use BTRFS or use ext4 with timeshift. @Igor @gprovost I would think that the best place to implement this would be as an extra option in armbian-config -> software. I wrote a simple script to install ZFS support and to set some default options for compression, arc, cache, etc for low mem / cpu devices. The same script works without changes on Debian Buster, Ubuntu 16.04, 18.04 & 19.04 as the process is identical on all OS variants as far as I can discern Is https://github.com/armbian/config the live location for the armbian-config utility? If so I will have a look at adding a basic ZFS option in software

Armbian kernel configs (the ones that I have looked at anyway) dont have the config options to build the ZFS modules. You will have to build a new kernel or build the module out of tree Also there is a lot of misunderstanding about ZFS ram use. The main culprit of the seemingly huge ram use of ZFS is the de-duplication feature. If you disable de-duplication then you can run a simple samba / nfs file server with 4-6TB of usable storage in about 650MB RAM. I have even run simple zfs pools on OPi Zero with 512MB RAM with de-dup disabled and a couple of config tweaks using a 1TB SSD over USB for storage, though I would suggest that 750MB RAM is a more sensible minimum The key is to disable de-dup BEFORE you write any data to the pools, disabling afterwards wont lower RAM use. You can also limit the RAM used by setting zfs_arc_max to 25% of system RAM instead of the default of 50% and disable vdev cache with zfs_vdev_cache_size = 0. I have also found that setting Armbian's ZRAM swap to 25-30% of RAM instead of 50% of RAM improves performance. Obviously performance isnt going to be quite as good as a machine with 8GB RAM but the difference isnt that big either

Have you tried libretech u-boot? It worked for me on S905x/w/x2 devices. I used balbes150 AMLG12 armbian build and then chainloaded The libretech u-boot from the AML u-boot https://github.com/libre-computer-project/libretech-u-boot

@utgf I have just gone through this problem with some S905 boxes. The problem was not the DTB (though changing it did give me a little extra usable RAM), the problem was with legacy u-boot

You need to post device make / model and amrbianmonitor -u output so your problem can be troubleshooted Why have you disabled the zram swap filesystem? That is probably the reason why your device is becoming unresponsive

Watchdog is part of the kernel and will not help you in this situation if, as you say, the device is hanging BEFORE the start of kernel loading You need to provide the serial debug output from the u-boot phase of the boot process AND the output of armbianmonitor -u if you want some help, your question doesnt really provide any technical info that can be used to troubleshoot

You are confusing mount options. gid & uid are only for network or local file systems that dont support unix like permissions. They allow you to overlay a fake permissions base over the top of a filesystem that doesnt have the attributes to support unix like permissions You shouldnt be using uig or gid to mount an ext4 filesystem, by design it will not work. Mount it without any -o gid or uid options and once mounted then you can use chown or chmod to set the native permissions that you want

Hi @hexdump I have built the libretech-cc u-boot and copied it to my /boot fs. How do I instruct legacy u-boot, installed on an sd card, to chainload the libretech u-boot? Thanks for the help

Im de-compiling the existing dbt with: dtc -I dtb -O dts meson-gxl-s905x-nexbox-a95x.dtb > custom.dts then modifying custom.dts and re-compiling with: dtc -O dtb -o custom.dtb custom.dts Then changing uEnv.ini to point at custom.dts Edit: Working Now OK so setting the FDT option in uEnv.ini doesnt do anything on S905x devices, you have to change the FDT in extlinux.conf instead (balbes images)

What are the advantages of UEFI vs u-boot or grub2?

Thanks @jock I have created a new dtb with the following change: linux,cma { compatible = "shared-dma-pool"; reusable; size = <0x0 0x2000000>; alignment = <0x0 0x400000>; linux,cma-default; }; This should reduce the cma size to 32MB (0x2000000) if I understand correctly? However even with that change I still see "cma: Reserved 256 MiB" in dmesg, not 32MB as I would expect. I have also tried various different "cma=x" values on the kernel command line but the argument seems to be ignored Have I misunderstood something?

Is that the 5.91 images from balbes150 unofficial test yandisk repo? If so then yes it is missing the bcmdhd module. You will have to clone balbes s905 kernel repo from github and build the module and / or kernel

Strange. Where did you download your armbian image from?

You dont seem to have the bcmdhd module loaded Can you "modprobe bcmdhd" then check the output of dmesg You should see something like below or see a firmware load error [141287.185258] dhd_module_init: in Dongle Host Driver, version 1.579.77.41.9 (r) [141287.185286] ======== dhd_wlan_init_plat_data ======== [141287.185298] [WLAN_RFKILL]: rockchip_wifi_get_oob_irq: Enter [141287.185315] dhd_wlan_init_gpio: WL_REG_ON=-1, WL_HOST_WAKE=-1 [141287.185326] dhd_wlan_init_gpio: oob_irq=65, oob_irq_flags=0x414 [141287.185336] dhd_wifi_platform_load: Enter [141287.185378] Power-up adapter 'DHD generic adapter' [141287.185782] dummy_sdmmc: probe of mmc2:0001:1 failed with error -110 [141287.186059] dummy_sdmmc: probe of mmc2:0001:2 failed with error -110 [141287.186883] wifi_platform_set_power = 1 [141287.186897] ======== PULL WL_REG_ON(-1) HIGH! ======== [141287.186909] [WLAN_RFKILL]: rockchip_wifi_power: 1 [141287.186921] [WLAN_RFKILL]: wifi turn on power. -1 [141287.489181] wifi_platform_bus_enumerate device present 1 [141287.489193] ======== Card detection to detect SDIO card! ======== [141287.489200] mmc2:mmc host rescan start!

Can you pot the output of armbianmonitor -u Check your dmesg output, there will be a firmware loading failed line

AP6356S WiFi chip in the 2.4/5Ghz models does work however the system looks for the firmware in the wrong place Copy the firmware from the rkwifi folder to the brcm folder and reboot, wifi should work cp -Rv /lib/firmware/rkwifi/* /lib/firmware/brcm/

A more interesting section in meson-gx.dtsi: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; /* 16 MiB reserved for Hardware ROM Firmware */ hwrom_reserved: hwrom@0 { reg = <0x0 0x0 0x0 0x1000000>; no-map; }; /* 2 MiB reserved for ARM Trusted Firmware (BL31) */ secmon_reserved: secmon@10000000 { reg = <0x0 0x10000000 0x0 0x200000>; no-map; }; /* Alternate 3 MiB reserved for ARM Trusted Firmware (BL31) */ secmon_reserved_alt: secmon@5000000 { reg = <0x0 0x05000000 0x0 0x300000>; no-map; }; /* 32 MiB reserved for ARM Trusted Firmware (BL32) */ secmon_reserved_bl32: secmon@5300000 { reg = <0x0 0x05300000 0x0 0x2000000>; no-map; }; linux,cma { compatible = "shared-dma-pool"; reusable; size = <0x0 0x38000000>; alignment = <0x0 0x400000>; linux,cma-default; }; }; I presume this is reserving 53MB for ROM and ATF? The linux cma section seems to be declaring 896MB of shared RAM but I dont understand what the alignment declaration does and none of these numbers match up with what seems to be allocated for the GPU