Hi Tom and Simon, On Fri, 28 Mar 2025 at 20:03, Tom Rini <[email protected]> wrote: > > On Fri, Mar 28, 2025 at 11:39:13PM +0000, Simon Glass wrote: > > Hi Raymond, > > > > On Fri, 28 Mar 2025 at 09:06, Raymond Mao <[email protected]> wrote: > > > > > > Hi Simon, > > > > > > On Fri, 28 Mar 2025 at 07:35, Simon Glass <[email protected]> wrote: > > > > > > > > Hi Raymond, > > > > > > > > On Thu, 27 Mar 2025 at 17:13, Raymond Mao <[email protected]> > > > > wrote: > > > > > > > > > > Point fdt_addr to the fdt embedded in the bloblist since fdt_addr > > > > > is a default address for bootefi, bootm and booti to look for the > > > > > device tree when launching the kernel. > > > > > > > > I wonder if we can drop use of that environment variable at some > > > > point? It seems strange to set a variable to gd->fdt_addr only to use > > > > it later. Why not just use gd->fdt_addr ? > > > > > > > > > > First, the fdtdec happens in an early stage and it is not able to set > > > the env variable at that time. > > > > No, I mean actually drop use of the environment var, so we wouldn't > > set it at all. > > The environment is for humans and also other use cases. It's not going > away. >
Since fdt_addr is used as a part of boot command in numerous projects, and it is a reality that "a fdt via bloblist" and "boot cmd with fdt_addr" can coexist if we cannot drop the env var from the boot command. This patch is trying to solve this in a compatible way, allowing users to pass a fdt_addr as a reference DT address, but U-Boot prioritizes on the fdt from bloblist if it exists - the var fdt_addr is treated as the final fdt address for kernel. I think we can add some documentation to describe this further, but generally I think the approach is simple and reasonable. Regards, Raymond > -- > Tom
