TRay

Thank you for your answer but I am a regular user of the ArmBian system on Orange Pi Zero 3 and I do not have such a large experience in such areas as recompiling U-Boot patch applications. I can only wait patiently that maybe in a stable version, it will be "fixed" and until then I will use the script provided by DietPi users

I found information on my OZPIv3 with Armbian 25.5 (which updated) in the directory /usr/lib/linux-u-boot-current-orangepizero3 declare UBOOT_BIN_DIR="/usr/lib/linux-u-boot-current-orangepizero3" declare UBOOT_VERSION="2024.01" declare UBOOT_ARTIFACT_VERSION="2024.01-S866c-P4a40-H8869-V380a-Bb703-R448a" declare UBOOT_GIT_REVISION="866ca972d6c3cabeaf6dbac431e8e08bb30b3c8e" declare UBOOT_GIT_SOURCE="https://github.com/u-boot/u-boot" declare UBOOT_GIT_BRANCH="tag:v2024.01" declare UBOOT_GIT_PATCHDIR="u-boot-sunxi"

Hi Nick A Thank you for links and looks like in post from c0rnelius above For v2025.01 and above; https://lore.kernel.org/linux-sunxi/20250309063143.62859-1-jernej.skrabec@gmail.com/T/#t Jernej Skrabiec send patch so we need to wait for update for U-boot / kernel for OZPI v3 in ArmBian distribution ? maybe this will solve the problem Currently OZPIv3 has kernel 6.6.75 available but I don't know what the U-Boot version is, probably I can see it via serial port

my case is exactly similar to the one I found in the description by providing a link in my post

I bought OZPI 3 in the 1 GB RAM version and when the system recognizes it as 2 GB I have problems with compilation system update because system want to use the memory range that does not exist physically when the system recognizes it as 1 GB everything works smoothly compilation and system update does not cause the system to hang But I am not an expert in this matter, I just write what I observe

I don't really understand, if there is some memory mounted on the board, why the system recognizes it once as 1 Gb and the next time the reboot recognizes it as 2 Gb???

Unfortunately I can't read it because I have special tapes on the CPU and memory to transfer the temperature to the mounted radiator I won't rip these tapes off because I don't have spare ones On the second OZPI v3 which has the same phenomenon, the system has the following written on it: SEC 913 K4F8E30 4HBMGCJ

If it happens that the system starts with an incorrect amount of physical memory, as a result of processes such as compilation or even system update (which I experienced a few times) that want to use memory that is not physically available, the system hangs during compilation or system update.

Now after next reboot looks all OK size memory

I have just managed to illustrate this phenomenon with screenshots

Thank you c0rnelius for your answer, maybe your suggestions are worth applying to Orange Pi Zero 3 and will help to solve the problem that does not appear permanently but only from time to time, which makes diagnosis difficult. At the moment I have used the proposed script that checks whether after a reboot the memory is not greater than 1 Gb, if so, then another reboot and I see that currently I no longer have problems with the system stopping during program compilation, and sometimes it happened during system updates. The solution based on the script is not an elegant solution, but it helps until corrections appear for Orange Pi Zero 3

Orange Pi Zero 3/2W | 1GB model sometimes detects 2GB after reboot I found an interesting description of the problem that appeared on my OZPI v3 with ArmBian 25.x , especially when the program was being compiled, so the memory usage was greater and OZPI v3 would hang. When I found the following information from DietPi users, I understood where my problem was coming from time to time. Maybe the following information will be useful to someone when they have a similar problem with U-Boot, which sometimes incorrectly detects DRAM on the 1 Gb version, but users of 2Gb DRAM also reported it https://github.com/MichaIng/DietPi/issues/7242

Hi I use Orange Pi Zero 3 with ArmBian Bookworm and in armbianEnv.txt I have overlays=uart-ph5 and I use /dev/ttyS1 which work good for communications with hardware connected to this serial port dmesg |grep ttyS1 [ 1.376441] 5001400.serial: ttyS1 at MMIO 0x5001400 (irq = 298, base_baud = 1500000) is a 16550A

