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.

Reply via email to