qstaq

September 23, 2019

7 hours ago, balbes150 said:

New image 5.97

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

September 17, 2019

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

September 10, 2019

@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

September 9, 2019

6 minutes ago, SvenHz said:

I am still stuck with spl-dkms. I am now on backports.

Interestingly, at that point, I can successfully do a manual "dkms build spl/0.7.13" and "dkms install spl/0.7.13"...!! However if I then do "apt-get install zfs-dkms", it decides to de-install spl-dkms, reinstall it, and fail with the above error :-)

Any ideas at this point? :-)

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

September 9, 2019

1 hour ago, gprovost said:

Yes this is the right place to do contribution to armbian-config tool.

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

September 9, 2019

2 minutes ago, balbes150 said:

The latest version is now available from the online repository Armbian

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

September 9, 2019

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

September 9, 2019

@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

September 9, 2019

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

September 8, 2019

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

September 7, 2019

9 hours ago, utgf said:

Thanks for pointing me to the right direction, but sadly I can't make get the mainline u-boot to work. Everything I do seems to lead to the same "Synchronous Abort" handler error.

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

September 6, 2019

@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

August 30, 2019

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

August 28, 2019

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

August 24, 2019

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

August 15, 2019

On 8/8/2019 at 4:48 PM, hexdump said:

i was looking into this a while ago for a s905w tv box and found out, that a lot of memory seems to be blocked already by legacy u-boot etc. (about 120m) and you cannot get it back by changes on linux kernel side. what helps is to chainload mainline u-boot (just build the libretech-cc u-boot from 2019.07 and use the resulting u-boot.bin):

fatload mmc 0 0x01000000 u-boot.bin
go 0x01000000

in legacy u-boot and then you can use regular boot.scr or extlinux to boot further from there using the chainloaded u-boot just booted.

good luck and best wishes - hexdump

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

August 15, 2019

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)

August 15, 2019

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

August 15, 2019

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?

August 10, 2019

Just now, podarok said:

Armbian_5.91_Aml-g12_Ubuntu_disco_default_5.2.0-rc7_20190708.img.xz

from yandex disk

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

August 10, 2019

2 minutes ago, podarok said:

root@aml:~# modprobe bcmdhd

modprobe: FATAL: Module bcmdhd not found in directory /lib/modules/5.2.0-rc7-aml-g12

Strange. Where did you download your armbian image from?

August 10, 2019

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!

August 10, 2019

20 minutes ago, podarok said:

doesn't work

root@aml:~# uname -a

Linux aml 5.2.0-rc7-aml-g12 #5.91 SMP PREEMPT Mon Jul 8 14:07:34 MSK 2019 aarch64 aarch64 aarch64 GNU/Linux

Can you pot the output of armbianmonitor -u

Check your dmesg output, there will be a firmware loading failed line

August 10, 2019

1 hour ago, podarok said:

installed today successfully on X96 Max

wifi is not working. all other systems working perfect

way performant replacement for the raspberry pi

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/

August 8, 2019

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

Sign In

Forums

Store

Crowdfunding

Applications

Events

Raffles

Community Map

Posts posted by qstaq

Important Information