tparys

Perhaps look at /boot/armbian_first_run.txt.template ?

Okay..  There's another open role that you may be interested in:

We're looking for someone who's interested in the hardware, likes to post on the forum to discuss and share technical improvements, but also get angry about low participation, and take any opportunity available to insult the Armbian project and yell at developers and contributors who generally have good intentions.
 
Is that something you'd be interested in taking on?

I think @lanefu was referring to doing a diff between the configs of the rockchip64 kernel which does not work, and the sunxi kernel which does.
 
Based on the error, I'd wager the keyslot open is failing because you're missing a hash function. Believe the default is SHA1, unless you specified something different. Running "cryptsetup luksDump /dev/sda1" or whatever, should tell you for sure.
 
If your system has AF_ALG compiled in, you can also run "cryptsetup benchmark", which runs typical hash and cipher algorithms used by LUKS. If it fails on something, that could be a clue.

Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
 
Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
 
Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
 
So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
 
### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
And using it isn't too hard ...
 
cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
 
cpufrequtils-bl

Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
 
Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
 
Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
 
So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
 
### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
And using it isn't too hard ...
 
cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
 
cpufrequtils-bl

ifupdown

As entertaining as this thread is so far, I suggested to @TCB13 to post here to get more eyes on the problem.
 
I can confirm that enabling the overlay in question didn't do the expected thing. And "armbianmonitor -u" is here: http://ix.io/3nS8
 
Interestingly, the overlay seems to be disabling the spidev?
 
fragment@4 { target = <0xffffffff>; __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; spidev { compatible = "spidev"; status = "disabled"; reg = <0x00>; spi-max-frequency = <0x989680>; }; }; };  
Offhand, I'm not sure what's required to switch between multi-function pins, but figured there would be far more eyes on the problem here rather than Peer to Peer Support.

So the M4V2 is a supported board. that the SPI isn't working is probably worth a post by itself in the Rockchip 3399 Subforum.
 
At a glance, I tried turning on the SPI on my M4V2 and didn't see any spidev devices pop up, but might need to pull out the serial console to see if u-boot is throwing any warnings about the overlay.
 
Taking a look at the overlay, I'm not sure it looks correct, as it looks like even if it applies the SPI channel is disabled.
 
fragment@4 { target = <0xffffffff>; __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; spidev { compatible = "spidev"; status = "disabled"; reg = <0x00>; spi-max-frequency = <0x989680>; }; }; };  
 

Which is true but barely anyone wants to step in and provide long-term maintenance....

Looks like a neat setup. I was not aware that M.2 to 5x SATA device existed.
 
But before you reinvent the wheel, have you considered that you basically made a Helios64 without the nice enclosure?

https://www.go4b.com/usa/technical-support/product-manuals/t500-hotbus/rs485-wiring-guide.pdf
 
485 uses differential pair as a both a send and a receive. Both pins are both input and output. There's not really an RX pin unless you convert back to 232.
 
If you take a look at example link. You can have multiple listeners using 485 to 232 converters attached to that differential pair, and may do what you want.

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.  
 

Not that I have experience with these sensors, but looks like the general flow is this:
hit the sensor with a pulse (low/high) count cycles until a response (pulseIn) As it's a microcontroller, pulseIn will probably not return until there is a response. The second call to pulseIn() probably starts counting after you're done printing the value from the first. Considering your output pulses happen within 2-10 ms of each other, I bet this happens:
 
digitalWrite(center_Trig, LOW); digitalWrite(right_Trig, LOW); a=pulseIn(left_Echo, HIGH) / 58.00; Serial.println(a); // <- 2nd, 3rd echos arrive here b=pulseIn(center_Echo, HIGH) / 58.00; // <- timeout Serial.println(b); c=pulseIn(right_Echo, HIGH) / 58.00; // <- timeout Serial.println(c);  
Maybe pulse the second sensor after you're done reading the return from the first? Then the third when the second is done?
 

To add to @tparysexcellent answer:
 
The original code with commented problems:
 
