going

You can try it. But you'd better wait. I'll do it on my own soon. Unfortunately, I have not found support in the 6.12 kernel for this device. drivers/gpu/drm/panel/Makefile:22:obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o drivers/gpu/drm/panel/Makefile:23:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o drivers/gpu/drm/panel/Makefile:24:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9805) += panel-ilitek-ili9805.o drivers/gpu/drm/panel/Makefile:25:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9806E) += panel-ilitek-ili9806e.o drivers/gpu/drm/panel/Makefile:26:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o drivers/gpu/drm/panel/Makefile:27:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9882T) += panel-ilitek-ili9882t.o .... drivers/gpu/drm/tiny/Kconfig:123: If M is selected the module will be called ili9163. drivers/gpu/drm/tiny/Kconfig:135: If M is selected the module will be called ili9225. drivers/gpu/drm/tiny/Kconfig:148: If M is selected the module will be called ili9341. drivers/gpu/drm/tiny/Kconfig:162: If M is selected the module will be called ili9486. drivers/gpu/drm/tiny/Makefile:11:obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o drivers/gpu/drm/tiny/Makefile:12:obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o drivers/gpu/drm/tiny/Makefile:13:obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o drivers/gpu/drm/tiny/Makefile:14:obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o .... drivers/staging/fbtft/Makefile:13:obj-$(CONFIG_FB_TFT_ILI9163) += fb_ili9163.o drivers/staging/fbtft/Makefile:14:obj-$(CONFIG_FB_TFT_ILI9320) += fb_ili9320.o drivers/staging/fbtft/Makefile:15:obj-$(CONFIG_FB_TFT_ILI9325) += fb_ili9325.o drivers/staging/fbtft/Makefile:16:obj-$(CONFIG_FB_TFT_ILI9340) += fb_ili9340.o drivers/staging/fbtft/Makefile:17:obj-$(CONFIG_FB_TFT_ILI9341) += fb_ili9341.o drivers/staging/fbtft/Makefile:18:obj-$(CONFIG_FB_TFT_ILI9481) += fb_ili9481.o drivers/staging/fbtft/Makefile:19:obj-$(CONFIG_FB_TFT_ILI9486) += fb_ili9486.o .... Maybe if you find a kernel patch to support this device, then I'll add it to the build system and we'll check it out.

Your processor is h616, which means you'll have to turn on everyone for h6, h616

On which platform did you launch the build system?

I will ask for a little more detail about this problem. Perhaps the translation was inaccurate.

Are we discussing this particular NVME here? If so, then publish the diagnostics from smartctl. This will help shed some light on some issues. There are two unpleasant moments here. 1) An old and actively used disk with a large number of failed memory cells. The internal disk controller will redistribute the exhausted memory cells from those used at the time of the write operation. Which greatly reduces the recording speed. Disk manufacturers warn about this. 2) The internal disk controller works well only for a few file systems such as FAT, NTFS, ISO. I have two such devices, a SD card and an SSD drive from Samsung. On EXT4 and BTRFS file systems, the speed of read and write operations is greatly reduced. This is my personal experience and this case is for devices that were manufactured in 2008, 2010.

This is the first step. This means that some patches have a negative effect on older processors. They need to be detected and corrected. I'll assemble another core and call you. Will you be able to continue testing?

Test what you need on core 6.12. If you have any questions or suggestions, just create a new topic and call me.

If you want to participate in testing the intermediate version, then add this branch to your build system: armbian/build> git remote add -t test-6.12 The-going https://github.com/The-going/armbian-build armbian/build> git fetch The-going armbian/build> git checkout -b test-6.12 The-going/test-6.12 # exclude patches armbian/build> egrep '^-' patch/kernel/archive/sunxi-6.12/series.conf # If you need them, just remove the minus sign

Orangepipc2-6.12-crust-mini I have excluded patches for h6 and newer processors. Just for the test.

Tomorrow I will post the download link and we will test the new kernel 6.12 I'm glad your board is in order.

