[PATCH 1/4] fdt: add support for adding pmem nodes

Sughosh Ganu sughosh.ganu at linaro.org
Mon Dec 2 10:54:02 CET 2024


On Mon, 28 Oct 2024 at 22:32, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Sughosh,
>
> On Mon, 28 Oct 2024 at 12:29, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> >
> > On Sun, 27 Oct 2024 at 20:30, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Fri, 25 Oct 2024 at 13:15, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> > > >
> > > > From: Masahisa Kojima <kojima.masahisa at socionext.com>
> > > >
> > > > One of the problems OS installers face, when running in EFI, is that
> > > > the mounted ISO after calling ExitBootServices goes away. For some
> > > > distros this is a problem since they rely on finding some core packages
> > > > before continuing the installation. Distros have works around this --
> > > > e.g Fedora has a special kernel command line parameter called
> > > > inst.stage2 [0].
> > > >
> > > > ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we
> > > > don't have anything in place for DTs. Linux and device trees have support
> > > > for persistent memory devices. So add a function that can inject a pmem
> > > > node in a DT, so we can use it when launhing OS installers with EFI.
> > > >
> > > > [0]
> > > > https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options#sect-boot-options-installer
> > > >
> > > > Signed-off-by: Masahisa Kojima <kojima.masahisa at socionext.com>
> > > > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> > > > ---
> > > >  boot/fdt_support.c    | 41 +++++++++++++++++++++++++++++++++++++++--
> > > >  include/fdt_support.h | 13 +++++++++++++
> > > >  2 files changed, 52 insertions(+), 2 deletions(-)
> > >
> > > Can you please use the ofnode interface for this? We are trying not to
> > > add more of this kind of fixup, as it means someone will have to port
> > > it over later.
> > >
> > > See EVT_FT_FIXUP
> >
> > Are you suggesting using the EVT_FT_FIXUP interface for adding the
> > pmem node? If so, how does this work on platforms which enable
> > livetree? Looking at the code, I see that the EVT_FT_FIXUP gets called
> > only when the livetree is not active. However, I am not able to find
> > any place where the livetree is getting disabled. We do have a
> > function, oftree_to_fdt() which flattens a livetree, but I don't see
> > it getting called from anywhere except from a 'upl' command. The
> > of_root pointer does get set in initr_of_live(), but apart from
> > dm_test_pre_run(), I do not see where we disable the livetree and set
> > of_root to NULL.
> >
> > So on platforms which do enable livetree, how does this fixup work?
> > What am I missing?
>
> It isn't implemented yet for OF_LIVE in image_setup_libfdt(). Most of the code is there though. It just needs to be hooked up - see oftree_to_fdt() and oftree_from_fdt().
>
> The idea would be to remove the of_live_active() check, so the event is always sent (will need to 'select EVENT' for OF_LIVE).
>
> Then in that same code, after the event, call oftree_to_fdt() and copy the fdt back to blob.

Sorry, I got pulled into other tasks, so could not reply to this
earlier. Looking at the code, I don't think that using livetree is a
good use-case in this context. What is happening here is that the
image_setup_libfdt() function gets called for fixing up the devicetree
before the OS is called. However, in this case, we cannot assume that
the FDT that is being passed to the OS is the same as the livetree.
What that means is that it would be required to first convert the FDT
to a livetree, apply the fixup's and then again convert the livetree
back to FDT. I can understand why you would want to convert a FDT to a
livetree during init, and then use the livetree for driver model init.
But why do we need this transformation to and back from livetree in
this context, only for adding a node to the FDT.

-sughosh

>
> If you have time, it should be a nice mini project and will allow us to migrate more things to the ofnode API.
>
> Regards,
> Simon


More information about the U-Boot mailing list