damn, it booted to the prompt on 1.5G with the hack after applying these 2 patches https://github.com/armbian/build/blob/main/patch/u-boot/u-boot-sunxi/allwinner-h616-THS-workaround.patch https://github.com/armbian/build/blob/main/patch/u-boot/u-boot-sunxi/allwinner-h616-GPU-enable-hack.patch
for THS (thermal sensor) ref: https://patchwork.kernel.org/project/linux-pm/patch/20230821-ths-h616-v2-2-cda60d556...@somainline.org/ I'm not too sure why it didn't work if I did not enable the GPU as well. I'd think these are more appropriate for the (linux) kernel drivers to initialize them uname -a Linux orangepizero3 6.7.10-edge-sunxi64 #2 SMP Sat Mar 16 02:22:41 +08 2024 aarch64 GNU/Linux On Thursday, April 25, 2024 at 5:26:21 PM UTC+8 andrew g wrote: > 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*, and this link > won't be there on a permanent basis > > 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/b146c45b-4389-4cca-ba8b-682f6c03d026n%40googlegroups.com.