Why do you use a stress test for NVME? Do you want its resource to run out faster? You can find out the status\information using the smartctl program. Example: old disk sudo smartctl --all /dev/sda ... === START OF INFORMATION SECTION === Device Model: SSD 512GB Serial Number: YS202010005170AA ... ATA Version is: ACS-2 T13/2015-D revision 3 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) ... 175 Program_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 117440512 176 Erase_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 2175044 177 Wear_Leveling_Count 0x0032 100 100 050 Old_age Always - 6113508 178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 050 Old_age Always - 1 181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 050 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 050 Old_age Always - 22 194 Temperature_Celsius 0x0032 100 100 050 Old_age Always - 40 195 Hardware_ECC_Recovered 0x0032 100 100 050 Old_age Always - 117242 ... a new disk sudo smartctl --all /dev/sdb ... === START OF INFORMATION SECTION === Device Model: SSD 128GB Serial Number: YS20211100077037 ... ATA Version is: ACS-2 T13/2015-D revision 3 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) ... 175 Program_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0 176 Erase_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0 177 Wear_Leveling_Count 0x0032 100 100 050 Old_age Always - 33617462 178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 050 Old_age Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 050 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 050 Old_age Always - 19 194 Temperature_Celsius 0x0032 100 100 050 Old_age Always - 40 195 Hardware_ECC_Recovered 0x0032 100 100 050 Old_age Always - 0 ...

I would probably try to write some old\minimal image to a new 8-16 Gb SD card. And see if this behavior will be repeated. Something tells me that it's not about the equipment. Alternatively, I can assemble an image for you without using some Armbian patches that provide functionality for the new h6, h616, h618 processors and crust firmware.

10 - 20 minutes is enough. I've come across this kind of behavior. One of the possible reasons is the SD card from the manufacturer SAMSUNG. I have a "fast" SD card if it is formatted as FAT32. If I format it into any other file system, it starts to work very very slowly. The built-in SD card controller cannot cope. P.S. It seems the problem is not with the card. If you download another operating system and it works.

By the way, it may also be the specifics of this particular board and/or this particular NVME disk manufacturer. If you want to deal with this problem, you need to build the EDGE kernel with a little more debugging options and publish the output here. Maybe we can see the reason and maybe someone can fix it.

@rmoriz You can also specify a string in the armbinanEnv.txt file: fdtfile=sun50i-h5-orangepi-pc2.dtb

Please download this already fixed script: boot-sun50i-next.cmd Saves it as /boot/boot.cmd # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Sorry for the inconvenience. The pull request is here: #7535

You can try to assemble the image yourself. How many minutes did you wait for the invitation at the first launch? Your SD card is 32GB. At the first launch, the script stretches the system partition over the entire card and this is a long process. What will the use of the Linux system utilities show if you insert the SD card into the USB-CD adapter and run the checks on another computer?

I understood perfectly well, but this functionality is necessary for mass deployment. Previously, this was used by lazy and smart system administrators when the task was to expand the number of new jobs. But there seems to be something different here. On which hardware devices does the author want to massively deploy operating systems?

The functionality of the armbian-install script is quite enough to meet your needs. But the community requests are a bit more than this script can handle. In addition, you will probably want to check how the system boots and works before deciding whether to install it on an internal drive.

This is not a viable option.

Do you mean that we need to make a boot image by analogy and similarity, as well-known distributions such as openSUSE, ubuntu do?

This will be a fork that will return the code to the parent project https://github.com/armbian/build ? Or is it planned to be developed as an independent project based on this branch?

@hexzhen3x7 This is grand planning worthy of a great warrior. Let me be curious. Do you represent the interests of the manufacturer?

There's only one way. You need to write these overlays yourself. Then compile them and put them in the target folder of overlays. After that, they will appear for selection in the configurator window. After you test them and be sure that they are correct, you can call me @going and publish the sources of these overlays here and I will add them to the build system.

This is an error in the build script. The discussion is here: issues/7456