tparys

I've never really spent too much time using overlays myself, but I did some digging, and this is what I found: In armbian-add-overlay, you have this chunk of code, which is generating the error. case "${LINUXFAMILY}" in sunxi|sunxi64|rk3399|rockchip64|rockpis) :;; *) echo >&2 "Overlays are not supported on ${LINUXFAMILY^} based boards." exit -1 ;; esac But what the script seems to do: Compiles the given dts file into a dtbo Copies the dtbo to /boot/overlay-user Adds "user_overlays=" to /boot/armbianEnv.txt and includes the given overlay file Given that the following is in the ODroid C4 (Amlogic / meson64) image (/boot/boot.cmd), I'm tempted to say it's an oversight. for overlay_file in ${user_overlays}; do if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then echo "Applying user provided DT overlay ${overlay_file}.dtbo" fdt apply ${load_addr} || setenv overlay_error "true" fi done So yeah, I'd suggest doing Genna suggests, or fix the script so it doesn't fail. Also, file a bug on the armbian-add-overlay script, or even better, a PR that fixes it

I may be missing something here, but can't you just ask the the running kernel what version it is? $ uname -r

Hrm. The C4 image I have has a /boot/dtb/amlogic/overlay directory, and that's definitely a Meson64. Maybe try armbian-config to enable your overlay? In the meantime, perhaps someone else can shed some light on what's going on?

Sorry I'm a little late finding this thread. I had traded some messages with Igor on this subject and had spent a few afternoons thinking about it. Though to be honest, if the push is towards Ansible, I must admit I'm not too familiar with the topic, and may not be much help. However, in case it's useful as a talking point, the thoughts I had were along the lines of something I had done for work, to break up the menu system into subdirectories of scripts. A top level bash script scanned each directory, and provided menu options derived from the folder names. Submenus would be directories within directories, leading the top level script to recurse. An action or executable would simply be a script at some level. And the best parts would be that it would be dead simple to add something to it. Drop a script in a directory with an appropriate name. Done. The filenames got a little long, so might want some better way to encode names, but I think it's a decent idea. Additionally, per looking at this post, made me think that we might need something simpler for those who need reading assistive devices. There's nothing saying that you couldn't swap out the calls to "dialog" to bash's "select" call to provide an extremely simple text front end. I suppose you could do some sort of an X tool with TCL/TK, though it wouldn't look pretty at all.

So I just got my M4V2, and installed a copy of 21.02.1 (focal), and it reports 4 GB RAM. You may want to upgrade and see if that fixes your problem.

Login failure counters on Linux are typically managed by pam_tally or pam_tally2, and manage the failed login count outside of /etc/shadow. Both have special console commands to reset those counts. That said, they're not in the Armbian images I have for either the ODroid C2 or NanoPi M4V2. Did you go out of your way to enable them? If not, it's more likely that you messed up your /etc/shadow entry if you edited by hand. If it's corrupt, the system will treat that as a failed password attempt regardless of what you enter.

I assure you that you can, and it's encouraged (see HERE). Fork the repository on github Make a change to your copy Hit the button to create a merge request

Ordinarily, the best place to start is https://www.armbian.com/download/, and grab an appropriate image for your board. If you happen to have a TV box, like you suggest in your link, you might be better suited to ask in https://forum.armbian.com/forum/41-support-armbian-tv/?

If you think it's wrong, submit a change via pull request? https://github.com/armbian/build/pulls

Based on that wiki, it looks like it's probably the same RTC chip (pcf8563), and similar config between the C4 and N2, at least for the HardKernel kernel, which Armbian would probably mark as "legacy". You might be able to enable it in armbian-config, but long term it'd probably serve you better to keep the mainline kernel. I'd probably start seeing if you can enable it manually with sudo or a root shell. Take a look HERE, which shows how to enable it manually. i2cdetect can verify if your RTC is visible on a given I2C bus (may need to test a bus other than 0). Based on the wiki, it should probably be at address 0x51, and probably end up with a command like this: # echo pcf8563 0x51 > /sys/class/i2c-adapter/i2c-0/new_device Or on i2c-1, or whatever bus it's on. And then see if you can read your RTC via "hwclock". If you can, then you know what the tell the Linux kernel. You can do this through a Device Tree Overlay, or via a SystemD script which will run on startup. If you go the overlay route, you'll need to see that the below block ends up inside the the DTB inside the appropriate I2C bus. The extra stuff in each overlay file just sorta specifies where your changes are going. Decompile your DTB with "dtc -o meson-sm1-odroid-hc4.dts meson-sm1-odroid-hc4.dtb", and take a look at the resulting DTS file to see what I mean. rtc@51 { compatible = "nxp,pcf8563"; reg = <0x51>; }; Another way which may be more approachable is the SystemD route (see HERE). Basically you'd be writing a short script, and telling SystemD to start it on boot.

