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/c931a67a-4de8-4d9f-b2e5-01a5bf7839e0n%40googlegroups.com.
