Jump to content

TRay

Members
  • Posts

    78
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes, I know about it and I did it right after the update was finished. Maybe it was an isolated case. I did armbin-install again and test 30 reboot again and each one correctly indicated 1Gb RAM 🙂
  2. Thank you. I did an Armbian update where there is a new U-Boot v2025.04 and kernel 6.12.35 and on 10 reboots one after another, one time it showed the RAM size incorrectly instead of 1 GB it gave 2 GB. I see a definite improvement compared to u-boot v2024.xx
  3. I realize that OZPI v3 is supported by the community, but I would like to ask if anyone has information whether u-boot for OZPI v3 will be in version 2025.04 and is the estimated date known? Will armbian-config be fixed for OZPI v3 etc. problem using overlay-prefix in device tree? https://github.com/armbian/configng/issues/592
  4. Yes in overlays i2c3-ph is on system is i2c-1 on OZPI v2/3 boards on pins 3 and 5 So you can check connected devices on pins 3 and 5 i2cdetect -y 1
  5. I confirm that armbian-config has problem with add ovelay prefix to overlays= please look on: https://github.com/armbian/configng/issues/592 So i must add manually devices in amrbinaEnv.txt and for OZPI v3 to use I2C i have overlay_prefix=sun50i-h616 overlays=i2c3-ph
  6. I use the ArmBian version which is updated very often (see below) so if U-Boot v2025.04 for OZPI v3 appears in the current updates it will be possible to check and other users who have OZPI v3 with 1,1.5, 2, or 4 Gb RAM check it
  7. From the information of DietPi users, it appears that they have used UBoot v2025.04 for Orange Pi Zero 3 and it seems that the problem of incorrect detection of RAM size has been solved, especially in the version with 1 MB. It would be valuable if ArmBian was also transferred for Orange Pi Zero 3 to Uboot v2025.04, we could avoid complications during system updates and other processes that need a lot of RAM causing the system to hang up because they try to use memory addresses that are not physically there when the RAM size was incorrectly identified during booting. More info about UBoot v2025.04 with Orange Pi Zero 3: https://github.com/MichaIng/DietPi/issues/7242#issuecomment-2912290816
  8. It was solved https://github.com/armbian/configng/issues/344 , but It looks like bug with overlay_prefix back again
  9. I see that u-boot 2025.04 has applied some fixes to DRAM detection a month ago https://github.com/u-boot/u-boot/commits/master/arch/arm/mach-sunxi/dram_sun50i_h616.c so if the new u-boot 2025.04 via apt upgrade will be available in armbian for Orange Pi Zero 3, there is hope that the problem of incorrect detection of RAM size will be solved
  10. The question is why (what was the reason) the name for h616 uart5-ph which was used so far to the name uart5 was changed (without -ph)? This will now cause many people to look for a solution to the problem with access to UART5. In the new kernel 6.12.23 I see that UART2 which is also available is still in the device tree called uart2-ph-...
  11. Hi I know that I can use UART5 as /dev/ttyS1 but it worked on kernel 6.6.67 when in overlays was used uart5-ph but after update to kernel 6.12.23 and new armbian-config now when you use armbian-config to setup device tree the UART5 has changed name to sun50i-h616-uart5 and this name is put in overlays in armbianEnv.txt. overlays=sun50i-h616-uart5 After reboot we lose UART5 as /dev/ttyS1 But I found old problem that armbian-config add overlay_prefix to device name (https://github.com/armbian/configng/issues/344#issuecomment-2613947809 ) and this make problem. When I removed sun50i-616 from name sun50i-616-uart5 and overlays line looks: overlays=uart5 (don't use uart5-ph) now I see again UART5 /dev/ttyS1 in my system [ 0.000624] printk: legacy console [tty1] enabled [ 1.552801] printk: legacy console [ttyS0] disabled [ 1.553231] 5000000.serial: ttyS0 at MMIO 0x5000000 (irq = 301, base_baud = 1500000) is a 16550A [ 1.553288] printk: legacy console [ttyS0] enabled [ 1.554781] 5001400.serial: ttyS1 at MMIO 0x5001400 (irq = 303, base_baud = 1500000) is a 16550A
  12. I see that current image Orange Pi Zero 3 for download base on kernel 6.12 so the question is, does anyone have a problem with access to UART5 which is on the 26-pin connector?
  13. I check on my old microSD card image with kernel 6.6.75 Linux armbian 6.6.75-current-sunxi64 #1 SMP Sat Feb 1 17:37:57 UTC 2025 aarch64 GNU/Linux [ 0.000505] printk: console [tty1] enabled [ 1.371166] printk: console [ttyS0] disabled [ 1.371473] 5000000.serial: ttyS0 at MMIO 0x5000000 (irq = 297, base_baud = 1500000) is a 16550A [ 1.371524] printk: console [ttyS0] enabled [ 1.372761] 5001400.serial: ttyS1 at MMIO 0x5001400 (irq = 298, base_baud = 1500000) is a 16550A and now I see that /dev/ttyS0 is for console connect but /dev/ttyS1 was UART5 on 26 PIN header so at current with new kernel 6.12.23 and we set in armbianEnv.txt sun50i-h616-uart5 via armbian-config we are not have access to UART5 /dev/ttyS1
  14. I notice that with now new kernel 6.12.23 and armbian-config where I set in device tree overlay uart5 for Orange Pi Zero 3 (OZPI v3 UART5 described in the original documentation) now change number from /dev/ttyS1 (it was up to 6.6.67 kernel version) now is /dev/ttyS0 [ 0.000621] printk: legacy console [tty1] enabled [ 1.550621] printk: legacy console [ttyS0] disabled [ 1.551031] 5000000.serial: ttyS0 at MMIO 0x5000000 (irq = 300, base_baud = 1500000) is a 16550A [ 1.551091] printk: legacy console [ttyS0] enabled but I am not sure why is now change name in device tree from uart5-ph to uart5
  15. I updated armbian-config to latest version and now show devicetree
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines