going

Updated section on loop devices in systemd-nspawn container
https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35
Currently systemd-nspawn do not support loop devices needed in the compile.sh build. This section documents some workarounds to create loop devices in a systemd-nspawn container. Use this shell script to start systemd-nspawn
#!/usr/bin/bash sudo systemd-nspawn -b --capability=CAP_MKNOD \ --property=DeviceAllow="block-loop rwm" \ --property=DeviceAllow="block-blkext rwm" \ --property=DeviceAllow="/dev/loop-control rwm" \ -D /opt/armbian-build  
when the container is started up, in the shell within the container, use this shell script to create the loop devices
#!/usr/bin/bash if ! test -e /dev/loop-control; then sudo mknod /dev/loop-control c 10 237 fi for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do if ! test -e /dev/loop${i}; then sudo mknod /dev/loop${i} b 7 ${i} fi done  
In current tests, the above did create the loop devices, but is inadequate to fully resolve the issue with loop devices in armbian build compile.sh.

Perhaps it doesn't work. More resources / ideas / background:
https://www.google.com/search?q=blacklist+USB+UAS+armbian
https://www.cnx-software.com/2020/08/12/how-to-fix-unreliable-usb-hard-drives-stalled-transfers-linux-windows/
https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS)

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg and mpv compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs.
 
The repository introduces a new package ffmpeg-v4l2request that integrates and substitues the base ffmpeg package and its related packages.
Also provides mpv 0.35.1 for Ubuntu Jammy, which has an overrall better support for hardware video decoders.
 
Preconditions:
Kernel should be 6.1 or more recent armhf or arm64 architecture Supported operating systems are Debian Bookworm and Ubuntu Jammy Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel  
APT REPOSITORY SETUP
To install the repository, just copy and paste the lines for your operating system in a terminal
 
For Debian Bookworm:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/debian bookworm main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
For Ubuntu Jammy:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
INSTALL FFMPEG AND MPV PACKAGES
$ sudo apt update $ sudo apt install ffmpeg-v4l2request mpv  
SETUP MPV CONFIG FILE
$ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf  
You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows!
Enjoy!
 
Notes:
your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel) bug: when rendered in X11/Wayland window, video may show scattered tiles during frames bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968) Panfrost driver should work flawlessy 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that  
 
 

Please understand me correctly.
I don't see much need to change the installation script.
All other issues are general Linux administration issues and they are very well covered on the Internet.

Hello, Frédéric From France.
There are many questions here.
1) fault tolerance.
2) recovery after exiting the working state of the root file system.
 
(1) CD card, eMMC,  are all flash drives.
Technologically, they are different, but they all have a limited resource for recording.
Armbian tries to reduce the number of write transactions using the overlay file system.
In fact, system write transactions occur in a file located in RAM and are synchronized
with the real file system on the drive at longer intervals than the system ones.
 
(2) You want to place the entire root file system on an LVM partition whose type is linear.
In this case, you have to recreate the initrd to make it work.
And if your drive at the physical level starts to fail or the LVM partition is full, you get very big difficulties for data recovery.
 
packages/bsp/common/usr/sbin/armbian-install
This is a very simple script that makes a copy of the OS on your CD card from which you booted and work on an empty nand, SATA, eMMC or NVME.
 
Your drives are eMMC and NVME.
What would I do at the very beginning of the journey, when both drives are clean?
Boot from the SD card and install the system on eMMC.
Boot from eMMC. (for health check)
Mark up the NVME drive as LVM or as BTRFS. (The BTRFS file system will provide you with all the necessary functionality.)
Make logical partitions for target folders "/opt" "/var" "/srv" "/home".
Boot from the SD card and copy the contents of each target folder to the corresponding logical partition while retaining all rights for files.
Add the necessary mount entries in the /etc/fstab file located on the eMMC.
Boot from eMMC. You are the master of the situation!
 

