hi Andre Przywara, Thanks for your response.
According to this thread, the author who has worked on the H616 and H618 dram codes including that '1.5G issue' https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/38?u=ag1233 For DDR4 (chips, and I'm not sure if it is that chip or all chips), because address wraps around to some unknown address. Hence, it is not possible to make generic codes that possibly caters to some (other) combination of memory size. And 'hacks' is about the only way. I (we (in Armbian forums)) tried some stuff: I did this hack https://forum.armbian.com/topic/29202-orange-pi-zero-3/page/20/#comment-188328 static unsigned long mctl_calc_size(const struct dram_config *config) { u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ unsigned long long memsz = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; log_info("detected memsize %d M\n", (int)(memsz >> 20)); /* 1.5 GB hardcoded */ memsz = 2048UL * 1024UL * 1024UL * 3 / 4; return memsz; } 1.5G is *hardcoded*, build a custom u-boot and we (in Armbian forums) ventured with some experiments: in the same comment https://forum.armbian.com/topic/29202-orange-pi-zero-3/page/20/#comment-188328 Unhide the spoiler, for Armbian distribution built based on Debian bookwork and mainline Linux 6.7 kernel (possibly with a patched DTS as well, on top of that already there for Zero 3 and Zero 2W). Currently that causes during linux boot: [ 2.144698] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down [ 2.153147] reboot: HARDWARE PROTECTION shutdown (Temperature too high) [ 2.192185] reboot: Power down if it is run with the mainline u-boot without this hack and the 'standard' boards e.g. 2G, 4G, it boots just fine. But that with the hack and on 1.5G Orange Pi Zero 3 board (I've only 1 of that) I get this gpu overheating goof on boot. Someone else who had some issues detecting memory size with the Orange Pi vendor distributions (based on 6.1 kernels I think) , tried the 1.5 G hacked u-boot replacing that in (patched into) Orange Pi vendor distributions. https://forum.armbian.com/topic/29202-orange-pi-zero-3/?do=findComment&comment=188078 Unfortunately, it turns out that (Orange Pi's distributed) u-boot is customized / different and it 'crashes' when (this hacked mainline) u-boot tries to include/call /boot/boot.scr (or /boot/boot.cmd) scripts in the root filesystem. This is currently the 'state of art' and I'm yet to figure out that 'gpu overheating' bug, which is obviously a bug (perhaps I've not considered some things) On Monday, April 22, 2024 at 10:15:37 PM UTC+8 Andre Przywara wrote: On Thu, 18 Apr 2024 22:40:59 -0700 (PDT) "'andrew g' via linux-sunxi" <linux...@googlegroups.com> wrote: Hi Andrew, > background: > > currently Armbian linux use the 'mainline u-boot' > https://source.denx.de/u-boot/u-boot Thanks for using mainline! > however, it has a '1.5GB' problem in that boards with 1.5GB DRAM is > detected incorrectly. > It detects 2GB instead possibly due to address wraparound, so the boot > crashes mid stream. > I'm trying to build a custom u-boot for a 'hack' i.e. to return 1.5GB dram > from the memory initialization and setup functions. in part to explore > solutions So yes, as you figured, the 1.5GB setup is not supported yet, mostly because no one with a board fixed that and sent a proper patch. There is this patch here - but please note that this is hack: https://lore.kernel.org/u-boot/20240413134352...@189.cn/T/#u <https://lore.kernel.org/u-boot/20240413134352.46495-1-da...@189.cn/T/#u> However in his reply Jernej gives some hints on what to do for a proper solution. So you might want to try this. Bonus points for trying to follow Jernej's hints and implementing that! Cheers, Andre P.S. Your build sequence below looks correct, and nice work on digging into the sequence. I sketched the U-Boot early code flow here: https://linux-sunxi.org/U-Boot/Boot_process > > what I tried and issues: > I'm building u-boot from > https://source.denx.de/u-boot/u-boot > basically following these instructions > https://docs.u-boot.org/en/latest/board/allwinner/sunxi.html > > my shell script ot build u-boot is like > #!/usr/bin/bash > export BL31=../arm-trusted-firmware/build/sun50i_h616/release/bl31.bin > make orangepi_zero3_defconfig > CROSS_COMPILE=aarch64-linux-gnu- make > > where the bl31 module from arm-trusted-firmware is in its own directory > build with > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h616 > > I did succeed with building u-boot and flashed the u-boot SPL into the sd > card > sudo dd if=u-boot-sunxi-with-spl.bin of=/de > v/sde bs=1024 seek=8 > > and it actually boots, but : > U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 12:46:06 +0800) > DRAM: 0 MiB > Trying to boot from MMC1 > NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c > NOTICE: BL31: Built : 23:11:18, Apr 18 2024 > NOTICE: BL31: Detected Allwinner H616 SoC (1823) > NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 > ERROR: RSB: set run-time address: 0x10003 > U-Boot 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 12:46:06 +0800) > Allwinner Technology > > size=30, ptr=590, limit=2000: 26370 > CPU: Allwinner H616 (SUN50I) > Model: OrangePi Zero3 > DRAM: 0 Bytes > > So apparently the DRAM is not detected. I tried tracing flow execution by > placing > debug("tag"); or log_info("tag") in > board_init_f() > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/board.c?ref_type=heads#L457 > and > sunxi_dram_init() > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1377 > > however, none of my tags are printed, which implies that the initialization > routines for both the board and sunxi_dram_init() are not called. > > I did configure logging to be pretty verbose in .config > # > # Logging > # > CONFIG_LOG=y > CONFIG_LOG_MAX_LEVEL=8 > CONFIG_LOG_DEFAULT_LEVEL=8 > CONFIG_LOG_CONSOLE=y > > I'm not sure what else could be wrong or how to go about it further. > > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/269f866e-7046-4eff-9c9b-b64788340cd3n%40googlegroups.com.
