I just did that test, I removed that 1.5GB hardcoding from mainline u-boot build as of current memsz = 2048UL * 1024UL * 1024UL * 3 / 4;
patched the hacked u-boot into my Armbian (Debian bookworm, linux 6.7) image. I got the same U-Boot 2024.04-00757-FixOPiZero3_1.5G ... Starting kernel ... [ 2.145316] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down [ 2.153753] reboot: HARDWARE PROTECTION shutdown (Temperature too high) [ 2.180852] reboot: Power down message on a 2 GB board, so I'm missing something that is there in Armbian u-boot On Thursday, April 25, 2024 at 2:19:01 PM UTC+8 andrew g wrote: > 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/d6076daf-a32c-4f86-ade6-a564fdbe78d2n%40googlegroups.com.
