going

Can you use @Nick A instructions?

It seems this shitty utility should be redesigned for better user use.

RTL8211F try to make an analogy with bananapi-m4-berry node for this chip. arch/arm64/boot/dts/allwinner/sun50i-h618-bananapi-m4-berry.dts

@Meestor_X Please check the following: on a running device. It seems that we have a more reliable way to determine the block device SD or eMMC

PR for these changes: https://github.com/armbian/build/pull/8734

Sorry, I don't have this device. Try inserting a USB flash drive into the USB connector and installing the OS from the SD card on it. Try the available options. And choose focusing on your own real logic. Of particular interest and attention if you install the OS on eMMC. Then boot from the eMMC without an SD card connected. And then insert the card into the SD connector and run $HOME/bin/armbian-install. What do you see in the selection window?

see: /usr/bin/armbian-install The create_armbian function takes different arguments depending on the selection number. Everything looks right on this selection screen. But it seems to me that we see an excessive selection offer in the next selection step and this is misleading. But on other platforms where loading is possible only from a soldered chip, which is defined by the kernel as /dev/mtd, the selection screen will look logical. Try installing the OS on an eMMC or on an SSD connected to the device via a USB-SATA adapter using various options. Experiment. If you find illogical options, then feel free to write your opinion here.

Copy armbian-install to bin home directory Please replace line 839 as indicated here: Run the corrected version of the script. If everything works correctly for you, confirm it here. I will add a correction to the next pull request.

Please show screenshots of the selection menu step by step when you are trying to install the OS on eMMC. Show me what you see that I cannot see.

On 99% of the devices I know, eMMC is initialized in the OS as /dev/mmcblk0, but there are cases when this is not the case. # find real mmcblk device numbered 0, 1, 2 for eMMC, SD for ret in $(find /dev -name 'mmcblk[0-2]' -and -type b) do if [ -b ${ret}boot0 ];then emmc_dev=$ret else sd_dev=$ret fi done This part of the code was implemented due to the fact that on some eMCC platforms there can be both /dev/mmsblk0 and /dev/mmcblk1(2) This works for chips that provide boot0\boot1 partitions to write the bootloader. I think we can add more sophisticated logic to handle this exception for these chips. You can add here the name of the chip on your device. The translation may not be accurate. Please specify if something is not clear.

Is this your SD card? This is your eMMC just 3.6G in size. This is the first time I have met this variant. We need to think about whether it is possible to add an exception for this case.

Please post the output of the df -h and lsblk commands here. Which image are you using and which version of u-boot is running on your board? (this can be seen in the UART console)

Please tell me the source of this patch.

I'm not sure what this adds? I saw a user struggling to get it working, I managed to get it working, so thought I would give my steps that they may help other people. I apologize. I have not read what you wrote earlier. Please write whatever you see fit your work can be very useful. Success to you in your endeavor.

dmesg | grep -E 'hdmi|gpu|drm' ?

What can be said about this (help)? Answer: nothing. Please show the output of the UART download, show the source code of the overlay you are using. By reading specific data, users will be able to give you advice.

Please specify which OS and kernel version. By the way, I recommend building EDGE yourself.

Each attached memory disk must have its own unique UUID. This is its essence. This depends on the platform (BROM bootloader flashed into the chip) and possibly the switch soldered to the board.

There are three ways to do this. The first simplest is to assemble a binary debian package using the Armbiyan assembly system and then convert it to a rpm package directly in a running OpenSuse OS. The second way is more complicated but it is more correct. You can take patches directly from the build system and apply them to OpenSuse kernel sources in the sequence in which the build system does this while running. Next, build the kernel package using rpmbuild. The third way is the same as the second but use OBS. This will allow you to have your own repository of signed packages and install them using zypper. You can find like-minded people anywhere on our planet, including this place. Hope this helps you.

This is similar to physical damage to the SD card

Please read the documentation on the manufacturer's website (radxa). It really works.

If you want to find a request, please publish the UART log. maybe after that we can say recommendations.

./compile.sh And choose this:

UART console log? In fact, only the u-boot version and the kernel version are interested. On my devices with rk3588 (s) chips, old versions of u-boot were originally installed and they did not allow loading Armbian images. I used the instructions from the manufacturer's official website and recorded the bootloader provided by Armbian on the SPI chip using special software. In other words, Armbian delivers his images from u-boot v2025.XX but my orangepi5plus was loaded using u-boot v2019 recorded on an SPI chip. And that may be the problem. After overwriting the new version, my device loads any images and PCI (NVME) devices register correctly. I checked several of these from different manufacturers. Hope this information helps with your problem.

Today it is EDGE v6.15 no v6.16.