Hello!
Using Debian packaged by the Olimex people (not Armbian, see their image here) I tried your 1-wire DTS plugin but it did not work.
Trying to understand why, I contacted the linux-sunxi developers who considered that your DTS plugin is outdated.
See the discussion here.
 
Their suggestions resulted in this DTS file that should work also on Armbian.
I did not make a pull request towards your overlay repository as I am not able to update the param_w1_pin_int_pullup setting code in the sun50i-a64-fixup.scr-cmd file.

The fourth point should look like this:
4.
$ sudo su root@helios64:~# mkdir -p /mnt/system root@helios64:~# mount /dev/mmcblk2p1 /mnt/system root@helios64:~# mount --bind /sys /mnt/system/sys root@helios64:~# mount --bind /proc /mnt/system/proc root@helios64:~# mount --bind /dev /mnt/system/dev root@helios64:~# mount --bind /dev/pts /mnt/system/dev/pts root@helios64:~# chroot /mnt/system/ .... ## install, reinstall ~# exit ## exit "chroot" ~# umount /mnt/system/dev/pts ~# umount /mnt/system/dev ~# umount /mnt/system/proc ~# umount /mnt/system/sys ~# exit ## exit "root user"  
If I understood correctly, booting from the system disk leads to periodic failure and reboot.
But loading from the SD card does not lead to such an effect? It is important. Please confirm or refute.
 
When loading occurs from the SD card, your raid array is not connected.
The disks were just determined and they are mounted as /dev/*.
The system does not access them (does not read or write). Energy consumption is at a minimum level.
When booting occurs from:
there may be short-term drawdowns of the supply voltage that lead to short-term inactivity of some chips
(resetting the clock, failure of the hard disk controller ....). Your operating system at the time of reading or
writing to the disk at the same time may be in the past or cannot read from the disk and as a result,
the failure stack is printed, each time different.
 
Fault repair:
1) Replace the watch battery on the board.
2) Open the power supply and look at the date of manufacture of the electrolytic capacitors of the output stage (they are the largest barrels in size).
If the age is more than 5 years, replace them with new ones.

I always have advice for such a case.
Download an image with an early kernel or\and later.
Write it to the SD card and boot from it.
If the operation of the device is stable, you will be able to mount your root partition from which the device is usually loaded
and in the chroot environment you will be able to reinstall a stable kernel that you have tested.
 

So, it is working!  It just wasn't working with my edge custom built image: Armbian_23.08.0-trunk_Orangepipc_bookworm_edge_6.5.5_minimal.img.
I reproduced my efforts on the latest armbian image Armbian_23.8.1_Orangepipc_bookworm_current_6.1.47.img and it is working as expected.
The display works and the touch events are working properly.  I changed my wiring to test swapping LCD and Touch.  Here is my working wiring chart:

1 - VCC     (1)  3.3v
2 - GND     (6)  GND
3 - CS         (24) PC3 SPI0 CS
4 - RESET     (26) PA21 GPIO 11
5 - DC         (31) PA8 GPIO 22
6 - SDI (MOSI)    (19) PC0 SPI0 MOSI
7 - SCLK    (23) PC2 SPI0 CLK
8 - LED        (33) PA9 GPIO 23
9 - SDO (MISO)    (21) PC1 SPI0 MISO
10 - T_CLK      (23) PC2 SPI0 CLK *
11 - T_CS       (18) PC7 GPIO 5
12 - T_DIN    (19) PC0 SPI0 MOSI *
13 - T_DO    (21) PC1 SPI0 MISO *
14 - T_IRQ    (29) PA7 GPIO 21
 
Here are steps to get the display working:
 
Install latest armbian image: Armbian_23.8.1_Orangepipc_bookworm_current_6.1.47.img
 
sudo armbian-config
 
enable desktop
 
sudo nano /boot/armbianEnv.txt
 
user_overlays=touchscreen
extraargs=fbcon=map:1
 
nano touchscreen.dts
 
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { spi0_cs1: spi0_cs1 { pins = "PC7"; function = "gpio_out"; output-high; }; opiz_display_pins: opiz_display_pins { pins = "PA21", "PA8", "PA9"; function = "gpio_out"; }; ads7846_pins: ads7846_pins { pins = "PA7"; function = "irq"; }; }; }; fragment@1 { target = <&spi0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-1 = <&spi0_cs1>; pinctrl-names = "default", "default"; cs-gpios= <0>, <&pio 2 7 0>; /* PC7 */ ads7846: ads7846@1 { reg = <0>; /* Chip Select 0 */ compatible = "ti,ads7846"; spi-max-frequency = <500000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&ads7846_pins>; interrupt-parent = <&pio>; interrupts = <0 7 2>; /* PA7 IRQ_TYPE_EDGE_FALLING */ pendown-gpio = <&pio 0 7 0>; /* PA7 */ /* driver defaults, optional */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0x0FFF>; ti,y-max = /bits/ 16 <0x0FFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0xFFFF>; ti,x-plate-ohms = /bits/ 16 <400>; }; opizdisplay: opiz-display@0 { reg = <1>; /* Chip Select 1 */ compatible = "ilitek,ili9341"; spi-max-frequency = <16000000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&opiz_display_pins>; rotate = <90>; bgr = <0>; fps = <10>; buswidth = <8>; dc-gpios = <&pio 0 8 0>; /* PA8 */ reset-gpios = <&pio 0 21 1 >; /* PA21 */ led-gpios=<&pio 0 9 0>; /* PA9 */ debug=<0>; }; }; }; };  
sudo armbian-add-overlay touchscreen.dts
 
