* [PATCH v3 0/7] vpl: Introduce a verifying program loader
@ 2021-07-12 2:19 Simon Glass
2021-07-12 2:19 ` [PATCH v3 1/7] doc: Convert SPL documentation to ReST Simon Glass
` (7 more replies)
0 siblings, 8 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-12 2:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini, Simon Glass
U-Boot provides a verified-boot feature based around FIT, but there is
no standard way of implementing it for a board. At present the various
required pieces must be built up separately, to produce a working
implementation. In particular, there is no built-in support for selecting
A/B boot or recovery mode.
This series introduces VPL, a verified program loader. Its purpose is to
run the verified-boot process and decide which SPL binary should be run.
Adding VPL into the boot flow provides a standard way of implementing
verified boot. So far, only the phase itself is added along with some
Kconfig options. The next step is to create a build for sandbox.
Changes in v3:
- Move VPL Kconfig options to a separate patch
- Add full build support for VPL
Changes in v2:
- Add some more VPL Kconfig options
Simon Glass (7):
doc: Convert SPL documentation to ReST
doc: Expand SPL docs to explain the phase and config
test: Tidy up test building with SPL
spl: Move TPL_HASH_SUPPORT down next to other TPL options
binman: Add VPL support
Introduce Verifying Program Loader (VPL)
vpl: Add Kconfig options for VPL
Kconfig | 10 +
Makefile | 15 +-
arch/sandbox/Kconfig | 8 +
common/Kconfig | 67 ++++++
common/spl/Kconfig | 226 +++++++++++++++++++--
common/spl/spl.c | 25 ++-
doc/develop/index.rst | 1 +
doc/{README.SPL => develop/spl.rst} | 99 +++++----
drivers/clk/Kconfig | 10 +
drivers/core/Makefile | 2 +-
drivers/gpio/Kconfig | 11 +
drivers/i2c/Kconfig | 11 +
drivers/misc/Kconfig | 19 ++
drivers/pinctrl/Kconfig | 18 +-
drivers/rtc/Kconfig | 9 +
drivers/serial/Kconfig | 20 ++
drivers/sysreset/Kconfig | 10 +
drivers/timer/Kconfig | 10 +
include/bootstage.h | 2 +
include/linux/kconfig.h | 3 +
include/spl.h | 20 +-
lib/Kconfig | 62 ++++++
scripts/Kbuild.include | 4 +
scripts/Makefile.autoconf | 12 ++
scripts/Makefile.build | 4 +
scripts/Makefile.lib | 5 +
scripts/Makefile.spl | 37 +++-
test/test-main.c | 2 +-
tools/binman/etype/u_boot_vpl.py | 42 ++++
tools/binman/etype/u_boot_vpl_bss_pad.py | 44 ++++
tools/binman/etype/u_boot_vpl_dtb.py | 28 +++
tools/binman/etype/u_boot_vpl_expanded.py | 45 ++++
tools/binman/etype/u_boot_vpl_nodtb.py | 42 ++++
tools/binman/ftest.py | 110 ++++++++--
tools/binman/state.py | 3 +-
tools/binman/test/082_fdt_update_all.dts | 2 +
tools/binman/test/201_u_boot_vpl.dts | 11 +
tools/binman/test/202_u_boot_vpl_nodtb.dts | 13 ++
tools/binman/test/203_fdt_incl_vpl.dts | 13 ++
tools/binman/test/204_vpl_bss_pad.dts | 17 ++
40 files changed, 997 insertions(+), 95 deletions(-)
rename doc/{README.SPL => develop/spl.rst} (61%)
create mode 100644 tools/binman/etype/u_boot_vpl.py
create mode 100644 tools/binman/etype/u_boot_vpl_bss_pad.py
create mode 100644 tools/binman/etype/u_boot_vpl_dtb.py
create mode 100644 tools/binman/etype/u_boot_vpl_expanded.py
create mode 100644 tools/binman/etype/u_boot_vpl_nodtb.py
create mode 100644 tools/binman/test/201_u_boot_vpl.dts
create mode 100644 tools/binman/test/202_u_boot_vpl_nodtb.dts
create mode 100644 tools/binman/test/203_fdt_incl_vpl.dts
create mode 100644 tools/binman/test/204_vpl_bss_pad.dts
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v3 1/7] doc: Convert SPL documentation to ReST
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
@ 2021-07-12 2:19 ` Simon Glass
2021-07-12 2:19 ` [PATCH v3 2/7] doc: Expand SPL docs to explain the phase and config Simon Glass
` (6 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-12 2:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini, Simon Glass
Move this documentation over to .rst format.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
doc/develop/index.rst | 1 +
doc/{README.SPL => develop/spl.rst} | 36 +++++++++++++++--------------
2 files changed, 20 insertions(+), 17 deletions(-)
rename doc/{README.SPL => develop/spl.rst} (87%)
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 3edffbc6373..79f345c9331 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -14,6 +14,7 @@ Implementation
global_data
logging
menus
+ spl
uefi/index
version
diff --git a/doc/README.SPL b/doc/develop/spl.rst
similarity index 87%
rename from doc/README.SPL
rename to doc/develop/spl.rst
index 2beb6d8f11b..1165f95335f 100644
--- a/doc/README.SPL
+++ b/doc/develop/spl.rst
@@ -20,19 +20,19 @@ u-boot-spl.map.
A config option named CONFIG_SPL_BUILD is enabled by Kconfig for SPL.
Source files can therefore be compiled for SPL with different settings.
-For example:
+For example::
-ifeq ($(CONFIG_SPL_BUILD),y)
-obj-y += board_spl.o
-else
-obj-y += board.o
-endif
+ ifeq ($(CONFIG_SPL_BUILD),y)
+ obj-y += board_spl.o
+ else
+ obj-y += board.o
+ endif
-obj-$(CONFIG_SPL_BUILD) += foo.o
+ obj-$(CONFIG_SPL_BUILD) += foo.o
-#ifdef CONFIG_SPL_BUILD
- foo();
-#endif
+ #ifdef CONFIG_SPL_BUILD
+ foo();
+ #endif
The building of SPL images can be enabled by CONFIG_SPL option in Kconfig.
@@ -71,11 +71,13 @@ Device tree
The U-Boot device tree is filtered by the fdtgrep tools during the build
process to generate a much smaller device tree used in SPL (spl/u-boot-spl.dtb)
with:
+
- the mandatory nodes (/alias, /chosen, /config)
- the nodes with one pre-relocation property:
'u-boot,dm-pre-reloc' or 'u-boot,dm-spl'
fdtgrep is also used to remove:
+
- the properties defined in CONFIG_OF_SPL_REMOVE_PROPS
- all the pre-relocation properties
('u-boot,dm-pre-reloc', 'u-boot,dm-spl' and 'u-boot,dm-tpl')
@@ -98,14 +100,14 @@ stack usage at various points in run sequence of SPL. The -fstack-usage option
to gcc will produce '.su' files (such as arch/arm/cpu/armv7/syslib.su) that
will give stack usage information and cflow can construct program flow.
-Must have gcc 4.6 or later, which supports -fstack-usage
+Must have gcc 4.6 or later, which supports -fstack-usage:
-1) Build normally
-2) Perform the following shell command to generate a list of C files used in
-SPL:
-$ find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > used-spl.list
-3) Execute cflow:
-$ cflow --main=board_init_r `cat used-spl.list` 2>&1 | $PAGER
+#. Build normally
+#. Perform the following shell command to generate a list of C files used in
+ SPL:
+#. `find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > used-spl.list`
+#. Execute cflow:
+ `$ cflow --main=board_init_r $(cat used-spl.list) 2>&1 | $PAGER`
cflow will spit out a number of warnings as it does not parse
the config files and picks functions based on #ifdef. Parsing the '.i'
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 2/7] doc: Expand SPL docs to explain the phase and config
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
2021-07-12 2:19 ` [PATCH v3 1/7] doc: Convert SPL documentation to ReST Simon Glass
@ 2021-07-12 2:19 ` Simon Glass
2021-07-12 2:19 ` [PATCH v3 3/7] test: Tidy up test building with SPL Simon Glass
` (5 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-12 2:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini, Simon Glass
Add a bit more information about how to use SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
doc/develop/spl.rst | 59 +++++++++++++++++++++++++++------------------
1 file changed, 36 insertions(+), 23 deletions(-)
diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst
index 1165f95335f..c2a29a8c0a4 100644
--- a/doc/develop/spl.rst
+++ b/doc/develop/spl.rst
@@ -42,29 +42,42 @@ configured by defining CONFIG_SPL_TEXT_BASE. The linker script has to be
defined with CONFIG_SPL_LDSCRIPT.
To support generic U-Boot libraries and drivers in the SPL binary one can
-optionally define CONFIG_SPL_XXX_SUPPORT. Currently following options
-are supported:
-
-CONFIG_SPL_LIBCOMMON_SUPPORT (common/libcommon.o)
-CONFIG_SPL_LIBDISK_SUPPORT (disk/libdisk.o)
-CONFIG_SPL_I2C_SUPPORT (drivers/i2c/libi2c.o)
-CONFIG_SPL_GPIO_SUPPORT (drivers/gpio/libgpio.o)
-CONFIG_SPL_MMC_SUPPORT (drivers/mmc/libmmc.o)
-CONFIG_SPL_SERIAL_SUPPORT (drivers/serial/libserial.o)
-CONFIG_SPL_SPI_FLASH_SUPPORT (drivers/mtd/spi/libspi_flash.o)
-CONFIG_SPL_SPI_SUPPORT (drivers/spi/libspi.o)
-CONFIG_SPL_FS_FAT (fs/fat/libfat.o)
-CONFIG_SPL_FS_EXT4
-CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o)
-CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o)
-CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/raw/libnand.o)
-CONFIG_SPL_DRIVERS_MISC_SUPPORT (drivers/misc)
-CONFIG_SPL_DMA (drivers/dma/libdma.o)
-CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o)
-CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/raw/nand_spl_load.o)
-CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o)
-CONFIG_SPL_RAM_DEVICE (common/spl/spl.c)
-CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o)
+optionally define CONFIG_SPL_XXX_SUPPORT (or CONFIG_SPL_XXX_SUPPORT for older
+options).
+
+Adding SPL-specific code
+------------------------
+
+To check whether a feature is enabled, use CONFIG_IS_ENABLED()::
+
+ if (CONFIG_IS_ENABLED(CLK))
+ ...
+
+This checks CONFIG_CLK for the main build, CONFIG_SPL_CLK for the SPL build,
+CONFIG_TPL_CLK for the TPL build, etc.
+
+U-Boot Phases
+-------------
+
+U-Boot boots through the following phases:
+
+TPL
+ Very early init, as tiny as possible. This loads SPL.
+
+SPL
+ Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also
+ load other firmware components.
+
+U-Boot
+ U-Boot proper, containing the command line and boot logic.
+
+
+Checking the boot phase
+-----------------------
+
+Use `spl_phase()` to find the current U-Boot phase, e.g. `PHASE_SPL`. You can
+also find the previous and next phase and get the phase name.
+
Device tree
-----------
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 3/7] test: Tidy up test building with SPL
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
2021-07-12 2:19 ` [PATCH v3 1/7] doc: Convert SPL documentation to ReST Simon Glass
2021-07-12 2:19 ` [PATCH v3 2/7] doc: Expand SPL docs to explain the phase and config Simon Glass
@ 2021-07-12 2:19 ` Simon Glass
2021-07-12 2:19 ` [PATCH v3 4/7] spl: Move TPL_HASH_SUPPORT down next to other TPL options Simon Glass
` (4 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-12 2:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini, Simon Glass
We can in principle add tests to any SPL build, e.g. TPL or VPL. Update
the build rules to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Makefile | 2 +-
scripts/Makefile.spl | 2 +-
test/test-main.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 0d3192cebad..f7f62979ae2 100644
--- a/Makefile
+++ b/Makefile
@@ -841,7 +841,7 @@ libs-$(CONFIG_API) += api/
ifdef CONFIG_POST
libs-y += post/
endif
-libs-$(CONFIG_UNIT_TEST) += test/
+libs-$(CONFIG_$(SPL_TPL_)UNIT_TEST) += test/
libs-$(CONFIG_UT_ENV) += test/env/
libs-$(CONFIG_UT_OPTEE) += test/optee/
libs-$(CONFIG_UT_OVERLAY) += test/overlay/
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 5be1a9ba1b1..ffe919dafab 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -109,7 +109,7 @@ libs-y += dts/
libs-y += fs/
libs-$(CONFIG_SPL_POST_MEM_SUPPORT) += post/drivers/
libs-$(CONFIG_SPL_NET_SUPPORT) += net/
-libs-$(CONFIG_SPL_UNIT_TEST) += test/
+libs-$(CONFIG_$(SPL_TPL_)UNIT_TEST) += test/
head-y := $(addprefix $(obj)/,$(head-y))
libs-y := $(addprefix $(obj)/,$(libs-y))
diff --git a/test/test-main.c b/test/test-main.c
index 7afe8741cf9..3cdf6849c57 100644
--- a/test/test-main.c
+++ b/test/test-main.c
@@ -45,7 +45,7 @@ static int dm_test_pre_run(struct unit_test_state *uts)
uts->force_fail_alloc = false;
uts->skip_post_probe = false;
gd->dm_root = NULL;
- if (IS_ENABLED(CONFIG_UT_DM) && !CONFIG_IS_ENABLED(OF_PLATDATA))
+ if (CONFIG_IS_ENABLED(UT_DM) && !CONFIG_IS_ENABLED(OF_PLATDATA))
memset(dm_testdrv_op_count, '\0', sizeof(dm_testdrv_op_count));
arch_reset_for_test();
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 4/7] spl: Move TPL_HASH_SUPPORT down next to other TPL options
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
` (2 preceding siblings ...)
2021-07-12 2:19 ` [PATCH v3 3/7] test: Tidy up test building with SPL Simon Glass
@ 2021-07-12 2:19 ` Simon Glass
2021-07-12 2:19 ` [PATCH v3 5/7] binman: Add VPL support Simon Glass
` (3 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-12 2:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini, Simon Glass
This option should be next to other TPL options, not next to the SPL hash
option, so it matches the placement conventions in this file.
Move it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
common/spl/Kconfig | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index fa80524cfb2..10384b835b2 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -519,17 +519,6 @@ config SPL_HASH_SUPPORT
this option to build system-specific drivers for hash acceleration
as part of an SPL build.
-config TPL_HASH_SUPPORT
- bool "Support hashing drivers in TPL"
- depends on TPL
- select SHA1
- select SHA256
- help
- Enable hashing drivers in SPL. These drivers can be used to
- accelerate secure boot processing in secure applications. Enable
- this option to build system-specific drivers for hash acceleration
- as part of an SPL build.
-
config SPL_DMA
bool "Support DMA drivers"
help
@@ -1491,6 +1480,17 @@ config TPL_GPIO_SUPPORT
for example. Enable this option to build the drivers in
drivers/gpio as part of an TPL build.
+config TPL_HASH_SUPPORT
+ bool "Support hashing drivers in TPL"
+ depends on TPL
+ select SHA1
+ select SHA256
+ help
+ Enable hashing drivers in SPL. These drivers can be used to
+ accelerate secure boot processing in secure applications. Enable
+ this option to build system-specific drivers for hash acceleration
+ as part of an SPL build.
+
config TPL_I2C_SUPPORT
bool "Support I2C"
help
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 5/7] binman: Add VPL support
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
` (3 preceding siblings ...)
2021-07-12 2:19 ` [PATCH v3 4/7] spl: Move TPL_HASH_SUPPORT down next to other TPL options Simon Glass
@ 2021-07-12 2:19 ` Simon Glass
2021-07-12 2:19 ` [PATCH v3 6/7] Introduce Verifying Program Loader (VPL) Simon Glass
` (2 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-12 2:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini, Simon Glass
Add support for U-Boot's Verifying Program Loader phase.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
tools/binman/etype/u_boot_vpl.py | 42 ++++++++
tools/binman/etype/u_boot_vpl_bss_pad.py | 44 +++++++++
tools/binman/etype/u_boot_vpl_dtb.py | 28 ++++++
tools/binman/etype/u_boot_vpl_expanded.py | 45 +++++++++
tools/binman/etype/u_boot_vpl_nodtb.py | 42 ++++++++
tools/binman/ftest.py | 110 +++++++++++++++++----
tools/binman/state.py | 3 +-
tools/binman/test/082_fdt_update_all.dts | 2 +
tools/binman/test/201_u_boot_vpl.dts | 11 +++
tools/binman/test/202_u_boot_vpl_nodtb.dts | 13 +++
tools/binman/test/203_fdt_incl_vpl.dts | 13 +++
tools/binman/test/204_vpl_bss_pad.dts | 17 ++++
12 files changed, 348 insertions(+), 22 deletions(-)
create mode 100644 tools/binman/etype/u_boot_vpl.py
create mode 100644 tools/binman/etype/u_boot_vpl_bss_pad.py
create mode 100644 tools/binman/etype/u_boot_vpl_dtb.py
create mode 100644 tools/binman/etype/u_boot_vpl_expanded.py
create mode 100644 tools/binman/etype/u_boot_vpl_nodtb.py
create mode 100644 tools/binman/test/201_u_boot_vpl.dts
create mode 100644 tools/binman/test/202_u_boot_vpl_nodtb.dts
create mode 100644 tools/binman/test/203_fdt_incl_vpl.dts
create mode 100644 tools/binman/test/204_vpl_bss_pad.dts
diff --git a/tools/binman/etype/u_boot_vpl.py b/tools/binman/etype/u_boot_vpl.py
new file mode 100644
index 00000000000..9daaca4f6fd
--- /dev/null
+++ b/tools/binman/etype/u_boot_vpl.py
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2016 Google, Inc
+# Written by Simon Glass <sjg@chromium.org>
+#
+# Entry-type module for vpl/u-boot-vpl.bin
+#
+
+from binman import elf
+from binman.entry import Entry
+from binman.etype.blob import Entry_blob
+
+class Entry_u_boot_vpl(Entry_blob):
+ """U-Boot VPL binary
+
+ Properties / Entry arguments:
+ - filename: Filename of u-boot-vpl.bin (default 'vpl/u-boot-vpl.bin')
+
+ This is the U-Boot VPL (Verifying Program Loader) binary. This is a small
+ binary which loads before SPL, typically into on-chip SRAM. It is
+ responsible for locating, loading and jumping to SPL, the next-stage
+ loader. Note that VPL is not relocatable so must be loaded to the correct
+ address in SRAM, or written to run from the correct address if direct
+ flash execution is possible (e.g. on x86 devices).
+
+ SPL can access binman symbols at runtime. See:
+
+ 'Access to binman entry offsets at run time (symbols)'
+
+ in the binman README for more information.
+
+ The ELF file 'vpl/u-boot-vpl' must also be available for this to work, since
+ binman uses that to look up symbols to write into the VPL binary.
+ """
+ def __init__(self, section, etype, node):
+ super().__init__(section, etype, node)
+ self.elf_fname = 'vpl/u-boot-vpl'
+
+ def GetDefaultFilename(self):
+ return 'vpl/u-boot-vpl.bin'
+
+ def WriteSymbols(self, section):
+ elf.LookupAndWriteSymbols(self.elf_fname, self, section.GetImage())
diff --git a/tools/binman/etype/u_boot_vpl_bss_pad.py b/tools/binman/etype/u_boot_vpl_bss_pad.py
new file mode 100644
index 00000000000..073833b3d0d
--- /dev/null
+++ b/tools/binman/etype/u_boot_vpl_bss_pad.py
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2021 Google LLC
+# Written by Simon Glass <sjg@chromium.org>
+#
+# Entry-type module for BSS padding for vpl/u-boot-vpl.bin. This padding
+# can be added after the VPL binary to ensure that anything concatenated
+# to it will appear to VPL to be at the end of BSS rather than the start.
+#
+
+from binman import elf
+from binman.entry import Entry
+from binman.etype.blob import Entry_blob
+from patman import tools
+
+class Entry_u_boot_vpl_bss_pad(Entry_blob):
+ """U-Boot VPL binary padded with a BSS region
+
+ Properties / Entry arguments:
+ None
+
+ This holds the padding added after the VPL binary to cover the BSS (Block
+ Started by Symbol) region. This region holds the various variables used by
+ VPL. It is set to 0 by VPL when it starts up. If you want to append data to
+ the VPL image (such as a device tree file), you must pad out the BSS region
+ to avoid the data overlapping with U-Boot variables. This entry is useful in
+ that case. It automatically pads out the entry size to cover both the code,
+ data and BSS.
+
+ The contents of this entry will a certain number of zero bytes, determined
+ by __bss_size
+
+ The ELF file 'vpl/u-boot-vpl' must also be available for this to work, since
+ binman uses that to look up the BSS address.
+ """
+ def __init__(self, section, etype, node):
+ super().__init__(section, etype, node)
+
+ def ObtainContents(self):
+ fname = tools.GetInputFilename('vpl/u-boot-vpl')
+ bss_size = elf.GetSymbolAddress(fname, '__bss_size')
+ if not bss_size:
+ self.Raise('Expected __bss_size symbol in vpl/u-boot-vpl')
+ self.SetContents(tools.GetBytes(0, bss_size))
+ return True
diff --git a/tools/binman/etype/u_boot_vpl_dtb.py b/tools/binman/etype/u_boot_vpl_dtb.py
new file mode 100644
index 00000000000..f6253bf2431
--- /dev/null
+++ b/tools/binman/etype/u_boot_vpl_dtb.py
@@ -0,0 +1,28 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2016 Google, Inc
+# Written by Simon Glass <sjg@chromium.org>
+#
+# Entry-type module for U-Boot device tree in VPL (Verifying Program Loader)
+#
+
+from binman.entry import Entry
+from binman.etype.blob_dtb import Entry_blob_dtb
+
+class Entry_u_boot_vpl_dtb(Entry_blob_dtb):
+ """U-Boot VPL device tree
+
+ Properties / Entry arguments:
+ - filename: Filename of u-boot.dtb (default 'vpl/u-boot-vpl.dtb')
+
+ This is the VPL device tree, containing configuration information for
+ VPL. VPL needs this to know what devices are present and which drivers
+ to activate.
+ """
+ def __init__(self, section, etype, node):
+ super().__init__(section, etype, node)
+
+ def GetDefaultFilename(self):
+ return 'vpl/u-boot-vpl.dtb'
+
+ def GetFdtEtype(self):
+ return 'u-boot-vpl-dtb'
diff --git a/tools/binman/etype/u_boot_vpl_expanded.py b/tools/binman/etype/u_boot_vpl_expanded.py
new file mode 100644
index 00000000000..945a90f856e
--- /dev/null
+++ b/tools/binman/etype/u_boot_vpl_expanded.py
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2021 Google LLC
+# Written by Simon Glass <sjg@chromium.org>
+#
+# Entry-type module for expanded U-Boot VPL binary
+#
+
+from patman import tout
+
+from binman import state
+from binman.etype.blob_phase import Entry_blob_phase
+
+class Entry_u_boot_vpl_expanded(Entry_blob_phase):
+ """U-Boot VPL flat binary broken out into its component parts
+
+ Properties / Entry arguments:
+ - vpl-dtb: Controls whether this entry is selected (set to 'y' or '1' to
+ select)
+
+ This is a section containing the U-Boot binary, BSS padding if needed and a
+ devicetree. Using this entry type automatically creates this section, with
+ the following entries in it:
+
+ u-boot-vpl-nodtb
+ u-boot-vpl-bss-pad
+ u-boot-dtb
+
+ Having the devicetree separate allows binman to update it in the final
+ image, so that the entries positions are provided to the running U-Boot.
+
+ This entry is selected based on the value of the 'vpl-dtb' entryarg. If
+ this is non-empty (and not 'n' or '0') then this expanded entry is selected.
+ """
+ def __init__(self, section, etype, node):
+ bss_pad = state.GetEntryArgBool('vpl-bss-pad')
+ super().__init__(section, etype, node, 'u-boot-vpl', 'u-boot-vpl-dtb',
+ bss_pad)
+
+ @classmethod
+ def UseExpanded(cls, node, etype, new_etype):
+ val = state.GetEntryArgBool('vpl-dtb')
+ tout.DoOutput(tout.INFO if val else tout.DETAIL,
+ "Node '%s': etype '%s': %s %sselected" %
+ (node.path, etype, new_etype, '' if val else 'not '))
+ return val
diff --git a/tools/binman/etype/u_boot_vpl_nodtb.py b/tools/binman/etype/u_boot_vpl_nodtb.py
new file mode 100644
index 00000000000..25c966cf342
--- /dev/null
+++ b/tools/binman/etype/u_boot_vpl_nodtb.py
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2016 Google, Inc
+# Written by Simon Glass <sjg@chromium.org>
+#
+# Entry-type module for 'u-boot-vpl-nodtb.bin'
+#
+
+from binman import elf
+from binman.entry import Entry
+from binman.etype.blob import Entry_blob
+
+class Entry_u_boot_vpl_nodtb(Entry_blob):
+ """VPL binary without device tree appended
+
+ Properties / Entry arguments:
+ - filename: Filename to include (default 'vpl/u-boot-vpl-nodtb.bin')
+
+ This is the U-Boot VPL binary, It does not include a device tree blob at
+ the end of it so may not be able to work without it, assuming VPL needs
+ a device tree to operate on your platform. You can add a u_boot_vpl_dtb
+ entry after this one, or use a u_boot_vpl entry instead, which normally
+ expands to a section containing u-boot-vpl-dtb, u-boot-vpl-bss-pad and
+ u-boot-vpl-dtb
+
+ VPL can access binman symbols at runtime. See:
+
+ 'Access to binman entry offsets at run time (symbols)'
+
+ in the binman README for more information.
+
+ The ELF file 'vpl/u-boot-vpl' must also be available for this to work, since
+ binman uses that to look up symbols to write into the VPL binary.
+ """
+ def __init__(self, section, etype, node):
+ super().__init__(section, etype, node)
+ self.elf_fname = 'vpl/u-boot-vpl'
+
+ def GetDefaultFilename(self):
+ return 'vpl/u-boot-vpl-nodtb.bin'
+
+ def WriteSymbols(self, section):
+ elf.LookupAndWriteSymbols(self.elf_fname, self, section.GetImage())
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 5383eec489a..14daa69a69b 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -40,12 +40,14 @@ U_BOOT_DATA = b'1234'
U_BOOT_IMG_DATA = b'img'
U_BOOT_SPL_DATA = b'56780123456789abcdefghi'
U_BOOT_TPL_DATA = b'tpl9876543210fedcbazyw'
+U_BOOT_VPL_DATA = b'vpl76543210fedcbazywxyz_'
BLOB_DATA = b'89'
ME_DATA = b'0abcd'
VGA_DATA = b'vga'
U_BOOT_DTB_DATA = b'udtb'
U_BOOT_SPL_DTB_DATA = b'spldtb'
U_BOOT_TPL_DTB_DATA = b'tpldtb'
+U_BOOT_VPL_DTB_DATA = b'vpldtb'
X86_START16_DATA = b'start16'
X86_START16_SPL_DATA = b'start16spl'
X86_START16_TPL_DATA = b'start16tpl'
@@ -56,6 +58,7 @@ PPC_MPC85XX_BR_DATA = b'ppcmpc85xxbr'
U_BOOT_NODTB_DATA = b'nodtb with microcode pointer somewhere in here'
U_BOOT_SPL_NODTB_DATA = b'splnodtb with microcode pointer somewhere in here'
U_BOOT_TPL_NODTB_DATA = b'tplnodtb with microcode pointer somewhere in here'
+U_BOOT_VPL_NODTB_DATA = b'vplnodtb'
FSP_DATA = b'fsp'
CMC_DATA = b'cmc'
VBT_DATA = b'vbt'
@@ -126,6 +129,7 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('u-boot.img', U_BOOT_IMG_DATA)
TestFunctional._MakeInputFile('spl/u-boot-spl.bin', U_BOOT_SPL_DATA)
TestFunctional._MakeInputFile('tpl/u-boot-tpl.bin', U_BOOT_TPL_DATA)
+ TestFunctional._MakeInputFile('vpl/u-boot-vpl.bin', U_BOOT_VPL_DATA)
TestFunctional._MakeInputFile('blobfile', BLOB_DATA)
TestFunctional._MakeInputFile('me.bin', ME_DATA)
TestFunctional._MakeInputFile('vga.bin', VGA_DATA)
@@ -151,6 +155,8 @@ class TestFunctional(unittest.TestCase):
U_BOOT_SPL_NODTB_DATA)
TestFunctional._MakeInputFile('tpl/u-boot-tpl-nodtb.bin',
U_BOOT_TPL_NODTB_DATA)
+ TestFunctional._MakeInputFile('vpl/u-boot-vpl-nodtb.bin',
+ U_BOOT_VPL_NODTB_DATA)
TestFunctional._MakeInputFile('fsp.bin', FSP_DATA)
TestFunctional._MakeInputFile('cmc.bin', CMC_DATA)
TestFunctional._MakeInputFile('vbt.bin', VBT_DATA)
@@ -273,6 +279,7 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('u-boot.dtb', U_BOOT_DTB_DATA)
TestFunctional._MakeInputFile('spl/u-boot-spl.dtb', U_BOOT_SPL_DTB_DATA)
TestFunctional._MakeInputFile('tpl/u-boot-tpl.dtb', U_BOOT_TPL_DTB_DATA)
+ TestFunctional._MakeInputFile('vpl/u-boot-vpl.dtb', U_BOOT_VPL_DTB_DATA)
def _RunBinman(self, *args, **kwargs):
"""Run binman using the command line
@@ -385,8 +392,8 @@ class TestFunctional(unittest.TestCase):
shutil.rmtree(tmpdir)
return data
- def _GetDtbContentsForSplTpl(self, dtb_data, name):
- """Create a version of the main DTB for SPL or SPL
+ def _GetDtbContentsForSpls(self, dtb_data, name):
+ """Create a version of the main DTB for SPL / TPL / VPL
For testing we don't actually have different versions of the DTB. With
U-Boot we normally run fdtgrep to remove unwanted nodes, but for tests
@@ -454,11 +461,11 @@ class TestFunctional(unittest.TestCase):
# For testing purposes, make a copy of the DT for SPL and TPL. Add
# a node indicating which it is, so aid verification.
- for name in ['spl', 'tpl']:
+ for name in ['spl', 'tpl', 'vpl']:
dtb_fname = '%s/u-boot-%s.dtb' % (name, name)
outfile = os.path.join(self._indir, dtb_fname)
TestFunctional._MakeInputFile(dtb_fname,
- self._GetDtbContentsForSplTpl(dtb_data, name))
+ self._GetDtbContentsForSpls(dtb_data, name))
try:
retcode = self._DoTestFile(fname, map=map, update_dtb=update_dtb,
@@ -563,6 +570,16 @@ class TestFunctional(unittest.TestCase):
TestFunctional._MakeInputFile('tpl/u-boot-tpl',
tools.ReadFile(cls.ElfTestFile(src_fname)))
+ @classmethod
+ def _SetupVplElf(cls, src_fname='bss_data'):
+ """Set up an ELF file with a '_dt_ucode_base_size' symbol
+
+ Args:
+ Filename of ELF file to use as VPL
+ """
+ TestFunctional._MakeInputFile('vpl/u-boot-vpl',
+ tools.ReadFile(cls.ElfTestFile(src_fname)))
+
@classmethod
def _SetupDescriptor(cls):
with open(cls.TestFile('descriptor.bin'), 'rb') as fd:
@@ -1832,21 +1849,24 @@ class TestFunctional(unittest.TestCase):
data = self._DoReadFileRealDtb('082_fdt_update_all.dts')
base_expected = {
- 'section:image-pos': 0,
- 'u-boot-tpl-dtb:size': 513,
- 'u-boot-spl-dtb:size': 513,
- 'u-boot-spl-dtb:offset': 493,
- 'image-pos': 0,
- 'section/u-boot-dtb:image-pos': 0,
- 'u-boot-spl-dtb:image-pos': 493,
- 'section/u-boot-dtb:size': 493,
- 'u-boot-tpl-dtb:image-pos': 1006,
- 'section/u-boot-dtb:offset': 0,
- 'section:size': 493,
'offset': 0,
+ 'image-pos': 0,
+ 'size': 2320,
'section:offset': 0,
- 'u-boot-tpl-dtb:offset': 1006,
- 'size': 1519
+ 'section:image-pos': 0,
+ 'section:size': 565,
+ 'section/u-boot-dtb:offset': 0,
+ 'section/u-boot-dtb:image-pos': 0,
+ 'section/u-boot-dtb:size': 565,
+ 'u-boot-spl-dtb:offset': 565,
+ 'u-boot-spl-dtb:image-pos': 565,
+ 'u-boot-spl-dtb:size': 585,
+ 'u-boot-tpl-dtb:offset': 1150,
+ 'u-boot-tpl-dtb:image-pos': 1150,
+ 'u-boot-tpl-dtb:size': 585,
+ 'u-boot-vpl-dtb:image-pos': 1735,
+ 'u-boot-vpl-dtb:offset': 1735,
+ 'u-boot-vpl-dtb:size': 585,
}
# We expect three device-tree files in the output, one after the other.
@@ -1854,11 +1874,12 @@ class TestFunctional(unittest.TestCase):
# and 'tpl' in the TPL tree, to make sure they are distinct from the
# main U-Boot tree. All three should have the same postions and offset.
start = 0
- for item in ['', 'spl', 'tpl']:
+ self.maxDiff = None
+ for item in ['', 'spl', 'tpl', 'vpl']:
dtb = fdt.Fdt.FromData(data[start:])
dtb.Scan()
props = self._GetPropTree(dtb, BASE_DTB_PROPS + REPACK_DTB_PROPS +
- ['spl', 'tpl'])
+ ['spl', 'tpl', 'vpl'])
expected = dict(base_expected)
if item:
expected[item] = 0
@@ -1878,7 +1899,7 @@ class TestFunctional(unittest.TestCase):
# over to the expected place.
start = 0
for fname in ['u-boot.dtb.out', 'spl/u-boot-spl.dtb.out',
- 'tpl/u-boot-tpl.dtb.out']:
+ 'tpl/u-boot-tpl.dtb.out', 'vpl/u-boot-vpl.dtb.out']:
dtb = fdt.Fdt.FromData(data[start:])
size = dtb._fdt_obj.totalsize()
pathname = tools.GetOutputFilename(os.path.split(fname)[1])
@@ -1886,7 +1907,7 @@ class TestFunctional(unittest.TestCase):
name = os.path.split(fname)[0]
if name:
- orig_indata = self._GetDtbContentsForSplTpl(dtb_data, name)
+ orig_indata = self._GetDtbContentsForSpls(dtb_data, name)
else:
orig_indata = dtb_data
self.assertNotEqual(outdata, orig_indata,
@@ -4542,5 +4563,52 @@ class TestFunctional(unittest.TestCase):
data = self._DoReadFile('201_opensbi.dts')
self.assertEqual(OPENSBI_DATA, data[:len(OPENSBI_DATA)])
+ def testVpl(self):
+ """Test that an image with VPL and its device tree can be created"""
+ # ELF file with a '__bss_size' symbol
+ self._SetupVplElf()
+ data = self._DoReadFile('201_u_boot_vpl.dts')
+ self.assertEqual(U_BOOT_VPL_DATA + U_BOOT_VPL_DTB_DATA, data)
+
+ def testVplNoDtb(self):
+ """Test that an image with vpl/u-boot-vpl-nodtb.bin can be created"""
+ self._SetupVplElf()
+ data = self._DoReadFile('202_u_boot_vpl_nodtb.dts')
+ self.assertEqual(U_BOOT_VPL_NODTB_DATA,
+ data[:len(U_BOOT_VPL_NODTB_DATA)])
+
+ def testExpandedVpl(self):
+ """Test that an expanded entry type is selected for TPL when needed"""
+ self._SetupVplElf()
+
+ entry_args = {
+ 'vpl-bss-pad': 'y',
+ 'vpl-dtb': 'y',
+ }
+ self._DoReadFileDtb('203_fdt_incl_vpl.dts', use_expanded=True,
+ entry_args=entry_args)
+ image = control.images['image']
+ entries = image.GetEntries()
+ self.assertEqual(1, len(entries))
+
+ # We only have u-boot-vpl, which be expanded
+ self.assertIn('u-boot-vpl', entries)
+ entry = entries['u-boot-vpl']
+ self.assertEqual('u-boot-vpl-expanded', entry.etype)
+ subent = entry.GetEntries()
+ self.assertEqual(3, len(subent))
+ self.assertIn('u-boot-vpl-nodtb', subent)
+ self.assertIn('u-boot-vpl-bss-pad', subent)
+ self.assertIn('u-boot-vpl-dtb', subent)
+
+ def testVplBssPadMissing(self):
+ """Test that a missing symbol is detected"""
+ self._SetupVplElf('u_boot_ucode_ptr')
+ with self.assertRaises(ValueError) as e:
+ self._DoReadFile('204_vpl_bss_pad.dts')
+ self.assertIn('Expected __bss_size symbol in vpl/u-boot-vpl',
+ str(e.exception))
+
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/state.py b/tools/binman/state.py
index dfb17604554..e4a3abd2805 100644
--- a/tools/binman/state.py
+++ b/tools/binman/state.py
@@ -17,6 +17,7 @@ from patman import tout
DTB_TYPE_FNAME = {
'u-boot-spl-dtb': 'spl/u-boot-spl.dtb',
'u-boot-tpl-dtb': 'tpl/u-boot-tpl.dtb',
+ 'u-boot-vpl-dtb': 'vpl/u-boot-vpl.dtb',
}
# Records the device-tree files known to binman, keyed by entry type (e.g.
@@ -263,7 +264,7 @@ def GetAllFdts():
"""Yield all device tree files being used by binman
Yields:
- Device trees being used (U-Boot proper, SPL, TPL)
+ Device trees being used (U-Boot proper, SPL, TPL, VPL)
"""
if main_dtb:
yield main_dtb
diff --git a/tools/binman/test/082_fdt_update_all.dts b/tools/binman/test/082_fdt_update_all.dts
index 284975cc289..1aea56989f0 100644
--- a/tools/binman/test/082_fdt_update_all.dts
+++ b/tools/binman/test/082_fdt_update_all.dts
@@ -14,5 +14,7 @@
};
u-boot-tpl-dtb {
};
+ u-boot-vpl-dtb {
+ };
};
};
diff --git a/tools/binman/test/201_u_boot_vpl.dts b/tools/binman/test/201_u_boot_vpl.dts
new file mode 100644
index 00000000000..a3a281a91e0
--- /dev/null
+++ b/tools/binman/test/201_u_boot_vpl.dts
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+
+/dts-v1/;
+
+/ {
+ binman {
+ u-boot-vpl {
+ };
+ u-boot-vpl-dtb {
+ };
+ };
+};
diff --git a/tools/binman/test/202_u_boot_vpl_nodtb.dts b/tools/binman/test/202_u_boot_vpl_nodtb.dts
new file mode 100644
index 00000000000..055016badd5
--- /dev/null
+++ b/tools/binman/test/202_u_boot_vpl_nodtb.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ u-boot-vpl-nodtb {
+ };
+ };
+};
diff --git a/tools/binman/test/203_fdt_incl_vpl.dts b/tools/binman/test/203_fdt_incl_vpl.dts
new file mode 100644
index 00000000000..435256fe317
--- /dev/null
+++ b/tools/binman/test/203_fdt_incl_vpl.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ u-boot-vpl {
+ };
+ };
+};
diff --git a/tools/binman/test/204_vpl_bss_pad.dts b/tools/binman/test/204_vpl_bss_pad.dts
new file mode 100644
index 00000000000..d1e55fff4f2
--- /dev/null
+++ b/tools/binman/test/204_vpl_bss_pad.dts
@@ -0,0 +1,17 @@
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ u-boot-vpl {
+ };
+
+ u-boot-vpl-bss-pad {
+ };
+
+ u-boot {
+ };
+ };
+};
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 6/7] Introduce Verifying Program Loader (VPL)
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
` (4 preceding siblings ...)
2021-07-12 2:19 ` [PATCH v3 5/7] binman: Add VPL support Simon Glass
@ 2021-07-12 2:19 ` Simon Glass
2021-07-12 2:19 ` [PATCH v3 7/7] vpl: Add Kconfig options for VPL Simon Glass
2021-07-27 16:20 ` [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
7 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-12 2:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini, Simon Glass
Add support for VPL, a new phase of U-Boot. This runs after TPL. It is
responsible for selecting which SPL binary to run, based on a
verified-boot process.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v3:
- Move VPL Kconfig options to a separate patch
- Add full build support for VPL
Changes in v2:
- Add some more VPL Kconfig options
Makefile | 13 +++++++++++++
common/spl/Kconfig | 15 ++++++++++++++-
common/spl/spl.c | 25 ++++++++++++++++++++++---
doc/develop/spl.rst | 6 +++++-
include/bootstage.h | 2 ++
include/linux/kconfig.h | 3 +++
include/spl.h | 20 +++++++++++++++++---
scripts/Kbuild.include | 4 ++++
scripts/Makefile.autoconf | 12 ++++++++++++
scripts/Makefile.build | 4 ++++
scripts/Makefile.lib | 5 +++++
scripts/Makefile.spl | 35 ++++++++++++++++++++++++++---------
12 files changed, 127 insertions(+), 17 deletions(-)
diff --git a/Makefile b/Makefile
index f7f62979ae2..b2ba80ca5de 100644
--- a/Makefile
+++ b/Makefile
@@ -946,6 +946,7 @@ INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot.img
endif
endif
INPUTS-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
+INPUTS-$(CONFIG_VPL) += vpl/u-boot-vpl.bin
INPUTS-$(CONFIG_OF_SEPARATE) += u-boot.dtb
INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb
ifeq ($(CONFIG_SPL_FRAMEWORK),y)
@@ -1986,6 +1987,18 @@ tpl/u-boot-tpl.bin: tools prepare \
$(Q)$(MAKE) obj=tpl -f $(srctree)/scripts/Makefile.spl all
$(TPL_SIZE_CHECK)
+tpl/u-boot-tpl: tools prepare \
+ $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
+ $(Q)$(MAKE) obj=tpl -f $(srctree)/scripts/Makefile.spl all
+
+vpl/u-boot-vpl.bin: vpl/u-boot-vpl
+ @:
+ $(VPL_SIZE_CHECK)
+
+vpl/u-boot-vpl: tools prepare \
+ $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE)$(CONFIG_VPL_OF_PLATDATA),dts/dt.dtb)
+ $(Q)$(MAKE) obj=vpl -f $(srctree)/scripts/Makefile.spl all
+
TAG_SUBDIRS := $(patsubst %,$(srctree)/%,$(u-boot-dirs) include)
FIND := find
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 10384b835b2..0443197cd55 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -1,4 +1,4 @@
-menu "SPL / TPL"
+menu "SPL / TPL / VPL"
config SUPPORT_SPL
bool
@@ -6,6 +6,9 @@ config SUPPORT_SPL
config SUPPORT_TPL
bool
+config SUPPORT_VPL
+ bool
+
config SPL_DFU_NO_RESET
bool
@@ -280,6 +283,16 @@ config SPL_READ_ONLY
writeable memory) of anything it wants to modify, such as
device-private data.
+config TPL_SEPARATE_BSS
+ bool "BSS section is in a different memory region from text"
+ default y if SPL_SEPARATE_BSS
+ help
+ Some platforms need a large BSS region in TPL and can provide this
+ because RAM is already set up. In this case BSS can be moved to RAM.
+ This option should then be enabled so that the correct device tree
+ location is used. Normally we put the device tree at the end of BSS
+ but with this option enabled, it goes at _image_binary_end.
+
config SPL_BANNER_PRINT
bool "Enable output of the SPL banner 'U-Boot SPL ...'"
default y
diff --git a/common/spl/spl.c b/common/spl/spl.c
index eba77cace6d..27ed855c018 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -55,6 +55,11 @@ binman_sym_declare(ulong, spl, image_pos);
binman_sym_declare(ulong, spl, size);
#endif
+#ifdef CONFIG_VPL
+binman_sym_declare(ulong, vpl, image_pos);
+binman_sym_declare(ulong, vpl, size);
+#endif
+
/* Define board data structure */
static struct bd_info bdata __attribute__ ((section(".data")));
@@ -139,21 +144,33 @@ void spl_fixup_fdt(void *fdt_blob)
ulong spl_get_image_pos(void)
{
- return spl_phase() == PHASE_TPL ?
+#ifdef CONFIG_VPL
+ if (spl_next_phase() == PHASE_VPL)
+ return binman_sym(ulong, vpl, image_pos);
+#endif
+ return spl_next_phase() == PHASE_SPL ?
binman_sym(ulong, spl, image_pos) :
binman_sym(ulong, u_boot_any, image_pos);
}
ulong spl_get_image_size(void)
{
- return spl_phase() == PHASE_TPL ?
+#ifdef CONFIG_VPL
+ if (spl_next_phase() == PHASE_VPL)
+ return binman_sym(ulong, vpl, size);
+#endif
+ return spl_next_phase() == PHASE_SPL ?
binman_sym(ulong, spl, size) :
binman_sym(ulong, u_boot_any, size);
}
ulong spl_get_image_text_base(void)
{
- return spl_phase() == PHASE_TPL ? CONFIG_SPL_TEXT_BASE :
+#ifdef CONFIG_VPL
+ if (spl_next_phase() == PHASE_VPL)
+ return CONFIG_VPL_TEXT_BASE;
+#endif
+ return spl_next_phase() == PHASE_SPL ? CONFIG_SPL_TEXT_BASE :
CONFIG_SYS_TEXT_BASE;
}
@@ -430,6 +447,8 @@ static enum bootstage_id get_bootstage_id(bool start)
if (IS_ENABLED(CONFIG_TPL_BUILD) && phase == PHASE_TPL)
return start ? BOOTSTAGE_ID_START_TPL : BOOTSTAGE_ID_END_TPL;
+ else if (IS_ENABLED(CONFIG_VPL_BUILD) && phase == PHASE_VPL)
+ return start ? BOOTSTAGE_ID_START_VPL : BOOTSTAGE_ID_END_VPL;
else
return start ? BOOTSTAGE_ID_START_SPL : BOOTSTAGE_ID_END_SPL;
}
diff --git a/doc/develop/spl.rst b/doc/develop/spl.rst
index c2a29a8c0a4..ede79431118 100644
--- a/doc/develop/spl.rst
+++ b/doc/develop/spl.rst
@@ -62,7 +62,11 @@ U-Boot Phases
U-Boot boots through the following phases:
TPL
- Very early init, as tiny as possible. This loads SPL.
+ Very early init, as tiny as possible. This loads SPL (or VPL if enabled).
+
+VPL
+ Optional verification step, which can select one of several SPL binaries,
+ if A/B verified boot
SPL
Secondary program loader. Sets up SDRAM and loads U-Boot proper. It may also
diff --git a/include/bootstage.h b/include/bootstage.h
index f837a387c8c..1a384e5b60a 100644
--- a/include/bootstage.h
+++ b/include/bootstage.h
@@ -176,6 +176,8 @@ enum bootstage_id {
BOOTSTAGE_ID_END_TPL,
BOOTSTAGE_ID_START_SPL,
BOOTSTAGE_ID_END_SPL,
+ BOOTSTAGE_ID_START_VPL,
+ BOOTSTAGE_ID_END_VPL,
BOOTSTAGE_ID_START_UBOOT_F,
BOOTSTAGE_ID_START_UBOOT_R,
BOOTSTAGE_ID_USB_START,
diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index d109ed3119e..26f1216f7da 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -37,6 +37,8 @@
#if defined(CONFIG_TPL_BUILD)
#define _CONFIG_PREFIX TPL_
+#elif defined(CONFIG_VPL_BUILD)
+#define _CONFIG_PREFIX VPL_
#elif defined(CONFIG_SPL_BUILD)
#define _CONFIG_PREFIX SPL_
#else
@@ -52,6 +54,7 @@
* CONFIG_FOO if CONFIG_SPL_BUILD is undefined,
* CONFIG_SPL_FOO if CONFIG_SPL_BUILD is defined.
* CONFIG_TPL_FOO if CONFIG_TPL_BUILD is defined.
+ * CONFIG_VPL_FOO if CONFIG_VPL_BUILD is defined.
*/
#define CONFIG_VAL(option) config_val(option)
diff --git a/include/spl.h b/include/spl.h
index cee9a42ddb5..d9fe4e1bfd4 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -60,6 +60,7 @@ static inline bool u_boot_first_phase(void)
enum u_boot_phase {
PHASE_NONE, /* Invalid phase, signifying before U-Boot */
PHASE_TPL, /* Running in TPL */
+ PHASE_VPL, /* Running in VPL */
PHASE_SPL, /* Running in SPL */
PHASE_BOARD_F, /* Running in U-Boot before relocation */
PHASE_BOARD_R, /* Running in U-Boot after relocation */
@@ -112,7 +113,9 @@ static inline enum u_boot_phase spl_phase(void)
{
#ifdef CONFIG_TPL_BUILD
return PHASE_TPL;
-#elif CONFIG_SPL_BUILD
+#elif defined(CONFIG_VPL_BUILD)
+ return PHASE_VPL;
+#elif defined(CONFIG_SPL_BUILD)
return PHASE_SPL;
#else
DECLARE_GLOBAL_DATA_PTR;
@@ -134,10 +137,15 @@ static inline enum u_boot_phase spl_prev_phase(void)
{
#ifdef CONFIG_TPL_BUILD
return PHASE_NONE;
+#elif defined(CONFIG_VPL_BUILD)
+ return PHASE_TPL; /* VPL requires TPL */
#elif defined(CONFIG_SPL_BUILD)
- return IS_ENABLED(CONFIG_TPL) ? PHASE_TPL : PHASE_NONE;
+ return IS_ENABLED(CONFIG_VPL) ? PHASE_VPL :
+ IS_ENABLED(CONFIG_TPL) ? PHASE_TPL :
+ PHASE_NONE;
#else
- return IS_ENABLED(CONFIG_SPL) ? PHASE_SPL : PHASE_NONE;
+ return IS_ENABLED(CONFIG_SPL) ? PHASE_SPL :
+ PHASE_NONE;
#endif
}
@@ -150,6 +158,8 @@ static inline enum u_boot_phase spl_prev_phase(void)
static inline enum u_boot_phase spl_next_phase(void)
{
#ifdef CONFIG_TPL_BUILD
+ return IS_ENABLED(CONFIG_VPL) ? PHASE_VPL : PHASE_SPL;
+#elif defined(CONFIG_VPL_BUILD)
return PHASE_SPL;
#else
return PHASE_BOARD_F;
@@ -166,6 +176,8 @@ static inline const char *spl_phase_name(enum u_boot_phase phase)
switch (phase) {
case PHASE_TPL:
return "TPL";
+ case PHASE_VPL:
+ return "VPL";
case PHASE_SPL:
return "SPL";
case PHASE_BOARD_F:
@@ -180,6 +192,8 @@ static inline const char *spl_phase_name(enum u_boot_phase phase)
#ifdef CONFIG_SPL_BUILD
# ifdef CONFIG_TPL_BUILD
# define SPL_TPL_NAME "TPL"
+# elif defined(CONFIG_VPL_BUILD)
+# define SPL_TPL_NAME "VPL"
# else
# define SPL_TPL_NAME "SPL"
# endif
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index dfb67226b08..c87d9c9f5f2 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -325,11 +325,15 @@ endif
ifdef CONFIG_SPL_BUILD
SPL_ := SPL_
+ifeq ($(CONFIG_VPL_BUILD),y)
+SPL_TPL_ := VPL_
+else
ifeq ($(CONFIG_TPL_BUILD),y)
SPL_TPL_ := TPL_
else
SPL_TPL_ := SPL_
endif
+endif
else
SPL_ :=
SPL_TPL_ :=
diff --git a/scripts/Makefile.autoconf b/scripts/Makefile.autoconf
index 0bfc1b2a629..ad556f80f71 100644
--- a/scripts/Makefile.autoconf
+++ b/scripts/Makefile.autoconf
@@ -18,6 +18,10 @@ ifeq ($(shell grep -q '^CONFIG_TPL=y' include/config/auto.conf 2>/dev/null && ec
__all: tpl/include/autoconf.mk
endif
+ifeq ($(shell grep -q '^CONFIG_VPL=y' include/config/auto.conf 2>/dev/null && echo y),y)
+__all: vpl/include/autoconf.mk
+endif
+
include include/config/auto.conf
include scripts/Kbuild.include
@@ -84,6 +88,10 @@ tpl/u-boot.cfg: include/config.h FORCE
$(Q)mkdir -p $(dir $@)
$(call cmd,u_boot_cfg,-DCONFIG_SPL_BUILD -DCONFIG_TPL_BUILD)
+vpl/u-boot.cfg: include/config.h FORCE
+ $(Q)mkdir -p $(dir $@)
+ $(call cmd,u_boot_cfg,-DCONFIG_SPL_BUILD -DCONFIG_VPL_BUILD)
+
include/autoconf.mk: u-boot.cfg
$(call cmd,autoconf)
@@ -95,6 +103,10 @@ tpl/include/autoconf.mk: tpl/u-boot.cfg
$(Q)mkdir -p $(dir $@)
$(call cmd,autoconf)
+vpl/include/autoconf.mk: vpl/u-boot.cfg
+ $(Q)mkdir -p $(dir $@)
+ $(call cmd,autoconf)
+
# include/config.h
# Prior to Kconfig, it was generated by mkconfig. Now it is created here.
define filechk_config_h
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 7e59ca54cd0..1d72ba18ebd 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -4,6 +4,9 @@
# ==========================================================================
# Modified for U-Boot
+prefix := vpl
+src := $(patsubst $(prefix)/%,%,$(obj))
+ifeq ($(obj),$(src))
prefix := tpl
src := $(patsubst $(prefix)/%,%,$(obj))
ifeq ($(obj),$(src))
@@ -13,6 +16,7 @@ ifeq ($(obj),$(src))
prefix := .
endif
endif
+endif
PHONY := __build
__build:
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 78bbebe7e93..c08ad44db5f 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -556,16 +556,21 @@ cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
# 'u-boot,dm-pre-reloc' property and thus are not needed by SPL. The second
# pass removes various unused properties from the remaining nodes.
# The output is typically a much smaller device tree file.
+ifeq ($(CONFIG_VPL_BUILD),y)
+fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-vpl
+else
ifeq ($(CONFIG_TPL_BUILD),y)
fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-tpl
else
fdtgrep_props := -b u-boot,dm-pre-reloc -b u-boot,dm-spl
endif
+endif
quiet_cmd_fdtgrep = FDTGREP $@
cmd_fdtgrep = $(objtree)/tools/fdtgrep $(fdtgrep_props) -RT $< \
-n /chosen -n /config -O dtb | \
$(objtree)/tools/fdtgrep -r -O dtb - -o $@ \
-P u-boot,dm-pre-reloc -P u-boot,dm-spl -P u-boot,dm-tpl \
+ -P u-boot,dm-vpl \
$(addprefix -P ,$(subst $\",,$(CONFIG_OF_SPL_REMOVE_PROPS)))
# fdt_rm_props
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ffe919dafab..082ddb9c5f2 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -27,8 +27,16 @@ UBOOTINCLUDE := -I$(obj)/include $(UBOOTINCLUDE)
KBUILD_CPPFLAGS += -DCONFIG_SPL_BUILD
ifeq ($(CONFIG_TPL_BUILD),y)
KBUILD_CPPFLAGS += -DCONFIG_TPL_BUILD
+else
+ifeq ($(CONFIG_VPL_BUILD),y)
+KBUILD_CPPFLAGS += -DCONFIG_VPL_BUILD
+endif
endif
+ifeq ($(CONFIG_VPL_BUILD),y)
+SPL_BIN := u-boot-vpl
+SPL_NAME := vpl
+else
ifeq ($(CONFIG_TPL_BUILD),y)
SPL_BIN := u-boot-tpl
SPL_NAME := tpl
@@ -36,16 +44,21 @@ else
SPL_BIN := u-boot-spl
SPL_NAME := spl
endif
+endif
export SPL_NAME
ifdef CONFIG_SPL_BUILD
SPL_ := SPL_
+ifeq ($(CONFIG_VPL_BUILD),y)
+SPL_TPL_ := VPL_
+else
ifeq ($(CONFIG_TPL_BUILD),y)
SPL_TPL_ := TPL_
else
SPL_TPL_ := SPL_
endif
+endif
else
SPL_ :=
SPL_TPL_ :=
@@ -57,6 +70,9 @@ endif
ifeq ($(obj)$(CONFIG_SUPPORT_TPL),tpl)
$(error You cannot build TPL without enabling CONFIG_SUPPORT_TPL)
endif
+ifeq ($(obj)$(CONFIG_SUPPORT_VPL),vpl)
+$(error You cannot build VPL without enabling CONFIG_SUPPORT_VPL)
+endif
include $(srctree)/config.mk
include $(srctree)/arch/$(ARCH)/Makefile
@@ -90,13 +106,12 @@ libs-$(CONFIG_SPL_FRAMEWORK) += common/spl/
endif
libs-y += common/init/
+# Special handling for a few options which support SPL/TPL/VPL
+libs-$(CONFIG_$(SPL_TPL_)LIBCOMMON_SUPPORT) += common/ cmd/ env/
+libs-$(CONFIG_$(SPL_TPL_)LIBGENERIC_SUPPORT) += lib/
+
# Special handling for a few options which support SPL/TPL
-ifeq ($(CONFIG_TPL_BUILD),y)
-libs-$(CONFIG_TPL_LIBCOMMON_SUPPORT) += common/ cmd/ env/
-libs-$(CONFIG_TPL_LIBGENERIC_SUPPORT) += lib/
-else
-libs-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/ cmd/ env/
-libs-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/
+ifeq ($(CONFIG_TPL_BUILD)$(CONFIG_VPL_BUILD),)
ifdef CONFIG_SPL_FRAMEWORK
libs-$(CONFIG_PARTITIONS) += disk/
endif
@@ -182,7 +197,7 @@ LDPPFLAGS += \
sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p')
# Turn various CONFIG symbols into IMAGE symbols for easy reuse of
-# the scripts between SPL and TPL.
+# the scripts between SPL, TPL and VPL.
ifneq ($(CONFIG_$(SPL_TPL_)MAX_SIZE),)
LDPPFLAGS += -DIMAGE_MAX_SIZE=$(CONFIG_$(SPL_TPL_)MAX_SIZE)
endif
@@ -264,6 +279,7 @@ ifeq ($(CONFIG_SYS_SOC),"at91")
INPUTS-y += $(obj)/boot.bin
endif
+ifndef CONFIG_VPL_BUILD
ifdef CONFIG_TPL_BUILD
INPUTS-$(CONFIG_TPL_X86_16BIT_INIT) += $(obj)/u-boot-x86-start16-tpl.bin \
$(obj)/u-boot-x86-reset16-tpl.bin
@@ -271,6 +287,7 @@ else
INPUTS-$(CONFIG_SPL_X86_16BIT_INIT) += $(obj)/u-boot-x86-start16-spl.bin \
$(obj)/u-boot-x86-reset16-spl.bin
endif
+endif
INPUTS-$(CONFIG_ARCH_ZYNQ) += $(obj)/boot.bin
INPUTS-$(CONFIG_ARCH_ZYNQMP) += $(obj)/boot.bin
@@ -310,7 +327,7 @@ endif
ifneq ($(build_dtb),)
$(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin \
- $(if $(CONFIG_SPL_SEPARATE_BSS),,$(obj)/$(SPL_BIN)-pad.bin) \
+ $(if $(CONFIG_$(SPL_TPL_)SEPARATE_BSS),,$(obj)/$(SPL_BIN)-pad.bin) \
$(FINAL_DTB_CONTAINER) FORCE
$(call if_changed,cat)
@@ -401,7 +418,7 @@ LDFLAGS_$(SPL_BIN) += $(call ld-option, --no-dynamic-linker)
LDFLAGS_$(SPL_BIN) += --build-id=none
-# Pick the best-match (i.e. SPL_TEXT_BASE for SPL, TPL_TEXT_BASE for TPL)
+# Pick the best match (e.g. SPL_TEXT_BASE for SPL, TPL_TEXT_BASE for TPL)
ifneq ($(CONFIG_$(SPL_TPL_)TEXT_BASE),)
LDFLAGS_$(SPL_BIN) += -Ttext $(CONFIG_$(SPL_TPL_)TEXT_BASE)
endif
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 7/7] vpl: Add Kconfig options for VPL
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
` (5 preceding siblings ...)
2021-07-12 2:19 ` [PATCH v3 6/7] Introduce Verifying Program Loader (VPL) Simon Glass
@ 2021-07-12 2:19 ` Simon Glass
2021-07-27 16:20 ` [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
7 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-12 2:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini, Simon Glass
Add VPL versions of commonly used Kconfig options.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Kconfig | 10 +++
arch/sandbox/Kconfig | 8 ++
common/Kconfig | 67 ++++++++++++++
common/spl/Kconfig | 189 +++++++++++++++++++++++++++++++++++++++
drivers/clk/Kconfig | 10 +++
drivers/core/Makefile | 2 +-
drivers/gpio/Kconfig | 11 +++
drivers/i2c/Kconfig | 11 +++
drivers/misc/Kconfig | 19 ++++
drivers/pinctrl/Kconfig | 18 +++-
drivers/rtc/Kconfig | 9 ++
drivers/serial/Kconfig | 20 +++++
drivers/sysreset/Kconfig | 10 +++
drivers/timer/Kconfig | 10 +++
lib/Kconfig | 62 +++++++++++++
15 files changed, 453 insertions(+), 3 deletions(-)
diff --git a/Kconfig b/Kconfig
index f8c1a77bedb..8cd8c59d045 100644
--- a/Kconfig
+++ b/Kconfig
@@ -264,6 +264,16 @@ config TPL_SYS_MALLOC_F_LEN
particular needs this to operate, so that it can allocate the
initial serial device and any others that are needed.
+config VPL_SYS_MALLOC_F_LEN
+ hex "Size of malloc() pool in VPL before relocation"
+ depends on SYS_MALLOC_F && VPL
+ default SYS_MALLOC_F_LEN
+ help
+ Before relocation, memory is very limited on many platforms. Still,
+ we can provide a small malloc() pool if needed. Driver model in
+ particular needs this to operate, so that it can allocate the
+ initial serial device and any others that are needed.
+
menuconfig EXPERT
bool "Configure standard U-Boot features (expert users)"
default y
diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
index f83282d9d56..e504b08b951 100644
--- a/arch/sandbox/Kconfig
+++ b/arch/sandbox/Kconfig
@@ -29,6 +29,14 @@ config SANDBOX_SPL
bool "Enable SPL for sandbox"
select SUPPORT_SPL
+config SANDBOX_TPL
+ bool "Enable TPL for sandbox"
+ select SUPPORT_TPL
+
+config SANDBOX_VPL
+ bool "Enable VPL for sandbox"
+ select SUPPORT_VPL
+
config SYS_CONFIG_NAME
default "sandbox_spl" if SANDBOX_SPL
default "sandbox" if !SANDBOX_SPL
diff --git a/common/Kconfig b/common/Kconfig
index 26496f9a2e7..2a7f08af1dc 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -81,6 +81,15 @@ config TPL_LOGLEVEL
int
default LOGLEVEL
+config VPL_LOGLEVEL
+ int "loglevel for VPL"
+ default LOGLEVEL
+ help
+ All Messages with a loglevel smaller than the console loglevel will
+ be compiled in to VPL. See LOGLEVEL for a list of available log
+ levels. Setting this to a value above 4 may increase the code size
+ significantly.
+
config SILENT_CONSOLE
bool "Support a silent console"
help
@@ -254,6 +263,15 @@ config LOG
if LOG
+config VPL_LOG
+ bool "Enable logging support in VPL"
+ depends on LOG
+ help
+ This enables support for logging of status and debug messages. These
+ can be displayed on the console, recorded in a memory buffer, or
+ discarded if not needed. Logging supports various categories and
+ levels of severity.
+
config LOG_MAX_LEVEL
int "Maximum log level to record"
default 6
@@ -415,6 +433,47 @@ config TPL_LOG_CONSOLE
endif
+config VPL_LOG
+ bool "Enable logging support in VPL"
+ depends on LOG
+ help
+ This enables support for logging of status and debug messages. These
+ can be displayed on the console, recorded in a memory buffer, or
+ discarded if not needed. Logging supports various categories and
+ levels of severity.
+
+if VPL_LOG
+
+config VPL_LOG_MAX_LEVEL
+ int "Maximum log level to record in VPL"
+ default 3
+ help
+ This selects the maximum log level that will be recorded. Any value
+ higher than this will be ignored. If possible log statements below
+ this level will be discarded at build time. Levels:
+
+ 0 - emergency
+ 1 - alert
+ 2 - critical
+ 3 - error
+ 4 - warning
+ 5 - note
+ 6 - info
+ 7 - debug
+ 8 - debug content
+ 9 - debug hardware I/O
+
+config VPL_LOG_CONSOLE
+ bool "Allow log output to the console in VPL"
+ default y
+ help
+ Enables a log driver which writes log records to the console.
+ Generally the console is the serial port or LCD display. Only the
+ log message is shown - other details like level, category, file and
+ line number are omitted.
+
+endif
+
config LOG_ERROR_RETURN
bool "Log all functions which return an error"
help
@@ -711,6 +770,14 @@ config TPL_BLOBLIST
This enables a bloblist in TPL. The bloblist is set up in TPL and
passed to SPL and U-Boot proper.
+config VPL_BLOBLIST
+ bool "Support for a bloblist in VPL"
+ depends on BLOBLIST
+ default y if TPL_BLOBLIST
+ help
+ This enables a bloblist in VPL. The bloblist is set up in VPL and
+ passed to SPL and U-Boot proper.
+
config BLOBLIST_SIZE
hex "Size of bloblist"
depends on BLOBLIST
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0443197cd55..106296d81d6 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -167,6 +167,13 @@ config SPL_BOARD_INIT
spl_board_init() from board_init_r(). This function should be
provided by the board.
+config VPL_BOARD_INIT
+ bool "Call board-specific initialization in VPL"
+ help
+ If this option is enabled, U-Boot will call the function
+ spl_board_init() from board_init_r(). This function should be
+ provided by the board.
+
config SPL_BOOTROM_SUPPORT
bool "Support returning to the BOOTROM"
help
@@ -310,6 +317,15 @@ config TPL_BANNER_PRINT
info. Disabling this option could be useful to reduce TPL boot time
(e.g. approx. 6 ms faster, when output on i.MX6 with 115200 baud).
+config VPL_BANNER_PRINT
+ bool "Enable output of the VPL banner 'U-Boot VPL ...'"
+ depends on VPL
+ default y
+ help
+ If this option is enabled, VPL will print the banner with version
+ info. Disabling this option could be useful to reduce VPL boot time
+ (e.g. approx. 6 ms faster, when output on i.MX6 with 115200 baud).
+
config SPL_EARLY_BSS
depends on ARM && !ARM64
bool "Allows initializing BSS early before entering board_init_f"
@@ -819,6 +835,27 @@ config SPL_DM_SPI_FLASH
Enable support for SPI DM flash drivers in SPL.
endif
+
+if TPL
+
+config VPL_CACHE
+ depends on CACHE
+ bool "Support cache drivers in SPL"
+ help
+ Enable support for cache drivers in SPL.
+
+config VPL_DM_SPI
+ bool "Support SPI DM drivers in SPL"
+ help
+ Enable support for SPI DM drivers in SPL.
+
+config VPL_DM_SPI_FLASH
+ bool "Support SPI DM FLASH drivers in SPL"
+ help
+ Enable support for SPI DM flash drivers in SPL.
+
+endif
+
if SPL_UBI
config SPL_UBI_LOAD_BY_VOLNAME
bool "Support loading volumes by name"
@@ -1636,6 +1673,158 @@ config TPL_YMODEM_SUPPORT
endif # TPL
+config VPL
+ bool
+ depends on SUPPORT_SPL
+ prompt "Enable VPL"
+ help
+ If you want to build VPL as well as the normal image, TPL and SPL,
+ say Y.
+
+if VPL
+
+config VPL_FRAMEWORK
+ bool "Support VPL based upon the common SPL framework"
+ default y
+ help
+ Enable the SPL framework under common/spl/ for VPL builds.
+ This framework supports MMC, NAND and YMODEM and other methods
+ loading of U-Boot's next stage. If unsure, say Y.
+
+config VPL_HANDOFF
+ bool "Pass hand-off information from VPL to SPL"
+ depends on HANDOFF && VPL_BLOBLIST
+ default y
+ help
+ This option enables VPL to write handoff information. This can be
+ used to pass information like the size of SDRAM from VPL to SPL. Also
+ VPL can receive information from TPL in the same place if that is
+ enabled.
+
+config VPL_LIBCOMMON_SUPPORT
+ bool "Support common libraries"
+ default y if SPL_LIBCOMMON_SUPPORT
+ help
+ Enable support for common U-Boot libraries within VPL. See
+ SPL_LIBCOMMON_SUPPORT for details.
+
+config VPL_LIBGENERIC_SUPPORT
+ bool "Support generic libraries"
+ default y if SPL_LIBGENERIC_SUPPORT
+ help
+ Enable support for generic U-Boot libraries within VPL. These
+ libraries include generic code to deal with device tree, hashing,
+ printf(), compression and the like. This option is enabled on many
+ boards. Enable this option to build the code in lib/ as part of an
+ SPL build.
+
+config VPL_DRIVERS_MISC_SUPPORT
+ bool "Support misc drivers"
+ default y if TPL_DRIVERS_MISC_SUPPORT
+ help
+ Enable miscellaneous drivers in VPL. These drivers perform various
+ tasks that don't fall nicely into other categories, Enable this
+ option to build the drivers in drivers/misc as part of an VPL
+ build, for those that support building in VPL (not all drivers do).
+
+config VPL_ENV_SUPPORT
+ bool "Support an environment"
+ help
+ Enable environment support in VPL. The U-Boot environment provides
+ a number of settings (essentially name/value pairs) which can
+ control many aspects of U-Boot's operation. Enabling this option will
+ make env_get() and env_set() available in VSPL.
+
+config VPL_GPIO_SUPPORT
+ bool "Support GPIO in VPL"
+ default y if SPL_GPIO_SUPPORT
+ help
+ Enable support for GPIOs (General-purpose Input/Output) in VPL.
+ GPIOs allow U-Boot to read the state of an input line (high or
+ low) and set the state of an output line. This can be used to
+ drive LEDs, control power to various system parts and read user
+ input. GPIOs can be useful in TPL to enable a 'sign-of-life' LED,
+ for example. Enable this option to build the drivers in
+ drivers/gpio as part of an TPL build.
+
+config VPL_HASH_SUPPORT
+ bool "Support hashing drivers in VPL"
+ depends on VPL
+ select SHA1
+ select SHA256
+ help
+ Enable hashing drivers in SPL. These drivers can be used to
+ accelerate secure boot processing in secure applications. Enable
+ this option to build system-specific drivers for hash acceleration
+ as part of an SPL build.
+
+config VPL_I2C_SUPPORT
+ bool "Support I2C in VPL"
+ default y if SPL_I2C_SUPPORT
+ help
+ Enable support for the I2C bus in TPL. Vee SPL_I2C_SUPPORT for
+ details.
+
+config VPL_PCH_SUPPORT
+ bool "Support PCH drivers"
+ default y if TPL_PCH_SUPPORT
+ help
+ Enable support for PCH (Platform Controller Hub) devices in VPL.
+ These are used to set up GPIOs and the SPI peripheral early in
+ boot. This enables the drivers in drivers/pch as part of a VPL
+ build.
+
+config VPL_PCI
+ bool "Support PCI drivers"
+ default y if SPL_PCI
+ help
+ Enable support for PCI in VPL. For platforms that need PCI to boot,
+ or must perform some init using PCI in VPL, this provides the
+ necessary driver support. This enables the drivers in drivers/pci
+ as part of a VPL build.
+
+config VPL_RTC_SUPPORT
+ bool "Support RTC drivers"
+ help
+ Enable RTC (Real-time Clock) support in VPL. This includes support
+ for reading and setting the time. Some RTC devices also have some
+ non-volatile (battery-backed) memory which is accessible if
+ needed. This enables the drivers in drivers/rtc as part of an VPL
+ build.
+
+config VPL_SERIAL_SUPPORT
+ bool "Support serial"
+ default y if SPL_SERIAL_SUPPORT
+ select VPL_PRINTF
+ select VPL_STRTO
+ help
+ Enable support for serial in VPL. See SPL_SERIAL_SUPPORT for
+ details.
+
+config VPL_SPI_SUPPORT
+ bool "Support SPI drivers"
+ help
+ Enable support for using SPI in VPL. See SPL_SPI_SUPPORT for
+ details.
+
+config VPL_SPI_FLASH_SUPPORT
+ bool "Support SPI flash drivers"
+ help
+ Enable support for using SPI flash in VPL, and loading U-Boot from
+ SPI flash. SPI flash (Serial Peripheral Bus flash) is named after
+ the SPI bus that is used to connect it to a system. It is a simple
+ but fast bidirectional 4-wire bus (clock, chip select and two data
+ lines). This enables the drivers in drivers/mtd/spi as part of an
+ VPL build. This normally requires VPL_SPI_SUPPORT.
+
+config VPL_TEXT_BASE
+ hex "VPL Text Base"
+ default 0x0
+ help
+ The address in memory that VPL will be running from.
+
+endif
+
config SPL_AT91_MCK_BYPASS
bool "Use external clock signal as a source of main clock for AT91 platforms"
depends on ARCH_AT91
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index e07c6dd78a6..4b0bed66bfb 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -30,6 +30,16 @@ config TPL_CLK
setting up clocks within TPL, and allows the same drivers to be
used as U-Boot proper.
+config VPL_CLK
+ bool "Enable clock support in VPL"
+ depends on CLK && VPL_DM
+ help
+ The clock subsystem adds a small amount of overhead to the image.
+ If this is acceptable and you have a need to use clock drivers in
+ SPL, enable this option. It might provide a cleaner interface to
+ setting up clocks within TPL, and allows the same drivers to be
+ used as U-Boot proper.
+
config CLK_BCM6345
bool "Clock controller driver for BCM6345"
depends on CLK && ARCH_BMIPS
diff --git a/drivers/core/Makefile b/drivers/core/Makefile
index 5edd4e41357..07a0886383f 100644
--- a/drivers/core/Makefile
+++ b/drivers/core/Makefile
@@ -5,7 +5,7 @@
obj-y += device.o fdtaddr.o lists.o root.o uclass.o util.o
obj-$(CONFIG_$(SPL_TPL_)ACPIGEN) += acpi.o
obj-$(CONFIG_DEVRES) += devres.o
-obj-$(CONFIG_$(SPL_)DM_DEVICE_REMOVE) += device-remove.o
+obj-$(CONFIG_$(SPL_TPL_)DM_DEVICE_REMOVE) += device-remove.o
obj-$(CONFIG_$(SPL_)SIMPLE_BUS) += simple-bus.o
obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
obj-$(CONFIG_DM) += dump.o
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index de4dc51d4b4..36a0074f5b9 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -36,6 +36,17 @@ config TPL_DM_GPIO
particular GPIOs that they provide. The uclass interface
is defined in include/asm-generic/gpio.h.
+config VPL_DM_GPIO
+ bool "Enable Driver Model for GPIO drivers in VPL"
+ depends on DM_GPIO && VPL_DM && VPL_GPIO
+ default y
+ help
+ Enable driver model for GPIO access in VPL. The standard GPIO
+ interface (gpio_get_value(), etc.) is then implemented by
+ the GPIO uclass. Drivers provide methods to query the
+ particular GPIOs that they provide. The uclass interface
+ is defined in include/asm-generic/gpio.h.
+
config GPIO_HOG
bool "Enable GPIO hog support"
depends on DM_GPIO
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 35d6e2c8ec5..31f9cb44769 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -25,6 +25,17 @@ config SPL_DM_I2C
device (bus child) info is kept as parent platdata. The interface
is defined in include/i2c.h.
+config VPL_DM_I2C
+ bool "Enable Driver Model for I2C drivers in VPL"
+ depends on VPL_DM && DM_I2C
+ default y
+ help
+ Enable driver model for I2C. The I2C uclass interface: probe, read,
+ write and speed, is implemented with the bus drivers operations,
+ which provide methods for bus setting and data transfer. Each chip
+ device (bus child) info is kept as parent platdata. The interface
+ is defined in include/i2c.h.
+
config I2C_CROS_EC_TUNNEL
tristate "Chrome OS EC tunnel I2C bus"
depends on CROS_EC
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 997b7132211..12f419771a2 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -122,6 +122,16 @@ config TPL_CROS_EC
control access to the battery and main PMIC depending on the
device. You can use the 'crosec' command to access it.
+config VPL_CROS_EC
+ bool "Enable Chrome OS EC in VPL"
+ depends on VPL
+ help
+ Enable access to the Chrome OS EC in VPL. This is a separate
+ microcontroller typically available on a SPI bus on Chromebooks. It
+ provides access to the keyboard, some internal storage and may
+ control access to the battery and main PMIC depending on the
+ device. You can use the 'crosec' command to access it.
+
config CROS_EC_I2C
bool "Enable Chrome OS EC I2C driver"
depends on CROS_EC
@@ -185,6 +195,15 @@ config TPL_CROS_EC_SANDBOX
EC flash read/write/erase support and a few other things. It is
enough to perform a Chrome OS verified boot on sandbox.
+config VPL_CROS_EC_SANDBOX
+ bool "Enable Chrome OS EC sandbox driver in VPL"
+ depends on VPL_CROS_EC && SANDBOX
+ help
+ Enable a sandbox emulation of the Chrome OS EC in VPL. This supports
+ keyboard (use the -l flag to enable the LCD), verified boot context,
+ EC flash read/write/erase support and a few other things. It is
+ enough to perform a Chrome OS verified boot on sandbox.
+
config CROS_EC_SPI
bool "Enable Chrome OS EC SPI driver"
depends on CROS_EC
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 77fb8511144..d967a82f726 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -89,20 +89,34 @@ config TPL_PINCTRL
This option is an TPL variant of the PINCTRL option.
See the help of PINCTRL for details.
+config VPL_PINCTRL
+ bool "Support pin controllers in VPL"
+ depends on VPL && VPL_DM
+ help
+ This option is an VPL variant of the PINCTRL option.
+ See the help of PINCTRL for details.
+
config SPL_PINCTRL_FULL
bool "Support full pin controllers in SPL"
depends on SPL_PINCTRL && SPL_OF_CONTROL
default n if TARGET_STM32F746_DISCO
default y
help
- This option is an SPL-variant of the PINCTRL_FULL option.
+ This option is an SPL variant of the PINCTRL_FULL option.
See the help of PINCTRL_FULL for details.
config TPL_PINCTRL_FULL
bool "Support full pin controllers in TPL"
depends on TPL_PINCTRL && TPL_OF_CONTROL
help
- This option is an TPL-variant of the PINCTRL_FULL option.
+ This option is a TPL variant of the PINCTRL_FULL option.
+ See the help of PINCTRL_FULL for details.
+
+config VPL_PINCTRL_FULL
+ bool "Support full pin controllers in VPL"
+ depends on VPL_PINCTRL && VPL_OF_CONTROL
+ help
+ This option is a VPL variant of the PINCTRL_FULL option.
See the help of PINCTRL_FULL for details.
config SPL_PINCTRL_GENERIC
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index cbdfddb80f6..3de6d3fb4d8 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -32,6 +32,15 @@ config TPL_DM_RTC
drivers to perform the actual functions. See rtc.h for a
description of the API.
+config VPL_DM_RTC
+ bool "Enable Driver Model for RTC drivers in VPL"
+ depends on VPL_DM
+ help
+ Enable drver model for real-time-clock drivers. The RTC uclass
+ then provides the rtc_get()/rtc_set() interface, delegating to
+ drivers to perform the actual functions. See rtc.h for a
+ description of the API.
+
config RTC_ENABLE_32KHZ_OUTPUT
bool "Enable RTC 32Khz output"
help
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 961e3fb0314..a8fdffe2ccf 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -63,6 +63,16 @@ config TPL_SERIAL_PRESENT
This option enables the full UART in TPL, so if is it disabled,
the full UART driver will be omitted, thus saving space.
+config VPL_SERIAL_PRESENT
+ bool "Provide a serial driver in VPL"
+ depends on DM_SERIAL && VPL
+ default y
+ help
+ In very space-constrained devices even the full UART driver is too
+ large. In this case the debug UART can still be used in some cases.
+ This option enables the full UART in TPL, so if is it disabled,
+ the full UART driver will be omitted, thus saving space.
+
# Logic to allow us to use the imply keyword to set what the default port
# should be. The default is otherwise 1.
config CONS_INDEX_0
@@ -172,6 +182,16 @@ config TPL_DM_SERIAL
implements serial_putc() etc. The uclass interface is
defined in include/serial.h.
+config VPL_DM_SERIAL
+ bool "Enable Driver Model for serial drivers in VPL"
+ depends on DM_SERIAL
+ default y if VPL && DM_SERIAL
+ help
+ Enable driver model for serial in VPL. This replaces
+ drivers/serial/serial.c with the serial uclass, which
+ implements serial_putc() etc. The uclass interface is
+ defined in include/serial.h.
+
config DEBUG_UART
bool "Enable an early debug UART for debugging"
help
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index ac77ffbc8be..fec6fed6c31 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -31,6 +31,16 @@ config TPL_SYSRESET
to effect a reset. The uclass will try all available drivers when
reset_walk() is called.
+config VPL_SYSRESET
+ bool "Enable support for system reset drivers in VPL mode"
+ depends on SYSRESET && VPL_DM
+ default y if TPL_SYSRESET
+ help
+ Enable system reset drivers which can be used to reset the CPU or
+ board. Each driver can provide a reset method which will be called
+ to effect a reset. The uclass will try all available drivers when
+ reset_walk() is called.
+
if SYSRESET
config SYSRESET_CMD_RESET
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index ee81dfa7768..ac601f00ecf 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -27,6 +27,16 @@ config TPL_TIMER
function. This enables the drivers in drivers/timer as part of an
TPL build.
+config VPL_TIMER
+ bool "Enable driver model for timer drivers in VPL"
+ depends on TIMER && VPL
+ default y if TPL_TIMER
+ help
+ Enable support for timer drivers in VPL. These can be used to get
+ a timer value when in VPL, or perhaps for implementing a delay
+ function. This enables the drivers in drivers/timer as part of an
+ TPL build.
+
config TIMER_EARLY
bool "Allow timer to be used early in U-Boot"
depends on TIMER
diff --git a/lib/Kconfig b/lib/Kconfig
index ad0cd52edd8..1706eef91c5 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -72,6 +72,11 @@ config TPL_PRINTF
select TPL_SPRINTF
select TPL_STRTO if !TPL_USE_TINY_PRINTF
+config VPL_PRINTF
+ bool
+ select VPL_SPRINTF
+ select VPL_STRTO if !VPL_USE_TINY_PRINTF
+
config SPRINTF
bool
default y
@@ -82,6 +87,9 @@ config SPL_SPRINTF
config TPL_SPRINTF
bool
+config VPL_SPRINTF
+ bool
+
config SSCANF
bool
default n
@@ -96,6 +104,9 @@ config SPL_STRTO
config TPL_STRTO
bool
+config VPL_STRTO
+ bool
+
config IMAGE_SPARSE
bool
@@ -148,6 +159,17 @@ config TPL_USE_TINY_PRINTF
The supported format specifiers are %c, %s, %u/%d and %x.
+config VPL_USE_TINY_PRINTF
+ bool "Enable tiny printf() version for VPL"
+ depends on VPL
+ help
+ This option enables a tiny, stripped down printf version.
+ This should only be used in space limited environments,
+ like SPL versions with hard memory limits. This version
+ reduces the code size by about 2.5KiB on armv7.
+
+ The supported format specifiers are %c, %s, %u/%d and %x.
+
config PANIC_HANG
bool "Do not reset the system on fatal error"
help
@@ -331,6 +353,17 @@ config TPL_TPM
for the low-level TPM interface, but only one TPM is supported at
a time by the TPM library.
+config VPL_TPM
+ bool "Trusted Platform Module (TPM) Support in VPL"
+ depends on VPL_DM
+ help
+ This enables support for TPMs which can be used to provide security
+ features for your board. The TPM can be connected via LPC or I2C
+ and a sandbox TPM is provided for testing purposes. Use the 'tpm'
+ command to interactive the TPM. Driver model support is provided
+ for the low-level TPM interface, but only one TPM is supported at
+ a time by the TPM library.
+
endmenu
menu "Android Verified Boot"
@@ -518,6 +551,12 @@ config SPL_LZMA
help
This enables support for LZMA compression algorithm for SPL boot.
+config VPL_LZMA
+ bool "Enable LZMA decompression support for VPL build"
+ default y if LZMA
+ help
+ This enables support for LZMA compression algorithm for VPL boot.
+
config SPL_LZO
bool "Enable LZO decompression support in SPL"
help
@@ -598,6 +637,7 @@ config OF_LIBFDT_OVERLAY
config SPL_OF_LIBFDT
bool "Enable the FDT library for SPL"
+ depends on SPL_LIBGENERIC_SUPPORT
default y if SPL_OF_CONTROL
help
This enables the FDT library (libfdt). It provides functions for
@@ -619,6 +659,7 @@ config SPL_OF_LIBFDT_ASSUME_MASK
config TPL_OF_LIBFDT
bool "Enable the FDT library for TPL"
+ depends on TPL_LIBGENERIC_SUPPORT
default y if TPL_OF_CONTROL
help
This enables the FDT library (libfdt). It provides functions for
@@ -638,6 +679,27 @@ config TPL_OF_LIBFDT_ASSUME_MASK
0xff means all assumptions are made and any invalid data may cause
unsafe execution. See FDT_ASSUME_PERFECT, etc. in libfdt_internal.h
+config VPL_OF_LIBFDT
+ bool "Enable the FDT library for VPL"
+ default y if VPL_OF_CONTROL && !VPL_OF_PLATDATA
+ help
+ This enables the FDT library (libfdt). It provides functions for
+ accessing binary device tree images in memory, such as adding and
+ removing nodes and properties, scanning through the tree and finding
+ particular compatible nodes. The library operates on a flattened
+ version of the device tree.
+
+config VPL_OF_LIBFDT_ASSUME_MASK
+ hex "Mask of conditions to assume for libfdt"
+ depends on VPL_OF_LIBFDT || FIT
+ default 0xff
+ help
+ Use this to change the assumptions made by libfdt in SPL about the
+ device tree it is working with. A value of 0 means that no assumptions
+ are made, and libfdt is able to deal with malicious data. A value of
+ 0xff means all assumptions are made and any invalid data may cause
+ unsafe execution. See FDT_ASSUME_PERFECT, etc. in libfdt_internal.h
+
config FDT_FIXUP_PARTITIONS
bool "overwrite MTD partitions in DTS through defined in 'mtdparts'"
depends on OF_LIBFDT
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
` (6 preceding siblings ...)
2021-07-12 2:19 ` [PATCH v3 7/7] vpl: Add Kconfig options for VPL Simon Glass
@ 2021-07-27 16:20 ` Simon Glass
2021-07-28 14:35 ` Tom Rini
7 siblings, 1 reply; 17+ messages in thread
From: Simon Glass @ 2021-07-27 16:20 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Tom Rini
Hi Tom,
On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
>
> U-Boot provides a verified-boot feature based around FIT, but there is
> no standard way of implementing it for a board. At present the various
> required pieces must be built up separately, to produce a working
> implementation. In particular, there is no built-in support for selecting
> A/B boot or recovery mode.
>
> This series introduces VPL, a verified program loader. Its purpose is to
> run the verified-boot process and decide which SPL binary should be run.
> Adding VPL into the boot flow provides a standard way of implementing
> verified boot. So far, only the phase itself is added along with some
> Kconfig options. The next step is to create a build for sandbox.
>
> Changes in v3:
> - Move VPL Kconfig options to a separate patch
> - Add full build support for VPL
>
> Changes in v2:
> - Add some more VPL Kconfig options
>
> Simon Glass (7):
> doc: Convert SPL documentation to ReST
> doc: Expand SPL docs to explain the phase and config
> test: Tidy up test building with SPL
> spl: Move TPL_HASH_SUPPORT down next to other TPL options
> binman: Add VPL support
> Introduce Verifying Program Loader (VPL)
> vpl: Add Kconfig options for VPL
Any thoughts on this one? I have a few updates so can send a rebase v4
if that helps.
Regards,
Simon
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-07-27 16:20 ` [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
@ 2021-07-28 14:35 ` Tom Rini
2021-07-28 15:33 ` Simon Glass
0 siblings, 1 reply; 17+ messages in thread
From: Tom Rini @ 2021-07-28 14:35 UTC (permalink / raw)
To: Simon Glass; +Cc: U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]
On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
> >
> > U-Boot provides a verified-boot feature based around FIT, but there is
> > no standard way of implementing it for a board. At present the various
> > required pieces must be built up separately, to produce a working
> > implementation. In particular, there is no built-in support for selecting
> > A/B boot or recovery mode.
> >
> > This series introduces VPL, a verified program loader. Its purpose is to
> > run the verified-boot process and decide which SPL binary should be run.
> > Adding VPL into the boot flow provides a standard way of implementing
> > verified boot. So far, only the phase itself is added along with some
> > Kconfig options. The next step is to create a build for sandbox.
> >
> > Changes in v3:
> > - Move VPL Kconfig options to a separate patch
> > - Add full build support for VPL
> >
> > Changes in v2:
> > - Add some more VPL Kconfig options
> >
> > Simon Glass (7):
> > doc: Convert SPL documentation to ReST
> > doc: Expand SPL docs to explain the phase and config
> > test: Tidy up test building with SPL
> > spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > binman: Add VPL support
> > Introduce Verifying Program Loader (VPL)
> > vpl: Add Kconfig options for VPL
>
> Any thoughts on this one? I have a few updates so can send a rebase v4
> if that helps.
Perhaps some of these general questions would be answered with seeing an
implementation for not just sandbox, but real hardware too. But I'm
missing what this provides exactly that we can't do already, or that
would justify a whole new stage rather than just some updates within
existing logic. What is this doing over SPL_FIT_SIGNATURE for example?
Checking in with a TPM to confirm good measurements? Having written
that out, now I really do want to see this implemented on real hardware
much more so than sandbox.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-07-28 14:35 ` Tom Rini
@ 2021-07-28 15:33 ` Simon Glass
2021-07-28 15:54 ` Michael Nazzareno Trimarchi
2021-07-28 17:37 ` Tom Rini
0 siblings, 2 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-28 15:33 UTC (permalink / raw)
To: Tom Rini; +Cc: U-Boot Mailing List
Hi Tom,
On Wed, 28 Jul 2021 at 08:35, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > no standard way of implementing it for a board. At present the various
> > > required pieces must be built up separately, to produce a working
> > > implementation. In particular, there is no built-in support for selecting
> > > A/B boot or recovery mode.
> > >
> > > This series introduces VPL, a verified program loader. Its purpose is to
> > > run the verified-boot process and decide which SPL binary should be run.
> > > Adding VPL into the boot flow provides a standard way of implementing
> > > verified boot. So far, only the phase itself is added along with some
> > > Kconfig options. The next step is to create a build for sandbox.
> > >
> > > Changes in v3:
> > > - Move VPL Kconfig options to a separate patch
> > > - Add full build support for VPL
> > >
> > > Changes in v2:
> > > - Add some more VPL Kconfig options
> > >
> > > Simon Glass (7):
> > > doc: Convert SPL documentation to ReST
> > > doc: Expand SPL docs to explain the phase and config
> > > test: Tidy up test building with SPL
> > > spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > binman: Add VPL support
> > > Introduce Verifying Program Loader (VPL)
> > > vpl: Add Kconfig options for VPL
> >
> > Any thoughts on this one? I have a few updates so can send a rebase v4
> > if that helps.
>
> Perhaps some of these general questions would be answered with seeing an
> implementation for not just sandbox, but real hardware too. But I'm
> missing what this provides exactly that we can't do already, or that
> would justify a whole new stage rather than just some updates within
> existing logic. What is this doing over SPL_FIT_SIGNATURE for example?
> Checking in with a TPM to confirm good measurements? Having written
> that out, now I really do want to see this implemented on real hardware
> much more so than sandbox.
Yes it was actually implemented on coral, an x86 Chromebook which is
in-tree. I have various patches to come but the docs are at [1]
The core reason for it is that SPL sets up SDRAM (and perhaps other
things) so needs to be updateable, so we cannot boot the vboot logic
in SPL. TPL often has very small size limits so it is difficult to put
it in there. I am thinking that VPL can be an optional phase used only
if verified boot is enabled. That makes it easy since it has a defined
purpose which can be enabled/disabled.
BTW in doing this I wonder whether we should look again at the
SPL_TPL_ Makefile variables. Do you think PHASE might be better?
Regards,
Simon
[1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-07-28 15:33 ` Simon Glass
@ 2021-07-28 15:54 ` Michael Nazzareno Trimarchi
2021-07-28 16:18 ` Simon Glass
2021-07-28 17:37 ` Tom Rini
1 sibling, 1 reply; 17+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-07-28 15:54 UTC (permalink / raw)
To: Simon Glass; +Cc: Tom Rini, U-Boot Mailing List
Hi
On Wed, Jul 28, 2021 at 5:34 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Wed, 28 Jul 2021 at 08:35, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > no standard way of implementing it for a board. At present the various
> > > > required pieces must be built up separately, to produce a working
> > > > implementation. In particular, there is no built-in support for selecting
> > > > A/B boot or recovery mode.
> > > >
> > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > run the verified-boot process and decide which SPL binary should be run.
> > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > verified boot. So far, only the phase itself is added along with some
> > > > Kconfig options. The next step is to create a build for sandbox.
> > > >
Let's try to understand. So we can have:
TPL (redundant most of cpus support it) -> VPL -\
-> SPL1 -\ = > UBOOT_B e/o fitImage
| -> ATF1
| -> TEE1
-> SPL2 -\ => UBOOT_A e/o fitImage
| => ATF2
| => TEE2
If you have this kind of system TPL and VPL can be combined. Is this
the scenario we will use with this patchset?
The funny thing here is that a lot of people ask to update the TPL. After
adding the VPL the communication will happen using hob memory area?
One of the most interesting parts will be to tag the TPL(x) to know what of them
the bootrom load.
Michael
> > > > Changes in v3:
> > > > - Move VPL Kconfig options to a separate patch
> > > > - Add full build support for VPL
> > > >
> > > > Changes in v2:
> > > > - Add some more VPL Kconfig options
> > > >
> > > > Simon Glass (7):
> > > > doc: Convert SPL documentation to ReST
> > > > doc: Expand SPL docs to explain the phase and config
> > > > test: Tidy up test building with SPL
> > > > spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > > binman: Add VPL support
> > > > Introduce Verifying Program Loader (VPL)
> > > > vpl: Add Kconfig options for VPL
> > >
> > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > if that helps.
> >
> > Perhaps some of these general questions would be answered with seeing an
> > implementation for not just sandbox, but real hardware too. But I'm
> > missing what this provides exactly that we can't do already, or that
> > would justify a whole new stage rather than just some updates within
> > existing logic. What is this doing over SPL_FIT_SIGNATURE for example?
> > Checking in with a TPM to confirm good measurements? Having written
> > that out, now I really do want to see this implemented on real hardware
> > much more so than sandbox.
>
> Yes it was actually implemented on coral, an x86 Chromebook which is
> in-tree. I have various patches to come but the docs are at [1]
>
> The core reason for it is that SPL sets up SDRAM (and perhaps other
> things) so needs to be updateable, so we cannot boot the vboot logic
> in SPL. TPL often has very small size limits so it is difficult to put
> it in there. I am thinking that VPL can be an optional phase used only
> if verified boot is enabled. That makes it easy since it has a defined
> purpose which can be enabled/disabled.
>
> BTW in doing this I wonder whether we should look again at the
> SPL_TPL_ Makefile variables. Do you think PHASE might be better?
>
> Regards,
> Simon
>
> [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-07-28 15:54 ` Michael Nazzareno Trimarchi
@ 2021-07-28 16:18 ` Simon Glass
0 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-07-28 16:18 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi; +Cc: Tom Rini, U-Boot Mailing List
Hi Michael,
On Wed, 28 Jul 2021 at 09:54, Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi
>
> On Wed, Jul 28, 2021 at 5:34 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Tom,
> >
> > On Wed, 28 Jul 2021 at 08:35, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > > no standard way of implementing it for a board. At present the various
> > > > > required pieces must be built up separately, to produce a working
> > > > > implementation. In particular, there is no built-in support for selecting
> > > > > A/B boot or recovery mode.
> > > > >
> > > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > > run the verified-boot process and decide which SPL binary should be run.
> > > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > > verified boot. So far, only the phase itself is added along with some
> > > > > Kconfig options. The next step is to create a build for sandbox.
> > > > >
>
> Let's try to understand. So we can have:
>
> TPL (redundant most of cpus support it) -> VPL -\
>
> -> SPL1 -\ = > UBOOT_B e/o fitImage
>
> | -> ATF1
> | -> TEE1
>
> -> SPL2 -\ => UBOOT_A e/o fitImage
> | => ATF2
> | => TEE2
I'm not quite sure how to read that diagram. I think we should have
SPLA_ and SPL_B (and perhaps SPL_RECOVERY) so it matches with U-Boot
proper.
>
> If you have this kind of system TPL and VPL can be combined. Is this
> the scenario we will use with this patchset?
Only if there is space to store both the early-init code and the
verified boot. So for coral this is not possible.
But if I understand things correctly, then yes this is the idea.
Regards,
Simon
>
> The funny thing here is that a lot of people ask to update the TPL. After
> adding the VPL the communication will happen using hob memory area?
>
> One of the most interesting parts will be to tag the TPL(x) to know what of them
> the bootrom load.
>
> Michael
>
>
> > > > > Changes in v3:
> > > > > - Move VPL Kconfig options to a separate patch
> > > > > - Add full build support for VPL
> > > > >
> > > > > Changes in v2:
> > > > > - Add some more VPL Kconfig options
> > > > >
> > > > > Simon Glass (7):
> > > > > doc: Convert SPL documentation to ReST
> > > > > doc: Expand SPL docs to explain the phase and config
> > > > > test: Tidy up test building with SPL
> > > > > spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > > > binman: Add VPL support
> > > > > Introduce Verifying Program Loader (VPL)
> > > > > vpl: Add Kconfig options for VPL
> > > >
> > > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > > if that helps.
> > >
> > > Perhaps some of these general questions would be answered with seeing an
> > > implementation for not just sandbox, but real hardware too. But I'm
> > > missing what this provides exactly that we can't do already, or that
> > > would justify a whole new stage rather than just some updates within
> > > existing logic. What is this doing over SPL_FIT_SIGNATURE for example?
> > > Checking in with a TPM to confirm good measurements? Having written
> > > that out, now I really do want to see this implemented on real hardware
> > > much more so than sandbox.
> >
> > Yes it was actually implemented on coral, an x86 Chromebook which is
> > in-tree. I have various patches to come but the docs are at [1]
> >
> > The core reason for it is that SPL sets up SDRAM (and perhaps other
> > things) so needs to be updateable, so we cannot boot the vboot logic
> > in SPL. TPL often has very small size limits so it is difficult to put
> > it in there. I am thinking that VPL can be an optional phase used only
> > if verified boot is enabled. That makes it easy since it has a defined
> > purpose which can be enabled/disabled.
> >
> > BTW in doing this I wonder whether we should look again at the
> > SPL_TPL_ Makefile variables. Do you think PHASE might be better?
> >
> > Regards,
> > Simon
> >
> > [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
>
>
>
> --
> Michael Nazzareno Trimarchi
> Co-Founder & Chief Executive Officer
> M. +39 347 913 2170
> michael@amarulasolutions.com
> __________________________________
>
> Amarula Solutions BV
> Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
> T. +31 (0)85 111 9172
> info@amarulasolutions.com
> www.amarulasolutions.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-07-28 15:33 ` Simon Glass
2021-07-28 15:54 ` Michael Nazzareno Trimarchi
@ 2021-07-28 17:37 ` Tom Rini
2021-07-28 18:37 ` Simon Glass
1 sibling, 1 reply; 17+ messages in thread
From: Tom Rini @ 2021-07-28 17:37 UTC (permalink / raw)
To: Simon Glass; +Cc: U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 3457 bytes --]
On Wed, Jul 28, 2021 at 09:33:56AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 28 Jul 2021 at 08:35, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > no standard way of implementing it for a board. At present the various
> > > > required pieces must be built up separately, to produce a working
> > > > implementation. In particular, there is no built-in support for selecting
> > > > A/B boot or recovery mode.
> > > >
> > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > run the verified-boot process and decide which SPL binary should be run.
> > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > verified boot. So far, only the phase itself is added along with some
> > > > Kconfig options. The next step is to create a build for sandbox.
> > > >
> > > > Changes in v3:
> > > > - Move VPL Kconfig options to a separate patch
> > > > - Add full build support for VPL
> > > >
> > > > Changes in v2:
> > > > - Add some more VPL Kconfig options
> > > >
> > > > Simon Glass (7):
> > > > doc: Convert SPL documentation to ReST
> > > > doc: Expand SPL docs to explain the phase and config
> > > > test: Tidy up test building with SPL
> > > > spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > > binman: Add VPL support
> > > > Introduce Verifying Program Loader (VPL)
> > > > vpl: Add Kconfig options for VPL
> > >
> > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > if that helps.
> >
> > Perhaps some of these general questions would be answered with seeing an
> > implementation for not just sandbox, but real hardware too. But I'm
> > missing what this provides exactly that we can't do already, or that
> > would justify a whole new stage rather than just some updates within
> > existing logic. What is this doing over SPL_FIT_SIGNATURE for example?
> > Checking in with a TPM to confirm good measurements? Having written
> > that out, now I really do want to see this implemented on real hardware
> > much more so than sandbox.
>
> Yes it was actually implemented on coral, an x86 Chromebook which is
> in-tree. I have various patches to come but the docs are at [1]
>
> The core reason for it is that SPL sets up SDRAM (and perhaps other
> things) so needs to be updateable, so we cannot boot the vboot logic
> in SPL. TPL often has very small size limits so it is difficult to put
> it in there. I am thinking that VPL can be an optional phase used only
> if verified boot is enabled. That makes it easy since it has a defined
> purpose which can be enabled/disabled.
>
> BTW in doing this I wonder whether we should look again at the
> SPL_TPL_ Makefile variables. Do you think PHASE might be better?
>
> Regards,
> Simon
>
> [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
There's always a "no updates before HERE" line to draw, as you need a
fall-back option. Since you mention SDRAM, does that mean both TPL and
VPL are running in SRAM/similar space? If so, why isn't this just part
of TPL, for when you have "a lot" of pre-SDRAM memory to use?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-07-28 17:37 ` Tom Rini
@ 2021-07-28 18:37 ` Simon Glass
2021-08-02 18:53 ` Tom Rini
0 siblings, 1 reply; 17+ messages in thread
From: Simon Glass @ 2021-07-28 18:37 UTC (permalink / raw)
To: Tom Rini; +Cc: U-Boot Mailing List
Hi Tom,
On Wed, 28 Jul 2021 at 11:37, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Jul 28, 2021 at 09:33:56AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 28 Jul 2021 at 08:35, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > > no standard way of implementing it for a board. At present the various
> > > > > required pieces must be built up separately, to produce a working
> > > > > implementation. In particular, there is no built-in support for selecting
> > > > > A/B boot or recovery mode.
> > > > >
> > > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > > run the verified-boot process and decide which SPL binary should be run.
> > > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > > verified boot. So far, only the phase itself is added along with some
> > > > > Kconfig options. The next step is to create a build for sandbox.
> > > > >
> > > > > Changes in v3:
> > > > > - Move VPL Kconfig options to a separate patch
> > > > > - Add full build support for VPL
> > > > >
> > > > > Changes in v2:
> > > > > - Add some more VPL Kconfig options
> > > > >
> > > > > Simon Glass (7):
> > > > > doc: Convert SPL documentation to ReST
> > > > > doc: Expand SPL docs to explain the phase and config
> > > > > test: Tidy up test building with SPL
> > > > > spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > > > binman: Add VPL support
> > > > > Introduce Verifying Program Loader (VPL)
> > > > > vpl: Add Kconfig options for VPL
> > > >
> > > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > > if that helps.
> > >
> > > Perhaps some of these general questions would be answered with seeing an
> > > implementation for not just sandbox, but real hardware too. But I'm
> > > missing what this provides exactly that we can't do already, or that
> > > would justify a whole new stage rather than just some updates within
> > > existing logic. What is this doing over SPL_FIT_SIGNATURE for example?
> > > Checking in with a TPM to confirm good measurements? Having written
> > > that out, now I really do want to see this implemented on real hardware
> > > much more so than sandbox.
> >
> > Yes it was actually implemented on coral, an x86 Chromebook which is
> > in-tree. I have various patches to come but the docs are at [1]
> >
> > The core reason for it is that SPL sets up SDRAM (and perhaps other
> > things) so needs to be updateable, so we cannot boot the vboot logic
> > in SPL. TPL often has very small size limits so it is difficult to put
> > it in there. I am thinking that VPL can be an optional phase used only
> > if verified boot is enabled. That makes it easy since it has a defined
> > purpose which can be enabled/disabled.
> >
> > BTW in doing this I wonder whether we should look again at the
> > SPL_TPL_ Makefile variables. Do you think PHASE might be better?
> >
> > Regards,
> > Simon
> >
> > [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
>
> There's always a "no updates before HERE" line to draw, as you need a
> fall-back option. Since you mention SDRAM, does that mean both TPL and
> VPL are running in SRAM/similar space? If so, why isn't this just part
> of TPL, for when you have "a lot" of pre-SDRAM memory to use?
It depends on the architecture. For coral (and other modern x86
devices) there is 32KB which is enough to run TPL but not enough to
run VPL. So TPL sets up 'Cache-as-RAM' which provides additional SRAM.
Other architectures may have their own constraints.
But another key difference is that we use OF_PLATDATA in TPL and that
is fine for the basic init needed there. But VPL needs lots of drivers
as well as info about the firmware image layout so it adds to the work
needed to get them running in that environment. So ideally, VPL can be
built without OF_PLATDATA.
Or put it another way, TPL needs to be as small as possible so it can
run on the widest array of devices. VPL is an optional phase (only
used with verified boot) so we should not pollute TPL with that. I
have a lot of other thoughts about all of this, some of which are in
the VBE doc...
Regards,
SImon
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-07-28 18:37 ` Simon Glass
@ 2021-08-02 18:53 ` Tom Rini
2021-09-02 16:42 ` Simon Glass
0 siblings, 1 reply; 17+ messages in thread
From: Tom Rini @ 2021-08-02 18:53 UTC (permalink / raw)
To: Simon Glass; +Cc: U-Boot Mailing List
[-- Attachment #1: Type: text/plain, Size: 5985 bytes --]
On Wed, Jul 28, 2021 at 12:37:55PM -0600, Simon Glass wrote:
> Hi Tom,
>
>
> On Wed, 28 Jul 2021 at 11:37, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Jul 28, 2021 at 09:33:56AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 28 Jul 2021 at 08:35, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > > > no standard way of implementing it for a board. At present the various
> > > > > > required pieces must be built up separately, to produce a working
> > > > > > implementation. In particular, there is no built-in support for selecting
> > > > > > A/B boot or recovery mode.
> > > > > >
> > > > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > > > run the verified-boot process and decide which SPL binary should be run.
> > > > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > > > verified boot. So far, only the phase itself is added along with some
> > > > > > Kconfig options. The next step is to create a build for sandbox.
> > > > > >
> > > > > > Changes in v3:
> > > > > > - Move VPL Kconfig options to a separate patch
> > > > > > - Add full build support for VPL
> > > > > >
> > > > > > Changes in v2:
> > > > > > - Add some more VPL Kconfig options
> > > > > >
> > > > > > Simon Glass (7):
> > > > > > doc: Convert SPL documentation to ReST
> > > > > > doc: Expand SPL docs to explain the phase and config
> > > > > > test: Tidy up test building with SPL
> > > > > > spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > > > > binman: Add VPL support
> > > > > > Introduce Verifying Program Loader (VPL)
> > > > > > vpl: Add Kconfig options for VPL
> > > > >
> > > > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > > > if that helps.
> > > >
> > > > Perhaps some of these general questions would be answered with seeing an
> > > > implementation for not just sandbox, but real hardware too. But I'm
> > > > missing what this provides exactly that we can't do already, or that
> > > > would justify a whole new stage rather than just some updates within
> > > > existing logic. What is this doing over SPL_FIT_SIGNATURE for example?
> > > > Checking in with a TPM to confirm good measurements? Having written
> > > > that out, now I really do want to see this implemented on real hardware
> > > > much more so than sandbox.
> > >
> > > Yes it was actually implemented on coral, an x86 Chromebook which is
> > > in-tree. I have various patches to come but the docs are at [1]
> > >
> > > The core reason for it is that SPL sets up SDRAM (and perhaps other
> > > things) so needs to be updateable, so we cannot boot the vboot logic
> > > in SPL. TPL often has very small size limits so it is difficult to put
> > > it in there. I am thinking that VPL can be an optional phase used only
> > > if verified boot is enabled. That makes it easy since it has a defined
> > > purpose which can be enabled/disabled.
> > >
> > > BTW in doing this I wonder whether we should look again at the
> > > SPL_TPL_ Makefile variables. Do you think PHASE might be better?
> > >
> > > Regards,
> > > Simon
> > >
> > > [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
> >
> > There's always a "no updates before HERE" line to draw, as you need a
> > fall-back option. Since you mention SDRAM, does that mean both TPL and
> > VPL are running in SRAM/similar space? If so, why isn't this just part
> > of TPL, for when you have "a lot" of pre-SDRAM memory to use?
>
> It depends on the architecture. For coral (and other modern x86
> devices) there is 32KB which is enough to run TPL but not enough to
> run VPL. So TPL sets up 'Cache-as-RAM' which provides additional SRAM.
> Other architectures may have their own constraints.
And in this case then VPL sets up DRAM?
> But another key difference is that we use OF_PLATDATA in TPL and that
> is fine for the basic init needed there. But VPL needs lots of drivers
> as well as info about the firmware image layout so it adds to the work
> needed to get them running in that environment. So ideally, VPL can be
> built without OF_PLATDATA.
>
> Or put it another way, TPL needs to be as small as possible so it can
> run on the widest array of devices. VPL is an optional phase (only
> used with verified boot) so we should not pollute TPL with that. I
> have a lot of other thoughts about all of this, some of which are in
> the VBE doc...
Right, the intention behind allowing "TPL" in-tree was that we have
enough cases where we're size constrained and just need to allow for
something "functional enough". This was what the old PowerPC "SPL" was
about, and SoCs keep coming out with relatively tiny initial memory
spaces.
I guess my concerns at the high level fall in to a few spots:
- I don't really like the idea of having to introduce yet another stage.
At that point, what infrastructure from U-Boot is it really even
using?
- In order to use this we're now needing platforms to support TPL to add
in VPL.
- That kind of ties in to another part of the issue I see. Why is this
not just a feature to enable in earlier stage?
- Why do we have both verified and "A/B or recovery" in the same spot?
Some of this I guess comes down to my thinking about how yes, x86 is
constrained, but we have a lot of other platforms with 128/256/way more
pre-SDRAM memory available and verified is the key feature to enable
rather than A/B update. And again, what does the verified part of this
provide over FIT_SIGNATURE? Outside of that A/B case, at least.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 0/7] vpl: Introduce a verifying program loader
2021-08-02 18:53 ` Tom Rini
@ 2021-09-02 16:42 ` Simon Glass
0 siblings, 0 replies; 17+ messages in thread
From: Simon Glass @ 2021-09-02 16:42 UTC (permalink / raw)
To: Tom Rini; +Cc: U-Boot Mailing List
Hi Tom,
(just to reply to this old email)
On Mon, 2 Aug 2021 at 12:54, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Jul 28, 2021 at 12:37:55PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> >
> > On Wed, 28 Jul 2021 at 11:37, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Jul 28, 2021 at 09:33:56AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 28 Jul 2021 at 08:35, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Jul 27, 2021 at 10:20:49AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Sun, 11 Jul 2021 at 20:19, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > U-Boot provides a verified-boot feature based around FIT, but there is
> > > > > > > no standard way of implementing it for a board. At present the various
> > > > > > > required pieces must be built up separately, to produce a working
> > > > > > > implementation. In particular, there is no built-in support for selecting
> > > > > > > A/B boot or recovery mode.
> > > > > > >
> > > > > > > This series introduces VPL, a verified program loader. Its purpose is to
> > > > > > > run the verified-boot process and decide which SPL binary should be run.
> > > > > > > Adding VPL into the boot flow provides a standard way of implementing
> > > > > > > verified boot. So far, only the phase itself is added along with some
> > > > > > > Kconfig options. The next step is to create a build for sandbox.
> > > > > > >
> > > > > > > Changes in v3:
> > > > > > > - Move VPL Kconfig options to a separate patch
> > > > > > > - Add full build support for VPL
> > > > > > >
> > > > > > > Changes in v2:
> > > > > > > - Add some more VPL Kconfig options
> > > > > > >
> > > > > > > Simon Glass (7):
> > > > > > > doc: Convert SPL documentation to ReST
> > > > > > > doc: Expand SPL docs to explain the phase and config
> > > > > > > test: Tidy up test building with SPL
> > > > > > > spl: Move TPL_HASH_SUPPORT down next to other TPL options
> > > > > > > binman: Add VPL support
> > > > > > > Introduce Verifying Program Loader (VPL)
> > > > > > > vpl: Add Kconfig options for VPL
> > > > > >
> > > > > > Any thoughts on this one? I have a few updates so can send a rebase v4
> > > > > > if that helps.
> > > > >
> > > > > Perhaps some of these general questions would be answered with seeing an
> > > > > implementation for not just sandbox, but real hardware too. But I'm
> > > > > missing what this provides exactly that we can't do already, or that
> > > > > would justify a whole new stage rather than just some updates within
> > > > > existing logic. What is this doing over SPL_FIT_SIGNATURE for example?
> > > > > Checking in with a TPM to confirm good measurements? Having written
> > > > > that out, now I really do want to see this implemented on real hardware
> > > > > much more so than sandbox.
> > > >
> > > > Yes it was actually implemented on coral, an x86 Chromebook which is
> > > > in-tree. I have various patches to come but the docs are at [1]
> > > >
> > > > The core reason for it is that SPL sets up SDRAM (and perhaps other
> > > > things) so needs to be updateable, so we cannot boot the vboot logic
> > > > in SPL. TPL often has very small size limits so it is difficult to put
> > > > it in there. I am thinking that VPL can be an optional phase used only
> > > > if verified boot is enabled. That makes it easy since it has a defined
> > > > purpose which can be enabled/disabled.
> > > >
> > > > BTW in doing this I wonder whether we should look again at the
> > > > SPL_TPL_ Makefile variables. Do you think PHASE might be better?
> > > >
> > > > Regards,
> > > > Simon
> > > >
> > > > [1] https://github.com/sjg20/u-boot/blob/cros-2021.04/cros/doc/cros_coral.rst
> > >
> > > There's always a "no updates before HERE" line to draw, as you need a
> > > fall-back option. Since you mention SDRAM, does that mean both TPL and
> > > VPL are running in SRAM/similar space? If so, why isn't this just part
> > > of TPL, for when you have "a lot" of pre-SDRAM memory to use?
> >
> > It depends on the architecture. For coral (and other modern x86
> > devices) there is 32KB which is enough to run TPL but not enough to
> > run VPL. So TPL sets up 'Cache-as-RAM' which provides additional SRAM.
> > Other architectures may have their own constraints.
>
> And in this case then VPL sets up DRAM?
No, SPL. Nothing changes there.
>
> > But another key difference is that we use OF_PLATDATA in TPL and that
> > is fine for the basic init needed there. But VPL needs lots of drivers
> > as well as info about the firmware image layout so it adds to the work
> > needed to get them running in that environment. So ideally, VPL can be
> > built without OF_PLATDATA.
> >
> > Or put it another way, TPL needs to be as small as possible so it can
> > run on the widest array of devices. VPL is an optional phase (only
> > used with verified boot) so we should not pollute TPL with that. I
> > have a lot of other thoughts about all of this, some of which are in
> > the VBE doc...
>
> Right, the intention behind allowing "TPL" in-tree was that we have
> enough cases where we're size constrained and just need to allow for
> something "functional enough". This was what the old PowerPC "SPL" was
> about, and SoCs keep coming out with relatively tiny initial memory
> spaces.
>
> I guess my concerns at the high level fall in to a few spots:
> - I don't really like the idea of having to introduce yet another stage.
Well I've been avoiding it for years...
> At that point, what infrastructure from U-Boot is it really even
> using?
Well the verification will be in VPL in U-Boot.
> - In order to use this we're now needing platforms to support TPL to add
> in VPL.
Not necessarily. If the platform has enough memory to enable
verification in TPL then that is still an option.
> - That kind of ties in to another part of the issue I see. Why is this
> not just a feature to enable in earlier stage?
Yes that's possible, but it cannot be implemented in TPL in quite a
few platforms, as I see it.
> - Why do we have both verified and "A/B or recovery" in the same spot?
I'm not sure what this means, sorry.
>
> Some of this I guess comes down to my thinking about how yes, x86 is
> constrained, but we have a lot of other platforms with 128/256/way more
> pre-SDRAM memory available and verified is the key feature to enable
> rather than A/B update. And again, what does the verified part of this
> provide over FIT_SIGNATURE? Outside of that A/B case, at least.
It uses FIT_SIGNATURE, but with U-Boot being the target binary. So
there are two updateable parts: firmware and kernel.
Regards,
Simon
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-09-02 16:42 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-12 2:19 [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
2021-07-12 2:19 ` [PATCH v3 1/7] doc: Convert SPL documentation to ReST Simon Glass
2021-07-12 2:19 ` [PATCH v3 2/7] doc: Expand SPL docs to explain the phase and config Simon Glass
2021-07-12 2:19 ` [PATCH v3 3/7] test: Tidy up test building with SPL Simon Glass
2021-07-12 2:19 ` [PATCH v3 4/7] spl: Move TPL_HASH_SUPPORT down next to other TPL options Simon Glass
2021-07-12 2:19 ` [PATCH v3 5/7] binman: Add VPL support Simon Glass
2021-07-12 2:19 ` [PATCH v3 6/7] Introduce Verifying Program Loader (VPL) Simon Glass
2021-07-12 2:19 ` [PATCH v3 7/7] vpl: Add Kconfig options for VPL Simon Glass
2021-07-27 16:20 ` [PATCH v3 0/7] vpl: Introduce a verifying program loader Simon Glass
2021-07-28 14:35 ` Tom Rini
2021-07-28 15:33 ` Simon Glass
2021-07-28 15:54 ` Michael Nazzareno Trimarchi
2021-07-28 16:18 ` Simon Glass
2021-07-28 17:37 ` Tom Rini
2021-07-28 18:37 ` Simon Glass
2021-08-02 18:53 ` Tom Rini
2021-09-02 16:42 ` 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.