MichaIng
Orange Pi Zero 3 | 1GB model shows up as a 2GB model after a reboot at random
Creating a bug report/issue
- [X] I have searched the existing open and closed issues
Required Information
- DietPi version | G_DIETPI_VERSION_CORE=9 G_DIETPI_VERSION_SUB=7 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng'
- Distro version | bookworm
- Kernel version | Linux zero3 6.6.44-current-sunxi64 SMP Sat Aug 3 06:54:42 UTC 2024 aarch64 GNU/Linux
- SBC model | Orange Pi Zero 3
- Power supply used | 5V 3A Raspberry Pi Adaptor
- SD card used | SanDisk Ultra 64GB
Steps to reproduce
- Check RAM size (either with free, htop or RAM usage in dietpi-banner
- Reboot and repeat
Expected behaviour
Show up as having 1GB of RAM on a 1GB model (919 MiB)
Actual behaviour
Intermittently shows up as having 2GB of RAM (1923 MiB)
Extra details
Randomly on a 6th reboot, the board thinks it has 2GB of RAM:
Then, I needed to reboot twice in order to show up with the correct amount of RAM:
Many thanks for your report.
The RAM size is obtained by the bootloader. How old is your system/image, and in case did you flash the new bootloader build?
/boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
reboot
I just got it running and set up today. I have not tried flashing the bootloader, I tried the commands you provided and rebooted. The board showed up with 2GB of RAM once again.
Do you have a USB-UART adapter, to check bootloader output via serial console? So far have not heard about issues with RAM size detection. There was a problem with 1.5 GB RAM detection in the past, requiring a dedicated bootloader build, but that has been solved months ago 🤔.
I just updated the bootloader package a few days ago. Our current image is shipped with 24.5.0 and you flashed 24.11.0, so both have the same issue for you, with 5 months between the two builds.
I'll also do some test reboots on my 2 GB models.
Yes I do have the adapter, this is the output:
U-Boot SPL 2024.01-armbian-2024.01-S866c-P667c-Ha9af-V5c1c-Bda0a-R448a (Oct 05 2024 - 02:23:53 +0000)
DRAM base address is defined as 0x40000000
DRAM has 16 b/raw, 10 b/col, 4 B/width, 1 #rank and 8 #bank
DRAM top address must be less than 0x80000000
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.10.2(debug):armbian
NOTICE: BL31: Built : 02:22:56, Oct 5 2024
NOTICE: BL31: Detected Allwinner H616 SoC (1823)
NOTICE: BL31: Found U-Boot DTB at 0x4a0b2eb8, model: OrangePi Zero3
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
INFO: PMIC: Probing AXP305 on RSB
ERROR: RSB: set run-time address: 0x10003
INFO: Could not init RSB: -65539
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied
INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
INFO: PSCI: Suspend is unavailable
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
INFO: Changed devicetree.
ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
U-Boot 2024.01-armbian-2024.01-S866c-P667c-Ha9af-V5c1c-Bda0a-R448a (Oct 05 2024 - 02:23:53 +0000) Allwinner Technology
CPU: Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM: 2 GiB
Core: 57 devices, 25 uclasses, devicetree: separate
WDT: Not starting watchdog@30090a0
MMC: mmc@4020000: 0
Loading Environment from FAT... Unable to use mmc 0:1...
In: serial@5000000
Out: serial@5000000
Err: serial@5000000
Allwinner mUSB OTG (Peripheral)
Net: Unsupported value 13, using default (13)
Unsupported value 13, using default (13)
eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC de:ad:be:ef:00:01
HOST MAC de:ad:be:ef:00:00
RNDIS ready
, eth1: usb_ether
starting USB...
Bus usb@5200000: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... 2 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2765 bytes read in 2 ms (1.3 MiB/s)
## Executing script at 4fc00000
327 bytes read in 1 ms (319.3 KiB/s)
23443464 bytes read in 969 ms (23.1 MiB/s)
30496581 bytes read in 1260 ms (23.1 MiB/s)
35795 bytes read in 5 ms (6.8 MiB/s)
Working FDT set to 4fa00000
Moving Image from 0x40080000 to 0x40200000, end=418f0000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
Image Name: uInitrd
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 30496517 Bytes = 29.1 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
Booting using the fdt blob at 0x4fa00000
Working FDT set to 4fa00000
Loading Ramdisk to 482ea000, end 49fff705 ... OK
Loading Device Tree to 00000000482de000, end 00000000482e9bd2 ... OK
Working FDT set to 482de000
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
...
After a reboot:
dietpi@zero3:~$ sudo reboot
Failed to connect to bus: No such file or directory
[ 94.542072] systemd-shutdown[1]: Failed to set watchdog hardware timeout to 10min: Invalid argument
[ 94.752471] reboot: Restarting system
U-Boot SPL 2024.01-armbian-2024.01-S866c-P667c-Ha9af-V5c1c-Bda0a-R448a (Oct 05 2024 - 02:23:53 +0000)
DRAM base address is defined as 0x40000000
DRAM has 15 b/raw, 10 b/col, 4 B/width, 1 #rank and 8 #bank
DRAM top address must be less than 0x40000000
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.10.2(debug):armbian
NOTICE: BL31: Built : 02:22:56, Oct 5 2024
NOTICE: BL31: Detected Allwinner H616 SoC (1823)
NOTICE: BL31: Found U-Boot DTB at 0x4a0b2eb8, model: OrangePi Zero3
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
INFO: PMIC: Probing AXP305 on RSB
ERROR: RSB: set run-time address: 0x10003
INFO: Could not init RSB: -65539
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied
INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied
INFO: PSCI: Suspend is unavailable
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
INFO: Changed devicetree.
ns16550_serial serial@5000000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
U-Boot 2024.01-armbian-2024.01-S866c-P667c-Ha9af-V5c1c-Bda0a-R448a (Oct 05 2024 - 02:23:53 +0000) Allwinner Technology
CPU: Allwinner H616 (SUN50I)
Model: OrangePi Zero3
DRAM: 1 GiB
Core: 57 devices, 25 uclasses, devicetree: separate
WDT: Not starting watchdog@30090a0
MMC: mmc@4020000: 0
Loading Environment from FAT... Unable to use mmc 0:1...
In: serial@5000000
Out: serial@5000000
Err: serial@5000000
Allwinner mUSB OTG (Peripheral)
Net: Unsupported value 13, using default (13)
Unsupported value 13, using default (13)
eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in
MAC de:ad:be:ef:00:01
HOST MAC de:ad:be:ef:00:00
RNDIS ready
, eth1: usb_ether
starting USB...
Bus usb@5200000: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@5200000 for devices... 2 USB Device(s) found
scanning bus usb@5200400 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2765 bytes read in 1 ms (2.6 MiB/s)
## Executing script at 4fc00000
327 bytes read in 1 ms (319.3 KiB/s)
23443464 bytes read in 969 ms (23.1 MiB/s)
30496581 bytes read in 1260 ms (23.1 MiB/s)
35795 bytes read in 5 ms (6.8 MiB/s)
Working FDT set to 4fa00000
Moving Image from 0x40080000 to 0x40200000, end=418f0000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
Image Name: uInitrd
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 30496517 Bytes = 29.1 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
Booting using the fdt blob at 0x4fa00000
Working FDT set to 4fa00000
Loading Ramdisk to 482ea000, end 49fff705 ... OK
Loading Device Tree to 00000000482de000, end 00000000482e9bd2 ... OK
Working FDT set to 482de000
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
...
I put these outputs into diffchecker and these are the lines that are different between them:
Thanks, well outlined the difference. Weird that it detects 16 b/raw sometimes, and 15 b/raw the other times, as this should be a static hardware value 🤔.
In general DRAM init code for this SoC is here: https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c
... ahh and now I find these messages in an Armbian patch: https://github.com/armbian/build/blob/main/patch/u-boot/u-boot-sunxi/opizero3-1.5GB-trim-from-u-boot-v2024.01.patch
The upper part is needed to detect and assign 1.5 GB RAM correctly. The bottom part however ... ah, it just adds debugging messages. The issue hence is config->rows which is not related to that patch, but wrong in the first place.
The values are derived here: https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c#L1363
I do not 100% understand the code, but it generally loops through a possible number of bits per column and row, derives the memory address/offset that would match the begin of RAM, and tests whether this is really the case, by writing and comparing values to the two addresses. This actually seems to be a correct method to me. The only value we do not see in logs, which could affect the outcome, is config->bus_full_width, which can be 0 or 1. If it should be 1 but is sometimes falsely detected as 0, it would lead to rows being detected as 1 bit larger, indeed. However, it would also make columns 1 bit larger, which is not the case. ... ah and u8 width = config->bus_full_width ? 4 : 2; => as the width is reported to be 4 in both your logs, bus_full_width must be 1 in both cases.
Here is the two functions which test whether the two addresses are the same: https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/dram_helpers.c#L28-L64 I do not see how this can fail either. Maybe if writing to both addresses fails, and both their values initially were different. But I guess the whole SPL would the fail.
I mailed the author of the U-Boot patch, in the hope he might have some idea how this can go randomly wrong.
@MichaIng thanks for mentioning. Will keep an eye on this thread. If there's anything I can test on my Zero 2W to help, let me know.
not sure if it could influence this behavior, but pin 272 is used by kernel, however has to be programable GPIO. line 272: unnamed kernel input active-high [used]
Temporary solution for this issue.
orange-pi-3-zero-1GB-version
script which chceck if ram is bigger that it should. so it restarts system. It will solve (not idealy) issue with ram size in Orange pi 3 Zero 1GB
- Create the script ram_check.sh
#!/bin/bash
ram_size=$(free -m | grep Mem | awk '{print $2}')
if [ $ram_size -gt 1024 ]; then
echo "RAM is bigger than 1 GB ($ram_size MB). System is restarting..."
sudo reboot
else
echo "RAM is 1 GB ($ram_size MB). As it should."
fi
Save your script as /usr/local/bin/ram_check.sh and make it executable:
sudo nano /usr/local/bin/ram_check.sh
Paste your script inside and save (Ctrl + X, then Y, then Enter).
Make it executable:
sudo chmod +x /usr/local/bin/ram_check.sh
- Create a systemd service
Create a new systemd service file:
sudo nano /etc/systemd/system/ramCheckSize.service
Paste the following content:
[Unit]
Description=Check RAM size at boot and reboot if >1GB
After=network.target
[Service]
ExecStart=/usr/local/bin/ram_check.sh
Type=oneshot
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Save and exit. 3. Enable and start the service
Run these commands to reload systemd, enable the service at boot, and start it immediately:
sudo systemctl daemon-reload
sudo systemctl enable ramCheckSize.service
sudo systemctl start ramCheckSize.service
- Check the status
To verify if the service ran successfully:
sudo systemctl status ramCheckSize.service
Now, every time the system boots, it will check the RAM size and restart if it’s greater than 1GB.
@jozefSCK
Not great (that such is needed), but a workaround indeed. May you provide the content of your ram_check.sh as well?
For the systemd unit: It runs very late after network, which is not necessary. To speed up things, you can let it run at very early boot stage:
[Unit]
Description=Check RAM size at boot and reboot if >1GB
DefaultDependencies=no
Before=systemd-remount-fs.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/ram_check.sh
[Install]
WantedBy=multi-user.target
Theoretically this should work as an all-in-one unit:
[Unit]
Description=Check RAM size at boot and reboot if >1GB
DefaultDependencies=no
Before=systemd-remount-fs.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c '(( $(free -m | mawk "/^Mem:/{print \$2;exit}") > 1024 )) && reboot'
[Install]
WantedBy=multi-user.target
Thanx for your corrections. I am just begginer. I am learning with AI assistance. I know it is not perfect at all, but still something. Here is ram_check.sh script.
#!/bin/bash
ram_size=$(free -m | grep Mem | awk '{print $2}')
if [ $ram_size -gt 1024 ]; then
echo "RAM is bigger than 1 GB ($ram_size MB). System is restarting..."
sudo reboot
else
echo "RAM is 1 GB ($ram_size MB). As it should."
fi
@MichaIng All-in-one solution looks fine. tried couple of times.
[Unit]
Description=Check RAM size at boot and reboot if >1GB
DefaultDependencies=no
Before=systemd-remount-fs.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c '(( $(free -m | mawk "/^Mem:/{print \$2;exit}") > 1024 )) && reboot'
[Install]
WantedBy=multi-user.target
I pushed new kernel and U-Boot packages to our APT repository. Could you test whether this fixes things, the U-Boot upgrade in particular?
sudo apt update
sudo apt upgrade
sudo /boot/dietpi/func/dietpi-set_hardware flash-uboot-mmc
sudo reboot
I pushed new kernel and U-Boot packages to our APT repository. Could you test whether this fixes things, the U-Boot upgrade in particular?
sudo apt update sudo apt upgrade sudo /boot/dietpi/func/dietpi-set_hardware flash-uboot-mmc sudo reboot
Sorry, now using diffrent os and have no free sdcard for such a thing. But when recieved new sd...i will do test.
Does this other distro not suffer from the by times false RAM size detection? In case its bootloader is generally based on mainline U-Boot, we might derive the needed patch from its sources.
@MichaIng, sorry, haven't kept up with this.
sudo apt update sudo apt upgrade sudo /boot/dietpi/func/dietpi-set_hardware flash-uboot-mmc sudo reboot
Just didt this on my 1GB board, and restarted a few times. First 5 or so showed 1GB, then this:
EDIT: Using Orange Pi Zero 2W 1GB
Okay, thanks for testing. Probably I also just need to restart my 2 GiB model more often to see it having 4 GiB assinged once. If so, I can add some (more) debug output to the U-Boot build to narrow down where exactly it fails to derive the correct RAM size.
Sorry for so late respong Michal. I am using Armbiang bookworm stable. I havent noticed any issue with ram size.
@jozefSCK Hmm, if it was fixed in Armbian, it would be fixed in DietPi as well, as we use the same kernel and U-Boot sources. It is as well Linux 6.12, right?
So far I wasn't able to trigger it on my 2 GB model, showing 4 GB RAM. But I remember someone faced this on 2 GB model as well. Probably just happens less often or so. Will do some more reboots today for some other fixes/tests 😄.
Yeah, probably coincidence then. Or did you forgot and have the RAM size check service in place, to apply an automatic reboot if detected falsely? 😉
A potential fix with a new U-Boot version. Armbian is using U-Boot 2024.04 for those SBCs, while they use 2025.04 for some other boards, where also two patches are applied, which seem to address this issue precisely:
- https://github.com/armbian/build/blob/main/patch/u-boot/v2025-sunxi/0001-sunxi-h616-dram-Rework-size-detection.patch
- https://github.com/armbian/build/blob/main/patch/u-boot/v2025-sunxi/0002-sunxi-H616-dram-Improve-address-wrapping-detection.patch
The second patch is exactly mentioning the confusion I faced further above when reviewing related U-Boot code. For me, the test looks bullet prove, without a way to return a wrong result, but for whatever reason it does sometimes return a wrong result. So the 2nd patch applies the test 16 times, so that it would return false result 16 times in a row to boot with wrong RAM size 😄. The original test is designed as a loop: it loops through possible RAM sizes (well, row and column bits, related to RAM sizes) and writes to an address which would be the start of the RAM if the loop reached the actual RAM size, then compares the written value with the start of the RAM (previously it resets both, of course). If they do not match, the actual RAM size must be larger, so that the high address was not pointing to the start of RAM, so the loop tests one RAM size larger. With the patch, there are now 16 writes done (incrementing the address for each of them), and then if only one of the values does not match the corresponding address at RAM start, the RAM size related to current loop iteration is taken as actual size. With this we need to hope that whichever inconsistency causes the problem, does not lead to a false positive now, so that 2 GB or 4 GB variants boot with only half RAM size 😄.
So I moved the OPi's to U-Boot v2025.05 as well: https://github.com/MichaIng/build/commit/5f9c6d0 It boots fine for me, but I also never faced wrong RAM size. Please test:
For Orange Pi Zero 3:
apt update
apt upgrade
sudo /boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
sudo reboot
For Orange Pi Zero 2W:
apt update
apt upgrade
sudo /boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
sudo reboot
cd /tmp wget https://dietpi.com/downloads/binaries/testing/linux-u-boot-orangepizero2w-current.deb sudo dpkg -i linux-u-boot-orangepizero2w-current.deb sudo /boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc sudo reboot
@MichaIng just did this to my Zero 2W 1GB. 15 reboots without issue. Seems to be fixed finally.🤞
Great news, also good to see it working on Zero 2W. I'll push this build to our APT server then and flash it on DietPi update. The patch really looks like a hack, lacking the understanding why the original test actually tails. So I would love to add some debug logs to find out how/at which point the the written/read values differ from what is expected. But on the other hand ... more important things to do 😄. Fixed with: https://github.com/MichaIng/DietPi/commit/42dbdd5
Spoke too soon. It breaks support for the 1.5 GB variants at least, and another user reports unbootable system with it on 1 GB variant: https://github.com/MichaIng/DietPi/issues/7545#issuecomment-2907823366
Here the missing patch, I hope I can migrate it: https://github.com/armbian/build/blob/main/patch/u-boot/u-boot-sunxi/opizero3-1.5GB-trim-from-u-boot-v2024.01.patch
Okay, with a little adjustment this worked. The Orange Pi Zero 3 build does now successfully boot on my 2 GB as well as 1.5 GB variants, detecting the RAM size correctly on the latter. Luckily all 3 patches adjust different parts of the code, and can hence coexist. It still would make SO much sense to merge them, and add more debug output to find the reason for the faulty doubled RAM size detection, then upstreaming everything.
I took the intermediate build away from our APT server again. So to test again, also pinging @milkywade:
For Orange Pi Zero 3:
apt update
apt upgrade
sudo /boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
sudo reboot
For Orange Pi Zero 2W:
apt update
apt upgrade
sudo /boot/dietpi/func/dietpi-set_hardware flash-u-boot-mmc
sudo reboot
If you have a USB-UART adapter, the upper part of its output would be particularly good so see, which contains the added (but incomplete) debug messages as well, e.g. on my boards:
with 2 GB RAM:
U-Boot SPL 2025.04-armbian-2025.04-S3482-Pf089-H8869-V3d5b-Bb703-R448a-dirty (May 25 2025 - 14:39:25 +0000)
DRAM base address is defined as 0x40000000
DRAM has 16 b/raw, 10 b/col, 4 B/width, 1 #rank and 8 #bank
DRAM top address must be less than 0x80000000
DRAM: 2048 MiB
Trying to boot from MMC1
...
with 1.5 GB RAM, one can see the first check detecting max 2 GB RAM size, and then the 1.5 GB check added with the patch, with detects that it cannot be 2 GB RAM either, and returns 3/4 of that instead:
U-Boot SPL 2025.04-armbian-2025.04-S3482-Pf089-H8869-V3d5b-Bb703-R448a-dirty (May 25 2025 - 14:39:25 +0000)
DRAM base address is defined as 0x40000000
DRAM has 16 b/raw, 10 b/col, 4 B/width, 1 #rank and 8 #bank
DRAM top address must be less than 0x80000000
DRAM top address must be less than 0x60000000
DRAM: 1536 MiB
Trying to boot from MMC1
...
What would be great to add for debugging is further output of the individual row/column bits loops, the values it writes to and checks back from which addresses, to derive whether the RAM size must be larger or cannot be larger.
Talking about upstreaming, here it was done, at least the doubled RAM size detection issue:
- https://github.com/u-boot/u-boot/commit/40c687a
- https://github.com/u-boot/u-boot/commit/3808029
- Then moved here: https://github.com/u-boot/u-boot/commit/923ad56
So those two patches can be dropped when moving to U-Boot v2025.07 after its release.
Hi - I performed above actions for Orange Pi Zero 3, my 1gb-that-identifies-as-2gb board still shows 2gb. I don't have a USB-UART adapter but could connect the board to a screen via hdmi, would that help ?
U-Boot sadly does not start displays usually, at least never in the relevant early SPL stage. So your board would then be really interesting to debug, to see how a complete repetitive test pattern can fail so completely. That would mean a very basic false assumption in the code. But it cannot be debugged without access to the serial debug console.
But at least both of your boards boot now with the new U-Boot version?
Booting is finally working again, I wanted to reinstall my system from scratch onto a new SD card so I guess I finally got myself up to do it.