sudo nano /etc/modules-load.d/fbtft.conf
 
fbtft
fb_ili9341
 
sudo nano /usr/share/X11/xorg.conf.d/99-fbdev.conf
 
Section "Device"
  Identifier "myfb"
  Driver "fbdev"
  Option "fbdev" "/dev/fb1"
EndSection
 
reboot and your display and touch should work!

I'm getting closer - I finally got the touch and display to initialize.  The trick is determining which GPIO pins can be used and which support interrupts.
Here is the pinout and connection diagram I am using:

1 - VCC     (1)  3.3v
2 - GND     (6)  GND
3 - CS         (24) PC3 SPI0 CS
4 - RESET     (29) PA7 GPIO 21
5 - DC         (31) PA8 GPIO 22
6 - SDI (MOSI)    (19) PC0 SPI0 MOSI
7 - SCLK    (23) PC2 SPI0 CLK
8 - LED        (33) PA9 GPIO 23
9 - SDO (MISO)    (21) PC1 SPI0 MISO
10 - T_CLK      (23) PC2 SPI0 CLK *
11 - T_CS       (26) PC7 GPIO 5
12 - T_DIN    (19) PC0 SPI0 MOSI *
13 - T_DO    (21) PC1 SPI0 MISO *
14 - T_IRQ    (18) PA21 GPIO 11 (Supports interrupt)
 