Might be worth trying to isolate the problem to hardware or software? Maybe try a build from HardKernel and see if you can reproduce the fault? If you're still having the issue, there may be something wrong with your board. If you can't reproduce the fault, maybe try one of the older images and see if there's different behavior? May help to point at something that's changed? https://armbian.hosthatch.com/archive/odroidc2/archive/

Can you use a pre-packaged copy from the Debian/Ubuntu repositories? # Python 2.x sudo apt install python-numpy # Python 3.x sudo apt install python3-numpy

Sadly, my M4V2 is still on order, so can't verify this. However, there's probably something different in u-boot, kernel configuration, or device tree, between the Armbian and FriendlyElec builds. Kernel configuration is in /proc/config, or /boot/config-<version>. If you can get both configs, it should be pretty easy to pull it up in "meld" or whatever other diff program you like. Device tree should be similar. Armbian's is in /boot/dtb. Not sure if FriendlyElec has it somewhere convenient, but you can dump it from a live system (see https://unix.stackexchange.com/questions/265890/is-it-possible-to-get-the-information-for-a-device-tree-using-sys-of-a-running). Should be easy to decompile the DTB and see if there's any interesting differences. . $ dtc -o rk3399-nanopi-m4v2.dts rk3399-nanopi-m4v2.dtb If you do find a difference, and it looks memory related (ie dram bank), you might try filing a bug here and clearly identify what you found: https://github.com/armbian/build/issues

I would start with the OrangePI's documentation, and see if they have a table somewhere on a wiki. You can also look at the kernel interface: https://www.kernel.org/doc/Documentation/gpio/sysfs.txt You might find more via "sudo gpio readall" or looking at "/sys/kernel/debug/gpio" on your board. Other vendors have RK3399 examples, which may also be useful: http://wiki.friendlyarm.com/wiki/index.php/WiringPi_for_RK3399#Test Failing that, you may have to flip some pins and see what changes with a LED or multimeter: https://www.ics.com/blog/gpio-programming-using-sysfs-interface

