[1/5] x86: fsp: Allow skipping init code when chain loading
diff mbox series

Message ID 20191221161340.27047-2-sjg@chromium.org
State Superseded
Delegated to: Bin Meng
Headers show
Series
  • x86: Improve support for chain-loading U-Boot
Related show

Commit Message

Simon Glass Dec. 21, 2019, 4:13 p.m. UTC
When U-Boot is no the first-stage bootloader much of this code is not
needed and can break booting. Add checks for this to the FSP code.

Rather than checking for the amount of available SDRAM, just use 1GB in
this situation, which should be safe. Using 2GB may run into a memory
hole on some SoCs.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 arch/x86/lib/fsp/fsp_dram.c     |  8 ++++++++
 arch/x86/lib/fsp/fsp_graphics.c |  3 +++
 arch/x86/lib/fsp2/fsp_dram.c    | 10 ++++++++++
 arch/x86/lib/fsp2/fsp_init.c    |  2 +-
 4 files changed, 22 insertions(+), 1 deletion(-)

Comments

Bin Meng Feb. 3, 2020, 11:05 a.m. UTC | #1
Hi Simon,

On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote:
>
> When U-Boot is no the first-stage bootloader much of this code is not
> needed and can break booting. Add checks for this to the FSP code.
>
> Rather than checking for the amount of available SDRAM, just use 1GB in
> this situation, which should be safe. Using 2GB may run into a memory
> hole on some SoCs.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  arch/x86/lib/fsp/fsp_dram.c     |  8 ++++++++
>  arch/x86/lib/fsp/fsp_graphics.c |  3 +++
>  arch/x86/lib/fsp2/fsp_dram.c    | 10 ++++++++++
>  arch/x86/lib/fsp2/fsp_init.c    |  2 +-
>  4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
> index 9ce0ddf0d3..15e82de2fe 100644
> --- a/arch/x86/lib/fsp/fsp_dram.c
> +++ b/arch/x86/lib/fsp/fsp_dram.c
> @@ -44,6 +44,14 @@ int dram_init_banksize(void)
>         phys_addr_t low_end;
>         uint bank;
>
> +       if (!ll_boot_init()) {
> +               gd->bd->bi_dram[0].start = 0;
> +               gd->bd->bi_dram[0].size = gd->ram_size;
> +
> +               mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
> +               return 0;
> +       }
> +

I wonder why this change is needed. When booting from other
bootloader, this dram_init_banksize() will not be called, no?