DTS that is working
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { spi0_cs1: spi0_cs1 { pins = "PC7"; function = "gpio_out"; output-high; }; opiz_display_pins: opiz_display_pins { pins = "PA7", "PA8", "PA9"; function = "gpio_out"; }; ads7846_pins: ads7846_pins { pins = "PA21"; function = "irq"; }; }; }; fragment@1 { target = <&spi0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-1 = <&spi0_cs1>; pinctrl-names = "default", "default"; cs-gpios= <0>, <&pio 2 7 0>; opizdisplay: opiz-display@0 { reg = <0>; /* Chip Select 0 */ compatible = "ilitek,ili9341"; spi-max-frequency = <16000000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&opiz_display_pins>; rotate = <90>; bgr = <0>; fps = <10>; buswidth = <8>; dc-gpios = <&pio 0 8 0>; /* PA8 */ reset-gpios = <&pio 0 7 1 >; /* PA7 */ led-gpios=<&pio 0 9 0>; /* PA9 */ debug=<4>; }; ads7846: ads7846@1 { reg = <1>; /* Chip Select 1 */ compatible = "ti,ads7846"; spi-max-frequency = <2000000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&ads7846_pins>; interrupt-parent = <&pio>; interrupts = <0 21 2>; /* PC7 IRQ_TYPE_EDGE_FALLING */ pendown-gpio = <&pio 0 21 0>; /* PC7 */ /* driver defaults, optional */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0x0FFF>; ti,y-max = /bits/ 16 <0x0FFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0xFFFF>; ti,x-plate-ohms = /bits/ 16 <400>; }; }; }; };
Using this configuration I get the following from dmesg:
 
[    6.231015] fbtft: module is from the staging directory, the quality is unknown, you have been warned.
[    6.234683] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned.
[    6.235590] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System...
[    6.235823] fb_ili9341 spi0.0: fbtft_property_value: buswidth = 8
[    6.235857] fb_ili9341 spi0.0: fbtft_property_value: debug = 4
[    6.235870] fb_ili9341 spi0.0: fbtft_property_value: rotate = 90
[    6.235892] fb_ili9341 spi0.0: fbtft_property_value: fps = 10
[    6.573436] fb_ili9341 spi0.0: Display update: 1787 kB/s, fps=0
[    6.574355] Console: switching to colour frame buffer device 40x30
[    6.575115] graphics fb1: fb_ili9341 frame buffer, 320x240, 150 KiB video memory, 16 KiB buffer memory, fps=10, spi0.0 at 16 MHz
[    8.471370] SPI driver ads7846 has no spi_device_id for ti,tsc2046
[    8.471402] SPI driver ads7846 has no spi_device_id for ti,ads7843
[    8.471410] SPI driver ads7846 has no spi_device_id for ti,ads7845
[    8.471417] SPI driver ads7846 has no spi_device_id for ti,ads7873
[    8.471620] ads7846 spi0.1: setup mode 0, 8 bits/w, 2000000 Hz max --> 0
[    8.471794] ads7846 spi0.1: supply vcc not found, using dummy regulator
[    8.481255] systemd[1]: Finished systemd-binfmt.service - Set Up Additional Binary Formats.
[    8.486590] ads7846 spi0.1: touchscreen, irq 62
[    8.501181] input: ADS7846 Touchscreen as /devices/platform/soc/1c68000.spi/spi_master/spi0/spi0.1/input/input2
 
I try touching the screen, but I'm not set up to use the new touch device as the main input yet.
I think I'm very close to getting this display operational.
 
running everest I get the following:
everest
'No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event0: gpio-keys
/dev/input/event1: sunxi-ir
/dev/input/event2: ADS7846 Touchscreen
/dev/input/event3: BRLTTY 6.5 Linux Screen Driver Keyboard
 
evtest --grab /dev/input/event2
Input driver version is 1.0.1
Input device ID: bus 0x1c vendor 0x0 product 0x1ea6 version 0x0
Input device name: "ADS7846 Touchscreen"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 330 (BTN_TOUCH)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      0
      Min        0
      Max     4095
    Event code 1 (ABS_Y)
      Value      0
      Min        0
      Max     4095
    Event code 24 (ABS_PRESSURE)
      Value      0
      Min        0
      Max    65535
