voapilro

@ag123 @OttawaHacker I saw community builds already generated here. I could check that they have u-boot DRAM patch, so I tried both of them in my board, and they boot normally 🙂 also minimal one having HDMI output.

@OttawaHacker This is a minimal build, probably it has no HDMI output. As @ag123 said, you need a serial cable to see output. Or you could access via SSH, looking at your router for DHCP address. Other option would be to use a build with desktop like this one, and apply patch the same way. Any way, pull request was already merged, so you can wait for next community release in a few days.

@ag123 @OttawaHacker I submitted a pull request in order to add DRAM patch to community builds. Let's see how it goes...

@OttawaHacker I already did it, you can find it attached here: This is what I am trying to avoid.

@SteeMan This is what I am trying to do, but I should submit at least two patches, one for u-boot release v2024.01 and other one for v2024.04 and newer. After doing some tests, adding patch to patch/u-boot/u-boot-sunxi folder, it is applied during build, but for any u-boot release. I tried to add it to patch/u-boot/v2024.01 folder, but it does not work. I did not find any document explaining how to do it. Any help is welcome.

@ag123 I have good news, I patched an Armbian community build with this patched u-boot, and now it boot 🙂 Before applying patch it detected 2GB memory and stopped: But after applying patch, it boots to the end: And this is what I did to patch image: I would suggest to add u-boot patch to community builds in order to any new build would be able to boot in any opi-zero3 board, even in the ones with 1.5GB memory. Do you know who is in charge of generating community builds?

@ag123 The value of CONFIG_SYS_SDRAM_BASE for opi-zero3 is 0x40000000 i.e. 1GB of memory, so it makes a big difference in results of memory size detection. By the other hand, CONFIG_SYS_SDRAM_BASE was renamed to CFG_SYS_SDRAM_BASE at some point between u-boot-sunxi and latest u-boot official release, so I updated my patch. Besides I was trying to use Armbian builder to generate an u-boot image to test patch: And after that, I got u-boot-sunxi-with-spl.bin in cache/sources/u-boot-worktree/u-boot/v2024.01 folder. So just adding patch to userpatches/u-boot/u-boot-sunxi folder and repeating build, I would get patched u-boot image. Well, to force rebuild, I had to remove packages in output/debs folder. The problem is that patch does not apply to v2024.01 u-boot release, so I had to create a new one from such release. Those new changes are here, and this is the new patch. This way I got a patched u-boot image I attached here. I replaced u-boot in my board by this patched one, and this is what I got: So, I works in my board. Well, It does not boot because of my u-boot configuration. I was no able to get a working Armbian build for opi-zero3, so I am using the vendor opi-zero3 Debian image. Any help for testing patch in other boards would be welcome, specially with1.5GB ones. u-boot-sunxi-with-spl-armbian-v2024.01-20240506-patch.tgz

@ag123 Thanks for testing it! But I think there is a mistake in your patch. Why you redefine CONFIG_SYS_SDRAM_BASE as 0? I forked u-boot and made a branch with my changes here and this is the patch. Please, can you try it?

@ag123 I have only tested on a 1.5GB board, but there should be no problem in remaining boards of 1GB, 2GB and 4GB, as 1.5GB is the only odd case. As far as I know there are no more memory options available. In principle, I was thinking in making detection to cover all possible cases, but I decided not to do it as there would be no board to test them.

@ag123 I have been doing a lot of tests using official Orange Pi Zero 3 SDK following instructions here, and I think a got a way to detect the right memory size. I was not able to fix random memory size detection yet, so it would be next. Anyway, what I saw is that current memory size detection is based on top address wap around to base address. It works well for 1GB, 2GB and 4GB, but not for 1.5GB, as it is not even tried by this method. So I tried to write something to 1.5GB memory address and looking around memory to find a match, and I did not find anything. Instead what I got is that address maps to nowhere, because writing something and then reading once an again, what I got was a kind of random values. And based on that I coded a memory size fix. First of all I need a funcion to check top memory: bool mctl_mem_matches_top(ulong offset) { static const unsigned value= 0xaa55aa55; /* Take last usable memory address */ offset -= sizeof(unsigned); dsb(); /* Set zero at last usable memory address */ writel(0, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Set other value at last usable memory address */ writel(value, (ulong)CONFIG_SYS_SDRAM_BASE + offset); dsb(); /* Check if the same value is actually observed when reading back */ return readl((ulong)CONFIG_SYS_SDRAM_BASE + offset) == value; } And then just use it to fix memory size: static unsigned long mctl_calc_size(struct dram_para *para) { u8 width = para->bus_full_width ? 4 : 2; unsigned long size; /* 8 banks */ size = (1ULL << (para->cols + para->rows + 3)) * width * para->ranks; /* Fix size if last usable memory address is not valid */ if (!mctl_mem_matches_top(size)) size = (size * 3) / 4; return size; }

@ag123 Yes, I did a backup of original u-boot before testing, and restored it successfully after testing. This is a directory listing of my /boot folder: And I also attached most of its contents, skipping big ones. Too late 🙂 I will try it next time I flash u-boot. I typed help command and some others, but I did not know what to do. some-files-from-boot-folder-20240420.tgz

Thanks @ag123 for your help! I tried your u-boot image and I got a different error, probably because Debian image I have is different than yours, so I have to restore u-boot from backup. This is console output I got: I see some differences from u-boot of my Debian image, but I am not able to see what is wrong or missing. Here is normal console log to compare:

I do not want to start a discussion on this subject. I just want to clarify my point of view. I have several flavours of RPi2, RPi3, RPi4 and I will buy a RPi5 soon. I really like RPi, not only the boards, specially software provided by both manufacturer and community. Just googling a while you can find a lot of resources on RPi, and as a contrary much less for OPi. I do not think RPi4 or RPi5 are expensive, they are new desings, very powerfull, so they cost money. But must of the times, in my case, a RPi3B+ is more than enough, it is an old design, but still powerfull enough for a lot of things, and very well supported. What I do not understand is that RPi3B+ is almost the price of RPi4B-1GB. If RPi3B+ price was more reasonable, I would not be looking for alternatives like OPi. I guess this way RPi manufacturer is pushing us to RPi4 and RPi5, but what they get is that some people like me are looking for other options same power as RPi3.

Thanks @electricworry for your help! I installed an official Debian build for Orange Pi Zero 3 with 1.5GB, downloaded from here and named Orangepizero3_1.0.2_debian_bookworm_server_linux6.1.31_1.5gb.7z. I coud see that there is no official Armbian release, just an unofficial community release not tested by Armbian, so I did not try it. I could not find any other trustable build I could try, so please let me kown if there are other options. Regarding "vendor build" you mentioned, are you talking about a build provided by seller? If that is the case, I do not think they can provide it, they just sell the boards. Regarding the number of times I observe correct and incorrect memory size, it is difficult to say. I rebooted and power cycled the boards a lot of times since last monday, that is when I receved them, and it is quite ramdom. Sometimes it is easy to get and incorrect memory size once and again, other times is more difficult, and I do not see a pattern. I have both boards powered on all the time, and from time to time I reboot or power cycle them. Anyway, I would say that memory size is incorrect 1 of 4 times in all, but it is just an overall perception. I really like these boards, and 1.5GB memory size is the best option for my purposes. I bought two other Orange Pi Zero 3 with 1GB memory two months ago and they are working well. I am using them for creating a VPN, and they are more than enough. However, I would like to install some network management software that should fit in 1 GB memory, but I prefer to have some spare memory, just in case. I have being using some Raspberry Pi for several years, and I am happy with them, but prices are higher year by year, so Orange Pi could be a good alternative.

Hi! I just bought two Orange Pi Zero 3 with 1.5 GB RAM, and I think they have same memory size detection mentioned earlier in this thread. I am looking for a quick solution, as I do not have much time to return them if it is not possible to fix them. I installed Debian Bookworm for 1.5 GB board with kernel version 6 and without GUI. Apparently it was working well, but sometimes rebooting via SSH just powered off. I did not see anything wrong in dmesg and syslog, but after plugging in a console cable I could see that when reboot failed, u-boot detected 3 GB of memory. Even more, next power cycle boots board with 3 GB memory detected. I did not have time to stress boad, but this issue will probably make board unstable appart not being able to reboot all the times. I attached console output with some comment for details. Any help would be welcome. I you want, I can provide more information or make more tests, in order to look for a solution. Thanks in advance for your help. commented-boot-20240417.out