[PATCH 2/2] env: point fdt address to the fdt in a bloblist
Raymond Mao
raymond.mao at linaro.org
Sat Mar 29 01:51:09 CET 2025
Hi Tom and Simon,
On Fri, 28 Mar 2025 at 20:03, Tom Rini <trini at konsulko.com> 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 <raymond.mao at linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, 28 Mar 2025 at 07:35, Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > Hi Raymond,
> > > >
> > > > On Thu, 27 Mar 2025 at 17:13, Raymond Mao <raymond.mao at linaro.org> 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
More information about the U-Boot
mailing list