VisionFive 2： U-Boot Fails to Autoboot openEuler from SD Card; HDMI Non-Functional After Workaround

[is-northfish]

1. Environment:

Board: StarFive VisionFive V2 (4GB LPDDR4)
U-Boot Version: U-Boot 2021.10 (May 07 2025 - 15:41:57 +0800), Build: jenkins-github_visionfive2_6.6-10
Operating System: openEuler 22.03 LTS (RISC-V 64-bit)
Kernel Version: 5.15.0-3.oe2203.riscv64
Boot Medium: SD Card (mmc1)
SD Card Layout: GPT partitioned. Boot files (extlinux.conf, kernel, initramfs, DTB, uEnv.txt) are on partition 2 (mmc1:2, FAT32/ESP). Rootfs is on partition 3 (mmc1:3).

2. Bug Description (Original U-Boot Autoboot Failure):
   The default U-Boot environment fails to automatically boot openEuler from the SD card (mmc1). Key issues identified in the U-Boot autoboot scripts (primarily related to bootcmd calling sdk_boot_env and distro_boot_env, which in turn use bootmode=flash and iterate through mmc_devnum_l=1 0):

MMC Initialization Failure: The distro_mmc_test_and_boot script (when devnum=1 for SD card) fails at the mmc dev 1 command or subsequent access, leading to errors:

Card did not respond to voltage select! : -110
Can't set block device
Error reading config file /extlinux/extlinux.conf This appears to be due to a missing mmc rescan command after mmc dev 1 in the automated script, which is necessary for reliable SD card access with this setup. Manual execution of mmc dev 1; mmc rescan works.

Incorrect Boot Partition Variable: The U-Boot environment variable bootpart defaults to 3. However, extlinux.conf and uEnv.txt are located on partition 2. This causes bootcmd_distro (specifically the sysboot command: sysboot ${bootdev} ${devnum}:${bootpart} fat ...) to look for boot files on the wrong partition (mmc1:3).

Undefined Variable Call: The mmc_test_and_boot script (called by sdk_boot_env) attempts to run boot2, but boot2 is undefined, causing an error message.

3. Workaround/Fix Implemented (U-Boot Environment):
   The following U-Boot commands were applied and saved to SPI Flash to enable successful automatic booting from the SD card:

setenv boot2 true

setenv boot_oe_sd 'echo Attempting to boot openEuler from SD Card (mmc1)...;
mmc dev 1;
if test $? -eq 0; then
mmc rescan;
echo Setting boot parameters for mmc1 partition 2...;
setenv devnum 1;
setenv bootdev mmc;
setenv bootpart 2;
setenv boot_syslinux_conf extlinux/extlinux.conf;
setenv bootenv boot/uEnv.txt;
setenv loadaddr 0x50000000;
setenv scriptaddr ${loadaddr};
echo Running bootcmd_distro...;
run bootcmd_distro;
else
echo Failed to select mmc dev 1.;
fi'

setenv bootcmd 'run boot_oe_sd; echo boot_oe_sd finished, falling back to original boot sequence if needed...; run sdk_boot_env; run distro_boot_env'

saveenv

This workaround ensures mmc dev 1 is followed by mmc rescan, and bootpart is correctly set to 2 before bootcmd_distro (which contains sysboot) is executed for the SD card.

4. Bug Description (New Issue After Applying Workaround):
   After successfully booting into openEuler using the U-Boot environment workaround described above, the HDMI display output is not functional. The system boots, and serial console access is fine, but no output is observed on a connected HDMI monitor.

Note: During the U-Boot phase of a successful manual boot (which used similar logic to the boot_oe_sd script), several libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND warnings were observed prior to kernel startup. This may or may not be related.
5. Impact:

The original U-Boot environment prevents reliable SD card booting of standard Linux distributions like openEuler without manual U-Boot intervention.
The workaround enabling SD card boot currently leads to a loss of HDMI functionality, hindering GUI-based usage.
6. Request for Investigation:

Please investigate the default U-Boot scripts (sdk_boot_env, distro_boot_env, and their components like distro_mmc_test_and_boot, mmc_test_and_boot) for mmc devices to ensure:
Proper MMC device initialization (including mmc rescan where necessary).
Correct determination of the boot partition (e.g., bootpart or distro_bootpart) when scanning for bootable configurations like extlinux.conf.
Resolution of undefined variable calls (e.g., boot2).
Please investigate the cause of the HDMI output failure when the system is booted using the described U-Boot environment workaround. This could involve checking U-Boot's FDT handling, memory map usage by the loaded components (kernel, initramfs, DTB at addresses specified in uEnv.txt), or any U-Boot initializations that might be inadvertently bypassed or altered by the custom boot script, affecting subsequent kernel-level HDMI driver initialization.

[is-northfish]

Please note that the solution I provided is not perfect. In the initial tests, although the serial port printed information indicating a successful entry into the OpenEuler 22.04 system, the screen still displayed no image after connecting an HDMI device. Additionally, I have not tested whether the modified U-Boot can boot the original image that was previously able to start normally. Moreover, the existing firmware can actually boot the Debian image provided by Starfive normally, and all peripherals, including the GPU, work perfectly. The issue I discovered is limited only to the inability to boot the OpenEuler 22.03 image.