a fix/hack/solution is implemented and shared till something better comes along https://github.com/ag88/1.5GB_Fix_for_Armbian_on_OrangePiZero3
On Friday, April 26, 2024 at 4:54:33 PM UTC+8 andrew g wrote: > 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/[email protected]/ >> >> <https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/> >> >> 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" <[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/ccc5ec96-ae27-4686-b90e-272876e6dd7en%40googlegroups.com.