>         low_end = 0;
>         for (bank = 1, hdr = gd->arch.hob_list;
>              bank < CONFIG_NR_DRAM_BANKS && !end_of_hob(hdr);
> diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c
> index 226c7e66b3..98b762209f 100644
> --- a/arch/x86/lib/fsp/fsp_graphics.c
> +++ b/arch/x86/lib/fsp/fsp_graphics.c
> @@ -78,6 +78,9 @@ static int fsp_video_probe(struct udevice *dev)
>         struct vesa_mode_info *vesa = &mode_info.vesa;
>         int ret;
>
> +       if (!ll_boot_init())
> +               return 0;
> +

the same question as above

>         printf("Video: ");
>
>         /* Initialize vesa_mode_info structure */
> diff --git a/arch/x86/lib/fsp2/fsp_dram.c b/arch/x86/lib/fsp2/fsp_dram.c
> index 90a238a224..74835eebce 100644
> --- a/arch/x86/lib/fsp2/fsp_dram.c
> +++ b/arch/x86/lib/fsp2/fsp_dram.c
> @@ -12,11 +12,18 @@
>  #include <asm/fsp/fsp_support.h>
>  #include <asm/fsp2/fsp_api.h>
>  #include <asm/fsp2/fsp_internal.h>
> +#include <linux/sizes.h>
>
>  int dram_init(void)
>  {
>         int ret;
>
> +       if (!ll_boot_init()) {
> +               /* Use a small and safe amount of 1GB */
> +               gd->ram_size = SZ_1G;
> +

ditto. Maybe we should explain on what configuration ll_boot_init() is
set to true / false?

> +               return 0;
> +       }
>         if (spl_phase() == PHASE_SPL) {
>  #ifdef CONFIG_HAVE_ACPI_RESUME
>                 bool s3wake = gd->arch.prev_sleep_state == ACPI_S3;
> @@ -68,6 +75,9 @@ int dram_init(void)
>
>  ulong board_get_usable_ram_top(ulong total_size)
>  {
> +       if (!ll_boot_init())
> +               return gd->ram_size;
> +
>  #if CONFIG_IS_ENABLED(HANDOFF)
>         struct spl_handoff *ho = gd->spl_handoff;
>
> diff --git a/arch/x86/lib/fsp2/fsp_init.c b/arch/x86/lib/fsp2/fsp_init.c
> index da9bd6b45c..c7dc2ea257 100644
> --- a/arch/x86/lib/fsp2/fsp_init.c
> +++ b/arch/x86/lib/fsp2/fsp_init.c
> @@ -23,7 +23,7 @@ int arch_cpu_init_dm(void)
>         int ret;
>
>         /* Make sure pads are set up early in U-Boot */
> -       if (spl_phase() != PHASE_BOARD_F)
> +       if (!ll_boot_init() || spl_phase() != PHASE_BOARD_F)
>                 return 0;
>
>         /* Probe all pinctrl devices to set up the pads */
> --

Regards,
Bin
Simon Glass Feb. 3, 2020, 4:20 p.m. UTC | #2
Hi Bin,

On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > When U-Boot is no the first-stage bootloader much of this code is not
> > needed and can break booting. Add checks for this to the FSP code.
> >
> > Rather than checking for the amount of available SDRAM, just use 1GB in
> > this situation, which should be safe. Using 2GB may run into a memory
> > hole on some SoCs.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> >  arch/x86/lib/fsp/fsp_dram.c     |  8 ++++++++
> >  arch/x86/lib/fsp/fsp_graphics.c |  3 +++
> >  arch/x86/lib/fsp2/fsp_dram.c    | 10 ++++++++++
> >  arch/x86/lib/fsp2/fsp_init.c    |  2 +-
> >  4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
> > index 9ce0ddf0d3..15e82de2fe 100644
> > --- a/arch/x86/lib/fsp/fsp_dram.c
> > +++ b/arch/x86/lib/fsp/fsp_dram.c
> > @@ -44,6 +44,14 @@ int dram_init_banksize(void)
> >         phys_addr_t low_end;
> >         uint bank;
> >
> > +       if (!ll_boot_init()) {
> > +               gd->bd->bi_dram[0].start = 0;
> > +               gd->bd->bi_dram[0].size = gd->ram_size;
> > +
> > +               mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
> > +               return 0;
> > +       }
> > +
>
> I wonder why this change is needed. When booting from other
> bootloader, this dram_init_banksize() will not be called, no?

How about this:

It is useful to be able to boot the same x86 image on a device with or
without a first-stage bootloader. For example, with chromebook_coral, it
is helpful for testing to be able to boot the same U-Boot (complete with
FSP) on bare metal and from coreboot. It allows checking of things like
CPU speed, comparing registers, ACPI tables and the like.

The idea is to change ll_boot_init() to false, and rebuild without changing
anything else.

Regards,
Simon
Bin Meng Feb. 3, 2020, 5:10 p.m. UTC | #3
Hi Simon,

On Tue, Feb 4, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > When U-Boot is no the first-stage bootloader much of this code is not
> > > needed and can break booting. Add checks for this to the FSP code.
> > >
> > > Rather than checking for the amount of available SDRAM, just use 1GB in
> > > this situation, which should be safe. Using 2GB may run into a memory
> > > hole on some SoCs.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > ---
> > >
> > >  arch/x86/lib/fsp/fsp_dram.c     |  8 ++++++++
> > >  arch/x86/lib/fsp/fsp_graphics.c |  3 +++
> > >  arch/x86/lib/fsp2/fsp_dram.c    | 10 ++++++++++
> > >  arch/x86/lib/fsp2/fsp_init.c    |  2 +-
> > >  4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
> > > index 9ce0ddf0d3..15e82de2fe 100644
> > > --- a/arch/x86/lib/fsp/fsp_dram.c
> > > +++ b/arch/x86/lib/fsp/fsp_dram.c
> > > @@ -44,6 +44,14 @@ int dram_init_banksize(void)
> > >         phys_addr_t low_end;
> > >         uint bank;
> > >
> > > +       if (!ll_boot_init()) {
> > > +               gd->bd->bi_dram[0].start = 0;
> > > +               gd->bd->bi_dram[0].size = gd->ram_size;
> > > +
> > > +               mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
> > > +               return 0;
> > > +       }
> > > +
> >
> > I wonder why this change is needed. When booting from other
> > bootloader, this dram_init_banksize() will not be called, no?
>
> How about this:
>
> It is useful to be able to boot the same x86 image on a device with or
> without a first-stage bootloader. For example, with chromebook_coral, it
> is helpful for testing to be able to boot the same U-Boot (complete with
> FSP) on bare metal and from coreboot. It allows checking of things like
> CPU speed, comparing registers, ACPI tables and the like.
>
> The idea is to change ll_boot_init() to false, and rebuild without changing
> anything else.

This sounds like for a debugging purpose, instead of a supported
configuration. So when we boot from previous bootloader, we really
should use its configuration, for the coreboot case,
coreboot-x86_defconfig should be used, and we can compare the
registers, ACPI tables in that configuration, instead of "hacking"
current U-Boot codes like in this series.

Regards,
Bin
Simon Glass Feb. 3, 2020, 5:15 p.m. UTC | #4
Hi Bin,

On Mon, 3 Feb 2020 at 10:10, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Tue, Feb 4, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > When U-Boot is no the first-stage bootloader much of this code is not
> > > > needed and can break booting. Add checks for this to the FSP code.
> > > >
> > > > Rather than checking for the amount of available SDRAM, just use 1GB in
> > > > this situation, which should be safe. Using 2GB may run into a memory
> > > > hole on some SoCs.
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > ---
> > > >
> > > >  arch/x86/lib/fsp/fsp_dram.c     |  8 ++++++++
> > > >  arch/x86/lib/fsp/fsp_graphics.c |  3 +++
> > > >  arch/x86/lib/fsp2/fsp_dram.c    | 10 ++++++++++
> > > >  arch/x86/lib/fsp2/fsp_init.c    |  2 +-
> > > >  4 files changed, 22 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
> > > > index 9ce0ddf0d3..15e82de2fe 100644
> > > > --- a/arch/x86/lib/fsp/fsp_dram.c
> > > > +++ b/arch/x86/lib/fsp/fsp_dram.c
> > > > @@ -44,6 +44,14 @@ int dram_init_banksize(void)
> > > >         phys_addr_t low_end;
> > > >         uint bank;
> > > >
> > > > +       if (!ll_boot_init()) {
> > > > +               gd->bd->bi_dram[0].start = 0;
> > > > +               gd->bd->bi_dram[0].size = gd->ram_size;
> > > > +
> > > > +               mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
> > > > +               return 0;
> > > > +       }
> > > > +
> > >
> > > I wonder why this change is needed. When booting from other
> > > bootloader, this dram_init_banksize() will not be called, no?
> >
> > How about this:
> >
> > It is useful to be able to boot the same x86 image on a device with or
> > without a first-stage bootloader. For example, with chromebook_coral, it
> > is helpful for testing to be able to boot the same U-Boot (complete with
> > FSP) on bare metal and from coreboot. It allows checking of things like
> > CPU speed, comparing registers, ACPI tables and the like.
> >
> > The idea is to change ll_boot_init() to false, and rebuild without changing
> > anything else.
>
> This sounds like for a debugging purpose, instead of a supported
> configuration. So when we boot from previous bootloader, we really
> should use its configuration, for the coreboot case,
> coreboot-x86_defconfig should be used, and we can compare the
> registers, ACPI tables in that configuration, instead of "hacking"
> current U-Boot codes like in this series.

Well the problem is then that we cannot boot the same image with or
without coreboot. Also there are various of device-tree things in
coral that we need for the laptop to work properly. My idea is to
detect coreboot and set ll_boot_init() dynamically if needed.

Regards,
Simon
Bin Meng Feb. 4, 2020, 4:52 a.m. UTC | #5
Hi Simon,

On Tue, Feb 4, 2020 at 1:15 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Mon, 3 Feb 2020 at 10:10, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Tue, Feb 4, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > When U-Boot is no the first-stage bootloader much of this code is not
> > > > > needed and can break booting. Add checks for this to the FSP code.
> > > > >
> > > > > Rather than checking for the amount of available SDRAM, just use 1GB in
> > > > > this situation, which should be safe. Using 2GB may run into a memory
> > > > > hole on some SoCs.
> > > > >
> > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > ---
> > > > >
> > > > >  arch/x86/lib/fsp/fsp_dram.c     |  8 ++++++++
> > > > >  arch/x86/lib/fsp/fsp_graphics.c |  3 +++
> > > > >  arch/x86/lib/fsp2/fsp_dram.c    | 10 ++++++++++
> > > > >  arch/x86/lib/fsp2/fsp_init.c    |  2 +-
> > > > >  4 files changed, 22 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
> > > > > index 9ce0ddf0d3..15e82de2fe 100644
> > > > > --- a/arch/x86/lib/fsp/fsp_dram.c
> > > > > +++ b/arch/x86/lib/fsp/fsp_dram.c
> > > > > @@ -44,6 +44,14 @@ int dram_init_banksize(void)
> > > > >         phys_addr_t low_end;
> > > > >         uint bank;
> > > > >
> > > > > +       if (!ll_boot_init()) {
> > > > > +               gd->bd->bi_dram[0].start = 0;
> > > > > +               gd->bd->bi_dram[0].size = gd->ram_size;
> > > > > +
> > > > > +               mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
> > > > > +               return 0;
> > > > > +       }
> > > > > +
> > > >
> > > > I wonder why this change is needed. When booting from other
> > > > bootloader, this dram_init_banksize() will not be called, no?
> > >
> > > How about this:
> > >
> > > It is useful to be able to boot the same x86 image on a device with or
> > > without a first-stage bootloader. For example, with chromebook_coral, it
> > > is helpful for testing to be able to boot the same U-Boot (complete with
> > > FSP) on bare metal and from coreboot. It allows checking of things like
> > > CPU speed, comparing registers, ACPI tables and the like.
> > >
> > > The idea is to change ll_boot_init() to false, and rebuild without changing
> > > anything else.
> >
> > This sounds like for a debugging purpose, instead of a supported
> > configuration. So when we boot from previous bootloader, we really
> > should use its configuration, for the coreboot case,
> > coreboot-x86_defconfig should be used, and we can compare the
> > registers, ACPI tables in that configuration, instead of "hacking"
> > current U-Boot codes like in this series.
>
> Well the problem is then that we cannot boot the same image with or
> without coreboot. Also there are various of device-tree things in
> coral that we need for the laptop to work properly. My idea is to
> detect coreboot and set ll_boot_init() dynamically if needed.

If so, why should we keep coreboot_defconfig for U-Boot as a supported target?

I am more interested in what you proposed here: "detect coreboot and
set ll_boot_init() dynamically if needed." The name ll_boot_init()
does not sound great. It's written like a function call but actually
it is a macro for true/false. Can we do something in the gd->flags to
indicate we are booting from previous stage bootloaders instead of
relying on ll_boot_init()?

Regards,
Bin
Simon Glass Feb. 5, 2020, 5:59 p.m. UTC | #6
Hi Bin,

On Mon, 3 Feb 2020 at 21:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Tue, Feb 4, 2020 at 1:15 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Mon, 3 Feb 2020 at 10:10, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, Feb 4, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > When U-Boot is no the first-stage bootloader much of this code is not
> > > > > > needed and can break booting. Add checks for this to the FSP code.
> > > > > >
> > > > > > Rather than checking for the amount of available SDRAM, just use 1GB in
> > > > > > this situation, which should be safe. Using 2GB may run into a memory
> > > > > > hole on some SoCs.
> > > > > >
> > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > ---
> > > > > >
> > > > > >  arch/x86/lib/fsp/fsp_dram.c     |  8 ++++++++
> > > > > >  arch/x86/lib/fsp/fsp_graphics.c |  3 +++
> > > > > >  arch/x86/lib/fsp2/fsp_dram.c    | 10 ++++++++++
> > > > > >  arch/x86/lib/fsp2/fsp_init.c    |  2 +-
> > > > > >  4 files changed, 22 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
> > > > > > index 9ce0ddf0d3..15e82de2fe 100644
> > > > > > --- a/arch/x86/lib/fsp/fsp_dram.c
> > > > > > +++ b/arch/x86/lib/fsp/fsp_dram.c
> > > > > > @@ -44,6 +44,14 @@ int dram_init_banksize(void)
> > > > > >         phys_addr_t low_end;
> > > > > >         uint bank;
> > > > > >
> > > > > > +       if (!ll_boot_init()) {
> > > > > > +               gd->bd->bi_dram[0].start = 0;
> > > > > > +               gd->bd->bi_dram[0].size = gd->ram_size;
> > > > > > +
> > > > > > +               mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
> > > > > > +               return 0;
> > > > > > +       }
> > > > > > +
> > > > >
> > > > > I wonder why this change is needed. When booting from other
> > > > > bootloader, this dram_init_banksize() will not be called, no?
> > > >
> > > > How about this:
> > > >
> > > > It is useful to be able to boot the same x86 image on a device with or
> > > > without a first-stage bootloader. For example, with chromebook_coral, it
> > > > is helpful for testing to be able to boot the same U-Boot (complete with
> > > > FSP) on bare metal and from coreboot. It allows checking of things like
> > > > CPU speed, comparing registers, ACPI tables and the like.
> > > >
> > > > The idea is to change ll_boot_init() to false, and rebuild without changing
> > > > anything else.
> > >
> > > This sounds like for a debugging purpose, instead of a supported
> > > configuration. So when we boot from previous bootloader, we really
> > > should use its configuration, for the coreboot case,
> > > coreboot-x86_defconfig should be used, and we can compare the
> > > registers, ACPI tables in that configuration, instead of "hacking"
> > > current U-Boot codes like in this series.
> >
> > Well the problem is then that we cannot boot the same image with or
> > without coreboot. Also there are various of device-tree things in
> > coral that we need for the laptop to work properly. My idea is to
> > detect coreboot and set ll_boot_init() dynamically if needed.
>
> If so, why should we keep coreboot_defconfig for U-Boot as a supported target?
>
> I am more interested in what you proposed here: "detect coreboot and
> set ll_boot_init() dynamically if needed." The name ll_boot_init()
> does not sound great. It's written like a function call but actually
> it is a macro for true/false. Can we do something in the gd->flags to
> indicate we are booting from previous stage bootloaders instead of
> relying on ll_boot_init()?

That sounds like a good idea, although at present it is statically
configured. But we don't really care about code size here I think.

Regards,
Simon

Patch
diff mbox series

diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c
index 9ce0ddf0d3..15e82de2fe 100644
--- a/arch/x86/lib/fsp/fsp_dram.c
+++ b/arch/x86/lib/fsp/fsp_dram.c
@@ -44,6 +44,14 @@  int dram_init_banksize(void)
 	phys_addr_t low_end;
 	uint bank;
 
+	if (!ll_boot_init()) {
+		gd->bd->bi_dram[0].start = 0;
+		gd->bd->bi_dram[0].size = gd->ram_size;
+
+		mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
+		return 0;
+	}
+
 	low_end = 0;
 	for (bank = 1, hdr = gd->arch.hob_list;
 	     bank < CONFIG_NR_DRAM_BANKS && !end_of_hob(hdr);
diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c
index 226c7e66b3..98b762209f 100644
--- a/arch/x86/lib/fsp/fsp_graphics.c
+++ b/arch/x86/lib/fsp/fsp_graphics.c
@@ -78,6 +78,9 @@  static int fsp_video_probe(struct udevice *dev)
 	struct vesa_mode_info *vesa = &mode_info.vesa;
 	int ret;
 
+	if (!ll_boot_init())
+		return 0;
+
 	printf("Video: ");
 
 	/* Initialize vesa_mode_info structure */
diff --git a/arch/x86/lib/fsp2/fsp_dram.c b/arch/x86/lib/fsp2/fsp_dram.c
index 90a238a224..74835eebce 100644
--- a/arch/x86/lib/fsp2/fsp_dram.c
+++ b/arch/x86/lib/fsp2/fsp_dram.c
@@ -12,11 +12,18 @@ 
 #include <asm/fsp/fsp_support.h>
 #include <asm/fsp2/fsp_api.h>
 #include <asm/fsp2/fsp_internal.h>
+#include <linux/sizes.h>
 
 int dram_init(void)
 {
 	int ret;
 
+	if (!ll_boot_init()) {
+		/* Use a small and safe amount of 1GB */
+		gd->ram_size = SZ_1G;
+
+		return 0;
+	}
 	if (spl_phase() == PHASE_SPL) {
 #ifdef CONFIG_HAVE_ACPI_RESUME
 		bool s3wake = gd->arch.prev_sleep_state == ACPI_S3;
@@ -68,6 +75,9 @@  int dram_init(void)
 
 ulong board_get_usable_ram_top(ulong total_size)
 {
+	if (!ll_boot_init())
+		return gd->ram_size;
+
 #if CONFIG_IS_ENABLED(HANDOFF)
 	struct spl_handoff *ho = gd->spl_handoff;
 
diff --git a/arch/x86/lib/fsp2/fsp_init.c b/arch/x86/lib/fsp2/fsp_init.c
index da9bd6b45c..c7dc2ea257 100644
--- a/arch/x86/lib/fsp2/fsp_init.c
+++ b/arch/x86/lib/fsp2/fsp_init.c
@@ -23,7 +23,7 @@  int arch_cpu_init_dm(void)
 	int ret;
 
 	/* Make sure pads are set up early in U-Boot */
-	if (spl_phase() != PHASE_BOARD_F)
+	if (!ll_boot_init() || spl_phase() != PHASE_BOARD_F)
 		return 0;
 
 	/* Probe all pinctrl devices to set up the pads */