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" <[email protected]> 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/[email protected]/T/#u > <https://lore.kernel.org/u-boot/[email protected]/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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/cd0a5f1d-833c-4e0e-b46a-bed8b3b0928cn%40googlegroups.com.
