going

@Maksimarm What do you mean by that? Can you explain it in an expanded form?

There is not enough space on the disk that is mounted in the /boot folder. df -h ls -al /boot this will give you a hint

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, Frederick. Will you be able to explain a little. Why exactly this configuration. Based on the information you provided, I would do the following: 1) Make a standard "Armbian" image for the selected Operating system. 2) Record the image on the SD card. 3) Check the quality of work by booting from the SD. 4)For training, insert a USB-CD adapter with a clean SD card into the USB. 5) Using only the command line and the command (fdisk or parted) to create a partition table and create the required number of partitions. Write down the sequence of actions in a text file. This will serve as a template for writing a script. 6) Format the partitions to the selected file system using /usr/sbin/mkfs.FSTYPE 7) To manipulate the LVM partition, use the command '/usr/sbin/lvm'. Write down the sequence of actions in a mylvm text file in which the first line will contain: #!/usr/sbin/lvm Details in 'man lvm' The lvm command represents its own shell with its own set of commands, so a separate script is needed for it. You can call it at the required stage in your main BASH script. Write the main BASH script and check if it works correctly.

If you use this instruction, you will get branches in the repository named: megi/orange-pi-6.4 megi/orange-pi-6.5 megi/orange-pi-6.6 These branches are the result of combining 27 branches with the corresponding branch kernel.org the repository. If you extract one of these branches to the working directory and extract the difference as a series of patches with the command "git format-patch v6.5.7..HEAD -o /path/to/tmpdir" you will get more than 600 files. These patch files are already available in the build system. All megi patches in tree patch/kernel/archive/sunxi-6.5/series.megous But only those necessary for sunxi are used. The minus (-) sign in the first position indicates that the patch file is not applied and does not adapt to the current version. Copy the patches.megous folder and the series.megous file somewhere, for example: mkdir -p patch/kernel/archive/megi-6.5 cp patch/kernel/archive/sunxi-6.5/series.megous patch/kernel/archive/megi-6.5/ cp -r patch/kernel/archive/sunxi-6.5/patches.megous patch/kernel/archive/megi-6.5/ cp patch/kernel/archive/megi-6.5/series.megous patch/kernel/archive/megi-6.5/series.conf Delete all minus (-) signs in the patch/kernel/archive/megi-6.5/series.conf file. After that, you have to adapt the patches to the current kernel version yourself. Apply them to the git repository as the "git am" command in the sequence order in the series file. When the work is finished and all the patches are applied, you will be able to extract them using a mk_format_patch script. Specify an existing patch/kernel/archive/megi-6.5/patches.megous folder to extract. The changed patches will be replaced. P.S. All other questions please in a personal conversation.

"OMV" is strictly tied to the Debian distribution version. This is written in the documentation. https://docs.openmediavault.org/en/6.x/releases.html#releases

Please don't make sense of it. Take care of your health. Just build the kernel with your configuration. Developer-Guide_Build-Preparation/#executing-any-bash-statement If you need to make kernel debugging symbols or utilities, you will have to abandon the build system and build the kernel in the traditional way.

I am not an expert on "OMV". Sorry. installation/on_debian - Use this documentation if "armbian-config" fails.

The key here is to mount the system folders /dev, /sys, /proc and enter the chroot environment using the chroot command. Mount the disk you need. If there is a separate boot partition, mount it in the /mnt/system/boot folder as well. Then these commands: 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/ As a result, you will get a full command prompt with superuser rights and any system commands for you will be executed correctly. Update the apt cache. Install, reinstall the packages, including the headers of the new\other kernel. Enable or disable system services. Recompile your custom applications.....

Alternatively, you can use a driver to emulate SPI on free pins (spi-gpio), if this driver is available in the kernel. This is a slow driver. But complete freedom.

@Gunjan Gupta You are, as always, the very courtesy! Provided a link to the documentation. From which follows: 26 pins | pin name | function | -------------------------------| 3 | PH5 | spi1-cs0 ?| 19 | PH7 | spi1-mosi | 21 | PH8 | spi1-miso | 23 | PH6 | spi1-clk | 24 | PH9 | spi1-cs0 ?| 26 | PC10 | spi1-cs1 | ------------------------------- But this scheme says that the pins are divorced somewhere else. GPIO ASSIGNMENT (4) The first thing that came to my mind was to take a soldering iron in my hands and .....

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.

orange-pi-pc-hdmi-lcd-mpi3508-touchscreen-spi-move-cs-from-pin-24-to-pin-22 You have just set up this touchscreen display for another device. This is a fact. See the schematic diagram for this new device. Perhaps SPI1 is already divorced on the board and connected to the memory chip? Use my suggestions and do it by analogy. I'm sure you can handle it.

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.

An ambiguous situation. I wouldn't deal with this core. Today v6.1.55. Try to build this version yourself. You must first check the correctness of the application of patches.

Information on your screen. But I can't read it. Something in the core.

function = "gpio_out";

Look very carefully at fragments 1,2,3. It can be only one fragment0, which does not use the same pins (PA7 PC7) to describe different functions. In a couple of days, my screen will reach the nearest post office. I will be able to test it on a real stand and describe step by step how to connect three devices to one SPI.

If I understood this code correctly, drivers/input/touchscreen/ads7846.c#L985 which returns your error, it believes that the touch is not connected. This pin must be configured <1> gpio active low. When the touch of the display is connected, there should be a voltage on the IRQ pin and when a touch occurs, the touch lowers the voltage, thereby signaling an event.

Will you be able to photograph a section of the printed circuit board. Where is the chip soldered and the tracks that are connected to the pins?

@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.

In your version of the dts overlay, this pin is not described. In this case, you must explicitly register it here. Must be /dev/fb0 Check whether the SPI interface has been created in the /sys file system and the status of the pin that is connected to the LED display. Or simply connect the pin of the LED display with 3.3v for the duration of the experiments. P.S. Other variables that drivers can accept are not known to me for certain. This remains for your experiments. A similar device is just coming to my address. I will post my working version upon arrival.