u-boot: need help building for H618 Orange Pi Zero 3

86 views
Skip to first unread message

andrew g

unread,
Apr 19, 2024, 1:40:59 AMApr 19
to linux-sunxi
background: 

currently Armbian linux use the 'mainline u-boot' 
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

what I tried and issues:
I'm building u-boot from
basically following these instructions

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()
and
sunxi_dram_init()

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.


Message has been deleted

andrew g

unread,
Apr 19, 2024, 1:53:11 AMApr 19
to linux-sunxi
Note that in the actual Armbian builds

u-boot in/from the image reports 2GB memory for the 1.5G board. Just that after I build u-boot from source as in prior comment, I got 0 bytes instead.

andrew g

unread,
Apr 19, 2024, 5:07:06 AMApr 19
to linux-sunxi
a little closer I found the call chain / boot sequence

arch/arm/cpu/armv8/start.S _start()
-> arch/arm/lib/crt0_64.S _main()
apparently
sunxi_board_init
DRAM:sunxi_dram_initshift 116 memsize 0
 0 MiB

mctl_calc_size()

apparently I edited my copy of the codes incorrectly, hence the incorrect DRAM size determined

Andre Przywara

unread,
Apr 22, 2024, 10:15:37 AMApr 22
to 'andrew g' via linux-sunxi, goha...@yahoo.com
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

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

andrew g

unread,
Apr 25, 2024, 1:45:06 AMApr 25
to 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'

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
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 
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.
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)

andrew g

unread,
Apr 25, 2024, 1:49:28 AMApr 25
to linux-sunxi
oops the 1st link should be
with the spoiler in it

the comment ref should be 188030 rather than 188328

andrew g

unread,
Apr 25, 2024, 2:07:45 AMApr 25
to 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.

andrew g

unread,
Apr 25, 2024, 2:19:01 AMApr 25
to 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.

andrew g

unread,
Apr 25, 2024, 3:35:00 AMApr 25
to 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 

andrew g

unread,
Apr 25, 2024, 4:56:54 AMApr 25
to 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 = 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.

Message has been deleted

andrew g

unread,
Apr 25, 2024, 5:26:21 AMApr 25
to 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

Armbian has 'official' ones here, based on 6.6.x as seen on the page, scroll right below for the links
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

andrew g

unread,
Apr 26, 2024, 4:36:52 AMApr 26
to 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

for THS (thermal sensor) ref:

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

andrew g

unread,
Apr 26, 2024, 4:54:33 AMApr 26
to linux-sunxi
too much black magic, should the 2 patches after all be committed to mainline u-boot?

andrew g

unread,
Apr 28, 2024, 11:11:12 AMApr 28
to linux-sunxi
a fix/hack/solution is implemented and shared till something better comes along
Reply all
Reply to author
Forward
0 new messages