Hello,
we bought new Rock 4 B+ with 32 eMMC storage. Installed Debian Bullseye image from Radxa github repository using the official guide: https://wiki.radxa.com/Rockpi4/dev/usb-install
It works but it takes very long time before the system starts booting. Although HDMI monitor is connected it shows nothing during this time - no signal. Only Ethernet is blinking and green LED is on. After about 1 minute, the blue LED starts blinking, the system boots and image on monitor is displayed.
This delay is not acceptable for us.
What’s going on? How to fix it?
Thank you!
Official software is here to demonstrate what hardware can do, that you can verify if you have connected power and monitor correctly. For professional grade software support you need to look elsewhere: Yocto, Armbian, BalenaOS, Buildroot while investing your time for your problems. This doesn’t look like a home user problem.
Right, use different software, for example Armbian which does not have this boot delay but none of the basic features that works on Radxa images (such as getting CPU temperature, Raspberry Pi display, OpenCL etc.) work there.
I made an account just to say this, it’s people like you that make this industry worse off.
Basic functionality working is a requirement every manufacturer must adhere to. This is 2023 and there is an expectation that if i buy hardware from a manufacturer I expect the software they provided should work with it. This is why raspberry pi dominates, if radxa is making rock PI 4 as an alternative they should also provide working software with it.
To actually answer your question unlike the other guy, I have a rock pi 4 se with a similar issues and I found with this board its usually due to the power provided, if its not receiving full power it sometimes takes a while to boot. Check your power supply and check your cable, cables affect it more than you realize.
Thank you! The power is the first idea that got into my mind but since Armbian starts correctly, it probably won’t be the issue.
I started studying it more and I found that a new image on SD card has delay of 10 seconds only (the first line of kernel log does not start at zero timestamp but at about 11 secs). This perfectly corresponds to u-boot’s default timeout which is probably hardcoded. When I write the image to eMMC, the delay increases to 50 seconds (kernel starts at about 51 secs) which makes the feeling that the device does not work after powering up. I have not studied the sources deeply but I found that some u-boots have actually the default timeout set to 50.
extlinux.conf contains timeout settings (val=10) as val/10, so it probably just adds one additional second but does not influence u-boot’s timeout.
So I think that the only way to reduce the delay is build own version of u-boot. This can be done but I’m not sure if it is the correct way - you need to rebuild the u-boot on every update just due to the one timeout value.
I will investigate this further, after I had this issue i changed my power source and updated my boot-loader using rsetup. That didn’t help much in my case but there is a OTG switch under the USB ports putting this on the right when the board is horizontal removed my long boot times, maybe in host mode the boot-loader is waiting for USB inputs and then timing out ? I didn’t get a chance to look at source as to why this helped yet.
So I build my own bullseye image with kernel and uboot. BOOTDELAY is set to 0 in uboot’s config file.
I also change my power source to PD451A USB-C PD 45W.
When I boot from SD card, it takes about 10 seconds before something starts happening after powering up. HDMI display tlights on for about 10 seconds, then some blue-yellow pattern appears for a few seconds and system starts booting.
When I write image to internal eMMC, the delay is longer. HDMI display lights on but no image is visible. It lights off after about 10 seconds. After another 10 seconds system is booted.
when OTG switch is set to OTG mode:
[ 20.397244] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
when OTG switch is set to HOST mode:
[ 15.944081] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
Fortunately, the long 50 second delay has gone, but it is still slower from eMMC than from SD card. But now it is acceptable.
So I finally was able to do some measurement using the serial console and I found that the most of the time in U-Boot is spent with USB scanning. This takes about 10 seconds. I compared Radxa vs Armbian and noticed that Armbian’s U-Boot does not use “preboot” that starts USB initialization before booting.
I guess this is done to support USB keyboard in bootmenu. Since display (HDMI/DSI) is disabled in U-Boot, I see this as unnecessary. Since we don’t use USB/network boot, I disabled USB/Network in U-Boot completely and now it boots much faster.
# CONFIG_NET is not set
# CONFIG_USB is not set
# CONFIG_USE_PREBOOT is not set
Additional 3 seconds are taken by loading a kernel image. It’s only a minor time but if someone wants fastest boot as possible the question could be why loading 28 MB file takes 3 seconds.
