tparys

Are the existing real time classes in the CPU and I/O schedulers not enough in the standard kernel? Substantial portions of the RT patch set were merged back in kernel 2.6, and we're substantially past that point now.

There are some strong opinions on the Raspberry Pi here, and many are not positive, mostly due to the closed hardware platform. If you need support with Raspberry Pi temperature sensing, you'd find better results asking on their forums. More standard SBC boards would use "sensors" from lm-sensors package, or just read the thermal sensors directly tparys@hobbes:/sys/class/hwmon$ ls -l /sys/class/hwmon/*/temp*_input -r--r--r-- 1 root root 4096 Apr 14 00:17 /sys/class/hwmon/hwmon0/temp1_input -r--r--r-- 1 root root 4096 Apr 14 00:17 /sys/class/hwmon/hwmon1/temp1_input

Possible yes, but perhaps not in the short term. ARM devices vary wildly, and it is unlikely that two boards that share the same processor can use the same image. If there is not yet a build for that specific device, it may be easy, or there may be some substantial work required to make things work there. The list of devices that currently have builds ready to go is here: https://www.armbian.com/download/ If your device is not in that list, you can ask nicely under feature requests. But unless someone's been funded to do the work, or has the hardware, time, and interest, you may be waiting some time. You are also welcome to start from one of the existing Armada builds, and try modifying it for your needs. At minimum, you'd likely need to modify the system's Device Tree (DTB), and may need to make substantial bootloader (u-boot) changes as well (see: Espressobin).

https://drive.google.com/drive/folders/1YWMDbbx0p4dLPO3Mr3921vNay8l-_vHo?usp=sharing This is a topic to discuss CSC Armbian support on the Avnet MicroZed board, and adding a similarly supported SoC family for the Xilinx Zynq. In terms of "interesting boards", the Zynq is a combination ARM/FPGA SoC that pairs a dual core Cortex A9 @ 667 MHz with a Artix-7 family FPGA fabric. In terms of performance, the A9's are nothing to write home about, but the FPGA fabric opens some rather interesting possibilities for those determined enough to use them. For the unfamiliar, an FPGA (Field Programmable Gate Array) is a sort of reconfigurable logic. It allows one to have dynamic hardware components instead of static pieces selected by the board manufacturer. Want 100+ GPIO? Sure. A dozen serial ports? Alright. 37 I2C buses? You might need to share some interrupts, but I'm not aware of a specific reason that shouldn't work. Really, you're limited by pin count, FPGA fabric usage, and what you can express in Xilinx Vivado. Be aware, if editing Device Trees puts you off, this is not the board for you. You will need to do substantially more to get anything significant working. If you do not have a copy of Vivado installed, you will not get far. Interested users should start with Xilinx/Avnet documentation or HERE. Current development status: MicroZed (7020) booting up, appears to be working fine CPU Frequency Scaling (333 or 667 MHz ) FPGA bitstream loading (See below gotchas) Onboard Gigabit Ethernet USB (See below gotchas) GPIO, including board heartbeat LED Things that aren't working: DTB Overlays (seems to freeze board when enabled in u-boot config) PMOD connector (Didn't enable it in the Vivado, Design, FSBL, DTB, etc..) Current gotchas: Zynq u-boot doesn't work like other boards. u-boot and the Zynq FSBL (First Stage Bootloader) get baked together into a file called "boot.bin" via a Xilinx program called "bootgen". This is not currently in the image, so are not able to modify this file on-board. The MicroZed 7010 and 7020 are different boards. The CPU is compatible, but the 7020 has a larger FPGA and access to more pins (eg - Bank 13 on the MicroZed schematics) One of the jobs of the FSBL is to configure the Zynq MIO (Multipurpose I/O). To a limited extent, this re-configures which CPU pins go where on the PMOD connector, sets pull-up or pull-down resistors, and does other things. I think it's possible to skip the FSBL entirely and go directly to u-boot, but am unsure how that's supposed to work in a general sense. The Avnet preset for the MicroZed board specifies the correct reset pin for the USB PHY, but Vivado is not currently using/respecting it. If you make a new design, and do not check that the USB0 reset is enabled on MIO7, and build your own FSBL, the onboard USB port will not be usable.

