[PATCH v2 1/4] x86: fsp: Allow skipping init code when chain loading

Bin Meng bmeng.cn at gmail.com
Sat Feb 29 10:16:42 CET 2020


Hi Simon,

On Wed, Feb 19, 2020 at 10:46 AM Simon Glass <sjg at 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 at 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


More information about the U-Boot mailing list