I'm building a Yocto image for the CM4 and included U-Boot with the intention of using it to read GPIO pins. Based on the pin values, I wanted U-Boot to dynamically select and load the appropriate Device Tree (DT) file for different hardware revisions. However, I encountered an unexpected behavior.
The first stage bootloader, which is already present on the CM4, seems to be doing most of the work. It retrieves the correct DT file based on the hardware revision, places it at the designated memory address (FDT address), and then hands it off to the kernel. Unfortunately, attempts to modify this behavior by loading a different DT file within U-Boot itself proved unsuccessful.
This essentially renders U-Boot somewhat redundant in this scenario. Since the first stage bootloader pre-configures everything, including the DT file, U-Boot doesn't have the ability to make changes or override these settings. This raises the question: why include U-Boot at all if it can't fulfill the intended purpose of dynamically selecting and loading the DT file based on GPIO readings?
The first stage bootloader, which is already present on the CM4, seems to be doing most of the work. It retrieves the correct DT file based on the hardware revision, places it at the designated memory address (FDT address), and then hands it off to the kernel. Unfortunately, attempts to modify this behavior by loading a different DT file within U-Boot itself proved unsuccessful.
This essentially renders U-Boot somewhat redundant in this scenario. Since the first stage bootloader pre-configures everything, including the DT file, U-Boot doesn't have the ability to make changes or override these settings. This raises the question: why include U-Boot at all if it can't fulfill the intended purpose of dynamically selecting and loading the DT file based on GPIO readings?
Statistics: Posted by funkpunkt — Wed Jun 12, 2024 8:23 am