Alright, spent some more time digging at this, and have the build system generating viable boot images. Also moved my stuff to a microzed-cleanup branch to merge a bunch of smaller dumb commits. I ended up settling on adding bootgen as one of the tools compiled by the build system by adding a extra function compile_xilinx_bootgen() in lib/compilation.sh, and a precompiled FSBL as a separate repo "xilinx-fsbl-blobs". Both get setup in do_default() in lib/main.sh. The boot.bin file gets created by uboot_custom_postprocess() in config/sources/families/zynq.conf, and gets dropped directly in /boot by the debian installation. I've marked it as a "config file" for now as the FSBL does change with Vivado project design, and don't want to clobber a user FSBL with the prepackaged one. Users who don't touch that file get it updated automatically. Probably want a better solution, but this should work for now. Cpufreq, GPIOs, Ethernet, LEDs, ZRAM all seem to be working. USB regulator might be off. I've seen that in previous DTB versions. PMOD connector hasn't been configured for anything, so that's dead/off for now.

Because GPIO pin mappings are different on every single SBC that exists, and often times they are not called out by hand? The software needs to know which board you're on, and vendor kernels can often times put in nonstandard hacks that don't exist elsewhere. Also, WiringPi isn't exactly a standard product, and I'm unsure if it's supported outside the FriendlyElec build. Perhaps you'd want to try something actually built for this project? https://forum.armbian.com/topic/5655-armbianio-api-proposal/ Barring that, I'd suggest installing gpiod, and using gpioinfo, gpioget, gpioset, etc ...

Does Armbian even have to package this? Consider packaging that driver via DKMS (https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging), and installing the resulting .deb on your board. It should persist through kernel upgrades.

Not booting entirely by itself, but progress here on microzed branch. armbianmonitor

Foreward: Not sure if this better fits in board bring up, but I can't post there, so feel free to move if appropriate. I'm looking into the feasibility of using the Armbian build system to generate OS images for the Avnet MicroZed board. This board is based on the Xilinx Zynq 7000 platform, which is a SoC made up of a dual core 500 MHz CPU, and a Artix-7 generation FPGA. The CPU is nothing to write home about, but the FPGA opens up an interesting array of possibilities. Just in case you need an ARM board with 100+ GPIO, over two dozen serial ports, or your own function generator. Really, you're limited only by pin count, FPGA fabric usage, and what you can manage in Vivado. Xilinx also has an active presence on GitHub, and branches for kernels as new as 5.12, so sees active support. The big rub, is that the Zynq CPU boots off a VFAT partition, that contains a file named "boot.bin". This boot file combines the first stage bootloader (FSBL) and u-boot, and needs to execute a C application to assemble this file. The application is recently open sourced, and previously existing open source software also exists. But I'm not sure how best to integrate that with the build system, or identify that the platform u-boot package depends on this extra package.

If you're doing a LUKS unlock via cryptsetup, it's done inside of the initramfs (or initrd). The text of that is sent to the Linux console. It's before SystemD starts and initializes all consoles listed as kernel arguments. So IIRC, it's only the last one specified that takes effect at that point in boot. So if you want it on the main display, you may have to append a "console=/dev/tty0" kernel argument in your boot options. Once SystemD takes over all specified consoles become active, but the kernel only will use the last one specified for that part of the boot process. Or maybe first one? Sometimes my brain's mashed potatoes. Experiment a bit? I've not looked through the current Armbian + LUKS instructions.

Another things I've been playing with in my spare time. Better identification of the SoC that some of these boards use. For example my NanoPi M4V2 (RK3399) kicks back this: tparys@hobbes:~$ ./arm-chip-id.sh 4x Arm Cortex-A53 @ 1416 MHz 2x Arm Cortex-A72 @ 1800 MHz Not sure if it's useful, but might be more descriptive for end users who don't know much about their systems, or for describing controls for each CPU cluster in their SoC (see this post). Apologies in advance the bash is a little hard to read as it's digging through sysfs topology bits. It also breaks if the first CPU in a cluster is knocked offline. Not like anyone would do that, right? arm-chip-id.sh arm-chip-id.db