Please look: overlay_prefix=sun50i-h6 overlay=uart3

Hi Werner, I don't know, this problem has been reported on github but I'm writing on the forum because more people read it and maybe have a similar problem I understand that on github the only solution to this problem is ? The fix currently (as I put in the forum post) is to edit the overlay names in armbianEnv.txt, removing the prefix.

Look at the description https://docs.armbian.com/User-Guide_Armbian_overlays/ when I set UART I2C in armbianEnv.txt it should be overlay_prefix=sun50i-h616 overlays=i2c3-ph uart5-ph as described on the given page But when I use armbian-config and go to Manage Overlays my settings are not seen and I have to set them but the names of all overlays are preceded by the prefix. After selecting and saving the settings in armbinEnv.txt it is overlay_prefix=sun50i-h616 overlays=sun50i-h616-i2c3-ph sun50i-h616-uart5-ph as a result the defined overlays are not loaded Is it supposed to be like this? I use OrangePi Zero 3 with updated system Welcome to Armbian_community 25.2.0-trunk.331 Bookworm Kernel Linux 6.6.70-current-sunxi64

Stephen, thanks for the tip, I will pass these suggestions on to my friend

My friend who had problems with OZPI v3 did not start after reboot, and sometimes after turning on the power, he had to turn the power on again for the system to start. Run armbian-config and select SYSTEM -> INSTALL from the menu and then select option 5 "Install/update the bootloader on SD/eMMC" Since then, there have been no problems with the computer not starting from time to time after reboot or after turning on the power It looks like updating the bootloader helped ?

I found interesting info on https://linux-sunxi.org/Xunlong_Orange_Pi_Zero2 SPI booting The board contains a 2MB SPI NOR flash chip (located on the underside of the board), and the SoC can boot firmware from there. The BOOT_MODE bit in the SID is cleared, to let GPIO pins determine the boot order. So to enable booting from SPI flash (after the micro-SD card has been tried), pull PC5 to GND, by bridging pins 9 and 13 on the expansion port header. U-Boot supports SPI booting since v2023.01-rc1. But I don't know if it is still possible to boot via SPI without micSD, which would allow you to use a USB drive later. Maybe someone tried this?

Thanks for the answer and you're probably right, but I was curious if it was possible, maybe someone did it just for experience 🙂 I think that this may have happened to many people with a broken microSD slot

My friend, when he next inserted the microSD card into the Orange Pi Zero 2 slot, the microSD slot fell off the board 😞 It is not possible to solder it because some of the tracks on the board have become detached so Is it possible to run the ArmBian system on OZPi v2 with a copy of the microSD system on a USB Pendrive? I am looking for a method to run OZIPI v2 without microSD on the system via USB disk

Hi How to disable HDMI audio and audiocodec 0 [audiocodec ]: audiocodec - audiocodec audiocodec 1 [SoundCard ]: USB-Audio - USB PnP Sound Device C-Media Electronics Inc. USB PnP Sound Device at usb-5200400.usb-1, full speed 2 [HDMI ]: HDMI - HDMI HDMI I don't need this because I use external sound card on USB and I would like prefer USB Sound card on index number 0 I try use /etc/modprobe.d/alsa.conf with options snd_usb_audio index=0 but don't work

I can add that Orange Pi Zero 3 users have similar problems, i.e. after turning on the power or, for example, after reboot. This is not a cyclical phenomenon. So when it happens that you need to reboot remotely, it may turn out that Orange Pi Zero 3 requires physical intervention by turning the power on and off.

The only thing I haven't been able to eliminate is this message [ 5.019754] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file I tried setting the GPIO flag for GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN but unfortunately, it doesn't work but it doesn't affect the operation of w1-gpio It seems that the GPIO pins do not have an "open drain" mode, they do outputs and inputs. It is a warning about what something sees as an invalid or incomplete configuration in Device Tree, rather than a real problem with the hardware.

Hi, for me w1-gpio on OZPI v3 working now very well via overlay dts file please read my last post in: