just in case anyone has a board and wants to try it out, the image for Orange Pi Zero 3 I'm messing with is this, note *unofficial* https://www.mediafire.com/file/bym559l94sn8xyd/Armbian-unofficial_24.5.0-trunk_Orangepizero3_bookworm_edge_6.7.10_minimal20240320.7z/file
Armbian has 'official' ones here, based on 6.6.x as seen on the page, scroll right below for the links https://www.armbian.com/orange-pi-zero-3/ in my own tests the 'official' ones has a 'goofed' /boot/boot.scr or /boot/boot.cmd the last time (days ago) I checked, it is the reason I'm testing my 1.5 G hack on my images which is build from the armbian build framework https://github.com/armbian/build On Thursday, April 25, 2024 at 4:56:54 PM UTC+8 andrew g wrote: > Applied 2 cortex_a53 erratum for BL31 stage in arm trusted firmware > INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied > INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied > > still not getting past that 'gpu overtemperature' bug. full boot messages: > full boot log: > U-Boot SPL 2024.04-00757-FixOPiZero3_1.5G (Apr 25 2024 - 16:47:05 +0800) > sunxi_board_init > DRAM:sunxi_dram_initdetected memsize 2048 M > 2048 MiB > spl_board_init_r > > Trying to boot from MMC1 > NOTICE: BL31: v2.10.0(debug):v2.10.0-729-gc8be7c08c > NOTICE: BL31: Built : 16:43:26, Apr 25 2024 > > NOTICE: BL31: Detected Allwinner H616 SoC (1823) > NOTICE: BL31: Found U-Boot DTB at 0x4a0b4330, model: OrangePi Zero3 > INFO: ARM GICv2 driver initialized > INFO: Configuring SPC Controller > INFO: PMIC: Probing AXP305 on RSB > > ERROR: RSB: set run-time address: 0x10003 > INFO: Could not init RSB: -65539 > INFO: BL31: Platform setup done > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied > INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied > INFO: PSCI: Suspend is unavailable > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x4a000000 > INFO: SPSR = 0x3c9 > INFO: Changed devicetree. > > U-Boot 2024.04-00757-FixOPiZero3_1.5G (Apr 25 2024 - 16:47:05 +0800) > Allwinner Technology > > > CPU: Allwinner H616 (SUN50I) > Model: OrangePi Zero3 > DRAM: 2 GiB > Core: 58 devices, 25 uclasses, devicetree: separate > WDT: Not starting watchdog@30090a0 > MMC: mmc@4020000: 0 > Loading Environment from FAT... Unable to use mmc 0:1... > In: serial@5000000 > Out: serial@5000000 > Err: serial@5000000 > Allwinner mUSB OTG (Peripheral) > Net: eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS > ep2in > MAC de:ad:be:ef:00:01 > HOST MAC de:ad:be:ef:00:00 > RNDIS ready > , eth1: usb_ether > starting USB... > Bus usb@5200000: USB EHCI 1.00 > Bus usb@5200400: USB OHCI 1.0 > scanning bus usb@5200000 for devices... 1 USB Device(s) found > scanning bus usb@5200400 for devices... 1 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found U-Boot script /boot/boot.scr > 3259 bytes read in 4 ms (794.9 KiB/s) > ## Executing script at 4fc00000 > U-boot loaded from SD > Boot script loaded from mmc > 156 bytes read in 4 ms (38.1 KiB/s) > 32823 bytes read in 10 ms (3.1 MiB/s) > Working FDT set to 4fa00000 > 4203 bytes read in 9 ms (456.1 KiB/s) > Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) > ## Executing script at 45000000 > 10936176 bytes read in 458 ms (22.8 MiB/s) > 23570440 bytes read in 983 ms (22.9 MiB/s) > Moving Image from 0x40080000 to 0x40200000, end=41910000 > ## Loading init Ramdisk from Legacy Image at 4ff00000 ... > Image Name: uInitrd > Image Type: AArch64 Linux RAMDisk Image (gzip compressed) > Data Size: 10936112 Bytes = 10.4 MiB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > ## Flattened Device Tree blob at 4fa00000 > Booting using the fdt blob at 0x4fa00000 > Working FDT set to 4fa00000 > Loading Ramdisk to 49592000, end 49ffff30 ... OK > Loading Device Tree to 0000000049521000, end 0000000049591fff ... OK > Working FDT set to 49521000 > > Starting kernel ... > > [ 2.149838] thermal thermal_zone0: gpu-thermal: critical temperature > reached, shutting down > [ 2.158312] reboot: HARDWARE PROTECTION shutdown (Temperature too high) > [ 2.192000] reboot: Power down > --- > > this is on a 2 GB board where the 'stock' Armbian u-boot boots just fine. > this doesn't have that 1.5GB hard coding. > > On Thursday, April 25, 2024 at 3:35:00 PM UTC+8 andrew g wrote: > >> 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/4551cbb3-8c1f-4246-ab61-39819922f42en%40googlegroups.com.
