[PATCH v2 0/4] U-boot refactor and uprevision

[PATCH v2 0/4] U-boot refactor and uprevision

[Vijai Kumar K]

Changes since v1:
 - Fix wrong variable name in P2

CI Job running at:
http://ci.isar-build.org:8080/job/isar_vkk_devel/101/console

Thanks,
Vijai Kumar K

Vijai Kumar K (4):
  u-boot: Switch to use DEB_BUILD_PROFILES
  meta-isar: u-boot: Migrate to U_BOOT_BUILD_PROFILES
  meta: u-boot: Prepare for newer versions
  meta-isar: u-boot: Update to 2021.10

 RECIPE-API-CHANGELOG.md                       |  12 ++
 ...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} |   2 +-
 ...0.10.bb => u-boot-de0-nano-soc_2021.10.bb} |   2 +-
 .../u-boot/u-boot-stm32mp15x_2020.10.bb       |  10 --
 .../u-boot/u-boot-stm32mp15x_2021.10.bb       |   6 +
 .../u-boot/files/debian/control.tmpl          |  13 ++
 meta/recipes-bsp/u-boot/files/debian/rules    |   9 +-
 meta/recipes-bsp/u-boot/u-boot-custom.inc     |  56 ++++---
 10 files changed, 71 insertions(+), 223 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-secure-reserved-memory.patch
 rename meta-isar/recipes-bsp/u-boot/{u-boot-2020.10.inc => u-boot-2021.10.inc} (72%)
 rename meta-isar/recipes-bsp/u-boot/{u-boot-de0-nano-soc_2020.10.bb => u-boot-de0-nano-soc_2021.10.bb} (83%)
 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

-- 
2.25.1

[PATCH v2 1/4] u-boot: Switch to use DEB_BUILD_PROFILES

[Vijai Kumar K]

Use DEB_BUILD_PROFILES to select packages to build.

This patch drops the U_BOOT_TOOLS_PACKAGE and U_BOOT_CONFIG_PACKAGE
variables and introduces U_BOOT_BUILD_PROFILES through which we can
enable particular packages like u-boot-tools, u-boot-dev and
u-boot-config.

Also, provide backward compatibility with U_BOOT_*_PACKAGES
variable and prompt a deprecation warning to user.

Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
---
 RECIPE-API-CHANGELOG.md                       | 12 +++++
 .../u-boot/files/debian/control.tmpl          | 13 +++++
 meta/recipes-bsp/u-boot/files/debian/rules    |  9 +++-
 meta/recipes-bsp/u-boot/u-boot-custom.inc     | 52 ++++++++++---------
 4 files changed, 60 insertions(+), 26 deletions(-)

diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
index 7312d4d..3b926bd 100644
--- a/RECIPE-API-CHANGELOG.md
+++ b/RECIPE-API-CHANGELOG.md
@@ -301,3 +301,15 @@ Kernel update with "apt-get" will not work since bootloader configuration will
 not be updated. It used to "kind of work" for grub and efi, that hack is gone.
 
 When using the plugins it is advised to name the partition "/boot" and to exclude boot from the follwing rootfs to not waste space.
+
+### Deprecate U_BOOT_TOOLS_PACKAGE and U_BOOT_CONFIG_PACKAGE
+
+Use U_BOOT_BUILD_PROFILES instead of U_BOOT_TOOLS_PACKAGE and U_BOOT_CONFIG_PACKAGE
+
+U_BOOT_TOOLS_PACKAGE = "1" is achieved by U_BOOT_BUILD_PROFILES += "tools"
+U_BOOT_CONFIG_PACKAGE = "1" is achieved by U_BOOT_BUILD_PROFILES += "config"
+
+u-boot-${MACHINE}-dev package build can also be controlled now. Enabled by default
+in u-boot-custom.inc. To remove use the below code in your recipe.
+
+U_BOOT_BUILD_PROFILES_remove = "dev"
diff --git a/meta/recipes-bsp/u-boot/files/debian/control.tmpl b/meta/recipes-bsp/u-boot/files/debian/control.tmpl
index 9379be7..7ac11ad 100644
--- a/meta/recipes-bsp/u-boot/files/debian/control.tmpl
+++ b/meta/recipes-bsp/u-boot/files/debian/control.tmpl
@@ -11,4 +11,17 @@ Description: ${DESCRIPTION}, bootloader binaries
 
 Package: u-boot-${MACHINE}-dev
 Architecture: ${DISTRO_ARCH}
+Build-Profiles: <dev>
 Description: ${DESCRIPTION}, bootloader libraries