const int left_Trig = 1; const int left_Echo = 2; const int center_Trig = 3; const int center_Echo = 4; const int right_Trig = 5; const int right_Echo = 6; float a; float b; float c; void setup() { Serial.begin(9600); pinMode(left_Trig, OUTPUT); pinMode(center_Trig, OUTPUT); pinMode(right_Trig, OUTPUT); pinMode(left_Echo, INPUT); pinMode(center_Echo, INPUT); pinMode(right_Echo, INPUT); Serial.println("Ultrasonic sensor:"); } void loop() { digitalWrite(left_Trig, LOW); delayMicroseconds(2); digitalWrite(center_Trig, LOW); delayMicroseconds(2); digitalWrite(right_Trig, LOW); delayMicroseconds(2); // Why the delay when turning them all off? Why not just turn all low at the same time? digitalWrite(left_Trig, HIGH); delayMicroseconds(10); digitalWrite(center_Trig, HIGH); delayMicroseconds(10); digitalWrite(right_Trig, HIGH); delayMicroseconds(10); // Delay after turning each one on, guarantees at this point the left one was on for 30µs already, the center for 20µs and the right one for 10µs that cant be right? // maybe again turn them all on, then wait 10µs? digitalWrite(left_Trig, LOW); digitalWrite(center_Trig, LOW); digitalWrite(right_Trig, LOW); // this seems ok a = pulseIn(left_Echo, HIGH) / 58.00; Serial.println(a); b = pulseIn(center_Echo, HIGH) / 58.00; Serial.println(b); c = pulseIn(right_Echo, HIGH) / 58.00; Serial.println(c); // this has problems because as tparys assumed pulseIn blocks. So the first pulseIn waits for the first echo, but then the second and so on might have been already missed! // https://www.arduino.cc/reference/en/language/functions/advanced-io/pulsein/ a = (int(a * 100.0)) / 100.0; b = (int(b * 100.0)) / 100.0; c = (int(c * 100.0)) / 100.0; // not sure what you are trying to do here? Multiply by 100 then divide by 100 just gives 1. So might just scrap it? Serial.println(a); Serial.println(b); Serial.println(c); Serial.println(); delay(10）; }  
 
Improved code, using one function to get rid of duplication and read one sensor after the other:
const int left_Trig = 1; const int left_Echo = 2; const int center_Trig = 3; const int center_Echo = 4; const int right_Trig = 5; const int right_Echo = 6; float a; float b; float c; void setup() { Serial.begin(9600); pinMode(left_Trig, OUTPUT); pinMode(center_Trig, OUTPUT); pinMode(right_Trig, OUTPUT); pinMode(left_Echo, INPUT); pinMode(center_Echo, INPUT); pinMode(right_Echo, INPUT); Serial.println("Ultrasonic sensor:"); } void loop() { a = getEchoTime(left_Trig); // use a funtion here to get rid of the duplicate code b = getEchoTime(center_Trig); c = getEchoTime(right_Trig); Serial.println(a); Serial.println(b); Serial.println(c); Serial.println(); delay(10）; } float getEchoTime(int channel) { digitalWrite(channel, LOW); delayMicroseconds(2); // turn channel of, and wait digitalWrite(channel, HIGH); delayMicroseconds(10); // turn channel on, then wait 10µs digitalWrite(channel, LOW); // turn off, total pulse time 10µs return pulseIn(channel + 1, HIGH) / 58.00; // use +1 here, as the echo channel seems to be trigger channel + 1 }

An even better way would be to use interrupts (either external or pinchange) as this would allow you to fire the pulse and then do something else while waiting for the echo. I'm sure there are plenty of tutorials out there on how to read ultrasonic sensors in arduino without blocking.
 
 

Reason I do that is that I've used this technique to backup (or obliterate) full OS images. If I rsync from an image that doesn't have that new directory, it'll wipe out the mount.
 
If I have the mount in a tmpfs at a known location, that shouldn't happen.

Make your changes to the image before you call rsync? /dev/shm/original is mounted rw unless you tell it otherwise.
 
 
You monster

Success!
 

% uname -a Linux miki 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux % dpkg -l | grep -v ^rc | grep -E "linux-dtb-current|linux-image-current" ii  linux-dtb-current-rockchip64            21.02.3                              arm64        Linux DTB, version 5.10.21-rockchip64 ii  linux-image-current-rockchip64          21.02.3                              arm64        Linux kernel, version 5.10.21-rockchip64   % aplay -l **** List of PLAYBACK Hardware Devices **** xcb_connection_has_error() returned true card 0: realtekrt5651co [realtek,rt5651-codec], device 0: ff890000.i2s-rt5651-aif1 rt5651-aif1-0 [ff890000.i2s-rt5651-aif1 rt5651-aif1-0]   Subdevices: 0/1   Subdevice #0: subdevice #0 card 1: hdmisound [hdmi-sound], device 0: ff8a0000.i2s-i2s-hifi i2s-hifi-0 [ff8a0000.i2s-i2s-hifi i2s-hifi-0]   Subdevices: 1/1   Subdevice #0: subdevice #0   % grep -iE "name|linux|version" /etc/armbian-release BOARD_NAME="NanoPi M4V2" DISTRIBUTION_CODENAME=focal VERSION=21.02.3 LINUXFAMILY=rockchip64
 
Patched .dts:

--- a/dt-bindings/clock/rk3399-cru.h +++ b/dt-bindings/clock/rk3399-cru.h @@ -19,6 +19,7 @@  #define ARMCLKB                9  /* sclk gates (special clocks) */ +#define SCLK_I2SOUT_SRC        64  #define SCLK_I2C1            65  #define SCLK_I2C2            66  #define SCLK_I2C3            67 diff --git a/rk3399-som-rk3399v2.dts b/rk3399-som-rk3399v2.dts index 2626e27..6c708f8 100644 --- a/rk3399-som-rk3399v2.dts +++ b/rk3399-som-rk3399v2.dts @@ -75,6 +75,35 @@              };          };      }; + +    rt5651_card: rt5651-sound { +        status = "okay"; +        compatible = "simple-audio-card"; +        pinctrl-names = "default"; +        pinctrl-0 = <&hp_det>; + +        simple-audio-card,name = "realtek,rt5651-codec"; +        simple-audio-card,format = "i2s"; +        simple-audio-card,mclk-fs = <256>; +        simple-audio-card,hp-det-gpio = <&gpio4 28 GPIO_ACTIVE_HIGH>; + +        simple-audio-card,widgets = +            "Microphone", "Mic Jack", +            "Headphone", "Headphone Jack"; +        simple-audio-card,routing = +            "Mic Jack", "micbias1", +            "IN2P", "Mic Jack", +            "IN3P", "Mic Jack", +            "Headphone Jack", "HPOL", +            "Headphone Jack", "HPOR"; + +        simple-audio-card,cpu { +            sound-dai = <&i2s1>; +        }; +        simple-audio-card,codec { +            sound-dai = <&rt5651>; +        }; +    };  };    // root/ node  &vcc3v3_sys { @@ -114,3 +143,44 @@          };      };  }; + +&i2c1 { +    status = "okay"; +    i2c-scl-rising-time-ns = <300>; +    i2c-scl-falling-time-ns = <15>; +    clock-frequency = <200000>; + +    rt5651: rt5651@1a { +        #sound-dai-cells = <0>; +        compatible = "realtek,rt5651"; +        reg = <0x1a>; +        clocks = <&cru SCLK_I2S_8CH_OUT>; +        clock-names = "mclk"; +        status = "okay"; +    }; +}; + +&i2s1 { +    assigned-clocks = <&cru SCLK_I2SOUT_SRC>; +    assigned-clock-parents = <&cru SCLK_I2S1_8CH>; +    pinctrl-names = "default"; +    pinctrl-0 = <&i2s_8ch_mclk>,<&i2s1_2ch_bus>; +    rockchip,playback-channels = <2>; +    rockchip,capture-channels = <2>; +    #sound-dai-cells = <0>; +    status = "okay"; +}; + +&pinctrl { +    i2s1 { +        i2s_8ch_mclk: i2s-8ch-mclk { +            rockchip,pins = <4 RK_PA0 1 &pcfg_pull_none>; +        }; +    }; + +    headphone { +        hp_det: hp-det { +            rockchip,pins = <4 28 RK_FUNC_GPIO &pcfg_pull_up>; +        }; +    }; +};
 
Funny thing is that clk_parent will change after audio player is started:

% cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent clk_i2s1 % mpv <audiofile> % cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent clk_i2s0

But in both cases sound works on my SoM-RK3399v2 SBC :)

I was able to successfully build and run PREEMPT_RT with a current kernel running Ubuntu focal on a nanopineo, getting these results in cyclictest:
sudo cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 1.41 1.40 1.11 1/154 3261 T: 0 ( 3242) P:80 I:200 C:4589037 Min: 18 Act: 30 Avg: 25 Max: 125 T: 1 ( 3243) P:80 I:200 C:4588573 Min: 17 Act: 23 Avg: 26 Max: 105 T: 2 ( 3244) P:80 I:200 C:4588088 Min: 18 Act: 32 Avg: 27 Max: 111 T: 3 ( 3245) P:80 I:200 C:4587408 Min: 18 Act: 30 Avg: 25 Max: 105  
Steps to build your own:
 
1. Build a normal armbian image, using current kernel and ubuntu focal for nanopineo (or your board), mostly to discover the full kernel version that gets built.  Note that, as is mentioned in this thread, the AllWinner-based boards do not get their code from the mainline Linux github repo, but rather from a forked repo at https://github.com/megous/linux/.  This repo is specified in ~/build/config/sources/families/include/sunxi_common.inc.  You do not need to make any changes to that file, I'm just noting it as an FYI.
./compile.sh BOARD=nanopineo BRANCH=current RELEASE=focal KERNEL_ONLY=no BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_CONFIGURE=no AUFS=no  
2. Check the kernel version from the build output.  Currently, that version is 5.10.21.  Download the PREEMPT_RT patch that most closely matches the kernel version.  NOTE: maybe you can download *any* RT patch file version that's at least the same or newer, but I went with the same because it makes sense to me:
cd build/userpatches/kernel/sunxi-current # You'll probably have to mkdir the sunxi-current folder the first time wget https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.10/older/patch-5.10.21-rt34.patch.gz gunzip patch-5.10.21-rt34.patch.gz  
3.  Build another armbian image, this time with an extra parameter, EXTRAWIFI=no.  I've discovered that the patch-5.10.xx-rtYY.patch files somehow cause at least one of the Realtek Wifi drivers to throw a compiler error (in the rt_spinlock code).  If you need Realtek Wifi (and any other Wifi built by EXTRAWIFI=yes, you'll have to find another solution.  Sorry.
 
Also, I now set KERNEL_CONFIGURE=yes because I think that it won't let  you choose "Full PREEMPT_RT" without you setting KERNEL_CONFIGURE=yes.  So when prompted during the build, choose option 4 (full PREEMPT):
./compile.sh BOARD=nanopineo BRANCH=current RELEASE=focal KERNEL_ONLY=no BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_CONFIGURE=yes AUFS=no EXTRAWIFI=no  
4. From there, just deploy the image like you do any other image.
uname -a Linux nanopineo 5.10.21-rt34-sunxi #trunk SMP PREEMPT_RT Sun Apr 18 22:21:06 EDT 2021 armv7l armv7l armv7l GNU/Linux  
Note that I also created a ~/build/userpatches/lib.config file that limited the CPU frequency to a paltry 480Mhz fixed value because I don't have a heat sink on the H3:
GOVERNOR=performance CPUMIN=480000 CPUMAX=480000  
 
Q: Is this possible with the legacy kernel?
A: Probably, if you use EXTRAWIFI=no, but I haven't tested it.  Both legacy and current kernels had compiler failures for various reasons, but most frequently with RealTek.
 
Q: Will this work for any AllWinner SoC?
A: I'm pretty sure that any H2/H3 AllWinner will work, as they are the same chipset as the nanopineo I'm using.  I don't know about H5 or A-series.
 
Q: I thought tparys told you that any version of PREEMPT_RT might not give you the determinism you need to read wiegand?
A: Yes, and I still agree, but this was just bugging me that I couldn't successfully build one.
 

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.

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.

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

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

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?