All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot
@ 2020-02-19  2:45 Simon Glass
  2020-02-19  2:45 ` [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading Simon Glass
                   ` (4 more replies)
  0 siblings, 5 replies; 9+ messages in thread
From: Simon Glass @ 2020-02-19  2:45 UTC (permalink / raw)
  To: u-boot

This little series adds a few checks into the code to allow better
operation when booting a build from a previous-state loader such as
coreboot.

At present we have a 'coreboot' target but this runs very different code
from the bare-metal targets, such as coral. There is very little in common
between them.

It is useful to be able to boot the same U-Boot 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 series makes the most important changes to allow coral to boot on
coreboot.

Changes in v2:
- Drop the other check in interrupt_init() which is not needed now
- Drop patch 'dm: Avoid initing built-in devices when chain loading'

Simon Glass (4):
  x86: fsp: Allow skipping init code when chain loading
  x86: apl: Skip init code when chain loading
  x86: cpu: Skip init code when chain loading
  pci: Avoid auto-config when chain loading

 arch/x86/cpu/apollolake/fsp_s.c |  2 ++
 arch/x86/cpu/cpu.c              |  4 +++-
 arch/x86/cpu/i386/interrupt.c   |  6 ++++--
 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 +-
 arch/x86/lib/init_helpers.c     |  3 +++
 drivers/pci/pci-uclass.c        |  4 ++--
 9 files changed, 36 insertions(+), 6 deletions(-)

-- 
2.25.0.265.gbab2e86ba0-goog

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading
  2020-02-19  2:45 [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Simon Glass
@ 2020-02-19  2:45 ` Simon Glass
  2020-02-29  9:16   ` Bin Meng
  2020-02-19  2:45 ` [PATCH v2 2/4] x86: apl: Skip " Simon Glass
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2020-02-19  2:45 UTC (permalink / raw)
  To: u-boot

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.

When U-Boot is not 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>
---

Changes in v2: None

 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;
+	}
+
 	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 */
-- 
2.25.0.265.gbab2e86ba0-goog

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH v2 2/4] x86: apl: Skip init code when chain loading
  2020-02-19  2:45 [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Simon Glass
  2020-02-19  2:45 ` [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading Simon Glass
@ 2020-02-19  2:45 ` Simon Glass
  2020-02-19  2:45 ` [PATCH v2 3/4] x86: cpu: " Simon Glass
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2020-02-19  2:45 UTC (permalink / raw)
  To: u-boot

When U-Boot is not the first-stage bootloader the FSP-S init must be
skipped. Update it to add a check.

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

Changes in v2: None

 arch/x86/cpu/apollolake/fsp_s.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/cpu/apollolake/fsp_s.c b/arch/x86/cpu/apollolake/fsp_s.c
index b2d9130841..3ee816f44b 100644
--- a/arch/x86/cpu/apollolake/fsp_s.c
+++ b/arch/x86/cpu/apollolake/fsp_s.c
@@ -565,6 +565,8 @@ int arch_fsp_init_r(void)
 	struct udevice *dev, *itss;
 	int ret;
 
+	if (!ll_boot_init())
+		return 0;
 	/*
 	 * This must be called before any devices are probed. Put any probing
 	 * into arch_fsps_preinit() above.
-- 
2.25.0.265.gbab2e86ba0-goog

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH v2 3/4] x86: cpu: Skip init code when chain loading
  2020-02-19  2:45 [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Simon Glass
  2020-02-19  2:45 ` [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading Simon Glass
  2020-02-19  2:45 ` [PATCH v2 2/4] x86: apl: Skip " Simon Glass
@ 2020-02-19  2:45 ` Simon Glass
  2020-02-19  2:45 ` [PATCH v2 4/4] pci: Avoid auto-config " Simon Glass
  2020-02-19  9:37 ` [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Andy Shevchenko
  4 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2020-02-19  2:45 UTC (permalink / raw)
  To: u-boot

When U-Boot is not the first-stage bootloader the interrupt and cache init
must be skipped, as well as init for various peripherals. Update the code
to add checks for this.

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

Changes in v2:
- Drop the other check in interrupt_init() which is not needed now

 arch/x86/cpu/cpu.c            | 4 +++-
 arch/x86/cpu/i386/interrupt.c | 6 ++++--
 arch/x86/lib/init_helpers.c   | 3 +++
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index dae06949cc..3db035c2c0 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -239,8 +239,10 @@ int cpu_init_r(void)
 	struct udevice *dev;
 	int ret;
 
-	if (!ll_boot_init())
+	if (!ll_boot_init()) {
+		uclass_first_device(UCLASS_PCI, &dev);
 		return 0;
+	}
 
 	ret = x86_init_cpus();
 	if (ret)
diff --git a/arch/x86/cpu/i386/interrupt.c b/arch/x86/cpu/i386/interrupt.c
index 4c7e9ea215..e67a116ac1 100644
--- a/arch/x86/cpu/i386/interrupt.c
+++ b/arch/x86/cpu/i386/interrupt.c
@@ -264,6 +264,9 @@ int interrupt_init(void)
 	struct udevice *dev;
 	int ret;
 
+	if (!ll_boot_init())
+		return 0;
+
 	/* Try to set up the interrupt router, but don't require one */
 	ret = irq_first_device_type(X86_IRQT_BASE, &dev);
 	if (ret && ret != -ENODEV)
@@ -295,8 +298,7 @@ int interrupt_init(void)
 	 * TODO(sjg at chromium.org): But we don't handle these correctly when
 	 * booted from EFI.
 	 */
-	if (ll_boot_init())
-		enable_interrupts();
+	enable_interrupts();
 #endif
 
 	return 0;
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 5bb55e256f..d906b528b3 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -30,6 +30,9 @@ int init_cache_f_r(void)
 			return ret;
 	}
 
+	if (!ll_boot_init())
+		return 0;
+
 	/* Initialise the CPU cache(s) */
 	return init_cache();
 }
-- 
2.25.0.265.gbab2e86ba0-goog

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH v2 4/4] pci: Avoid auto-config when chain loading
  2020-02-19  2:45 [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Simon Glass
                   ` (2 preceding siblings ...)
  2020-02-19  2:45 ` [PATCH v2 3/4] x86: cpu: " Simon Glass
@ 2020-02-19  2:45 ` Simon Glass
  2020-02-19  9:37 ` [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Andy Shevchenko
  4 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2020-02-19  2:45 UTC (permalink / raw)
  To: u-boot

When U-Boot is not the first-stage bootloader we don't want to
re-configure the PCI devices, since this has already been done. Add a
check to avoid this.

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

Changes in v2:
- Drop patch 'dm: Avoid initing built-in devices when chain loading'

 drivers/pci/pci-uclass.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 5be2dfd0bf..0ad63b41ac 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1004,7 +1004,7 @@ static int pci_uclass_post_probe(struct udevice *bus)
 	if (ret)
 		return ret;
 
-	if (CONFIG_IS_ENABLED(PCI_PNP) &&
+	if (CONFIG_IS_ENABLED(PCI_PNP) && ll_boot_init() &&
 	    (!hose->skip_auto_config_until_reloc ||
 	     (gd->flags & GD_FLG_RELOC))) {
 		ret = pci_auto_config_devices(bus);
@@ -1026,7 +1026,7 @@ static int pci_uclass_post_probe(struct udevice *bus)
 	 * Note we only call this 1) after U-Boot is relocated, and 2)
 	 * root bus has finished probing.
 	 */
-	if ((gd->flags & GD_FLG_RELOC) && (bus->seq == 0)) {
+	if ((gd->flags & GD_FLG_RELOC) && bus->seq == 0 && ll_boot_init()) {
 		ret = fsp_init_phase_pci();
 		if (ret)
 			return ret;
-- 
2.25.0.265.gbab2e86ba0-goog

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot
  2020-02-19  2:45 [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Simon Glass
                   ` (3 preceding siblings ...)
  2020-02-19  2:45 ` [PATCH v2 4/4] pci: Avoid auto-config " Simon Glass
@ 2020-02-19  9:37 ` Andy Shevchenko
  2020-02-20  3:04   ` Simon Glass
  4 siblings, 1 reply; 9+ messages in thread
From: Andy Shevchenko @ 2020-02-19  9:37 UTC (permalink / raw)
  To: u-boot

On Wed, Feb 19, 2020 at 4:46 AM Simon Glass <sjg@chromium.org> wrote:
>
> This little series adds a few checks into the code to allow better
> operation when booting a build from a previous-state loader such as
> coreboot.
>
> At present we have a 'coreboot' target but this runs very different code
> from the bare-metal targets, such as coral. There is very little in common
> between them.
>
> It is useful to be able to boot the same U-Boot 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 series makes the most important changes to allow coral to boot on
> coreboot.

Is there any patchwork instance or branch which I may use for testing?

> Changes in v2:
> - Drop the other check in interrupt_init() which is not needed now
> - Drop patch 'dm: Avoid initing built-in devices when chain loading'
>
> Simon Glass (4):
>   x86: fsp: Allow skipping init code when chain loading
>   x86: apl: Skip init code when chain loading
>   x86: cpu: Skip init code when chain loading
>   pci: Avoid auto-config when chain loading
>
>  arch/x86/cpu/apollolake/fsp_s.c |  2 ++
>  arch/x86/cpu/cpu.c              |  4 +++-
>  arch/x86/cpu/i386/interrupt.c   |  6 ++++--
>  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 +-
>  arch/x86/lib/init_helpers.c     |  3 +++
>  drivers/pci/pci-uclass.c        |  4 ++--
>  9 files changed, 36 insertions(+), 6 deletions(-)
>
> --
> 2.25.0.265.gbab2e86ba0-goog
>


-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot
  2020-02-19  9:37 ` [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Andy Shevchenko
@ 2020-02-20  3:04   ` Simon Glass
  0 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2020-02-20  3:04 UTC (permalink / raw)
  To: u-boot

Hi Andy,

On Wed, 19 Feb 2020 at 02:37, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Wed, Feb 19, 2020 at 4:46 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > This little series adds a few checks into the code to allow better
> > operation when booting a build from a previous-state loader such as
> > coreboot.
> >
> > At present we have a 'coreboot' target but this runs very different code
> > from the bare-metal targets, such as coral. There is very little in common
> > between them.
> >
> > It is useful to be able to boot the same U-Boot 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 series makes the most important changes to allow coral to boot on
> > coreboot.
>
> Is there any patchwork instance or branch which I may use for testing?

Yes I always push to u-boot-dm before sending.

This one is in branch cor3chain-working

It will be collected into patchwork automatically, normally a few
minutes after sending.

Regards,
Simon

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading
  2020-02-19  2:45 ` [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading Simon Glass
@ 2020-02-29  9:16   ` Bin Meng
  2020-03-02 19:46     ` Simon Glass
  0 siblings, 1 reply; 9+ messages in thread
From: Bin Meng @ 2020-02-29  9:16 UTC (permalink / raw)
  To: u-boot

Hi Simon,

On Wed, Feb 19, 2020 at 10:46 AM Simon Glass <sjg@chromium.org> wrote:
>
> 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.
>
> When U-Boot is not 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>
> ---
>
> Changes in v2: None
>
>  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;
> +       }
> +
>         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 */
> --

I assume the proposed ll_boot_init() debug only works with FSP2, right?

I still would like to use the gd->flags instead of ll_boot_init().

Besides, I think the x86 doc need be updated to describe the purpose
and usage, using one board as an example.

Regards,
Bin

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading
  2020-02-29  9:16   ` Bin Meng
@ 2020-03-02 19:46     ` Simon Glass
  0 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2020-03-02 19:46 UTC (permalink / raw)
  To: u-boot

Hi Bin,

On Sat, 29 Feb 2020 at 02:16, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Wed, Feb 19, 2020 at 10:46 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > 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.
> >
> > When U-Boot is not 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>
> > ---
> >
> > Changes in v2: None
> >
> >  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;
> > +       }
> > +
> >         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 */
> > --
>
> I assume the proposed ll_boot_init() debug only works with FSP2, right?
>
> I still would like to use the gd->flags instead of ll_boot_init().
>
> Besides, I think the x86 doc need be updated to describe the purpose
> and usage, using one board as an example.

OK I ill take a look and see if I can detect booting from coreboot at
least, and set the flag.

BTW what is next with the ACPI series?

Regards,
Simon

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-03-02 19:46 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-19  2:45 [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Simon Glass
2020-02-19  2:45 ` [PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading Simon Glass
2020-02-29  9:16   ` Bin Meng
2020-03-02 19:46     ` Simon Glass
2020-02-19  2:45 ` [PATCH v2 2/4] x86: apl: Skip " Simon Glass
2020-02-19  2:45 ` [PATCH v2 3/4] x86: cpu: " Simon Glass
2020-02-19  2:45 ` [PATCH v2 4/4] pci: Avoid auto-config " Simon Glass
2020-02-19  9:37 ` [PATCH v2 0/4] x86: Improve support for chain-loading U-Boot Andy Shevchenko
2020-02-20  3:04   ` Simon Glass

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.