TRay

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:

Reading many others documents about OPEN DRAIN flag , OZPI v3 and others like Raspberry Pi don't support Open DRAIN, but they should work in emulated mode, switching between input and output-driving-low. So for this reason if we set flag for GPIO with OPEN DARIN it looks not influence and not need setting this flag for w1-gpio for this SBC

Hi, I managed to make w1-GPIO work in Orange Pi Zero v3 for, for example, the DS18B20 sensor. However, I have some doubts about setting the GPIO flags for w1-gpio. Many examples provide flags in the form gpios = <&pio 0 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; but in the dts file when I use this form it does not work (syntax error) so I have to provide the flags in digital form. A description of flags and bits is here https://elixir.bootlin.com/linux/v6.6.30/source/include/dt-bindings/gpio/gpio.h If I would like to set GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN then the digital value for these bits will be for set bits: 0110000 = 48 because GPIO_OPEN_DRAIN it is (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN) Please help me and confirm whether I understood it correctly I wanted to get rid of the message in the logs for w1-gpio [ 4.994183] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file which understands that I need to set the GPIO flag GPIO_OPEN_DRAIN in the dts file I see one problem with this source https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt where a number of bits to set is 6 in source https://elixir.bootlin.com/linux/v6.6.30/source/include/dt-bindings/gpio/gpio.h number of bits to set is 7 I hope I posted this question in the right section, if not please move it

I used simple dts file as possible : /dts-v1/; /plugin/; / { model = "OrangePi Zero3"; compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618"; fragment@0 { target-path = "/"; __overlay__ { w1: onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; gpios = <&pio 2 7 0>; status = "okay"; }; }; }; }; compiled: armbian-add-overlay w1-gpio.dts and works 🙂 with armbianEnv.txt user_overlays=w1-gpio param_w1_pin=PC10 param_w1_pin_int_pullup=0 demsg show [ 5.015541] Driver for 1-wire Dallas network protocol. [ 5.019754] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 5.046831] w1_master_driver w1_bus_master1: Attaching one wire slave 28.03165129ecff crc 24 and cat /sys//bus/w1/devices/28-03165129ecff/w1_slave 76 01 4b 46 7f ff 0c 10 d3 : crc=d3 YES 76 01 4b 46 7f ff 0c 10 d3 t=23375 SBC DS18B20 VCC (3V3) Pin 1 ---------- VCC DS18B20 | R1 = 4k7 | GPIO74 Pin 26 --------- Data DS18B20 GND Pin 6 ---------- GND DS18B20