[SOLVED] Custom u-boot for Rock64 with downclocked DDR

[viacheslav]

Hello here.

I'm trying to run Arch on Rock64 board from SD card. I'm following official guide at https://archlinuxarm.org/platforms/armv ... hip/rock64.
Setup is quite unstable, alarm is able to boot once in 5-10 attempts. Usually I have kernel panic at different boot stages.
Board and SD card a-ok as I can run other distros w/o problems.

Reading different threads in this form and on pine64 I suspect that the problem is with high DDR clock set by Arch uboot (800Mhz). Other distro which is rather stable set it to 786Mhz. Thus I'm looking for a way how to use another u-boot build.

I found different threads (rather old) where folks is patching Arch u-boot images with binaries from rockchip. But nothing is working for me.

I'm trying to build custom u-boot following this guide https://github.com/u-boot/u-boot/blob/m ... ckchip.rst
Build is ok, I flash new u-boot to SD.

Boot process fails with following:
$this->bbcode_second_pass_code('', 'U-Boot TPL 2023.07-rc1-00158-gab75996ba4 (May 06 2023 - 11:20:23)
LPDDR3, 800MHz
BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2023.07-rc1-00158-gab75996ba4 (May 06 2023 - 11:20:23 +0300)
Trying to boot from MMC1
NOTICE: BL31: v2.8(release):c194aa0
NOTICE: BL31: Built : 09:21:05, May 6 2023
NOTICE: BL31:Rockchip release version: v1.2


U-Boot 2023.07-rc1-00158-gab75996ba4 (May 06 2023 - 11:20:23 +0300) Arch Linux ARM

Model: Pine64 Rock64
DRAM: 4 GiB
PMIC: RK8050 (on=0x40, off=0x00)
Core: 230 devices, 24 uclasses, devicetree: separate
MMC: mmc@ff500000: 1, mmc@ff520000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In: serial@ff130000
Out: serial@ff130000
Err: serial@ff130000
Model: Pine64 Rock64
Net: eth0: ethernet@ff540000
Hit any key to stop autoboot: 2 <0x08><0x08><0x08> 1 <0x08><0x08><0x08> 0
Card did not respond to voltage select! : -110
Bus usb@ff5c0000: ehci_generic usb@ff5c0000: Failed to get clocks (ret=-19)
Port not available.
Bus usb@ff5d0000: USB OHCI 1.0
Bus usb@ff580000: USB DWC2
scanning bus usb@ff5d0000 for devices... 1 USB Device(s) found
scanning bus usb@ff580000 for devices... 1 USB Device(s) found
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000
ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@ff540000')

Comparing it to original Arch u-boot log the problem begins here $this->bbcode_second_pass_code('', 'Card did not respond to voltage select! : -110')
for some reason u-boot doesn't try to boot from SD card. Instead it tries to connect eth and boot from tftp (when I connect ethernet).

What could be the problem? Why u-boot refuses to continue boot from SD? Maybe it unable to find root partition which starts at 32768 in Arch?
I'm trying to find .config file which is used by Arch to build their u-boot but no luck. Does anyone know where to find it? I'd like to compare it with mine. Maybe there is some specific setting there?

Thanks.

[Kabbone]

I didn't update the rock64 for a long time because it's in the drawer, so I can't say if this still works.
Here is how I have done it back then. But if you update u-boot didn't they lower the frequency upstream in U-boot? No idea about the version in Arch right now.

[viacheslav]

Kabbone, thanks for helping. No, seems like it is still 800 MHz (however there is option for 333). But honestly I don't think there is much sense to downclock DDR for _all_ if there is problems with _some_ h/w. But digging this forum and pine64 I have to admit this is quite common issue for Rock64. Thus it would be nice to have this issue described in the wiki with explicit instructions what to do. Maybe even publish alternative u-boot with reduced DDR freq for "lucky" owners of buggy h/w.

As for the original issue I reported -- I managed to work it around. Seems like this is some regression in u-boot master branch. I switched to latest stable release (v2023.04) and issue gone.

Summarizing, as of today (2023) the solution which works for me is following:
1. Get latest upstream u-boot https://github.com/u-boot/u-boot
2. Switch to stable release (v2023.04 in my case)
3. Patch sources as it is done here. i.e. $this->bbcode_second_pass_code('', 'diff --git a/arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi b/arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
index 07f27b2b7b..e8f693343c 100644
--- a/arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
+++ b/arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
@@ -26,7 +26,7 @@
0x00000432
0x000000ff

- 800
+ 600
6
1
0
')
4. Build image following official guide for rk3328. For me: $this->bbcode_second_pass_code('', '
$ make rock64-rk3328_defconfig
$ make CROSS_COMPILE=aarch64-unknown-linux-gnu-')
(don't forget to build TF-A first)
5. Flush image. As of now you need only single image$this->bbcode_second_pass_code('', 'dd if=u-boot-rockchip.bin of=/dev/mmcblk0 seek=64 conv=notrunc')

Alternatively, if you don't have cross-dev toolchain for compiling it from x86_64, but have aarch64 box with docker, you can follow this approach. However it requires small updates in my case. I used:$this->bbcode_second_pass_code('', 'FROM debian:10.4
RUN apt-get update
RUN apt-get upgrade -y
RUN apt-get install -y build-essential git gcc-arm-none-eabi device-tree-compiler bison flex swig libssl-dev python3 python3-distutils python3-dev python3-setuptools
python3-pyelftools
RUN git clone https://github.com/ARM-software/arm-trusted-firmware
WORKDIR /arm-trusted-firmware
RUN find . -name '*.bin' -exec rm -rf {} \;
RUN make PLAT=rk3328
WORKDIR /
ENV BL31=/arm-trusted-firmware/build/rk3328/release/bl31/bl31.elf
#This place is slow, using github mirror instead
#RUN git clone https://gitlab.denx.de/u-boot/u-boot.git/
RUN git clone https://github.com/u-boot/u-boot.git
WORKDIR /u-boot
RUN git checkout v2023.04
RUN sed -i 's/800/600/g' arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
RUN make rock64-rk3328_defconfig
RUN sed -i 's/CONFIG_IDENT_STRING=""/CONFIG_IDENT_STRING=" Arch Linux ARM"/' .config
RUN make
')
this will make u-boot-rockchip.bin with 600 MHz DDR for you (this is the only image you need to flush).

In my case 600 MHz DDR setting helped to fix random crashes during boot. Will test how it works under load.

Thanks.

[Kabbone]

In the end it looks the same as what I did, just edit the clock down in the *1600.dtsi.
Before I did that I had random memory failures, every checksum seemed to be different on the same file. Afterwards it was stable.

[summers]

Yes find what sets it the device tree. Then have uboot rewrite the device tree. Done it on a few machines here - probably do instructions tomorrow.

on a nsa325 I did $this->bbcode_second_pass_code('', 'loadfdt=echo loading ${fdtdir}/${fdtfile} ...; load ${devtype} ${bootpart} ${fdtaddr} ${fdtdir}/${fdtfile}; fdt addr ${fdtaddr}; fdt set /mbus@f1000000/nand@12f chip-delay <45>')

and on an odroid-c2 I did $this->bbcode_second_pass_code('', 'if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /boot/Image; then
if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
fdt addr ${fdt_addr_r}
fdt set /soc/apb@d0000000/mmc@74000 max-frequency <0x08f0d180>
if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
booti ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi
')