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.