too much black magic, should the 2 patches after all be committed to mainline u-boot?
On Friday, April 26, 2024 at 4:36:52 PM UTC+8 andrew g wrote: > 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...@somainline.org/ > > <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/174d23a4-14e3-458a-95a3-e55aa92da776n%40googlegroups.com.