So if I can toss my 2 cents into the ring. I think there's probably two implementations that might be possible here. There's the ARM64 crypto accelerations (which appear in /proc/crypto), and a secure coprocessor which exists on some CPUs. It's my experience that if you care about speed / performance, you want the first one, not the second. Based on the below, your chip has ARM64 crypto extensions. $ grep aes /proc/cpuinfo Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid ^--- HERE Looking HERE, it looks like they're turned on. And they're built in, so you won't see them is lsmod. CONFIG_CRYPTO_AES_ARM64=y CONFIG_CRYPTO_AES_ARM64_CE=y CONFIG_CRYPTO_AES_ARM64_CE_CCM=y CONFIG_CRYPTO_AES_ARM64_CE_BLK=y CONFIG_CRYPTO_AES_ARM64_NEON_BLK=y OpenSSL's output is expected. Recent builds do not provide special drivers to use HW acceleration. It works this way on other ARM64, such as NVidia Jetson. You can see that the ARM64 / NEON versions were loaded in /proc/crypto. I would also put more faith in the output of "openssl speed aes" and check that you're getting speeds 500+ MB/s. I don't have an RK3399 yet (still on order), so unsure what you'd get. Should you be interested, you can selectively disable OpenSSL HW acceleration, such as AESNI on AMD64 (https://mjanja.ch/2013/11/disabling-aes-ni-on-linux-openssl/). Looks like the environment variable on ARM is OPENSSL_armcap. Never tried playing with it, but it's there if you get bored. And I wouldn't enable the coprocessor support unless you really need it. Those tend to be "secure" rather than "fast". Edit: as an additional example of what you might see, head on over to the sbc bench results HERE, and take a look at the results of the ODroid C2 vs C4. C2 lacks crypto extensions and gets about 44 MB/s AES speed, while the C4 has them and gets closer to 195 MB/s. Obviously a slight difference in max clock rate, but otherwise the same CPU family. Should give you an idea of what you might expect to see.

Generally, installing a kernel package triggers initramfs rebuild, but it's possible something got stuck or failed. This may not be your only issue. Something you can try: $ sudo apt-get install binfmt-support $ sudo chroot /mnt/sdcard # update-initramfs -u -k 5.9.14-meson64 update-initramfs: Generating /boot/initrd.img-5.9.14-meson64 W: Couldn't identify type of root file system for fsck hook update-initramfs: Converting to u-boot format If that doesn't work, and you're feeling adventurous, steal the kernel and boot environment from a known good Armbian image? Note the trailing slashes after the rsync arguments. $ sudo kpartx -av Armbian_20.11.7_Odroidc4_focal_current_5.9.14.img add map loop10p1 (253:1): 0 3088384 linear 7:11 8192 $ sudo mkdir /mnt/image $ sudo mount /dev/mapper/loop10p1 /mnt/image $ sudo rsync -av /mnt/image/boot/ /mnt/sdcard/boot/ $ sudo rsync -av /mnt/image/lib/modules/ /mnt/sdcard/lib/modules/ $ sudo umount /mnt/image $ sudo kpartx -dv Armbian_20.11.7_Odroidc4_focal_current_5.9.14.img

Generally, you'll want to provide debug output (see this post) ... But this one might simply be a missing dependency (eject), which you might be able to install manually via synaptic or at the console via: sudo apt install eject

*Edited because I think I gave you bum information* Per this post, looks like the answer is that you do have to use the DTB overlay. Looks like the gpio_pin might have something specific to the ODroid C2 legacy kernel.

*EDIT - For the interested, looks like the gpio_pin argument is nonstandard, see this post* Hi John, The short version is that I'm not sure you've provided enough information here. The answer really depends on what you have, and where you have it connected (if at all). Most GPS units I've seen provide PPS signalling through a DB-9 serial connection at RS-232 levels (~12V), often on one of the modem control pins on that connector such as DCD. If you have one of these units on a USB to serial adapter, you might be able to use it via ldattach (https://www.crc.id.au/2016/09/24/adding-a-pps-source-to-ntpd/). Note that DCD is not always standard, and some USB to serial adapters don't connect DCD at all as it's not always used. If you have a GPS providing 3.3V signalling, and you have your PPS hooked up to the GPIO header, then you should consult the documentation to find out what GPIO goes to what pin (https://wiki.odroid.com/odroid-c2/hardware/expansion_connectors). Note that these GPIO assignments can change with kernel version. I don't have my C2 in front of my at the moment so can't check this for you. But you can always look at /sys/kernel/debug/gpio and see what the valid ranges are. If you do need to experiment, note that you can dynamically load the pps-gpio driver and experiment a bit. The ODroid wiki has more on the subject (https://wiki.odroid.com/odroid-c2/application_note/gpio/pps). # Load PPS on given pin sudo modprobe pps-gpio pin=XXX # Unload PPS sudo rmmod pps-gpio And I wouldn't worry about doing anything with the DTB until you're sure what pin it's on.

https://github.com/armbian/config/pull/135 In case anyone wants to try and break it.

I know this topic's already marked solved, however wanted to add something interesting that I found in my travels. If for some reason a software software controlled read-only switch isn't sufficient, it is actually possible to make a MicroSD card read-only. https://github.com/BertoldVdb/sdtool I'll still echo that overlayroot is generally the way to go. But in some applications that may not be sufficient. And the permlock function does work as advertised.

Looks like someone's already beat me to it, has been merged, and will presumably be in the next round of packages. https://github.com/armbian/build/pull/2446

Just recently got my hands on a new ODroid C4, just to find out it doesn't work with my gamepad. A quick check of the kernel config with linux-image-current-meson64 (20.11.3) suggests this: # CONFIG_INPUT_JOYDEV is not set While I'm pulling down the 5.9 sources and brushing up on cross compiling Linux kernel debians, is there any way this could get added to the Armbian baseline? Thanks in advance.