+
+Package: u-boot-tools
+Architecture: linux-any
+Build-Profiles: <tools>
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: ${DESCRIPTION}, companion tools
+
+Package: u-boot-${MACHINE}-config
+Build-Profiles: <config>
+Provides: u-boot-config
+Architecture: ${DISTRO_ARCH}
+Description: ${DESCRIPTION}, environment configuration
diff --git a/meta/recipes-bsp/u-boot/files/debian/rules b/meta/recipes-bsp/u-boot/files/debian/rules
index 3d66762..121b00e 100755
--- a/meta/recipes-bsp/u-boot/files/debian/rules
+++ b/meta/recipes-bsp/u-boot/files/debian/rules
@@ -20,10 +20,17 @@ override_dh_auto_build:
 	else \
 		./scripts/get_default_envs.sh >u-boot-initial-env; \
 	fi
-	$(MAKE) $(PARALLEL_MAKE) $(SET_CROSS_BUILD_TOOLS) NO_SDL=1 tools-only envtools
+ifneq (,$(filter dev,$(DEB_BUILD_PROFILES)))
+	$(MAKE) $(PARALLEL_MAKE) $(SET_CROSS_BUILD_TOOLS) NO_SDL=1 envtools
+endif
+ifneq (,$(filter tools,$(DEB_BUILD_PROFILES)))
+	$(MAKE) $(PARALLEL_MAKE) $(SET_CROSS_BUILD_TOOLS) NO_SDL=1 tools-only
+endif
 
 override_dh_auto_install:
+ifneq (,$(filter dev,$(DEB_BUILD_PROFILES)))
 	mv tools/env/lib.a tools/env/libubootenv.a
+endif
 
 override_dh_auto_test:
 
diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
index 9984d8c..5198809 100644
--- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
@@ -9,10 +9,13 @@ FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/files:"
 
 DESCRIPTION ?= "Custom U-Boot"
 
-PROVIDES += "u-boot-${MACHINE} u-boot-${MACHINE}-dev"
-PROVIDES += "${@'u-boot-tools' if d.getVar('U_BOOT_TOOLS_PACKAGE') == '1' else ''}"
+PROVIDES += "u-boot-${MACHINE}"
+PROVIDES += "${@'u-boot-tools' \
+	if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
 PROVIDES += "${@('u-boot-config u-boot-' + d.getVar('MACHINE') + '-config') \
-    if d.getVar('U_BOOT_CONFIG_PACKAGE') == '1' else ''}"
+	if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'config', 1, 0, d) else ''}"
+PROVIDES += "${@('u-boot-' + d.getVar('MACHINE') + '-dev') \
+	if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'dev', 1, 0, d) else ''}"
 
 inherit dpkg
 
@@ -22,6 +25,20 @@ python() {
     if d.getVar('BUILD_DEPENDS'):
         bb.warn("u-boot-custom: Deprecated use of BUILD_DEPENDS, please switch to DEBIAN_BUILD_DEPENDS")
         d.setVar('DEBIAN_BUILD_DEPENDS', d.getVar('BUILD_DEPENDS'))
+
+    if d.getVar('U_BOOT_TOOLS_PACKAGE') is not None:
+        bb.warn("u-boot-custom: Deprecated use of U_BOOT_TOOLS_PACKAGE, please switch to U_BOOT_BUILD_PROFILES")
+        if d.getVar('U_BOOT_TOOLS_PACKAGE') == "1":
+            d.appendVar('U_BOOT_BUILD_PROFILES', " tools")
+        else:
+            d.setVar('U_BOOT_BUILD_PROFILES_remove', "tools")
+
+    if d.getVar('U_BOOT_CONFIG_PACKAGE') is not None:
+        bb.warn("u-boot-custom: Deprecated use of U_BOOT_CONFIG_PACKAGE, please switch to U_BOOT_BUILD_PROFILES")
+        if d.getVar('U_BOOT_CONFIG_PACKAGE') == "1":
+            d.appendVar('U_BOOT_BUILD_PROFILES', " config")
+        else:
+            d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
 }
 
 DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
@@ -29,8 +46,8 @@ DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
 TEMPLATE_FILES = "debian/control.tmpl"
 TEMPLATE_VARS += "MACHINE DEBIAN_BUILD_DEPENDS"
 