Properties:
Testing ... (interrupt to exit)
Event: time 1695777743.332287, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1695777743.332287, type 3 (EV_ABS), code 0 (ABS_X), value 562
Event: time 1695777743.332287, type 3 (EV_ABS), code 1 (ABS_Y), value 2228
Event: time 1695777743.332287, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 64919
Event: time 1695777743.332287, -------------- SYN_REPORT ------------
Event: time 1695777743.340652, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1695777743.340652, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 0
Event: time 1695777743.340652, -------------- SYN_REPORT ------------
Event: time 1695777762.428725, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1695777762.428725, type 3 (EV_ABS), code 0 (ABS_X), value 21
Event: time 1695777762.428725, type 3 (EV_ABS), code 1 (ABS_Y), value 3185
Event: time 1695777762.428725, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 65502
Event: time 1695777762.428725, -------------- SYN_REPORT ------------
Event: time 1695777762.440670, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1695777762.440670, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 0
Event: time 1695777762.440670, -------------- SYN_REPORT ------------
 
I'm getting touch events.  I still need to find out how to set the touch device as the default pointer.
 
After testing and trying to get the touch working consistently I've come to the conclusion the interrupt is not working as expected.
I can hook my device up to a scope and every touch will cause a drop in the pen down pin, but I don't see a corresponding drop in CS1 pin to SPI activity to get the touch data.  Every now and then it will query the touch device in response to a touch event, but it does it only after repeated touch & move operations.  I don't see a way to turn on debugging for the touch module, so it is difficult to determine where the problem is.  Anyone else see this behavior?

function = "gpio_out";

Only after the "Apple" is renamed. It has nothing to do with the production of agricultural products.

@lalakii is In Armbian for chips, allwinner uses only a branch with kernel.org . There is no special branch for a separate chip.
 
There is a series of patches that were taken from different places or made by different users and added to the series file.
The binary files that you kindly provided are useless for the build system.
Links to download from Google drive are also not useful.
All you need is to apply a series of patches to the corresponding kernel branch as a "git am" command.
Then make your comments on top with explanations and an indication of the author. Then extract these last commits using a script.
cp armbian/build/tools/mk_format_patch $USER/bin; chmod +x $USER/bin mkdir -p $USER/tmpwork/patches.armbian cd /path/to/linux-stable mk_format_patch . HEAD~7..HEAD $USER/tmpwork/patches.armbian I think that you have guessed where they need to be placed, make a commit in the build system itself and make a pull request.

Usually provide a difference file.
Please, if you want to share the results of your work, make a set of patches as the output of the "git format-patch" command.
Or a more time-consuming but faster way to make a pull request directly to the project on github.

Only after the "Apple" is renamed. It has nothing to do with the production of agricultural products.

After a few days of trying to get rid of these annoyances by modifying the kernel source code as well as the device tree, I've finally gotten rid of them, and now there are only a few inconsequential warnings

Great advice.  I made the switch to the latest Armbian image
 
Armbian_23.8.1_Orangepipc_bookworm_current_6.1.47
 
I was in the process of applying what I've done so far. Enabling dual SPI with the spi-double-spidev-cs user overlay does not work in this image (it didn't work on the other image properly either)
I'll check out the binaries listed above and see if I can make them work for me.
Thanks for all the advice!  If I get it working, I'll paste a tutorial.

Hello Everyone,
As I am still working on hardening my Odroid-M1 servers, I am looking for a solution to activate a real console for root login only. My homelab is not in the same room as my desk, so I need to get access from an internal VLAN with restrictions and take control even if the network drivers are not enabled. Have you tested or used a UART to Ethernet converter like https://www.pusr.com/products/ethernet-to-uart-modules-usr-k7.html
or
https://www.waveshare.com/uart-to-eth.htm
 
or something else?
 
Let me know your thoughts.
 
Sincerely, Frederic

Maybe you can keep your blog here and interested people will join. I'm one of them.

5.19.0-1015-allwinner riscv64

Just build EDGE or install the EDGE kernel ready to confirm or refute my assumptions.
 
P.S. BRANCH=edge
Today it is the core v6.4.8

