Hi Stephen,
Looks good to me then. I wasn't sure how U-Boot was typically used on the RPi.
Regards, Jonathan
On Sunday, 7 February 2016, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/06/2016 12:30 AM, Jonathan Liu wrote:
Hi Stephen,
I actually read the DT loaded by RPi's binary firmware on an RPi 2 in a U-Boot script: fdt addr ${fdt_addr_r} && fdt get value bootargs /chosen bootargs fatload mmc 0:1 ${kernel_addr_r} uImage bootm ${kernel_addr_r} - ${fdt_addr_r}
Essentially this loads the kernel with the same arguments and DT that RPi's binary firmware would have used if it booted the kernel directly with device tree support. This allows for the normal patching of the kernel arguments and device tree to be done by the RPi binary firmware so that things like reading the serial number in /proc/cpuinfo works.
A trailer is added to u-boot.bin with "mkknlimg --dtok u-boot.bin u-boot.bin" for the FW to enable device tree support and load the patched device tree to 0x00000100.
So I am not sure about the comment that the DT loaded by the FW is typically ignored by U-Boot scripts.
This is a very unusual use-case. Typically the reason for using U-Boot in the first place is so that U-Boot has full control over the kernel, DT, and command-line. This way, users can configure all these aspects the exact same way on an RPi running U-Boot as on any other system running U-Boot. Mixing configuration between config.txt and the scripts/config-files that U-Boot reads/executes isn't typical, since it involves board-specific config file. As such, I believe the comment is correct for the common case, and already admits that other cases are possible.