

going
Members-
Posts
831 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Everything posted by going
-
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.
-
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.
-
Please tell me the source of this patch.
-
Install openVFD for LCD display on recent (6.12) kernels - Tutorial
going replied to torz77's topic in Reviews / Tutorials
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' ?
-
Install openVFD for LCD display on recent (6.12) kernels - Tutorial
going replied to torz77's topic in Reviews / Tutorials
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.
-
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.
-
-
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.
- 23 replies
-
- Orange Pi Zero
- Orange Pi Zero 2
-
(and 1 more)
Tagged with:
-
Recommended to upgrade U-Boot to version v2025.07 This version has big changes for allwinner (sunxi) chips. This concerns the initialization of a non-standard size of RAM (1.5; 2.5 GB), downloads from eMMC.....
- 23 replies
-
1
-
- Orange Pi Zero
- Orange Pi Zero 2
-
(and 1 more)
Tagged with:
-
Yes, that's right. This is relevant to the issue under discussion.
- 23 replies
-
- Orange Pi Zero
- Orange Pi Zero 2
-
(and 1 more)
Tagged with:
-
H3 cedrus video acceleration, device tree problem?
going replied to schunckt's topic in Allwinner sunxi
Which OS works well for you? -
H3 cedrus video acceleration, device tree problem?
going replied to schunckt's topic in Allwinner sunxi
v5.1-rc5 v6.12.35 Please use the current documentation for the CURRENT kernel. sun4i-a10-video-engine.yaml sun8i-h3-deinterlace.yaml Documentation/arch/arm/sunxi.rst arch/arm/boot/dts/allwinner/sun8i-h3-nanopi-duo2.dts arch/arm/boot/dts/allwinner/sun8i-h3.dtsi P.S. Please read this. repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner