Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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/20230821-ths-h616...@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 = 0x4a00
 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@402: 0
 Loading Environment from FAT... Unable to use mmc 0:1...
 In:serial@500
 Out:   serial@500
 Err:   serial@500
 Allwinner mUSB OTG (Peripheral)
 Net:   eth0: ethernet@502using 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@520: USB EHCI 1.00
 Bus usb@5200400: USB OHCI 1.0
 scanning bus usb@520 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 4fc0
 U-boot loaded from SD
 Boot script loaded from mmc
 156 bytes read in 4 ms (38.1 KiB/s)
 32823 bytes re

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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/
>  
> 
>
> 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 = 0x4a00
>>> 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@402: 0
>>> Loading Environment from FAT... Unable to use mmc 0:1...
>>> In:serial@500
>>> Out:   serial@500
>>> Err:   serial@500
>>> Allwinner mUSB OTG (Peripheral)
>>> Net:   eth0: ethernet@502using 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@520: USB EHCI 1.00
>>> Bus usb@5200400: USB OHCI 1.0
>>> scanning bus usb@520 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 4fc0
>>> 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 4fa0
>>> 4203 bytes read in 9 ms (456.1 KiB/s)
>>> Applying kernel provided DT fixup script (sun50i-h616-fixup.scr)
>>> ## Executing script at 4500
>>> 10936176 bytes read in 458 ms (22.8 MiB/s)
>>> 23570440 bytes read in 983 ms (22.9 MiB/s)
>>> Moving Image from 0x4008 to 0x402000

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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 = 0x4a00
>> 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@402: 0
>> Loading Environment from FAT... Unable to use mmc 0:1...
>> In:serial@500
>> Out:   serial@500
>> Err:   serial@500
>> Allwinner mUSB OTG (Peripheral)
>> Net:   eth0: ethernet@502using 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@520: USB EHCI 1.00
>> Bus usb@5200400: USB OHCI 1.0
>> scanning bus usb@520 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 4fc0
>> 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 4fa0
>> 4203 bytes read in 9 ms (456.1 KiB/s)
>> Applying kernel provided DT fixup script (sun50i-h616-fixup.scr)
>> ## Executing script at 4500
>> 10936176 bytes read in 458 ms (22.8 MiB/s)
>> 23570440 bytes read in 983 ms (22.9 MiB/s)
>> Moving Image from 0x4008 to 0x4020, end=4191
>> ## Loading init Ramdisk from Legacy Image at 4ff0 ...
>>Image Name:   uInitrd
>>Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
>>Data Size:10936112 Bytes = 10.4 MiB
>>Load Address: 
>>Entry Point:  
>>Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 4fa0
>>Booting using the fdt blob 

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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 = 0x4a00
> 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@402: 0
> Loading Environment from FAT... Unable to use mmc 0:1...
> In:serial@500
> Out:   serial@500
> Err:   serial@500
> Allwinner mUSB OTG (Peripheral)
> Net:   eth0: ethernet@502using 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@520: USB EHCI 1.00
> Bus usb@5200400: USB OHCI 1.0
> scanning bus usb@520 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 4fc0
> 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 4fa0
> 4203 bytes read in 9 ms (456.1 KiB/s)
> Applying kernel provided DT fixup script (sun50i-h616-fixup.scr)
> ## Executing script at 4500
> 10936176 bytes read in 458 ms (22.8 MiB/s)
> 23570440 bytes read in 983 ms (22.9 MiB/s)
> Moving Image from 0x4008 to 0x4020, end=4191
> ## Loading init Ramdisk from Legacy Image at 4ff0 ...
>Image Name:   uInitrd
>Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
>Data Size:10936112 Bytes = 10.4 MiB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 4fa0
>Booting using the fdt blob at 0x4fa0
> Working FDT set to 4fa0
>Loading Ramdisk to 49592000, end 4930 ... OK
>Loading Device Tree to 49521000, end 49591fff ... 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

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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 = 0x4a00
> 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@402: 0
> Loading Environment from FAT... Unable to use mmc 0:1...
> In:serial@500
> Out:   serial@500
> Err:   serial@500
> Allwinner mUSB OTG (Peripheral)
> Net:   eth0: ethernet@502using 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@520: USB EHCI 1.00
> Bus usb@5200400: USB OHCI 1.0
> scanning bus usb@520 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 4fc0
> 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 4fa0
> 4203 bytes read in 9 ms (456.1 KiB/s)
> Applying kernel provided DT fixup script (sun50i-h616-fixup.scr)
> ## Executing script at 4500
> 10936176 bytes read in 458 ms (22.8 MiB/s)
> 23570440 bytes read in 983 ms (22.9 MiB/s)
> Moving Image from 0x4008 to 0x4020, end=4191
> ## Loading init Ramdisk from Legacy Image at 4ff0 ...
>Image Name:   uInitrd
>Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
>Data Size:10936112 Bytes = 10.4 MiB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 4fa0
>Booting using the fdt blob at 0x4fa0
> Working FDT set to 4fa0
>Loading Ramdisk to 49592000, end 4930 ... OK
>Loading Device Tree to 49521000, end 49591fff ... 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_

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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 = 0x4a00
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@402: 0
Loading Environment from FAT... Unable to use mmc 0:1...
In:serial@500
Out:   serial@500
Err:   serial@500
Allwinner mUSB OTG (Peripheral)
Net:   eth0: ethernet@502using 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@520: USB EHCI 1.00
Bus usb@5200400: USB OHCI 1.0
scanning bus usb@520 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 4fc0
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 4fa0
4203 bytes read in 9 ms (456.1 KiB/s)
Applying kernel provided DT fixup script (sun50i-h616-fixup.scr)
## Executing script at 4500
10936176 bytes read in 458 ms (22.8 MiB/s)
23570440 bytes read in 983 ms (22.9 MiB/s)
Moving Image from 0x4008 to 0x4020, end=4191
## Loading init Ramdisk from Legacy Image at 4ff0 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:10936112 Bytes = 10.4 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
Working FDT set to 4fa0
   Loading Ramdisk to 49592000, end 4930 ... OK
   Loading Device Tree to 49521000, end 49591fff ... 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 overheati

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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/?

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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"  wrote: 
>>
>> Hi Andrew, 
>>
>> > background: 
>> > 
>> > currently Armbian linux use the 'mainline u-boot' 
>> > https://source.denx.de/u-boot/u-boot 
>>
>> Thanks

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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"  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 
>  
>
>
> 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! 
>
> Ch

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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"  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 
 


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 

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

['andrew g' via linux-sunxi]

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"  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 
 

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

Re: [linux-sunxi] u-boot: need help building for H618 Orange Pi Zero 3

[Andre Przywara]

On Thu, 18 Apr 2024 22:40:59 -0700 (PDT)
"'andrew g' via linux-sunxi"  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.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/20240422151530.3f26073f%40donnerap.manchester.arm.com.