Orange PI Zero3 ram intermittently detected incorrectly

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

My Orange PI Zero3 has 1GB ram. But occasionally the system detects it to have 1923.2 Mi. I have to reboot until it is correctly identified as 918Mi in free -h command. I noticed similar issue with the Armbian port as well.

When its incorrectly detected causes random system crashes. Thank you.

Required Information

  • DietPi version | cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=11
G_DIETPI_VERSION_RC=2
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
  • Distro version | bookworm
  • Kernel version | Linux DietPi 6.6.44-current-sunxi64 #1 SMP Sat Aug 3 06:54:42 UTC 2024 aarch64 GNU/Linux
  • Architecture | arm64
  • SBC model | Orange Pi Zero 3 (aarch64)
  • Power supply used | Generic “Fastcharger” 5V
  • SD card used | various

Steps to reproduce

free -h

Expected behaviour

free -h
               total        used        free      shared  buff/cache   available
Mem:           918Mi       142Mi       729Mi       2.2Mi       115Mi       776Mi
Swap:          124Mi          0B       124Mi

Actual behaviour

free -h
               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       152Mi       1.7Gi       3.1Mi       111Mi       1.7Gi
Swap:          124Mi          0B       124Mi
2

probably an issue with the kernel if similar happen on Armbian. Maybe @MichaIng knows

3

I’m not fully certain… but I think uboot was wrongly reporting the Ram size. This is the vendor’s patched vesion. But if I remember correctly, the upstream version (supported from ~Jan 2024) didn’t have this issue. Sorry I dont have exact details as it’s been a year since I’ve tried to build custom images for the board… Thanks!

4

yeah uboot and/or kernel

5

Sadly a known issue, and outside of my abilities: Orange Pi Zero 3/2W | 1GB model sometimes detects 2GB after reboot · Issue #7242 · MichaIng/DietPi · GitHub
I did have a close look into the bootloader code, and it looks all sane and failsafe to me. No idea how this can go wrong.

But at last I can do a new bootloader build to test. Maybe something has been fixed upstream.