-U_BOOT_TOOLS_PACKAGE ?= "0"
-U_BOOT_CONFIG_PACKAGE ?= "0"
+
+U_BOOT_BUILD_PROFILES ?= "dev"
 
 do_prepare_build() {
     cp -r ${WORKDIR}/debian ${S}/
@@ -40,31 +57,15 @@ do_prepare_build() {
     echo "${U_BOOT_BIN} /usr/lib/u-boot/${MACHINE}" > \
         ${S}/debian/u-boot-${MACHINE}.install
 
-    echo "tools/env/libubootenv.a usr/lib" > \
-        ${S}/debian/u-boot-${MACHINE}-dev.install
-
-    if [ "${U_BOOT_TOOLS_PACKAGE}" = "1" ]; then
-        cat <<EOF >>${S}/debian/control
-
-Package: u-boot-tools
-Architecture: linux-any
-Depends: \${shlibs:Depends}, \${misc:Depends}
-Description: ${DESCRIPTION}, companion tools
-EOF
+    if [ "${@bb.utils.contains('U_BOOT_BUILD_PROFILES', 'dev', 'yes', 'no', d)}" = "yes" ];then
+        echo "tools/env/libubootenv.a usr/lib" > \
+            ${S}/debian/u-boot-${MACHINE}-dev.install
     fi
 
-    if [ "${U_BOOT_CONFIG_PACKAGE}" = "1" ]; then
+    if [ "${@bb.utils.contains('U_BOOT_BUILD_PROFILES', 'config', 'yes', 'no', d)}" = "yes" ];then
         cp ${WORKDIR}/fw_env.config ${S}/ || \
             die "U_BOOT_CONFIG_PACKAGE requires a fw_env.config in SRC_URI"
 
-        cat <<EOF >>${S}/debian/control
-
-Package: u-boot-${MACHINE}-config
-Provides: u-boot-config
-Architecture: ${DISTRO_ARCH}
-Description: ${DESCRIPTION}, environment configuration
-EOF
-
         cat <<EOF >>${S}/debian/u-boot-${MACHINE}-config.install
 u-boot-initial-env /etc
 fw_env.config      /etc
@@ -75,4 +76,5 @@ EOF
 dpkg_runbuild_prepend() {
     export U_BOOT_CONFIG="${U_BOOT_CONFIG}"
     export U_BOOT_BIN="${U_BOOT_BIN}"
+    export DEB_BUILD_PROFILES="${U_BOOT_BUILD_PROFILES}"
 }
-- 
2.25.1

[PATCH v2 2/4] meta-isar: u-boot: Migrate to U_BOOT_BUILD_PROFILES

[Vijai Kumar K]

Migrate u-boot recipe to use U_BOOT_BUILD_PROFILES instead of
U_BOOT_TOOLS_PACKAGE variable

Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
---
 meta-isar/recipes-bsp/u-boot/u-boot-de0-nano-soc_2020.10.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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_2020.10.bb
index dcb76c5..640b7ea 100644
--- 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_2020.10.bb
@@ -6,4 +6,4 @@
 require u-boot-${PV}.inc
 
 # Just for testing purposes, distro package would be recent enough
-U_BOOT_TOOLS_PACKAGE = "1"
+U_BOOT_BUILD_PROFILES += "tools"
-- 
2.25.1

[PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[Vijai Kumar K]

Newer versions of u-boot require libssl-dev:native for compilation.
It also needs libssl-dev of the host architecture for cross compilation
of tools.

Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
---
 meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
index 5198809..cfae0e2 100644
--- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
@@ -41,7 +41,9 @@ python() {
             d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
 }
 
-DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
+DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
+DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
+	if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
 
 TEMPLATE_FILES = "debian/control.tmpl"
 TEMPLATE_VARS += "MACHINE DEBIAN_BUILD_DEPENDS"
-- 
2.25.1

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[Gylstorff Quirin]

Hi,

On 11/22/21 4:26 PM, Vijai Kumar K wrote:
> Newer versions of u-boot require libssl-dev:native for compilation.
> It also needs libssl-dev of the host architecture for cross compilation
> of tools.
> 
> Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
> ---
>   meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> index 5198809..cfae0e2 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> @@ -41,7 +41,9 @@ python() {
>               d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
>   }
>   
> -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
> +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
> +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
> +	if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"

Is there are reason why you didn't use `Build-Depends syntax extension` 
from[1]?


[1]: https://wiki.debian.org/BuildProfileSpec


Quirin
>   
>   TEMPLATE_FILES = "debian/control.tmpl"
>   TEMPLATE_VARS += "MACHINE DEBIAN_BUILD_DEPENDS"
> 

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[vijai kumar]

On Tue, Nov 23, 2021 at 3:24 PM Gylstorff Quirin
<quirin.gylstorff@siemens.com> wrote:
>
> Hi,
>
> On 11/22/21 4:26 PM, Vijai Kumar K wrote:
> > Newer versions of u-boot require libssl-dev:native for compilation.
> > It also needs libssl-dev of the host architecture for cross compilation
> > of tools.
> >
> > Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
> > ---
> >   meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > index 5198809..cfae0e2 100644
> > --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > @@ -41,7 +41,9 @@ python() {
> >               d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
> >   }
> >
> > -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
> > +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
> > +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
> > +     if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
>
> Is there are reason why you didn't use `Build-Depends syntax extension`
> from[1]?
>
Hi Quirin,

Yes. There was. The previous version of patch depends on
ISAR_CROSS_COMPILE as well.

Guess there is nothing stopping us now. But, wondering if we can start
introducing it via some
example app with some documentation so that basic users are not
puzzled on seeing that line in
a recipe.

Also, we could define a whole new variable to help recipe writers to
define profiles and seamlessly
use them without the need to explicitly export DEB_BUILD_PROFILES in
the recipe's dpkg_runbuild

Now that we are serious enough, we should probably take care of your
earlier comment
as well on following the standard. So that we don't conflict with
Debian's predefined variables in case
we decided to build a package fetched from apt:// and wanted to make
use of its profile settings.

Still need to look further but these are my initial thoughts. I could
probably send some patches for review in
coming days.

For now, maybe we should call it and use pkg.uboot.tools instead of
tools here so that we don't
find something in that implementation that requires us to change this
in future, possibly breaking
u-boot / or the need to provide compatibility.

Thoughts?

Thanks,
Vijai Kumar K


>
> [1]: https://wiki.debian.org/BuildProfileSpec
>
>
> Quirin
> >
> >   TEMPLATE_FILES = "debian/control.tmpl"
> >   TEMPLATE_VARS += "MACHINE DEBIAN_BUILD_DEPENDS"
> >
>
> --
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/8319aef1-420a-034e-9152-b0c3c8c3536a%40siemens.com.

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[vijai kumar]

On Thu, Nov 25, 2021 at 12:12 PM vijai kumar
<vijaikumar.kanagarajan@gmail.com> wrote:
>
> On Tue, Nov 23, 2021 at 3:24 PM Gylstorff Quirin
> <quirin.gylstorff@siemens.com> wrote:
> >
> > Hi,
> >
> > On 11/22/21 4:26 PM, Vijai Kumar K wrote:
> > > Newer versions of u-boot require libssl-dev:native for compilation.
> > > It also needs libssl-dev of the host architecture for cross compilation
> > > of tools.
> > >
> > > Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
> > > ---
> > >   meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
> > >   1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > > index 5198809..cfae0e2 100644
> > > --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > > +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > > @@ -41,7 +41,9 @@ python() {
> > >               d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
> > >   }
> > >
> > > -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
> > > +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
> > > +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
> > > +     if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
> >
> > Is there are reason why you didn't use `Build-Depends syntax extension`
> > from[1]?
> >
> Hi Quirin,
>
> Yes. There was. The previous version of patch depends on
> ISAR_CROSS_COMPILE as well.
>
> Guess there is nothing stopping us now. But, wondering if we can start
> introducing it via some
> example app with some documentation so that basic users are not
> puzzled on seeing that line in
> a recipe.
>
> Also, we could define a whole new variable to help recipe writers to
> define profiles and seamlessly
> use them without the need to explicitly export DEB_BUILD_PROFILES in
> the recipe's dpkg_runbuild
>
> Now that we are serious enough, we should probably take care of your
> earlier comment
> as well on following the standard. So that we don't conflict with
> Debian's predefined variables in case
> we decided to build a package fetched from apt:// and wanted to make
> use of its profile settings.
>
> Still need to look further but these are my initial thoughts. I could
> probably send some patches for review in
> coming days.
>
> For now, maybe we should call it and use pkg.uboot.tools instead of
> tools here so that we don't
> find something in that implementation that requires us to change this
> in future, possibly breaking
> u-boot / or the need to provide compatibility.
>
> Thoughts?

OTOH, This could still go in. Since the design I am thinking of is not
finalized and might take some discussions in the list, there is no
point in holding this back.


Thanks,
Vijai Kumar K

>
> Thanks,
> Vijai Kumar K
>
>
> >
> > [1]: https://wiki.debian.org/BuildProfileSpec
> >
> >
> > Quirin
> > >
> > >   TEMPLATE_FILES = "debian/control.tmpl"
> > >   TEMPLATE_VARS += "MACHINE DEBIAN_BUILD_DEPENDS"
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "isar-users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/8319aef1-420a-034e-9152-b0c3c8c3536a%40siemens.com.

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[Jan Kiszka]

On 25.11.21 17:27, vijai kumar wrote:
> On Thu, Nov 25, 2021 at 12:12 PM vijai kumar
> <vijaikumar.kanagarajan@gmail.com> wrote:
>>
>> On Tue, Nov 23, 2021 at 3:24 PM Gylstorff Quirin
>> <quirin.gylstorff@siemens.com> wrote:
>>>
>>> Hi,
>>>
>>> On 11/22/21 4:26 PM, Vijai Kumar K wrote:
>>>> Newer versions of u-boot require libssl-dev:native for compilation.
>>>> It also needs libssl-dev of the host architecture for cross compilation
>>>> of tools.
>>>>
>>>> Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
>>>> ---
>>>>   meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
>>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
>>>> index 5198809..cfae0e2 100644
>>>> --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
>>>> +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
>>>> @@ -41,7 +41,9 @@ python() {
>>>>               d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
>>>>   }
>>>>
>>>> -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
>>>> +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
>>>> +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
>>>> +     if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
>>>
>>> Is there are reason why you didn't use `Build-Depends syntax extension`
>>> from[1]?
>>>
>> Hi Quirin,
>>
>> Yes. There was. The previous version of patch depends on
>> ISAR_CROSS_COMPILE as well.
>>
>> Guess there is nothing stopping us now. But, wondering if we can start
>> introducing it via some
>> example app with some documentation so that basic users are not
>> puzzled on seeing that line in
>> a recipe.
>>
>> Also, we could define a whole new variable to help recipe writers to
>> define profiles and seamlessly
>> use them without the need to explicitly export DEB_BUILD_PROFILES in
>> the recipe's dpkg_runbuild
>>
>> Now that we are serious enough, we should probably take care of your
>> earlier comment
>> as well on following the standard. So that we don't conflict with
>> Debian's predefined variables in case
>> we decided to build a package fetched from apt:// and wanted to make
>> use of its profile settings.
>>
>> Still need to look further but these are my initial thoughts. I could
>> probably send some patches for review in
>> coming days.
>>
>> For now, maybe we should call it and use pkg.uboot.tools instead of
>> tools here so that we don't
>> find something in that implementation that requires us to change this
>> in future, possibly breaking
>> u-boot / or the need to provide compatibility.
>>
>> Thoughts?
> 
> OTOH, This could still go in. Since the design I am thinking of is not
> finalized and might take some discussions in the list, there is no
> point in holding this back.
> 

I think Quirin was just asking for

DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, \
	libssl-dev:native, libssl-dev <tools>"

rather than using bitbake logic. If that also works, would be more elegant.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[vijai kumar]

On Thu, Nov 25, 2021 at 10:04 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 25.11.21 17:27, vijai kumar wrote:
> > On Thu, Nov 25, 2021 at 12:12 PM vijai kumar
> > <vijaikumar.kanagarajan@gmail.com> wrote:
> >>
> >> On Tue, Nov 23, 2021 at 3:24 PM Gylstorff Quirin
> >> <quirin.gylstorff@siemens.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 11/22/21 4:26 PM, Vijai Kumar K wrote:
> >>>> Newer versions of u-boot require libssl-dev:native for compilation.
> >>>> It also needs libssl-dev of the host architecture for cross compilation
> >>>> of tools.
> >>>>
> >>>> Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
> >>>> ---
> >>>>   meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
> >>>>   1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> >>>> index 5198809..cfae0e2 100644
> >>>> --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
> >>>> +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> >>>> @@ -41,7 +41,9 @@ python() {
> >>>>               d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
> >>>>   }
> >>>>
> >>>> -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
> >>>> +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
> >>>> +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
> >>>> +     if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
> >>>
> >>> Is there are reason why you didn't use `Build-Depends syntax extension`
> >>> from[1]?
> >>>
> >> Hi Quirin,
> >>
> >> Yes. There was. The previous version of patch depends on
> >> ISAR_CROSS_COMPILE as well.
> >>
> >> Guess there is nothing stopping us now. But, wondering if we can start
> >> introducing it via some
> >> example app with some documentation so that basic users are not
> >> puzzled on seeing that line in
> >> a recipe.
> >>
> >> Also, we could define a whole new variable to help recipe writers to
> >> define profiles and seamlessly
> >> use them without the need to explicitly export DEB_BUILD_PROFILES in
> >> the recipe's dpkg_runbuild
> >>
> >> Now that we are serious enough, we should probably take care of your
> >> earlier comment
> >> as well on following the standard. So that we don't conflict with
> >> Debian's predefined variables in case
> >> we decided to build a package fetched from apt:// and wanted to make
> >> use of its profile settings.
> >>
> >> Still need to look further but these are my initial thoughts. I could
> >> probably send some patches for review in
> >> coming days.
> >>
> >> For now, maybe we should call it and use pkg.uboot.tools instead of
> >> tools here so that we don't
> >> find something in that implementation that requires us to change this
> >> in future, possibly breaking
> >> u-boot / or the need to provide compatibility.
> >>
> >> Thoughts?
> >
> > OTOH, This could still go in. Since the design I am thinking of is not
> > finalized and might take some discussions in the list, there is no
> > point in holding this back.
> >
>
> I think Quirin was just asking for
>
> DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, \
>         libssl-dev:native, libssl-dev <tools>"
>
> rather than using bitbake logic. If that also works, would be more elegant.

Yes, that also works. But just a bit difficult to read for normal users.

A framework for DEB_BUILD_PROFILES for isar would be helpful I guess,
like I mentioned above.
Will see if I can convert my thoughts to some patches sometime soon.

Thanks,
VIjai Kumar K

>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[Jan Kiszka]

On 26.11.21 07:07, vijai kumar wrote:
> On Thu, Nov 25, 2021 at 10:04 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 25.11.21 17:27, vijai kumar wrote:
>>> On Thu, Nov 25, 2021 at 12:12 PM vijai kumar
>>> <vijaikumar.kanagarajan@gmail.com> wrote:
>>>>
>>>> On Tue, Nov 23, 2021 at 3:24 PM Gylstorff Quirin
>>>> <quirin.gylstorff@siemens.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 11/22/21 4:26 PM, Vijai Kumar K wrote:
>>>>>> Newer versions of u-boot require libssl-dev:native for compilation.
>>>>>> It also needs libssl-dev of the host architecture for cross compilation
>>>>>> of tools.
>>>>>>
>>>>>> Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
>>>>>> ---
>>>>>>   meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
>>>>>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
>>>>>> index 5198809..cfae0e2 100644
>>>>>> --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
>>>>>> +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
>>>>>> @@ -41,7 +41,9 @@ python() {
>>>>>>               d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
>>>>>>   }
>>>>>>
>>>>>> -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
>>>>>> +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
>>>>>> +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
>>>>>> +     if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
>>>>>
>>>>> Is there are reason why you didn't use `Build-Depends syntax extension`
>>>>> from[1]?
>>>>>
>>>> Hi Quirin,
>>>>
>>>> Yes. There was. The previous version of patch depends on
>>>> ISAR_CROSS_COMPILE as well.
>>>>
>>>> Guess there is nothing stopping us now. But, wondering if we can start
>>>> introducing it via some
>>>> example app with some documentation so that basic users are not
>>>> puzzled on seeing that line in
>>>> a recipe.
>>>>
>>>> Also, we could define a whole new variable to help recipe writers to
>>>> define profiles and seamlessly
>>>> use them without the need to explicitly export DEB_BUILD_PROFILES in
>>>> the recipe's dpkg_runbuild
>>>>
>>>> Now that we are serious enough, we should probably take care of your
>>>> earlier comment
>>>> as well on following the standard. So that we don't conflict with
>>>> Debian's predefined variables in case
>>>> we decided to build a package fetched from apt:// and wanted to make
>>>> use of its profile settings.
>>>>
>>>> Still need to look further but these are my initial thoughts. I could
>>>> probably send some patches for review in
>>>> coming days.
>>>>
>>>> For now, maybe we should call it and use pkg.uboot.tools instead of
>>>> tools here so that we don't
>>>> find something in that implementation that requires us to change this
>>>> in future, possibly breaking
>>>> u-boot / or the need to provide compatibility.
>>>>
>>>> Thoughts?
>>>
>>> OTOH, This could still go in. Since the design I am thinking of is not
>>> finalized and might take some discussions in the list, there is no
>>> point in holding this back.
>>>
>>
>> I think Quirin was just asking for
>>
>> DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, \
>>         libssl-dev:native, libssl-dev <tools>"
>>
>> rather than using bitbake logic. If that also works, would be more elegant.
> 
> Yes, that also works. But just a bit difficult to read for normal users.

It's more Debian-style, thus to be preferred according to Isar principles.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[vijai kumar]

On Fri, Nov 26, 2021 at 11:59 AM Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 26.11.21 07:07, vijai kumar wrote:
> > On Thu, Nov 25, 2021 at 10:04 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 25.11.21 17:27, vijai kumar wrote:
> >>> On Thu, Nov 25, 2021 at 12:12 PM vijai kumar
> >>> <vijaikumar.kanagarajan@gmail.com> wrote:
> >>>>
> >>>> On Tue, Nov 23, 2021 at 3:24 PM Gylstorff Quirin
> >>>> <quirin.gylstorff@siemens.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On 11/22/21 4:26 PM, Vijai Kumar K wrote:
> >>>>>> Newer versions of u-boot require libssl-dev:native for compilation.
> >>>>>> It also needs libssl-dev of the host architecture for cross compilation
> >>>>>> of tools.
> >>>>>>
> >>>>>> Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
> >>>>>> ---
> >>>>>>   meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
> >>>>>>   1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> >>>>>> index 5198809..cfae0e2 100644
> >>>>>> --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
> >>>>>> +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> >>>>>> @@ -41,7 +41,9 @@ python() {
> >>>>>>               d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
> >>>>>>   }
> >>>>>>
> >>>>>> -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
> >>>>>> +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
> >>>>>> +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
> >>>>>> +     if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
> >>>>>
> >>>>> Is there are reason why you didn't use `Build-Depends syntax extension`
> >>>>> from[1]?
> >>>>>
> >>>> Hi Quirin,
> >>>>
> >>>> Yes. There was. The previous version of patch depends on
> >>>> ISAR_CROSS_COMPILE as well.
> >>>>
> >>>> Guess there is nothing stopping us now. But, wondering if we can start
> >>>> introducing it via some
> >>>> example app with some documentation so that basic users are not
> >>>> puzzled on seeing that line in
> >>>> a recipe.
> >>>>
> >>>> Also, we could define a whole new variable to help recipe writers to
> >>>> define profiles and seamlessly
> >>>> use them without the need to explicitly export DEB_BUILD_PROFILES in
> >>>> the recipe's dpkg_runbuild
> >>>>
> >>>> Now that we are serious enough, we should probably take care of your
> >>>> earlier comment
> >>>> as well on following the standard. So that we don't conflict with
> >>>> Debian's predefined variables in case
> >>>> we decided to build a package fetched from apt:// and wanted to make
> >>>> use of its profile settings.
> >>>>
> >>>> Still need to look further but these are my initial thoughts. I could
> >>>> probably send some patches for review in
> >>>> coming days.
> >>>>
> >>>> For now, maybe we should call it and use pkg.uboot.tools instead of
> >>>> tools here so that we don't
> >>>> find something in that implementation that requires us to change this
> >>>> in future, possibly breaking
> >>>> u-boot / or the need to provide compatibility.
> >>>>
> >>>> Thoughts?
> >>>
> >>> OTOH, This could still go in. Since the design I am thinking of is not
> >>> finalized and might take some discussions in the list, there is no
> >>> point in holding this back.
> >>>
> >>
> >> I think Quirin was just asking for
> >>
> >> DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, \
> >>         libssl-dev:native, libssl-dev <tools>"
> >>
> >> rather than using bitbake logic. If that also works, would be more elegant.
> >
> > Yes, that also works. But just a bit difficult to read for normal users.
>
> It's more Debian-style, thus to be preferred according to Isar principles.

Ok.  v3 coming up. It should be on the mailing list anytime now.

Thanks,
Vijai Kumar K

>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[vijai kumar]

On Fri, Nov 26, 2021 at 11:37 AM vijai kumar
<vijaikumar.kanagarajan@gmail.com> wrote:
>
> On Thu, Nov 25, 2021 at 10:04 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >
> > On 25.11.21 17:27, vijai kumar wrote:
> > > On Thu, Nov 25, 2021 at 12:12 PM vijai kumar
> > > <vijaikumar.kanagarajan@gmail.com> wrote:
> > >>
> > >> On Tue, Nov 23, 2021 at 3:24 PM Gylstorff Quirin
> > >> <quirin.gylstorff@siemens.com> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> On 11/22/21 4:26 PM, Vijai Kumar K wrote:
> > >>>> Newer versions of u-boot require libssl-dev:native for compilation.
> > >>>> It also needs libssl-dev of the host architecture for cross compilation
> > >>>> of tools.
> > >>>>
> > >>>> Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
> > >>>> ---
> > >>>>   meta/recipes-bsp/u-boot/u-boot-custom.inc | 4 +++-
> > >>>>   1 file changed, 3 insertions(+), 1 deletion(-)
> > >>>>
> > >>>> diff --git a/meta/recipes-bsp/u-boot/u-boot-custom.inc b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > >>>> index 5198809..cfae0e2 100644
> > >>>> --- a/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > >>>> +++ b/meta/recipes-bsp/u-boot/u-boot-custom.inc
> > >>>> @@ -41,7 +41,9 @@ python() {
> > >>>>               d.setVar('U_BOOT_BUILD_PROFILES_remove', "config")
> > >>>>   }
> > >>>>
> > >>>> -DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git"
> > >>>> +DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, libssl-dev:native"
> > >>>> +DEBIAN_BUILD_DEPENDS += "${@', libssl-dev' \
> > >>>> +     if bb.utils.contains('U_BOOT_BUILD_PROFILES', 'tools', 1, 0, d) else ''}"
> > >>>
> > >>> Is there are reason why you didn't use `Build-Depends syntax extension`
> > >>> from[1]?
> > >>>
> > >> Hi Quirin,
> > >>
> > >> Yes. There was. The previous version of patch depends on
> > >> ISAR_CROSS_COMPILE as well.
> > >>
> > >> Guess there is nothing stopping us now. But, wondering if we can start
> > >> introducing it via some
> > >> example app with some documentation so that basic users are not
> > >> puzzled on seeing that line in
> > >> a recipe.
> > >>
> > >> Also, we could define a whole new variable to help recipe writers to
> > >> define profiles and seamlessly
> > >> use them without the need to explicitly export DEB_BUILD_PROFILES in
> > >> the recipe's dpkg_runbuild
> > >>
> > >> Now that we are serious enough, we should probably take care of your
> > >> earlier comment
> > >> as well on following the standard. So that we don't conflict with
> > >> Debian's predefined variables in case
> > >> we decided to build a package fetched from apt:// and wanted to make
> > >> use of its profile settings.
> > >>
> > >> Still need to look further but these are my initial thoughts. I could
> > >> probably send some patches for review in
> > >> coming days.
> > >>
> > >> For now, maybe we should call it and use pkg.uboot.tools instead of
> > >> tools here so that we don't
> > >> find something in that implementation that requires us to change this
> > >> in future, possibly breaking
> > >> u-boot / or the need to provide compatibility.
> > >>
> > >> Thoughts?
> > >
> > > OTOH, This could still go in. Since the design I am thinking of is not
> > > finalized and might take some discussions in the list, there is no
> > > point in holding this back.
> > >
> >
> > I think Quirin was just asking for
> >
> > DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, \
> >         libssl-dev:native, libssl-dev <tools>"
> >
> > rather than using bitbake logic. If that also works, would be more elegant.
>
> Yes, that also works. But just a bit difficult to read for normal users.

No. False positive. Just did a build after cleaning buildchroot. It
doesnot work as expected.

I will look into it when I start working on the DEB_BUILD_PROFILES
framework. I hope
I can spend time doing that. Fingers crossed.

Thanks,
Vijai Kumar K

>
> A framework for DEB_BUILD_PROFILES for isar would be helpful I guess,
> like I mentioned above.
> Will see if I can convert my thoughts to some patches sometime soon.
>
> Thanks,
> VIjai Kumar K
>
> >
> > Jan
> >
> > --
> > Siemens AG, T RDA IOT
> > Corporate Competence Center Embedded Linux

Re: [PATCH v2 3/4] meta: u-boot: Prepare for newer versions

[Gylstorff Quirin]

On 11/25/21 5:34 PM, Jan Kiszka wrote:
> I think Quirin was just asking for
> 
> DEBIAN_BUILD_DEPENDS ?= "bc, bison, flex, device-tree-compiler, git, \
> 	libssl-dev:native, libssl-dev <tools>"
> 
> rather than using bitbake logic. If that also works, would be more elegant.
> 

I think that pattern looks much better - if it works.

Quirin

> Jan

-

[PATCH v2 4/4] meta-isar: u-boot: Update to 2021.10

[Vijai Kumar K]

Update to the latest u-boot.

Signed-off-by: Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
---
 ...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} |   2 +-
 ...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, 7 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-secure-reserved-memory.patch
 rename meta-isar/recipes-bsp/u-boot/{u-boot-2020.10.inc => u-boot-2021.10.inc} (72%)
 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-property-no-map-to-created-res.patch b/meta-isar/recipes-bsp/u-boot/files/0001-fdtdec-optionally-add-property-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-property-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 72%
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..f3f822a 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
@@ -8,6 +8,6 @@ require recipes-bsp/u-boot/u-boot-custom.inc
 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
-- 
2.25.1