Tinkerboard R2.0 Dietpi powers off during boot if powered only over GPIO

Hello, everyone, occasional DietPi enjoyer, first-time caller. Just got an Asus Tinkerboard R2.0 (no eMMC onboard) at work to try and get an internal tool running on it, ran into a problem that might be either u-boot related or DietPi related.

DietPi version: 8.7.1/master
Distro Version: bullseye ($G_RASPBIAN is empty)
Kernel version: Linux DietPi 5.15.48-rockchip #22.05.3 SMP PREEMPT Wed Jun 22 07:34:52 UTC 2022 armv7l GNU/Linux

  • SBC model | ASUS Tinker Board (armv71) (Asus tinker board R2.0 in reality)
  • Power supply used | Raspberry Pi 5V/3A or GPIO - more in the description
  • SD card used | Kingston 8 GB

The image was freshly burned to the SD card using WinImg32. When powering on using USB PSU, the device boots up properly, I can immediately SSH to it and update to latest, I can install userspace tools such as git without issues.

However, when the device is powered on over GPIO pins 2&4 (+5V), the device supposedly passes through uBoot, clears the screen and moves onto (what I assume is) the Kernel boot

[timestamp1] rockchip_pll_wait_lock: timeout waiting for pll to lock
[timestamp2] rockchip-spi_ff130000.spi: csl >= max 1
[timestamp3] spi_master_spi2: spi_device_register_error /spi@ff130000/spidev@1
[timestamp4] rk_gmac_dwmac ff29000.ethernet: cannot get clock clk_mac_speed

However, it halts at this log output for two seconds and immediately powers off.

Disconnecting the GPIO power and reattaching the USB PSU lets it boot properly again.

Is this a hardware problem with the power rails? Is this solvable using rewiring (i.e. powering through USB and the GPIO +5V pins atthe same time)? I read a related thread on the Armbian forum that blamed u-boot for the power management problems, but that was supposedly fixed soon after, the thread is from six years ago anyway and I would assume this version of DietPi already has an included fix.

Thanks in advance for any help.

Welcome to our community forum and thanks for your report.

Probably the issue was re-introduced, could be in U-Boot, kernel or device tree, I guess. Can you try to flash the latest U-Boot:

. /usr/lib/u-boot/platform_install.sh
sudo write_uboot_platform "$DIR" "$(lsblk -no PKNAME "$(findmnt -no SOURCE /)")"