The pps_gpio module does not take parameters. Definitions of a PPS device must be in the DTB, or overlay: https://mjmwired.net/kernel/Documentation/devicetree/bindings/pps/pps-gpio.txt That's because you're missing parts of the DTB overlay. Notably, you need to specify that: It's an overlay Where it applies ("target" or "target-path") What you're doing there (overlay or fixup) And in this case, what you're adding ... You probably meant to do something like this instead. Note that I don't have your setup, nor your board, so can't test this. But probably a better start than where you are. /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328"; // Define a PPS device on GPIO Bank 1, pin 2 fragment@0 { target-path = "/"; __overlay__ { pps0: pps-gpio0 { compatible = "pps-gpio"; gpios = <&gpio1 2 0>; assert-falling-edge; }; }; }; };

If the driver is compiled as a module on your system, it's possible to swap out the module with your own copy via DKMS. It involves copying out the driver, and packaging it through the DKMS system. Install on your board and will replace the stock module on future kernel updates (at least given no major changes). If the driver is builtin, you cannot swap it out and must rebuild the whole kernel image. What category you fall into depends on what board you have, what kernel you're using, and what audio codec you want to change. Without additional detail and "armbianmonitor -u", there's no way to guess from your description.

FYI, the reason this post got flagged is that it's missing armbianmonitor output (see https://forum.armbian.com/topic/5699-how-to-provide-and-interpret-debug-output/). Edit your original post, and put it at the top. I think it'd be in the interest of others to identify which builds are showing this behavior.

By the way, this was merged some time back. Unless this needs additional work, you can probably close / delete this topic.

As a kick in the right direction, I have this in "/etc/udev/rules.d/50-gpio.rules". KERNEL=="gpio*", GROUP="users" Then need to trigger udev, or reboot. Afterwards ... tparys@hobbes:~$ ls -l /dev/gpiochip* crw-rw---- 1 root users 254, 0 Mar 20 20:58 /dev/gpiochip0 crw-rw---- 1 root users 254, 1 Mar 20 20:58 /dev/gpiochip1 crw-rw---- 1 root users 254, 2 Mar 20 20:58 /dev/gpiochip2 crw-rw---- 1 root users 254, 3 Mar 20 20:58 /dev/gpiochip3 crw-rw---- 1 root users 254, 4 Mar 20 20:58 /dev/gpiochip4 Then make sure gpiod is installed (sudo apt-get install gpiod). Then do something like this, or read man pages for gpioget / gpioset. # Reading GPIO chip 1, line 3 gpioget 1 3 # Setting that GPIO to 1 (high gpioset 1 3=1

Hi friend, this is indeed the solution for a lost password. Sarcasm will not help this situation, and threatening to install TinkerOS is a don't care for us. user@compy $ sudo -i root@compy # mount /dev/mmcblk0p1 /mnt/armbian root@compy # chroot /mnt/armbian root@armbian # passwd <username> New password: Retype new password: passwd: password updated successfully root@armbian # exit root@compy # exit user@compy Do note that if you've gummed up your sudoers file (eg - editing outside of visudo), no amount of password resets will permit user sudo to root.

Hi Ramon, This is actually a different problem, in that /sys (sysfs) is a virtual filesystem and not actually something on the SD card. In that sense, there's nothing to save boot-to-boot. It's also a deprecated interface, so you may just want to look into the newer interface. If you do want to use the GPIO that way, you can do one of a few things: Make a script that configures your GPIO on every boot (such as rc.local) Write a udev rule that sets ownership of gpio files in sysfs Just run your application with setuid root privileges

Serious question. The sysfs gpio export interface is deprecated since 4.8, and you guys run bleeding edge kernels for your SBCs. Why do you want this? Also, the newer gpiod interface already has a native python interface. Is there need to reinvent the wheel here?

I don't have a N2 or an HC4 handy, but these two links appear interesting ... https://isolated.site/2019/07/08/debian-10-hangs-during-booting-on-phicomm-n1/ https://lists.opensuse.org/opensuse-bugs/2019-03/msg00250.html Both have the same error code, and apparently the same solution. Notably, the phicomm N1 is also an Amlogic S905 ... Any chance setting this in your /etc/default/haveged fixes it? DAEMON_ARGS="-w 1024 -d16" Apparently haveged is supposed to auto-detect CPU settings, but apparently doesn't always work, and the fallback doesn't either.

Make a PR. Igor handles a lot.

