From: "Kanagarajan, Vijaikumar" <Vijaikumar_Kanagarajan@mentor.com>
To: Henning Schild <henning.schild@siemens.com>
Cc: "isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: RE: [PATCH] meta-isar: u-boot: Update to 2021.10
Date: Fri, 5 Nov 2021 06:05:38 +0000 [thread overview]
Message-ID: <07e7dbd000db4db2b1aa57c039a8e96c@svr-orw-mbx-01.mgc.mentorg.com> (raw)
In-Reply-To: <20211103192527.793e13bb@md1za8fc.ad001.siemens.net>
-----Original Message-----
From: Henning Schild <henning.schild@siemens.com>
Sent: 03 November 2021 23:55
To: Kanagarajan, Vijaikumar <Vijaikumar_Kanagarajan@mentor.com>
Cc: isar-users@googlegroups.com
Subject: Re: [PATCH] meta-isar: u-boot: Update to 2021.10
Am Wed, 3 Nov 2021 16:19:50 +0530
schrieb Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>:
> Update to the latest u-boot.
>
> Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
> ---
> Boot tested on de0-nano-soc.
>
> I donot have a stm32 board. Only build tested for it.
>
> Thanks,
> Vijai Kumar K
>
> ...y-add-property-no-map-to-created-res.patch | 151
> ------------------ ...rty-no-map-to-secure-reserved-memory.patch |
> 33 ---- ...{u-boot-2020.10.inc => u-boot-2021.10.inc} | 4 +-
> ...0.10.bb => u-boot-de0-nano-soc_2021.10.bb} | 0
> .../u-boot/u-boot-stm32mp15x_2020.10.bb | 10 --
> .../u-boot/u-boot-stm32mp15x_2021.10.bb | 6 +
> 6 files changed, 9 insertions(+), 195 deletions(-) delete mode
> 100644
> meta-isar/recipes-bsp/u-boot/files/0001-fdtdec-optionally-add-property
> -no-map-to-created-res.patch
> delete mode 100644
> meta-isar/recipes-bsp/u-boot/files/0002-optee-add-property-no-map-to-s
> ecure-reserved-memory.patch rename
> meta-isar/recipes-bsp/u-boot/{u-boot-2020.10.inc =>
> u-boot-2021.10.inc} (64%) rename
> meta-isar/recipes-bsp/u-boot/{u-boot-de0-nano-soc_2020.10.bb =>
> u-boot-de0-nano-soc_2021.10.bb} (100%) delete mode 100644
> meta-isar/recipes-bsp/u-boot/u-boot-stm32mp15x_2020.10.bb create mode
> 100644 meta-isar/recipes-bsp/u-boot/u-boot-stm32mp15x_2021.10.bb
>
> diff --git
> a/meta-isar/recipes-bsp/u-boot/files/0001-fdtdec-optionally-add-proper
> ty-no-map-to-created-res.patch
> b/meta-isar/recipes-bsp/u-boot/files/0001-fdtdec-optionally-add-proper
> ty-no-map-to-created-res.patch deleted file mode 100644 index
> 8a32fc1..0000000 ---
> a/meta-isar/recipes-bsp/u-boot/files/0001-fdtdec-optionally-add-proper
> ty-no-map-to-created-res.patch
> +++ /dev/null @@ -1,151 +0,0 @@
> -From ccaa5747bdeae4261199dd7e80771e4de1c550ca Mon Sep 17 00:00:00
> 2001 -From: Etienne Carriere <etienne.carriere@st.com>
> -Date: Thu, 10 Sep 2020 10:49:59 +0200
> -Subject: [PATCH] fdtdec: optionally add property no-map to created
> reserved
> - memory node
> -
> -Add boolean input argument @no_map to helper function
> -fdtdec_add_reserved_memory() to add or not "no-map" property -for an
> added reserved memory node.
> -
> -Property no-map is used by the Linux kernel to not not map memory -in
> its static memory mapping. It is needed for example for the|
> -consistency of system non-cached memory and to prevent speculative
> -accesses to some firewalled memory.
> -
> -No functional change. A later change will update to OPTEE library to
> -add no-map property to OP-TEE reserved memory nodes.
> -
> -Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
> -Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> -Reviewed-by: Simon Glass <sjg@chromium.org>
> ----
> - arch/riscv/lib/fdt_fixup.c | 2 +-
> - include/fdtdec.h | 5 +++--
> - lib/fdtdec.c | 10 ++++++++--
> - lib/optee/optee.c | 2 +-
> - test/dm/fdtdec.c | 6 +++---
> - 5 files changed, 16 insertions(+), 9 deletions(-)
> -
> -diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> -index 5b2420243f..d02062fd5b 100644
> ---- a/arch/riscv/lib/fdt_fixup.c
> -+++ b/arch/riscv/lib/fdt_fixup.c
> -@@ -75,7 +75,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src,
> void *dst)
> - pmp_mem.start = addr;
> - pmp_mem.end = addr + size - 1;
> - err = fdtdec_add_reserved_memory(dst, basename,
> &pmp_mem, --
> &phandle); -+
> &phandle, false);
> - if (err < 0 && err != -FDT_ERR_EXISTS) {
> - log_err("failed to add reserved memory:
> %d\n", err);
> - return err;
> -diff --git a/include/fdtdec.h b/include/fdtdec.h -index
> 152eb07b9e..62d1660973 100644
> ---- a/include/fdtdec.h
> -+++ b/include/fdtdec.h
> -@@ -1029,7 +1029,7 @@ static inline int fdtdec_set_phandle(void
> *blob, int node, uint32_t phandle)
> - * };
> - * uint32_t phandle;
> - *
> -- * fdtdec_add_reserved_memory(fdt, "framebuffer", &fb,
> &phandle); -+ * fdtdec_add_reserved_memory(fdt, "framebuffer",
> &fb, &phandle, false);
> - *
> - * This results in the following subnode being added to the
> top-level
> - * /reserved-memory node:
> -@@ -1056,11 +1056,12 @@ static inline int fdtdec_set_phandle(void
> *blob, int node, uint32_t phandle)
> - * @param carveout information about the carveout region
> - * @param phandlep return location for the phandle of the
> carveout region
> - * can be NULL if no phandle should be added
> -+ * @param no_map add "no-map" property if true
> - * @return 0 on success or a negative error code on failure
> - */
> - int fdtdec_add_reserved_memory(void *blob, const char *basename,
> - const struct fdt_memory *carveout,
> -- uint32_t *phandlep);
> -+ uint32_t *phandlep, bool no_map);
> -
> - /**
> - * fdtdec_get_carveout() - reads a carveout from an FDT -diff --git
> a/lib/fdtdec.c b/lib/fdtdec.c -index 56bf9fcc79..b8fc5e2bff 100644
> ---- a/lib/fdtdec.c
> -+++ b/lib/fdtdec.c
> -@@ -1316,7 +1316,7 @@ static int fdtdec_init_reserved_memory(void
> *blob)
> -
> - int fdtdec_add_reserved_memory(void *blob, const char *basename,
> - const struct fdt_memory *carveout,
> -- uint32_t *phandlep)
> -+ uint32_t *phandlep, bool no_map)
> - {
> - fdt32_t cells[4] = {}, *ptr = cells;
> - uint32_t upper, lower, phandle;
> -@@ -1416,6 +1416,12 @@ int fdtdec_add_reserved_memory(void *blob,
> const char *basename,
> - if (err < 0)
> - return err;
> -
> -+ if (no_map) {
> -+ err = fdt_setprop(blob, node, "no-map", NULL, 0);
> -+ if (err < 0)
> -+ return err;
> -+ }
> -+
> - /* return the phandle for the new node for the caller to
> use */
> - if (phandlep)
> - *phandlep = phandle;
> -@@ -1481,7 +1487,7 @@ int fdtdec_set_carveout(void *blob, const char
> *node, const char *prop_name,
> - fdt32_t value;
> - void *prop;
> -
> -- err = fdtdec_add_reserved_memory(blob, name, carveout,
> &phandle); -+ err = fdtdec_add_reserved_memory(blob, name,
> carveout, &phandle, false);
> - if (err < 0) {
> - debug("failed to add reserved memory: %d\n", err);
> - return err;
> -diff --git a/lib/optee/optee.c b/lib/optee/optee.c -index
> 457d4cca8a..963c2ff430 100644
> ---- a/lib/optee/optee.c
> -+++ b/lib/optee/optee.c
> -@@ -192,7 +192,7 @@ int optee_copy_fdt_nodes(const void *old_blob,
> void *new_blob)
> - ret =
> fdtdec_add_reserved_memory(new_blob,
> -
> nodename,
> -
> &carveout, --
> NULL); -+
> NULL, false);
> - free(oldname);
> -
> - if (ret < 0)
> -diff --git a/test/dm/fdtdec.c b/test/dm/fdtdec.c -index
> 716993f706..4119003041 100644
> ---- a/test/dm/fdtdec.c
> -+++ b/test/dm/fdtdec.c
> -@@ -80,7 +80,7 @@ static int
> dm_test_fdtdec_add_reserved_memory(struct unit_test_state *uts)
> - resv.start = 0x1000;
> - resv.end = 0x1fff;
> - ut_assertok(fdtdec_add_reserved_memory(blob, "rsvd_region",
> -- &resv, &phandle));
> -+ &resv, &phandle,
> false));
> -
> - /* Test /reserve-memory and its subnode should exist */
> - parent = fdt_path_offset(blob, "/reserved-memory");
> -@@ -101,7 +101,7 @@ static int
> dm_test_fdtdec_add_reserved_memory(struct unit_test_state *uts)
> - resv.start = 0x2000;
> - resv.end = 0x2fff;
> - ut_assertok(fdtdec_add_reserved_memory(blob, "rsvd_region1",
> -- &resv, &phandle1));
> -+ &resv, &phandle1,
> false));
> - subnode = fdt_path_offset(blob,
> "/reserved-memory/rsvd_region1");
> - ut_assert(subnode > 0);
> -
> -@@ -115,7 +115,7 @@ static int
> dm_test_fdtdec_add_reserved_memory(struct unit_test_state *uts)
> - resv.start = 0x1000;
> - resv.end = 0x1fff;
> - ut_assertok(fdtdec_add_reserved_memory(blob, "rsvd_region2",
> -- &resv, &phandle1));
> -+ &resv, &phandle1,
> false));
> - subnode = fdt_path_offset(blob,
> "/reserved-memory/rsvd_region2");
> - ut_assert(subnode < 0);
> -
> ---
> -2.26.2
> -
> diff --git
> a/meta-isar/recipes-bsp/u-boot/files/0002-optee-add-property-no-map-to
> -secure-reserved-memory.patch
> b/meta-isar/recipes-bsp/u-boot/files/0002-optee-add-property-no-map-to
> -secure-reserved-memory.patch deleted file mode 100644 index
> 6a39968..0000000 ---
> a/meta-isar/recipes-bsp/u-boot/files/0002-optee-add-property-no-map-to
> -secure-reserved-memory.patch
> +++ /dev/null @@ -1,33 +0,0 @@
> -From 3e15c315f97401f394ae83ed17fbef72b765222a Mon Sep 17 00:00:00
> 2001 -From: Etienne Carriere <etienne.carriere@st.com>
> -Date: Thu, 10 Sep 2020 10:50:01 +0200
> -Subject: [PATCH] optee: add property no-map to secure reserved memory
> -
> -OP-TEE reserved memory node must set property "no-map" to prevent
> -Linux kernel from mapping secure memory unless what non-secure world
> -speculative accesses of the CPU can violate the memory firmware
> -configuration.
> -
> -Fixes: 6ccb05eae01b ("image: fdt: copy possible optee nodes to a
> loaded devicetree") -Signed-off-by: Etienne Carriere
> <etienne.carriere@st.com> -Signed-off-by: Patrice Chotard
> <patrice.chotard@st.com> ----
> - lib/optee/optee.c | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/lib/optee/optee.c b/lib/optee/optee.c -index
> 963c2ff430..9e6606568f 100644
> ---- a/lib/optee/optee.c
> -+++ b/lib/optee/optee.c
> -@@ -192,7 +192,7 @@ int optee_copy_fdt_nodes(const void *old_blob,
> void *new_blob)
> - ret =
> fdtdec_add_reserved_memory(new_blob,
> -
> nodename,
> -
> &carveout, --
> NULL, false); -+
> NULL, true);
> - free(oldname);
> -
> - if (ret < 0)
> ---
> -2.26.2
> -
> diff --git a/meta-isar/recipes-bsp/u-boot/u-boot-2020.10.inc
> b/meta-isar/recipes-bsp/u-boot/u-boot-2021.10.inc similarity index 64%
> rename from meta-isar/recipes-bsp/u-boot/u-boot-2020.10.inc
> rename to meta-isar/recipes-bsp/u-boot/u-boot-2021.10.inc
> index 604776a..964ae6d 100644
> --- a/meta-isar/recipes-bsp/u-boot/u-boot-2020.10.inc
> +++ b/meta-isar/recipes-bsp/u-boot/u-boot-2021.10.inc
> @@ -5,9 +5,11 @@
>
> require recipes-bsp/u-boot/u-boot-custom.inc
>
> +DEBIAN_BUILD_DEPENDS += ", libssl-dev"
> +
I guess that should go into the inc and not the recipe. If that inc should still support older u-boots it should be somehow done conditionally depending on $PV[0] > 2020
My guess is that you have another board for which you can test, and you might have that very line in another recipe.
Yes. Will move to the inc in meta layer.
I am not sure if making it conditionally dependent is worth the effort. We could just add it. I see no harm in having an extra dependency for the older u-boots.
Maybe downstream users with frozen base-apts might have an issue, but they could always remove it in their layer.
Thanks,
Vijai Kumar K
Henning
> SRC_URI += " \
> https://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2 \
> "
> -SRC_URI[sha256sum] =
> "0d481bbdc05c0ee74908ec2f56a6daa53166cc6a78a0e4fac2ac5d025770a622"
> +SRC_URI[sha256sum] =
> "cde723e19262e646f2670d25e5ec4b1b368490de950d4e26275a988c36df0bd4" S =
> "${WORKDIR}/u-boot-${PV}" diff --git
> a/meta-isar/recipes-bsp/u-boot/u-boot-de0-nano-soc_2020.10.bb
> b/meta-isar/recipes-bsp/u-boot/u-boot-de0-nano-soc_2021.10.bb
> similarity index 100% rename from
> meta-isar/recipes-bsp/u-boot/u-boot-de0-nano-soc_2020.10.bb rename to
> meta-isar/recipes-bsp/u-boot/u-boot-de0-nano-soc_2021.10.bb diff --git
> a/meta-isar/recipes-bsp/u-boot/u-boot-stm32mp15x_2020.10.bb
> b/meta-isar/recipes-bsp/u-boot/u-boot-stm32mp15x_2020.10.bb deleted
> file mode 100644 index 39fceb2..0000000 ---
> a/meta-isar/recipes-bsp/u-boot/u-boot-stm32mp15x_2020.10.bb +++
> /dev/null @@ -1,10 +0,0 @@ -# -# Copyright (c) Siemens AG, 2020 -# -#
> SPDX-License-Identifier: MIT
> -
> -require u-boot-${PV}.inc
> -
> -SRC_URI += " \
> -
> file://0001-fdtdec-optionally-add-property-no-map-to-created-res.patch
> \
> -
> file://0002-optee-add-property-no-map-to-secure-reserved-memory.patch"
> diff --git
> a/meta-isar/recipes-bsp/u-boot/u-boot-stm32mp15x_2021.10.bb
> b/meta-isar/recipes-bsp/u-boot/u-boot-stm32mp15x_2021.10.bb new file
> mode 100644 index 0000000..6d95643 --- /dev/null +++
> b/meta-isar/recipes-bsp/u-boot/u-boot-stm32mp15x_2021.10.bb @@ -0,0
> +1,6 @@ +#
> +# Copyright (c) Siemens AG, 2020
> +#
> +# SPDX-License-Identifier: MIT
> +
> +require u-boot-${PV}.inc
next prev parent reply other threads:[~2021-11-05 6:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 10:49 Vijai Kumar K
2021-11-03 11:01 ` Jan Kiszka
2021-11-05 5:55 ` Kanagarajan, Vijaikumar
2021-11-03 18:25 ` Henning Schild
2021-11-05 6:05 ` Kanagarajan, Vijaikumar [this message]
2021-11-05 6:15 ` [PATCH v2 1/2] " Vijai Kumar K
2021-11-05 6:15 ` [PATCH v2 2/2] u-boot: Move libssl-dev dependency to u-boot-custom Vijai Kumar K
2021-11-05 6:28 ` Jan Kiszka
2021-11-05 7:40 ` vijai kumar
2021-11-05 12:16 ` vijai kumar
2021-11-06 12:12 ` [PATCH v3 1/2] meta-isar: u-boot: Update to 2021.10 Vijai Kumar K
2021-11-06 12:12 ` [PATCH v3 2/2] u-boot: Move libssl-dev dependency to u-boot-custom Vijai Kumar K
2021-11-09 6:01 ` Jan Kiszka
2021-11-19 16:54 ` vijai kumar
2021-11-22 6:20 ` Jan Kiszka
2021-11-22 6:37 ` vijai kumar
2021-11-09 6:06 ` [PATCH v3 1/2] meta-isar: u-boot: Update to 2021.10 Jan Kiszka
2021-11-19 17:54 ` vijaikumar....@gmail.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=07e7dbd000db4db2b1aa57c039a8e96c@svr-orw-mbx-01.mgc.mentorg.com \
--to=vijaikumar_kanagarajan@mentor.com \
--cc=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox