the statment >> 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.
isn't really correct, with *stock* Armbian u-boot (which is based on mainline) it boots 1G, 2G, 4G 'standard' H618 (Orange Pi Zero 3) boards. I'm not too sure if I'd build mainline u-boot from the trunk as of current, if that 'just works'. that 'gpu overheating' thing is seen after I 'solved' the '1.5G issue' with the hack, then comes the 'gpu overheating' message, and it is reproducible on my 1.5G board practically for all boots. I simply install and replace u-boot over that in the distribution in the sd-card. On Thursday, April 25, 2024 at 2:07:45 PM UTC+8 andrew g wrote: > on a 'longer term', if after all this *hack* (hard coding memory size) > works, I'd guess a possible way is to read custom memory size from an > 'environment variable' say set by scripts in /boot/boot.scr or > /boot/boot.cmd in the root partition > or perhaps in a DTS overlay. There is a 'chicken and egg' problem as > u-boot needs to setup and initialize dram and relocate itself into dram to > run for H616 and H618. The hack by hardcoding dram works, but I'd guess > that reading /parsing /boot/boot.scr or /boot/boot.cmd would need to be > done in the relocated u-boot. > > On Thursday, April 25, 2024 at 1:49:28 PM UTC+8 andrew g wrote: > >> oops the 1st link should be >> >> https://forum.armbian.com/topic/29202-orange-pi-zero-3/page/20/#comment-188030 >> with the spoiler in it >> >> the comment ref should be 188030 rather than 188328 >> >> >> On Thursday, April 25, 2024 at 1:45:06 PM UTC+8 andrew g wrote: >> >> 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/5e3bd3cb-3b58-4f47-a34d-dbbb578d9207n%40googlegroups.com.