First, "armbian-monitor -u". Edit your top post and add it at the top. What you're seeing is initial ramfs (or initramfs), but is often written as inital ramdisk (or initrd) for historical reasons. It's singular job is to mount the root filesystem before init / SystemD takes over. It's basically a compressed archive (CPIO) of a bunch of scripts made by initramfs-tools (or dracut on systems like Redhat) that load drivers and pivot to the real filesystem before continuing. In this case, it's attempting to mount the device listed as "/dev/mmcblk0p1", and it can't find it, and eventually gave up. Linux is running, but boot is stuck. If the MMC interface is anything like the Ethernet subsystem, devices get enumerated based on the order they are found. So eth0 is first, eth1 is second and so forth. If two drivers load at the same time, there's a possible race condition and they can flip occasionally, and even change behavior after a software update. This is also the reason for the "persistent" Ethernet device names like "enp3s2" which are crazy looking, but deterministic. I've noticed that many ARM boards get device names from the DTB aliases. But maybe it's not being used for whatever reason? Not sure. In the meantime, if mmcblk0 and mmcblk1 occasionally swap position, it's probably far better to specify your root device via LABEL or even better, by UUID. $ sudo blkid /dev/mmcblk0p1 Then change your boot arguments to include "root=UUID=<WHATEVER>". Should be in /etc/armbianEnv.txt. but don't have it in front of me at the moment. Also update your /etc/fstab to point to "UUID=<WHATEVER>", else you won't get much further. More information on initramfs-tools, and boot arguments: https://manpages.debian.org/testing/initramfs-tools-core/initramfs-tools.7.en.html

HardKernel has added non-standard "features" to their kernels in the past. For example, see THIS POST. This may be one of them. Notably, kernel arguments are generally of the MODULE.PARAMETER=VALUE form, and "gpiopower" doesn't fit that at all. So, if you want the kernel to handle it, you can enable it by specifying a DTB overlay, adding "gpio-poweroff" to your specified GPIO pin. See these examples: https://www.kernel.org/doc/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt https://www.toradex.com/community/questions/10564/how-to-power-onoff-colibri-vfxx-properly-using-gpi.html Else you can write a script to monitor that GPIO and call shutdown when desired.

The section that configures CPU scaling in armbian-config configures cpufrequtils (/etc/default/cpufrequtils), and cpufrequtils does not currently support doing anything other than one policy system-wide. If you need to do something else, I'd suggest disabling the cpufrequtils service via SystemD, and spell out exactly what you want in /etc/rc.local, making sure the rc-local.service is enabled and started. # Little cores (0-3) POLICY=/sys/devices/system/cpu/cpufreq/policy0 echo ondemand > ${POLICY}/scaling_governor echo 408000 > ${POLICY}/scaling_min_freq echo 1416000 > ${POLICY}/scaling_max_freq # Big cores (4-5) POLICY=/sys/devices/system/cpu/cpufreq/policy4 echo ondemand > ${POLICY}/scaling_governor echo 408000 > ${POLICY}/scaling_min_freq echo 1800000 > ${POLICY}/scaling_max_freq

So the boot script is actually provided by the u-boot for your board. And depending on how well your board is supported by the u-boot mainline, there's often many board specific tweaks. In your case, the boot script is unique to your board: https://github.com/armbian/build/blob/master/config/bootscripts/boot-odroid-n2.ini And while there's a generic Meson 64 and N2 Mainline, neither of which is used in the most recent image for your board (21.02), tells me that it's still being worked on. So if you look at the Generic Meson 64 script, your boot script should probably support both "extraargs" and "usbstoragequirks" in /etc/armbianEnv.txt, but currently does not. Not sure if it's an oversight, or some outstanding issue preventing it's use. However, should be pretty easy to add in. Be warned your edits to /etc/boot.ini will certainly be overwritten on the next u-boot update. Best to submit a fix via pull request at https://github.com/armbian/build/pulls, or at least an issue at https://github.com/armbian/build/issues, Also, going forward, the community peer-to-peer board doesn't see a lot of support. The N2 is a supported board and better to post questions in https://forum.armbian.com/forum/16-amlogic-s905x-s922x/ if you still need help. Be sure to include armbianmonitor output, else the replies might be more blunt and less helpful.