Wolfgang Denk wrote: > That was on IRC; here the relevant snippet:
Thanks. Just to be clear, do you expect fdt_fw_addr always to point to a FIT-wrapped firmware binary? > (17:40:56) TimurTabi: also, the binding says that the qe firmware > node should be located inside the first qe node > (17:41:17) TimurTabi: and that the other qe nodes should have > phandles pointing to the firmware node in the first qe node > (17:41:53) wdenk_: TimurTabi: I do not care about QE... > (17:42:22) TimurTabi: wdenk1: I'm giving you an example of why we > can't treat embedded firmware blobs in the device tree in a > completely generic manner > (17:42:49) TimurTabi: the process of putting the firmware in the > device tree is specific to the type of firmware itself > (17:43:20) wdenk_: sorry, gotta run now > (17:43:30) TimurTabi: ok We never finished this discussion. My point was that even if the firmware is wrapped in a FIT image, the process by which the firmware is actually inserted into the device tree is specific to the actual firmware. You could even say it's board-specific. In contrast, you want the fdt relocation code to be able to increase the size of the fdt without knowing any details about the firmware itself. Therefore, there will be two pieces of code that references fdt_fw_addr. The first is in boot_relocate_fdt(), which will extract the size information from the FIT image that fdt_fw_addr points to. The second is the QE code which extracts the firmware from the FIT image and embeds it into the device tree, in a QE-specific way. I just want to make sure that we're on the same page. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