Did further play around with ffmpeg and v4l pipeline.
This now WORKS also 6.4.8-sunxi  (Armbian_23.08.0-trunk_Nanopiduo2_jammy_edge_6.4.8_minimal  build from 07-Aug)
v4l2-ctl --device /dev/video1 --set-fmt-video=width=1280,height=720,pixelformat=YUYV media-ctl --device /dev/media1 --set-v4l2 '"ov5640 2-003c":0[fmt:YUYV8_2X8/1280x720]' ffmpeg -i /dev/video1 -q 10 -pix_fmt yuv420p -video_size 1280x720 -r 5 -listen 1 -f avi http://192.168.179.55:8080/stream VLC http://192.168.179.55:8080/stream ffmpeg is  version 4.4.2-0ubuntu0.22.04.1
 
This means, there was a problem "behind the scenes" in 6.1x  which is now fixed.
Other parameters which did work in the past and now failing might be a side effect of internal improvments.
I'll figure out anyway because this kernel now also contains the cedrus video engine and I want to use that for encoding and decoding.
 
So from my point of view the issue is solved.
 
@going the highest resolution 2592x1944 did work in friendlycore xenial 4.14 so the driver WAS able to do so.
Don't know yet if something is now broken - but as said above need to play around anyways.
 
 
Thanks @all!
 
    Thilo
 

Finally I made it! Thanks a lot for the help but it was something else. The final overlay is the next one:
 
/dts-v1/; /plugin/; / { compatible = "allwinner,d1-nezha\0allwinner,sun20i-d1"; fragment@0 { target-path = "/clocks"; __overlay__ { #address-cells = <1>; #size-cells = <1>; /* External crystal oscillator on the board */ can0_osc_fixed: can0_osc_fixed { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <8000000>; phandle = <0x81>; }; }; }; fragment@1 { target = <&pinctrl>; // pinctrl@2000000 __overlay__ { can0_pin_irq: can0_pin_irq { pins = "PD17"; function = "irq"; phandle = <0x85>; bias-pull-up; }; }; }; fragment@2 { target = <&spi>; //spi@4026000 __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; mcp2515 { reg = <0>; // SPI 1 compatible = "microchip,mcp2515"; pinctrl-names = "default"; pinctrl-0 = <0x85>; spi-max-frequency = <10000000>; interrupt-parent = <0x22>; // pinctrl@2000000 interrupts = <3 17 8>; // IRQ LINE, try with <0 65 2> clocks = <0x81>; status = "okay"; }; }; }; };  
I learnt some things about the interrupts field:
* The part of interrupts is like this, <BANK NUMBER TYPE_INTERRUPT>
* BANK is like, A -> 0, B-> 1, C->2, D->3
* NUMBER, PD17 -> 17
* TYPE_INTERRUPT, is described here

Alright. some progress on testing.
 
Tried rtcwake command, that gave me a write error I will see what caused this later. My board doesn't have hdmi, so hdmi-cec is out of picture. That leaves me with IR, but the board doesn't have inbuilt IR receiver, but has some gpio pin to interface one. I didn't had an IR receiver so have ordered it and it will likely arrive by Monday.
 
Meanwhile, I enabled DEBUG_MONITOR in the crust config and used that for testing. This gave me access to debug terminal for crust when linux is suspended or powered off.
I ran systemctl suspend that stopped linux and dropped me to crust debug console. I pressed w on the crust debug console and it brought back linux from suspended state. I powered off Linux and that too dropped me off to crust debug console. I pressed w and it rebooted the board. So I guess its working the way it was expected.
 
I will also test if the system resumes on IR once that arrives and will try to debug why rtcwake command is not working.

@royk I already realized that this is not your snapshot of the test. I am reading this post listed in the link.
 
Rod wrote about my repository.
This is currently in development and not finished.
In the final version, this branch will collect an image with a real-time kernel and linuxcnc + a certain number of libraries and settings necessary for work. All in one build system.
When I am ready, I will join your company on the linuxcnc forum.
 
It looks like the truth.