From: Alexandru Gagniuc <mr.nuke.me@gmail.com>
To: u-boot@lists.denx.de, patrick.delaunay@foss.st.com
Cc: patrice.chotard@foss.st.com,
uboot-stm32@st-md-mailman.stormreply.com,
Alexandru Gagniuc <mr.nuke.me@gmail.com>,
marex@denx.de, etienne.carriere@linaro.org
Subject: [PATCH 0/3] stm32mp: Attempt to resolve unintended breakage with v2021.10-rc2
Date: Thu, 9 Sep 2021 09:55:33 -0500 [thread overview]
Message-ID: <20210909145536.2979951-1-mr.nuke.me@gmail.com> (raw)
u-boot v2021.10-rc2 Introduced support for booting from FIP images
(not to be confused with FIT) for stm32mp. I am also working on a
different boot flow based on u-boot's falcon mode. The changes to
accommodate the FIP mode inadvertently broke the falcon flow. This
series intends to address that.
The core issue is that optee nodes are removed from the u-boot
devicetree. For reasons detailed in my other series
("[PATCH v2 00/11] stm32mp1: Support falcon mode with OP-TEE payloads")
the "optee" nodes are required.
It might seem like an obvious solution to "just re-add the nodes", but
I found out it didn't work like that. I couldn't use
STM32MP15x_STM32IMAGE to get me back my nodes, because that would have
required TFABOOT. What I needed was a new config that more accuratelyreflected the available boot flows.
STM32MP15x_STM32IMAGE is a confusing because it conflates image
generation with u-boot behavior. I'm proposing replacing it with
TFABOOT_FIP_CONTAINER because I think this new config is much easier
to understand in layman's terms. I also thinks it maps more elegantly
to what STM is trying to do: add a new boot flow.
Alexandru Gagniuc (3):
stm32mp: Rename FIP config to stm32mp15_tfaboot_fip_defconig
arm: Kconfig: Introduce a TFABOOT_FIP_CONTAINER option
stm32mp1: Replace STM32MP15x_STM32IMAGE with TFABOOT_FIP_CONTAINER
arch/arm/Kconfig | 15 ++++++++++++
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 9 ++++----
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 9 ++++----
arch/arm/mach-stm32mp/Kconfig | 7 ------
.../cmd_stm32prog/cmd_stm32prog.c | 5 ++--
.../mach-stm32mp/cmd_stm32prog/stm32prog.c | 4 ----
.../mach-stm32mp/cmd_stm32prog/stm32prog.h | 2 --
arch/arm/mach-stm32mp/config.mk | 2 +-
arch/arm/mach-stm32mp/fdt.c | 4 +---
.../arm/mach-stm32mp/include/mach/stm32prog.h | 2 --
board/st/common/Kconfig | 23 ++++++++++---------
board/st/common/stm32mp_mtdparts.c | 20 +---------------
board/st/stm32mp1/MAINTAINERS | 2 +-
board/st/stm32mp1/stm32mp1.c | 6 ++---
...config => stm32mp15_tfaboot_fip_defconfig} | 1 +
configs/stm32mp15_trusted_defconfig | 1 -
doc/board/st/stm32mp1.rst | 16 ++++++-------
17 files changed, 54 insertions(+), 74 deletions(-)
rename configs/{stm32mp15_defconfig => stm32mp15_tfaboot_fip_defconfig} (99%)
--
2.31.1
next reply other threads:[~2021-09-09 14:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-09 14:55 Alexandru Gagniuc [this message]
2021-09-09 14:55 ` [PATCH 1/3] stm32mp: Rename FIP config to stm32mp15_tfaboot_fip_defconig Alexandru Gagniuc
2021-09-09 14:55 ` [PATCH 2/3] arm: Kconfig: Introduce a TFABOOT_FIP_CONTAINER option Alexandru Gagniuc
2021-09-09 14:55 ` [PATCH 3/3] stm32mp1: Replace STM32MP15x_STM32IMAGE with TFABOOT_FIP_CONTAINER Alexandru Gagniuc
2021-09-14 12:26 ` [PATCH 0/3] stm32mp: Attempt to resolve unintended breakage with v2021.10-rc2 Patrick DELAUNAY
2021-10-07 17:13 ` Alex G.
2021-10-08 9:18 ` Patrick DELAUNAY
2021-10-08 11:28 ` Marek Vasut
2021-10-08 13:20 ` Patrick DELAUNAY
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=20210909145536.2979951-1-mr.nuke.me@gmail.com \
--to=mr.nuke.me@gmail.com \
--cc=etienne.carriere@linaro.org \
--cc=marex@denx.de \
--cc=patrice.chotard@foss.st.com \
--cc=patrick.delaunay@foss.st.com \
--cc=u-boot@lists.denx.de \
--cc=uboot-stm32@st-md-mailman.stormreply.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