* [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-12 22:36 [PATCH 1/3] arm64: Add late jump to kernel board hook Marek Vasut
@ 2025-01-12 22:36 ` Marek Vasut
2025-01-13 12:15 ` Biju Das
` (2 more replies)
2025-01-12 22:36 ` [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support Marek Vasut
2025-01-15 1:13 ` [PATCH 1/3] arm64: Add late jump to kernel board hook Tom Rini
2 siblings, 3 replies; 19+ messages in thread
From: Marek Vasut @ 2025-01-12 22:36 UTC (permalink / raw)
To: u-boot
Cc: Marek Vasut, Andre Przywara, Caleb Connolly, Igor Opaniuk,
Ilias Apalodimas, Julien Masson, Mattijs Korpershoek,
Maxim Moskalets, Michael Walle, Nobuhiro Iwamatsu,
Patrick Rudolph, Paul Barker, Paul-Erwan Rio, Peter Hoyes,
Raymond Mao, Sam Protsenko, Simon Glass, Sughosh Ganu, Tom Rini
Add support for starting TFA from U-Boot running in EL3 as part of
fitImage boot, so the user can start U-Boot in the highest privilege
level on the platform, bundle TFA, Linux, DT into a single fitImage
and boot such a bundle as a whole.
There are two main benefits of this approach. First is the ability
to run U-Boot in EL3, where it has unrestricted access to the entire
system and can act as a useful debug tool, as it was always intended
to be used. Second is the ability to easily and safely update of any
component in the fitImage, be it TFA, Linux or DT.
The boot process is similar to regular Linux with DT fitImage boot
process, except the TFA has to be bundled into the fitImage. For the
bundling instructions, see below. The TFA is started as a 'loadables'
with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling implemented in board code, and performing the handoff and
boot in case the TFA was loaded.
The loadables handler is optional and meant to set up any sort of
handoff structures used by the TFA BL31 or perform any other setup
that is needed by the blob. The custom armv8_switch_to_el2_prep()
has to implement the jump to TFA BL31 with return to U-Boot just
before booting the Linux kernel.
Example fitImage image and configuration section:
/dts-v1/;
/ {
description = "Linux kernel with FDT blob and TFA BL31";
images {
kernel-1 { ... };
fdt-1 { ... };
atf-1 { /* This is the TFA BL31 image */
description = "TFA BL31";
data = /incbin/("../build/plat/release/bl31.bin");
type = "tfa-bl31";
arch = "arm64";
os = "arm-trusted-firmware";
compression = "none";
load = <0x46400000>;
entry = <0x46400000>;
};
};
configurations {
default = "conf-1";
conf-1 {
description = "Boot Linux";
kernel = "kernel-1";
fdt = "fdt-1";
loadables = "atf-1"; /* This is the TFA BL31 loadable */
};
};
};
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Caleb Connolly <caleb.connolly@linaro.org>
Cc: Igor Opaniuk <igor.opaniuk@gmail.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Julien Masson <jmasson@baylibre.com>
Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Cc: Maxim Moskalets <maximmosk4@gmail.com>
Cc: Michael Walle <mwalle@kernel.org>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
Cc: Paul Barker <paul.barker.ct@bp.renesas.com>
Cc: Paul-Erwan Rio <paulerwan.rio@gmail.com>
Cc: Peter Hoyes <Peter.Hoyes@arm.com>
Cc: Raymond Mao <raymond.mao@linaro.org>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Sughosh Ganu <sughosh.ganu@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de
---
boot/image-fit.c | 1 +
boot/image.c | 1 +
include/image.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/boot/image-fit.c b/boot/image-fit.c
index db7fb61bca9..3b6d7231aff 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -2167,6 +2167,7 @@ int fit_image_load(struct bootm_headers *images, ulong addr,
type_ok = fit_image_check_type(fit, noffset, image_type) ||
fit_image_check_type(fit, noffset, IH_TYPE_FIRMWARE) ||
fit_image_check_type(fit, noffset, IH_TYPE_TEE) ||
+ fit_image_check_type(fit, noffset, IH_TYPE_TFA_BL31) ||
(image_type == IH_TYPE_KERNEL &&
fit_image_check_type(fit, noffset, IH_TYPE_KERNEL_NOLOAD));
diff --git a/boot/image.c b/boot/image.c
index abac254e026..139c5bd035a 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -183,6 +183,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_FDT_LEGACY, "fdt_legacy", "legacy Image with Flat Device Tree ", },
{ IH_TYPE_RENESAS_SPKG, "spkgimage", "Renesas SPKG Image" },
{ IH_TYPE_STARFIVE_SPL, "sfspl", "StarFive SPL Image" },
+ { IH_TYPE_TFA_BL31, "tfa-bl31", "TFA BL31 Image", },
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index 0a61dfd556c..3adb7219809 100644
--- a/include/image.h
+++ b/include/image.h
@@ -232,6 +232,7 @@ enum image_type_t {
IH_TYPE_FDT_LEGACY, /* Binary Flat Device Tree Blob in a Legacy Image */
IH_TYPE_RENESAS_SPKG, /* Renesas SPKG image */
IH_TYPE_STARFIVE_SPL, /* StarFive SPL image */
+ IH_TYPE_TFA_BL31, /* TFA BL31 image */
IH_TYPE_COUNT, /* Number of image types */
};
--
2.45.2
^ permalink raw reply related [flat|nested] 19+ messages in thread* RE: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-12 22:36 ` [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables Marek Vasut
@ 2025-01-13 12:15 ` Biju Das
2025-01-13 12:39 ` Marek Vasut
2025-01-15 1:13 ` Tom Rini
2025-01-29 17:10 ` Quentin Schulz
2 siblings, 1 reply; 19+ messages in thread
From: Biju Das @ 2025-01-13 12:15 UTC (permalink / raw)
To: Marek Vasut, u-boot@lists.denx.de
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
Hi Marex,
Thanks for the patch
> -----Original Message-----
> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Marek Vasut
> Sent: 12 January 2025 22:37
> Subject: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
>
> Add support for starting TFA from U-Boot running in EL3 as part of fitImage boot, so the user can
> start U-Boot in the highest privilege level on the platform, bundle TFA, Linux, DT into a single
> fitImage and boot such a bundle as a whole.
>
> There are two main benefits of this approach. First is the ability to run U-Boot in EL3, where it has
> unrestricted access to the entire system and can act as a useful debug tool, as it was always intended
> to be used. Second is the ability to easily and safely update of any component in the fitImage, be it
> TFA, Linux or DT.
In this case, who will do switching from secure world to normal world, u-boot?
Do you have any link to the u-boot patch from secure to normal world switching
with kernel entry point passed to BL31?
Otherwise, kernel, also will be executing in secure world mode.
Cheers,
Biju
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-13 12:15 ` Biju Das
@ 2025-01-13 12:39 ` Marek Vasut
2025-01-13 13:31 ` Biju Das
0 siblings, 1 reply; 19+ messages in thread
From: Marek Vasut @ 2025-01-13 12:39 UTC (permalink / raw)
To: Biju Das, Marek Vasut, u-boot@lists.denx.de
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/13/25 1:15 PM, Biju Das wrote:
> Hi Marex,
>
> Thanks for the patch
>
>> -----Original Message-----
>> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Marek Vasut
>> Sent: 12 January 2025 22:37
>> Subject: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
>>
>> Add support for starting TFA from U-Boot running in EL3 as part of fitImage boot, so the user can
>> start U-Boot in the highest privilege level on the platform, bundle TFA, Linux, DT into a single
>> fitImage and boot such a bundle as a whole.
>>
>> There are two main benefits of this approach. First is the ability to run U-Boot in EL3, where it has
>> unrestricted access to the entire system and can act as a useful debug tool, as it was always intended
>> to be used. Second is the ability to easily and safely update of any component in the fitImage, be it
>> TFA, Linux or DT.
>
> In this case, who will do switching from secure world to normal world, u-boot?
> Do you have any link to the u-boot patch from secure to normal world switching
> with kernel entry point passed to BL31?
>
> Otherwise, kernel, also will be executing in secure world mode.
See 3/3 , U-Boot runs in EL3 , before starting kernel it jumps into TFA
BL31 , TFA BL31 does its setup and switches from EL3 to EL2 , TFA BL31
returns to U-Boot armv8_switch_to_el2 which checks if this code is
running in EL2 (it is) and does the last few steps before starting
kernel, and then finally jumps to the kernel .
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-13 12:39 ` Marek Vasut
@ 2025-01-13 13:31 ` Biju Das
2025-01-15 11:51 ` Quentin Schulz
0 siblings, 1 reply; 19+ messages in thread
From: Biju Das @ 2025-01-13 13:31 UTC (permalink / raw)
To: Marek Vasut, Marek Vasut, u-boot@lists.denx.de
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
Hi Marex,
> -----Original Message-----
> From: Marek Vasut <marek.vasut@mailbox.org>
> Sent: 13 January 2025 12:40
> Subject: Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
>
> On 1/13/25 1:15 PM, Biju Das wrote:
> > Hi Marex,
> >
> > Thanks for the patch
> >
> >> -----Original Message-----
> >> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Marek Vasut
> >> Sent: 12 January 2025 22:37
> >> Subject: [PATCH 2/3] image: Add support for starting TFA BL31 as
> >> fitImage loadables
> >>
> >> Add support for starting TFA from U-Boot running in EL3 as part of
> >> fitImage boot, so the user can start U-Boot in the highest privilege
> >> level on the platform, bundle TFA, Linux, DT into a single fitImage and boot such a bundle as a
> whole.
> >>
> >> There are two main benefits of this approach. First is the ability to
> >> run U-Boot in EL3, where it has unrestricted access to the entire
> >> system and can act as a useful debug tool, as it was always intendedSecure)
> >> to be used. Second is the ability to easily and safely update of any component in the fitImage, be
> it TFA, Linux or DT.
> >
> > In this case, who will do switching from secure world to normal world, u-boot?
> > Do you have any link to the u-boot patch from secure to normal world
> > switching with kernel entry point passed to BL31?
> >
> > Otherwise, kernel, also will be executing in secure world mode.
> See 3/3 , U-Boot runs in EL3 , before starting kernel it jumps into TFA
> BL31 , TFA BL31 does its setup and switches from EL3 to EL2 , TFA BL31 returns to U-Boot
> armv8_switch_to_el2 which checks if this code is running in EL2 (it is) and does the last few steps
> before starting kernel, and then finally jumps to the kernel .
Thanks for the explanation. I missed the details in 3/3.
BL2(Secure)->U-boot(Secure)->BL31(Secure)-->U-boot(Normal)->Linux Kernel(Normal)
Cheers,
Biju
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-13 13:31 ` Biju Das
@ 2025-01-15 11:51 ` Quentin Schulz
2025-01-18 13:49 ` Marek Vasut
0 siblings, 1 reply; 19+ messages in thread
From: Quentin Schulz @ 2025-01-15 11:51 UTC (permalink / raw)
To: Biju Das, Marek Vasut, Marek Vasut, u-boot@lists.denx.de
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
Hi Marek, Biju,
On 1/13/25 2:31 PM, Biju Das wrote:
> Hi Marex,
>
>> -----Original Message-----
>> From: Marek Vasut <marek.vasut@mailbox.org>
>> Sent: 13 January 2025 12:40
>> Subject: Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
>>
>> On 1/13/25 1:15 PM, Biju Das wrote:
>>> Hi Marex,
>>>
>>> Thanks for the patch
>>>
>>>> -----Original Message-----
>>>> From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Marek Vasut
>>>> Sent: 12 January 2025 22:37
>>>> Subject: [PATCH 2/3] image: Add support for starting TFA BL31 as
>>>> fitImage loadables
>>>>
>>>> Add support for starting TFA from U-Boot running in EL3 as part of
>>>> fitImage boot, so the user can start U-Boot in the highest privilege
>>>> level on the platform, bundle TFA, Linux, DT into a single fitImage and boot such a bundle as a
>> whole.
>>>>
>>>> There are two main benefits of this approach. First is the ability to
>>>> run U-Boot in EL3, where it has unrestricted access to the entire
>>>> system and can act as a useful debug tool, as it was always intendedSecure)
>>>> to be used. Second is the ability to easily and safely update of any component in the fitImage, be
>> it TFA, Linux or DT.
>>>
>>> In this case, who will do switching from secure world to normal world, u-boot?
>>> Do you have any link to the u-boot patch from secure to normal world
>>> switching with kernel entry point passed to BL31?
>>>
>>> Otherwise, kernel, also will be executing in secure world mode.
>> See 3/3 , U-Boot runs in EL3 , before starting kernel it jumps into TFA
>> BL31 , TFA BL31 does its setup and switches from EL3 to EL2 , TFA BL31 returns to U-Boot
>> armv8_switch_to_el2 which checks if this code is running in EL2 (it is) and does the last few steps
>> before starting kernel, and then finally jumps to the kernel .
>
> Thanks for the explanation. I missed the details in 3/3.
>
> BL2(Secure)->U-boot(Secure)->BL31(Secure)-->U-boot(Normal)->Linux Kernel(Normal)
>
If the fit image is missing the TF-A loadable property for example (and
maybe in other corner case scenario?) the kernel will start in EL3
though and fail very early since it needs TF-A BL31 for a few things.
However, part of the kernel code will actually run in EL3 and that could
be enough to mess things up with a carefully crafted kernel image.
Is this actually possible or am I making stuff up? If it is possible,
isn't that an issue?
Currently, this is already possible and has happened a few times already
at my company with people forgetting to bundle TF-A in U-Boot and then
the kernel would boot but stops early (no console output even IIRC). But
the bootloader is not THAT often updated in the field compared to kernel
(especially if coming from distros) which would now allow to store the
TF-A, so this opens an even bigger can of worms? In a way, it allows to
update TF-A likely more securely (which is VERY welcome on Rockchip for
example, where we usually start new SoC bringups with a blob from
Rockchip and then have upstream TF-A catch up a few years later. Having
BL31 part of U-Boot is a huge pain because it is difficult for some
devices to do safe updates of U-Boot) but may introduce some bigger
security issues?
Finally, another question, what happens if we have a U-Boot with bundled
TF-A BL31 AND it tries to boot a fitimage with a TF-A BL31 loadable?
Should we only allow to load tf-a BL31 if running from EL3 (meaning if
in EL2, TF-A is expected to be already running)?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-15 11:51 ` Quentin Schulz
@ 2025-01-18 13:49 ` Marek Vasut
0 siblings, 0 replies; 19+ messages in thread
From: Marek Vasut @ 2025-01-18 13:49 UTC (permalink / raw)
To: Quentin Schulz, Biju Das, Marek Vasut, u-boot@lists.denx.de
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/15/25 12:51 PM, Quentin Schulz wrote:
> Hi Marek, Biju,
Hi,
[...]
>>> See 3/3 , U-Boot runs in EL3 , before starting kernel it jumps into TFA
>>> BL31 , TFA BL31 does its setup and switches from EL3 to EL2 , TFA
>>> BL31 returns to U-Boot
>>> armv8_switch_to_el2 which checks if this code is running in EL2 (it
>>> is) and does the last few steps
>>> before starting kernel, and then finally jumps to the kernel .
>>
>> Thanks for the explanation. I missed the details in 3/3.
>>
>> BL2(Secure)->U-boot(Secure)->BL31(Secure)-->U-boot(Normal)->Linux
>> Kernel(Normal)
>>
>
> If the fit image is missing the TF-A loadable property for example (and
> maybe in other corner case scenario?) the kernel will start in EL3
> though and fail very early since it needs TF-A BL31 for a few things.
Not quite, even if the TFA loadable is not present, the kernel will
still be started through armv8_switch_to_el2() , which will switch the
core into EL2 and then start the kernel. The kernel will however likely
fail to boot because it will attempt to access PSCI via SMC and there
will be nothing there, so it will fail at that point.
There will be a follow up patch for R-Car Gen4, which will extend and
enable the current minimal R-Car Gen4 PSCI support in U-Boot, so even if
you do not bundle TFA into the fitImage, the kernel won't fail to boot
entirely.
With the current R-Car Gen4 PSCI implementation in U-Boot, the kernel
can boot and run on a single CPU core only, because the CPU core start
and stop callbacks are not implemented and not advertised to Linux yet.
Any other SoC that would like to move TFA start after U-Boot start would
also likely have to implement at least minimal PSCI implementation to
provide a safety net for users who do not bundle the TFA BL31 PSCI
provider blob into the fitImage for some reason. The current R-Car Gen4
PSCI implementation is generic enough, that it can act as a template for
such other future SoC specific PSCI implementations.
> However, part of the kernel code will actually run in EL3 and that could
> be enough to mess things up with a carefully crafted kernel image.
>
> Is this actually possible or am I making stuff up? If it is possible,
> isn't that an issue?
>
> Currently, this is already possible and has happened a few times already
> at my company with people forgetting to bundle TF-A in U-Boot and then
> the kernel would boot but stops early (no console output even IIRC). But
> the bootloader is not THAT often updated in the field compared to kernel
> (especially if coming from distros) which would now allow to store the
> TF-A, so this opens an even bigger can of worms?
See above, I think that answers this question.
> In a way, it allows to
> update TF-A likely more securely
That is very much the point of this, yes.
Also, safely update as much as possible in lockstep, for example in case
someone has the idea to extend the TFA PSCI implementation with custom
SMC call handler(s) and make vendor Linux kernel fork depend on those
custom SMC calls for something (*). If the next kernel fork depends on a
different set of custom SMC calls (because stable ABI in such cases may
not be a guarantee) then updating only the kernel may lead to unbootable
system. Worse, updating the bootloader and kernel may lead to kernel
boot failure, AND if (usually seldom updated) recovery system kernel did
not get updated in lockstep with bootloader, recovery system which
depends on the old SMC ABI would also fail to boot, leaving the system
unrecoverable.
If both kernel and the custom TFA implementation are updated and booted
as part of the same fitImage file, the ABI problem goes away.
Also, it allows for easy experimentation with the TFA, you can keep
swapping blobs in and out as needed to test them out.
(*) This is not the case with Renesas to my knowledge , whew !
> (which is VERY welcome on Rockchip for
> example, where we usually start new SoC bringups with a blob from
> Rockchip and then have upstream TF-A catch up a few years later. Having
> BL31 part of U-Boot is a huge pain because it is difficult for some
> devices to do safe updates of U-Boot) but may introduce some bigger
> security issues?
U-Boot will run in EL3 instead of EL2 in this case, which gives it
complete unrestricted access to the entire system. It can act as a debug
tool, the way it was designed to work since the very beginning.
Do you have anything specific in mind here ?
> Finally, another question, what happens if we have a U-Boot with bundled
> TF-A BL31 AND it tries to boot a fitimage with a TF-A BL31 loadable?
It very much depends on the SoC specific TFA BL31 start handler
implementation (see patch 3/3). It is possible to add check in there to
test whether the system is already running in EL2 for example, and if
anything responds to PSCI version SMC call, and if so, skip starting the
TFA again.
I don't think TFA BL31 can be started in EL2 in any case.
> Should we only allow to load tf-a BL31 if running from EL3 (meaning if
> in EL2, TF-A is expected to be already running)?
That's for the SoC specific handler to decide, see above.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-12 22:36 ` [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables Marek Vasut
2025-01-13 12:15 ` Biju Das
@ 2025-01-15 1:13 ` Tom Rini
2025-01-29 17:10 ` Quentin Schulz
2 siblings, 0 replies; 19+ messages in thread
From: Tom Rini @ 2025-01-15 1:13 UTC (permalink / raw)
To: Marek Vasut
Cc: u-boot, Andre Przywara, Caleb Connolly, Igor Opaniuk,
Ilias Apalodimas, Julien Masson, Mattijs Korpershoek,
Maxim Moskalets, Michael Walle, Nobuhiro Iwamatsu,
Patrick Rudolph, Paul Barker, Paul-Erwan Rio, Peter Hoyes,
Raymond Mao, Sam Protsenko, Simon Glass, Sughosh Ganu
[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]
On Sun, Jan 12, 2025 at 11:36:58PM +0100, Marek Vasut wrote:
> Add support for starting TFA from U-Boot running in EL3 as part of
> fitImage boot, so the user can start U-Boot in the highest privilege
> level on the platform, bundle TFA, Linux, DT into a single fitImage
> and boot such a bundle as a whole.
>
> There are two main benefits of this approach. First is the ability
> to run U-Boot in EL3, where it has unrestricted access to the entire
> system and can act as a useful debug tool, as it was always intended
> to be used. Second is the ability to easily and safely update of any
> component in the fitImage, be it TFA, Linux or DT.
>
> The boot process is similar to regular Linux with DT fitImage boot
> process, except the TFA has to be bundled into the fitImage. For the
> bundling instructions, see below. The TFA is started as a 'loadables'
> with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
> handling implemented in board code, and performing the handoff and
> boot in case the TFA was loaded.
>
> The loadables handler is optional and meant to set up any sort of
> handoff structures used by the TFA BL31 or perform any other setup
> that is needed by the blob. The custom armv8_switch_to_el2_prep()
> has to implement the jump to TFA BL31 with return to U-Boot just
> before booting the Linux kernel.
>
> Example fitImage image and configuration section:
>
> /dts-v1/;
>
> / {
> description = "Linux kernel with FDT blob and TFA BL31";
>
> images {
> kernel-1 { ... };
> fdt-1 { ... };
> atf-1 { /* This is the TFA BL31 image */
> description = "TFA BL31";
> data = /incbin/("../build/plat/release/bl31.bin");
> type = "tfa-bl31";
> arch = "arm64";
> os = "arm-trusted-firmware";
> compression = "none";
> load = <0x46400000>;
> entry = <0x46400000>;
> };
> };
>
> configurations {
> default = "conf-1";
> conf-1 {
> description = "Boot Linux";
> kernel = "kernel-1";
> fdt = "fdt-1";
> loadables = "atf-1"; /* This is the TFA BL31 loadable */
> };
> };
> };
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-12 22:36 ` [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables Marek Vasut
2025-01-13 12:15 ` Biju Das
2025-01-15 1:13 ` Tom Rini
@ 2025-01-29 17:10 ` Quentin Schulz
2025-01-29 17:38 ` Marek Vasut
2 siblings, 1 reply; 19+ messages in thread
From: Quentin Schulz @ 2025-01-29 17:10 UTC (permalink / raw)
To: Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
Hi Marek,
On 1/12/25 11:36 PM, Marek Vasut wrote:
> Add support for starting TFA from U-Boot running in EL3 as part of
> fitImage boot, so the user can start U-Boot in the highest privilege
> level on the platform, bundle TFA, Linux, DT into a single fitImage
> and boot such a bundle as a whole.
>
> There are two main benefits of this approach. First is the ability
> to run U-Boot in EL3, where it has unrestricted access to the entire
> system and can act as a useful debug tool, as it was always intended
> to be used. Second is the ability to easily and safely update of any
> component in the fitImage, be it TFA, Linux or DT.
>
> The boot process is similar to regular Linux with DT fitImage boot
> process, except the TFA has to be bundled into the fitImage. For the
> bundling instructions, see below. The TFA is started as a 'loadables'
> with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
> handling implemented in board code, and performing the handoff and
> boot in case the TFA was loaded.
>
> The loadables handler is optional and meant to set up any sort of
> handoff structures used by the TFA BL31 or perform any other setup
> that is needed by the blob. The custom armv8_switch_to_el2_prep()
> has to implement the jump to TFA BL31 with return to U-Boot just
> before booting the Linux kernel.
>
> Example fitImage image and configuration section:
>
> /dts-v1/;
>
> / {
> description = "Linux kernel with FDT blob and TFA BL31";
>
> images {
> kernel-1 { ... };
> fdt-1 { ... };
> atf-1 { /* This is the TFA BL31 image */
> description = "TFA BL31";
> data = /incbin/("../build/plat/release/bl31.bin");
> type = "tfa-bl31";
This would need to be added to the ITS spec, c.f.
https://fitspec.osfw.foundation/
> arch = "arm64";
> os = "arm-trusted-firmware";
> compression = "none";
> load = <0x46400000>;
> entry = <0x46400000>;
> };
> };
>
> configurations {
> default = "conf-1";
> conf-1 {
> description = "Boot Linux";
> kernel = "kernel-1";
> fdt = "fdt-1";
> loadables = "atf-1"; /* This is the TFA BL31 loadable */
We have some special stuff around TF-A (and TEE for that matter IIRC) on
Rockchip. The ELF is split into multiple binaries to load at different
addresses:
rk3399:
Image 1 (atf-1)
Description: ARM Trusted Firmware
Created: Wed Jan 29 16:24:16 2025
Type: Firmware
Compression: uncompressed
Data Size: 143438 Bytes = 140.08 KiB = 0.14 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0x00040000
Hash algo: sha256
Hash value:
44285ea3a629cceee42a5fbfe838b6193e7c9a2f6643b0496dae617e2f7e2e8a
Image 2 (atf-2)
Description: ARM Trusted Firmware
Created: Wed Jan 29 16:24:16 2025
Type: Firmware
Compression: uncompressed
Data Size: 8024 Bytes = 7.84 KiB = 0.01 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0xff3b0000
Hash algo: sha256
Hash value:
7da49d2642204ded0a8eff093ae5c0e7300cfb18427d7a3e2f4e4cb227e4c2e9
Image 3 (atf-3)
Description: ARM Trusted Firmware
Created: Wed Jan 29 16:24:16 2025
Type: Firmware
Compression: uncompressed
Data Size: 4096 Bytes = 4.00 KiB = 0.00 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0xff8c0000
Hash algo: sha256
Hash value:
52c626d345ceeab61d8ede858a191834843f234cb4c2d2145546fd824e09c815
Image 4 (atf-4)
Description: ARM Trusted Firmware
Created: Wed Jan 29 16:24:16 2025
Type: Firmware
Compression: uncompressed
Data Size: 4096 Bytes = 4.00 KiB = 0.00 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0xff8c1000
Hash algo: sha256
Hash value:
50a7da66c26f838220d3befe84dd070988d238fa8abb34d1342815dae1083ec6
Image 5 (atf-5)
Description: ARM Trusted Firmware
Created: Wed Jan 29 16:24:16 2025
Type: Firmware
Compression: uncompressed
Data Size: 0 Bytes = 0.00 KiB = 0.00 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0xff8c2000
Hash algo: sha256
Hash value:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Image 6 (fdt-1)
Description: fdt-rockchip/rk3399-puma-haikou
Created: Wed Jan 29 16:24:16 2025
Type: Flat Device Tree
Compression: uncompressed
Data Size: 93264 Bytes = 91.08 KiB = 0.09 MiB
Architecture: Unknown Architecture
Hash algo: sha256
Hash value:
9bcaaba8ea986042273421510acb76d5043bde550e463e80c2ee306239864f4c
Default Configuration: 'config-1'
Configuration 0 (config-1)
Description: rockchip/rk3399-puma-haikou.dtb
Kernel: unavailable
Firmware: atf-1
FDT: fdt-1
Loadables: u-boot
atf-2
atf-3
atf-4
atf-5
px30:
Image 1 (atf-1)
Description: ARM Trusted Firmware
Created: Wed Jan 29 17:06:59 2025
Type: Firmware
Compression: uncompressed
Data Size: 102526 Bytes = 100.12 KiB = 0.10 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0x00040000
Hash algo: sha256
Hash value:
d3eb0776f5e1628eaaa38355992bc8a4cc8b12de565ebd6098897269e70345b3
Image 2 (atf-2)
Description: ARM Trusted Firmware
Created: Wed Jan 29 17:06:59 2025
Type: Firmware
Compression: uncompressed
Data Size: 112 Bytes = 0.11 KiB = 0.00 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0xff020000
Hash algo: sha256
Hash value:
19968b2d18472c485c02be72c609c2e9cc5dc4ea7993b86f462a788d109977d6
Image 3 (fdt-1)
Description: fdt-rockchip/px30-ringneck-haikou
Created: Wed Jan 29 17:06:59 2025
Type: Flat Device Tree
Compression: uncompressed
Data Size: 50032 Bytes = 48.86 KiB = 0.05 MiB
Architecture: Unknown Architecture
Hash algo: sha256
Hash value:
f8416b75b2c0a16fd4599f47a4b24d763eb1e2dc0fdaac597510f5b907575c4d
Default Configuration: 'config-1'
Configuration 0 (config-1)
Description: rockchip/px30-ringneck-haikou.dtb
Kernel: unavailable
Firmware: atf-1
FDT: fdt-1
Loadables: u-boot
atf-2
rk3588:
Image 1 (atf-1)
Description: ARM Trusted Firmware
Created: Wed Jan 29 17:08:54 2025
Type: Firmware
Compression: uncompressed
Data Size: 204860 Bytes = 200.06 KiB = 0.20 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0x00040000
Hash algo: sha256
Hash value:
7612223b82b911a56f044a2be63befd1e0d47f9579c50e5b59ca62f12361912d
Image 2 (atf-2)
Description: ARM Trusted Firmware
Created: Wed Jan 29 17:08:54 2025
Type: Firmware
Compression: uncompressed
Data Size: 24576 Bytes = 24.00 KiB = 0.02 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0x000f0000
Hash algo: sha256
Hash value:
b2af21b50499777f862cc9d8d6ca9707248694b739badbe875e3b6834ae77e0d
Image 3 (atf-3)
Description: ARM Trusted Firmware
Created: Wed Jan 29 17:08:54 2025
Type: Firmware
Compression: uncompressed
Data Size: 36864 Bytes = 36.00 KiB = 0.04 MiB
Architecture: AArch64
OS: ARM Trusted Firmware
Load Address: 0xff100000
Hash algo: sha256
Hash value:
70505bb764db81a665c8bba4953d804ed9eab580d5428888a4436121eff11c50
Image 4 (fdt-1)
Description: fdt-rockchip/rk3588-tiger-haikou
Created: Wed Jan 29 17:08:54 2025
Type: Flat Device Tree
Compression: uncompressed
Data Size: 115080 Bytes = 112.38 KiB = 0.11 MiB
Architecture: Unknown Architecture
Hash algo: sha256
Hash value:
c78f6f09dacfaf504d95d8f7d65ab8e0150b9014f033c5aaca85e45448fe177d
Default Configuration: 'config-1'
Configuration 0 (config-1)
Description: rockchip/rk3588-tiger-haikou.dtb
Kernel: unavailable
Firmware: atf-1
FDT: fdt-1
Loadables: u-boot
atf-2
atf-3
I assume this would be supported as well and we would "just" need some
sort of SoC-specific implementation of what was added in patch 1 of this
series? Is this what you're recommending? We would then identify which
part of the binary it is based on the hardcoded load address instead of
reading the load address from the ITS. Or should we think of a way of
identifying them directly inside the ITS with some property for example?
Otherwise a global remark on that feature is I believe it may increase
exposure to exploits. This means U-Boot will happily run anything
provided in EL3. E.g. imagine I provide a script in the ITS which U-Boot
loads and executes before loading the kernel, fdt and loadables. Let's
imagine this is sideloading (we even have some wget support now in
U-Boot so not too far fetched) some app to keep running in EL3 after the
kernel has booted. Or modify registers only accessible from EL3. Now you
better be even more careful about what you're booting from your
linux.itb. Is this a correct interpretation of the situation?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-29 17:10 ` Quentin Schulz
@ 2025-01-29 17:38 ` Marek Vasut
2025-01-29 17:51 ` Quentin Schulz
0 siblings, 1 reply; 19+ messages in thread
From: Marek Vasut @ 2025-01-29 17:38 UTC (permalink / raw)
To: Quentin Schulz, Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/29/25 6:10 PM, Quentin Schulz wrote:
> Hi Marek,
Hi,
> On 1/12/25 11:36 PM, Marek Vasut wrote:
>> Add support for starting TFA from U-Boot running in EL3 as part of
>> fitImage boot, so the user can start U-Boot in the highest privilege
>> level on the platform, bundle TFA, Linux, DT into a single fitImage
>> and boot such a bundle as a whole.
>>
>> There are two main benefits of this approach. First is the ability
>> to run U-Boot in EL3, where it has unrestricted access to the entire
>> system and can act as a useful debug tool, as it was always intended
>> to be used. Second is the ability to easily and safely update of any
>> component in the fitImage, be it TFA, Linux or DT.
>>
>> The boot process is similar to regular Linux with DT fitImage boot
>> process, except the TFA has to be bundled into the fitImage. For the
>> bundling instructions, see below. The TFA is started as a 'loadables'
>> with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
>> handling implemented in board code, and performing the handoff and
>> boot in case the TFA was loaded.
>>
>> The loadables handler is optional and meant to set up any sort of
>> handoff structures used by the TFA BL31 or perform any other setup
>> that is needed by the blob. The custom armv8_switch_to_el2_prep()
>> has to implement the jump to TFA BL31 with return to U-Boot just
>> before booting the Linux kernel.
>>
>> Example fitImage image and configuration section:
>>
>> /dts-v1/;
>>
>> / {
>> description = "Linux kernel with FDT blob and TFA BL31";
>>
>> images {
>> kernel-1 { ... };
>> fdt-1 { ... };
>> atf-1 { /* This is the TFA BL31 image */
>> description = "TFA BL31";
>> data = /incbin/("../build/plat/release/bl31.bin");
>> type = "tfa-bl31";
>
> This would need to be added to the ITS spec, c.f. https://
> fitspec.osfw.foundation/
Where does one do that ?
>> arch = "arm64";
>> os = "arm-trusted-firmware";
>> compression = "none";
>> load = <0x46400000>;
>> entry = <0x46400000>;
>> };
>> };
>>
>> configurations {
>> default = "conf-1";
>> conf-1 {
>> description = "Boot Linux";
>> kernel = "kernel-1";
>> fdt = "fdt-1";
>> loadables = "atf-1"; /* This is the TFA BL31 loadable */
>
> We have some special stuff around TF-A (and TEE for that matter IIRC) on
> Rockchip. The ELF is split into multiple binaries to load at different
> addresses:
[...]
> Loadables: u-boot
> atf-2
> atf-3
>
> I assume this would be supported as well and we would "just" need some
> sort of SoC-specific implementation of what was added in patch 1 of this
> series?
Yes, I think so.
> Is this what you're recommending? We would then identify which
> part of the binary it is based on the hardcoded load address instead of
> reading the load address from the ITS. Or should we think of a way of
> identifying them directly inside the ITS with some property for example?
Maybe try and prototype this loading of TFA for Rockchip and see how
well it fits first (if at all), and then we can decide on the
integration later?
> Otherwise a global remark on that feature is I believe it may increase
> exposure to exploits. This means U-Boot will happily run anything
> provided in EL3. E.g. imagine I provide a script in the ITS which U-Boot
> loads and executes before loading the kernel, fdt and loadables. Let's
> imagine this is sideloading (we even have some wget support now in U-
> Boot so not too far fetched) some app to keep running in EL3 after the
> kernel has booted. Or modify registers only accessible from EL3. Now you
> better be even more careful about what you're booting from your
> linux.itb. Is this a correct interpretation of the situation?
You have freedom to do whatever you want with no restrictions, for
example shoot yourself in the leg by not authenticating random scripts
up front and running whatever unknown stuff, sure. That is not a bad thing.
Running U-Boot in EL2 on top of non-free blobs is not any better, rather
the opposite I think.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-29 17:38 ` Marek Vasut
@ 2025-01-29 17:51 ` Quentin Schulz
2025-07-21 21:43 ` Marek Vasut
0 siblings, 1 reply; 19+ messages in thread
From: Quentin Schulz @ 2025-01-29 17:51 UTC (permalink / raw)
To: Marek Vasut, Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/29/25 6:38 PM, Marek Vasut wrote:
> On 1/29/25 6:10 PM, Quentin Schulz wrote:
>> Hi Marek,
>
> Hi,
>
>> On 1/12/25 11:36 PM, Marek Vasut wrote:
>>> Add support for starting TFA from U-Boot running in EL3 as part of
>>> fitImage boot, so the user can start U-Boot in the highest privilege
>>> level on the platform, bundle TFA, Linux, DT into a single fitImage
>>> and boot such a bundle as a whole.
>>>
>>> There are two main benefits of this approach. First is the ability
>>> to run U-Boot in EL3, where it has unrestricted access to the entire
>>> system and can act as a useful debug tool, as it was always intended
>>> to be used. Second is the ability to easily and safely update of any
>>> component in the fitImage, be it TFA, Linux or DT.
>>>
>>> The boot process is similar to regular Linux with DT fitImage boot
>>> process, except the TFA has to be bundled into the fitImage. For the
>>> bundling instructions, see below. The TFA is started as a 'loadables'
>>> with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
>>> handling implemented in board code, and performing the handoff and
>>> boot in case the TFA was loaded.
>>>
>>> The loadables handler is optional and meant to set up any sort of
>>> handoff structures used by the TFA BL31 or perform any other setup
>>> that is needed by the blob. The custom armv8_switch_to_el2_prep()
>>> has to implement the jump to TFA BL31 with return to U-Boot just
>>> before booting the Linux kernel.
>>>
>>> Example fitImage image and configuration section:
>>>
>>> /dts-v1/;
>>>
>>> / {
>>> description = "Linux kernel with FDT blob and TFA BL31";
>>>
>>> images {
>>> kernel-1 { ... };
>>> fdt-1 { ... };
>>> atf-1 { /* This is the TFA BL31 image */
>>> description = "TFA BL31";
>>> data = /incbin/("../build/plat/release/bl31.bin");
>>> type = "tfa-bl31";
>>
>> This would need to be added to the ITS spec, c.f. https://
>> fitspec.osfw.foundation/
>
> Where does one do that ?
>
https://github.com/open-source-firmware/flat-image-tree I guess?
[...]
>> Is this what you're recommending? We would then identify which part of
>> the binary it is based on the hardcoded load address instead of
>> reading the load address from the ITS. Or should we think of a way of
>> identifying them directly inside the ITS with some property for example?
>
> Maybe try and prototype this loading of TFA for Rockchip and see how
> well it fits first (if at all), and then we can decide on the
> integration later?
>
Fair point. Not sure if I'll have time to look into this soon though.
>> Otherwise a global remark on that feature is I believe it may increase
>> exposure to exploits. This means U-Boot will happily run anything
>> provided in EL3. E.g. imagine I provide a script in the ITS which U-
>> Boot loads and executes before loading the kernel, fdt and loadables.
>> Let's imagine this is sideloading (we even have some wget support now
>> in U- Boot so not too far fetched) some app to keep running in EL3
>> after the kernel has booted. Or modify registers only accessible from
>> EL3. Now you better be even more careful about what you're booting
>> from your linux.itb. Is this a correct interpretation of the situation?
> You have freedom to do whatever you want with no restrictions, for
> example shoot yourself in the leg by not authenticating random scripts
> up front and running whatever unknown stuff, sure. That is not a bad thing.
>
> Running U-Boot in EL2 on top of non-free blobs is not any better, rather
> the opposite I think.
Up to distros to implement the proper security measures then :)
Cheers,
Quentin
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables
2025-01-29 17:51 ` Quentin Schulz
@ 2025-07-21 21:43 ` Marek Vasut
0 siblings, 0 replies; 19+ messages in thread
From: Marek Vasut @ 2025-07-21 21:43 UTC (permalink / raw)
To: Quentin Schulz, Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/29/25 6:51 PM, Quentin Schulz wrote:
>>> This would need to be added to the ITS spec, c.f. https://
>>> fitspec.osfw.foundation/
>>
>> Where does one do that ?
>>
>
> https://github.com/open-source-firmware/flat-image-tree I guess?
Thank you for adding the entry.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support
2025-01-12 22:36 [PATCH 1/3] arm64: Add late jump to kernel board hook Marek Vasut
2025-01-12 22:36 ` [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables Marek Vasut
@ 2025-01-12 22:36 ` Marek Vasut
2025-01-29 16:02 ` Quentin Schulz
2025-01-15 1:13 ` [PATCH 1/3] arm64: Add late jump to kernel board hook Tom Rini
2 siblings, 1 reply; 19+ messages in thread
From: Marek Vasut @ 2025-01-12 22:36 UTC (permalink / raw)
To: u-boot
Cc: Marek Vasut, Andre Przywara, Caleb Connolly, Igor Opaniuk,
Ilias Apalodimas, Julien Masson, Mattijs Korpershoek,
Maxim Moskalets, Michael Walle, Nobuhiro Iwamatsu,
Patrick Rudolph, Paul Barker, Paul-Erwan Rio, Peter Hoyes,
Raymond Mao, Sam Protsenko, Simon Glass, Sughosh Ganu, Tom Rini
Implement custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling in case the TFA was loaded. The loadables handler sets up custom
handoff structure used by Renesas TFA fork in fixed location in DRAM and
indicates the TFA has been loaded.
The custom armv8_switch_to_el2_prep() handling tests whether the TFA BL31
was previously loaded and the custom handoff structure was set up, and if
so, jumps to TFA BL31 which switches from EL3 to EL2 and then returns to
U-Boot just past bl in armv8_switch_to_el2() to finish starting the Linux
kernel.
The jump to Linux through TFA works in such a way that the custom
armv8_switch_to_el2_prep() handler configures the custom handoff structure
such that the target jump address of the TFA BL31 on exit is set to the
armv8_switch_to_el2() + 4, which is just past the bl, and just before the
U-Boot code which implements the Linux kernel boot from either EL. The
registers passed through the TFA BL31 are all the registers passed into
armv8_switch_to_el2_prep() to assure maximum compatibility with all the
boot modes. The armv8_switch_to_el2_prep() handler jumps to the TFA BL31,
which does its setup, drops EL from EL3 to EL2 and finally jumps to the
armv8_switch_to_el2() + 4 entry point, which then allows U-Boot to boot
the Linux kernel the usual way.
In order to build suitable kernel fitImage, build TFA first, temporarily
from downstream repository:
remote: https://github.com/renesas-rcar/arm-trusted-firmware.git
branch: rcar_gen4_v2.7_v4x
```
$ git clean -fqdx
$ MBEDTLS_DIR=/path/to/mbedtls/ make -j$(nproc) bl31 \
PLAT=rcar_gen4 ARCH=aarch64 LSI=V4H SPD=none \
CTX_INCLUDE_AARCH32_REGS=0 MBEDTLS_COMMON_MK=1 \
PTP_NONSECURE_ACCESS=1 LOG_LEVEL=20 DEBUG=0 \
ENABLE_ASSERTIONS=0 E=0
```
Build Linux kernel Image and device tree from current mainline Linux
kernel repository, obtain 'Image' and 'r8a779g0-white-hawk.dtb' .
Bundle the files together using provided fit-image.its fitImage description:
```
$ mkimage -f fit-image.its fitImage
```
To start the kernel fiImage generated in previous step, load fitImage
to DRAM and use the 'bootm' command to start it:
=> load 0x58000000 ... fitImage && bootm 0x58000000
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Caleb Connolly <caleb.connolly@linaro.org>
Cc: Igor Opaniuk <igor.opaniuk@gmail.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Julien Masson <jmasson@baylibre.com>
Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Cc: Maxim Moskalets <maximmosk4@gmail.com>
Cc: Michael Walle <mwalle@kernel.org>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
Cc: Paul Barker <paul.barker.ct@bp.renesas.com>
Cc: Paul-Erwan Rio <paulerwan.rio@gmail.com>
Cc: Peter Hoyes <Peter.Hoyes@arm.com>
Cc: Raymond Mao <raymond.mao@linaro.org>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Sughosh Ganu <sughosh.ganu@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de
---
board/renesas/common/gen4-common.c | 118 +++++++++++++++++++++++++++++
1 file changed, 118 insertions(+)
diff --git a/board/renesas/common/gen4-common.c b/board/renesas/common/gen4-common.c
index 52a0639073b..c7f3f9a30ab 100644
--- a/board/renesas/common/gen4-common.c
+++ b/board/renesas/common/gen4-common.c
@@ -7,11 +7,13 @@
#include <asm/arch/renesas.h>
#include <asm/arch/sys_proto.h>
+#include <asm/armv8/mmu.h>
#include <asm/global_data.h>
#include <asm/io.h>
#include <asm/mach-types.h>
#include <asm/processor.h>
#include <asm/system.h>
+#include <image.h>
#include <linux/errno.h>
#define RST_BASE 0xE6160000 /* Domain0 */
@@ -88,3 +90,119 @@ int ft_board_setup(void *blob, struct bd_info *bd)
{
return 0;
}
+
+/* R-Car Gen4 TFA BL31 handoff structure and handling. */
+struct param_header {
+ u8 type;
+ u8 version;
+ u16 size;
+ u32 attr;
+};
+
+struct tfa_image_info {
+ struct param_header h;
+ uintptr_t image_base;
+ u32 image_size;
+ u32 image_max_size;
+};
+
+struct aapcs64_params {
+ u64 arg0;
+ u64 arg1;
+ u64 arg2;
+ u64 arg3;
+ u64 arg4;
+ u64 arg5;
+ u64 arg6;
+ u64 arg7;
+};
+
+struct entry_point_info {
+ struct param_header h;
+ uintptr_t pc;
+ u32 spsr;
+ struct aapcs64_params args;
+};
+
+struct bl2_to_bl31_params_mem {
+ struct tfa_image_info bl32_image_info;
+ struct tfa_image_info bl33_image_info;
+ struct entry_point_info bl33_ep_info;
+ struct entry_point_info bl32_ep_info;
+};
+
+/* Default jump address, return to U-Boot */
+#define BL33_BASE 0x44100000
+/* Custom parameters address passed to TFA by ICUMXA loader */
+#define PARAMS_BASE 0x46422200
+
+/* Usually such a structure is produced by ICUMXA and passed in at 0x46422200 */
+static const struct bl2_to_bl31_params_mem blinfo_template = {
+ .bl33_ep_info.h.type = 1, /* PARAM_EP */
+ .bl33_ep_info.h.version = 2, /* Version 2 */
+ .bl33_ep_info.h.size = sizeof(struct entry_point_info),
+ .bl33_ep_info.h.attr = 0x81, /* Executable | Non-Secure */
+ .bl33_ep_info.spsr = 0x2c9, /* Mode=EL2, SP=ELX, Exceptions=OFF */
+ .bl33_ep_info.pc = BL33_BASE,
+
+ .bl33_image_info.h.type = 1, /* PARAM_EP */
+ .bl33_image_info.h.version = 2, /* Version 2 */
+ .bl33_image_info.h.size = sizeof(struct image_info),
+ .bl33_image_info.h.attr = 0,
+ .bl33_image_info.image_base = BL33_BASE,
+};
+
+static bool tfa_bl31_image_loaded;
+static ulong tfa_bl31_image_addr;
+
+static void tfa_bl31_image_process(ulong image, size_t size)
+{
+ /* Custom parameters address passed to TFA by ICUMXA loader */
+ struct bl2_to_bl31_params_mem *blinfo = (struct bl2_to_bl31_params_mem *)PARAMS_BASE;
+
+ /* Clear a page and copy template */
+ memset((void *)PARAMS_BASE, 0, PAGE_SIZE);
+ memcpy(blinfo, &blinfo_template, sizeof(*blinfo));
+ tfa_bl31_image_addr = image;
+ tfa_bl31_image_loaded = true;
+}
+
+U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TFA_BL31, tfa_bl31_image_process);
+
+void armv8_switch_to_el2_prep(u64 args, u64 mach_nr, u64 fdt_addr,
+ u64 arg4, u64 entry_point, u64 es_flag)
+{
+ typedef void __noreturn (*image_entry_noargs_t)(void);
+ image_entry_noargs_t image_entry =
+ (image_entry_noargs_t)(void *)tfa_bl31_image_addr;
+ struct bl2_to_bl31_params_mem *blinfo =
+ (struct bl2_to_bl31_params_mem *)PARAMS_BASE;
+
+ /*
+ * Destination address in arch/arm/cpu/armv8/transition.S
+ * right past the first bl in armv8_switch_to_el2() to let
+ * the rest of U-Boot pre-Linux code run. The code does run
+ * without stack pointer!
+ */
+ const u64 ep = ((u64)(uintptr_t)&armv8_switch_to_el2) + 4;
+
+ /* If TFA BL31 was not part of the fitImage, do regular boot. */
+ if (!tfa_bl31_image_loaded)
+ return;
+
+ /*
+ * Set up kernel entry point and parameters:
+ * x0 is FDT address, x1..x3 must be 0
+ */
+ blinfo->bl33_ep_info.pc = ep;
+ blinfo->bl33_ep_info.args.arg0 = args;
+ blinfo->bl33_ep_info.args.arg1 = mach_nr;
+ blinfo->bl33_ep_info.args.arg2 = fdt_addr;
+ blinfo->bl33_ep_info.args.arg3 = arg4;
+ blinfo->bl33_ep_info.args.arg4 = entry_point;
+ blinfo->bl33_ep_info.args.arg5 = es_flag;
+ blinfo->bl33_image_info.image_base = ep;
+
+ /* Jump to TFA BL31 */
+ image_entry();
+}
--
2.45.2
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support
2025-01-12 22:36 ` [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support Marek Vasut
@ 2025-01-29 16:02 ` Quentin Schulz
2025-01-29 16:28 ` Quentin Schulz
2025-01-29 17:00 ` Marek Vasut
0 siblings, 2 replies; 19+ messages in thread
From: Quentin Schulz @ 2025-01-29 16:02 UTC (permalink / raw)
To: Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
Hi Marek,
On 1/12/25 11:36 PM, Marek Vasut wrote:
> Implement custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
> handling in case the TFA was loaded. The loadables handler sets up custom
> handoff structure used by Renesas TFA fork in fixed location in DRAM and
> indicates the TFA has been loaded.
>
> The custom armv8_switch_to_el2_prep() handling tests whether the TFA BL31
> was previously loaded and the custom handoff structure was set up, and if
> so, jumps to TFA BL31 which switches from EL3 to EL2 and then returns to
> U-Boot just past bl in armv8_switch_to_el2() to finish starting the Linux
> kernel.
>
> The jump to Linux through TFA works in such a way that the custom
> armv8_switch_to_el2_prep() handler configures the custom handoff structure
> such that the target jump address of the TFA BL31 on exit is set to the
> armv8_switch_to_el2() + 4, which is just past the bl, and just before the
> U-Boot code which implements the Linux kernel boot from either EL. The
> registers passed through the TFA BL31 are all the registers passed into
> armv8_switch_to_el2_prep() to assure maximum compatibility with all the
> boot modes. The armv8_switch_to_el2_prep() handler jumps to the TFA BL31,
> which does its setup, drops EL from EL3 to EL2 and finally jumps to the
> armv8_switch_to_el2() + 4 entry point, which then allows U-Boot to boot
> the Linux kernel the usual way.
>
> In order to build suitable kernel fitImage, build TFA first, temporarily
> from downstream repository:
> remote: https://github.com/renesas-rcar/arm-trusted-firmware.git
> branch: rcar_gen4_v2.7_v4x
>
> ```
> $ git clean -fqdx
> $ MBEDTLS_DIR=/path/to/mbedtls/ make -j$(nproc) bl31 \
> PLAT=rcar_gen4 ARCH=aarch64 LSI=V4H SPD=none \
> CTX_INCLUDE_AARCH32_REGS=0 MBEDTLS_COMMON_MK=1 \
> PTP_NONSECURE_ACCESS=1 LOG_LEVEL=20 DEBUG=0 \
> ENABLE_ASSERTIONS=0 E=0
> ```
>
> Build Linux kernel Image and device tree from current mainline Linux
> kernel repository, obtain 'Image' and 'r8a779g0-white-hawk.dtb' .
>
> Bundle the files together using provided fit-image.its fitImage description:
> ```
> $ mkimage -f fit-image.its fitImage
> ```
>
> To start the kernel fiImage generated in previous step, load fitImage
> to DRAM and use the 'bootm' command to start it:
> => load 0x58000000 ... fitImage && bootm 0x58000000
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Caleb Connolly <caleb.connolly@linaro.org>
> Cc: Igor Opaniuk <igor.opaniuk@gmail.com>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: Julien Masson <jmasson@baylibre.com>
> Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
> Cc: Maxim Moskalets <maximmosk4@gmail.com>
> Cc: Michael Walle <mwalle@kernel.org>
> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
> Cc: Paul Barker <paul.barker.ct@bp.renesas.com>
> Cc: Paul-Erwan Rio <paulerwan.rio@gmail.com>
> Cc: Peter Hoyes <Peter.Hoyes@arm.com>
> Cc: Raymond Mao <raymond.mao@linaro.org>
> Cc: Sam Protsenko <semen.protsenko@linaro.org>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Sughosh Ganu <sughosh.ganu@linaro.org>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: u-boot@lists.denx.de
> ---
> board/renesas/common/gen4-common.c | 118 +++++++++++++++++++++++++++++
> 1 file changed, 118 insertions(+)
>
> diff --git a/board/renesas/common/gen4-common.c b/board/renesas/common/gen4-common.c
> index 52a0639073b..c7f3f9a30ab 100644
> --- a/board/renesas/common/gen4-common.c
> +++ b/board/renesas/common/gen4-common.c
> @@ -7,11 +7,13 @@
>
> #include <asm/arch/renesas.h>
> #include <asm/arch/sys_proto.h>
> +#include <asm/armv8/mmu.h>
> #include <asm/global_data.h>
> #include <asm/io.h>
> #include <asm/mach-types.h>
> #include <asm/processor.h>
> #include <asm/system.h>
> +#include <image.h>
> #include <linux/errno.h>
>
> #define RST_BASE 0xE6160000 /* Domain0 */
> @@ -88,3 +90,119 @@ int ft_board_setup(void *blob, struct bd_info *bd)
> {
> return 0;
> }
> +
> +/* R-Car Gen4 TFA BL31 handoff structure and handling. */
> +struct param_header {
> + u8 type;
> + u8 version;
> + u16 size;
> + u32 attr;
> +};
> +
> +struct tfa_image_info {
> + struct param_header h;
> + uintptr_t image_base;
> + u32 image_size;
> + u32 image_max_size;
> +};
> +
> +struct aapcs64_params {
> + u64 arg0;
> + u64 arg1;
> + u64 arg2;
> + u64 arg3;
> + u64 arg4;
> + u64 arg5;
> + u64 arg6;
> + u64 arg7;
> +};
> +
> +struct entry_point_info {
> + struct param_header h;
> + uintptr_t pc;
> + u32 spsr;
> + struct aapcs64_params args;
> +};
> +
> +struct bl2_to_bl31_params_mem {
> + struct tfa_image_info bl32_image_info;
> + struct tfa_image_info bl33_image_info;
> + struct entry_point_info bl33_ep_info;
> + struct entry_point_info bl32_ep_info;
> +};
> +
> +/* Default jump address, return to U-Boot */
> +#define BL33_BASE 0x44100000
> +/* Custom parameters address passed to TFA by ICUMXA loader */
> +#define PARAMS_BASE 0x46422200
> +
Shouldn't we rather set those as offset compared to the load/entry
address passed in the ITS?
> +/* Usually such a structure is produced by ICUMXA and passed in at 0x46422200 */
> +static const struct bl2_to_bl31_params_mem blinfo_template = {
> + .bl33_ep_info.h.type = 1, /* PARAM_EP */
> + .bl33_ep_info.h.version = 2, /* Version 2 */
> + .bl33_ep_info.h.size = sizeof(struct entry_point_info),
> + .bl33_ep_info.h.attr = 0x81, /* Executable | Non-Secure */
> + .bl33_ep_info.spsr = 0x2c9, /* Mode=EL2, SP=ELX, Exceptions=OFF */
> + .bl33_ep_info.pc = BL33_BASE,
> +
> + .bl33_image_info.h.type = 1, /* PARAM_EP */
> + .bl33_image_info.h.version = 2, /* Version 2 */
> + .bl33_image_info.h.size = sizeof(struct image_info),
> + .bl33_image_info.h.attr = 0,
> + .bl33_image_info.image_base = BL33_BASE,
> +};
> +
> +static bool tfa_bl31_image_loaded;
> +static ulong tfa_bl31_image_addr;
> +
> +static void tfa_bl31_image_process(ulong image, size_t size)
> +{
> + /* Custom parameters address passed to TFA by ICUMXA loader */
> + struct bl2_to_bl31_params_mem *blinfo = (struct bl2_to_bl31_params_mem *)PARAMS_BASE;
> +
> + /* Clear a page and copy template */
> + memset((void *)PARAMS_BASE, 0, PAGE_SIZE);
> + memcpy(blinfo, &blinfo_template, sizeof(*blinfo));
> + tfa_bl31_image_addr = image;
> + tfa_bl31_image_loaded = true;
> +}
> +
> +U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TFA_BL31, tfa_bl31_image_process);
> +
> +void armv8_switch_to_el2_prep(u64 args, u64 mach_nr, u64 fdt_addr,
> + u64 arg4, u64 entry_point, u64 es_flag)
> +{
> + typedef void __noreturn (*image_entry_noargs_t)(void);
> + image_entry_noargs_t image_entry =
> + (image_entry_noargs_t)(void *)tfa_bl31_image_addr;
> + struct bl2_to_bl31_params_mem *blinfo =
> + (struct bl2_to_bl31_params_mem *)PARAMS_BASE;
> +
> + /*
> + * Destination address in arch/arm/cpu/armv8/transition.S
> + * right past the first bl in armv8_switch_to_el2() to let
> + * the rest of U-Boot pre-Linux code run. The code does run
> + * without stack pointer!
> + */
> + const u64 ep = ((u64)(uintptr_t)&armv8_switch_to_el2) + 4;
> +
> + /* If TFA BL31 was not part of the fitImage, do regular boot. */
> + if (!tfa_bl31_image_loaded)
> + return;
> +
> + /*
> + * Set up kernel entry point and parameters:
> + * x0 is FDT address, x1..x3 must be 0
> + */
> + blinfo->bl33_ep_info.pc = ep;
> + blinfo->bl33_ep_info.args.arg0 = args;
> + blinfo->bl33_ep_info.args.arg1 = mach_nr;
> + blinfo->bl33_ep_info.args.arg2 = fdt_addr;
> + blinfo->bl33_ep_info.args.arg3 = arg4;
> + blinfo->bl33_ep_info.args.arg4 = entry_point;
> + blinfo->bl33_ep_info.args.arg5 = es_flag;
> + blinfo->bl33_image_info.image_base = ep;
> +
> + /* Jump to TFA BL31 */
> + image_entry();
> +}
Shouldn't we have a weak implementation that SoC vendor can override if
they feel like it?
To me this feels like it could be much quicker adopted if we had some
default people could try out for their boards.
We already have a generic spl_invoke_atf() so why not the same for this
mechanism? As far as I could tell, we get the load address of TEE and
U-Boot proper (bl32 and bl33) and pass it the FDT (or nothing if
SPL_ATF_NO_PLATFORM_PARAM symbol set).
I am not too sure who and how TEE will be started as it needs to be
executing in EL3 too I believe? So we may still have to provide that
one? BL33 would be the kernel params like you did in this patch. Then
the bl31 param could also be either the fdt or nothing if
ATF_NO_PLATFORM_PARAM is set.
I guess the issue is that Renesas doesn't use any of that generic stuff?
What do you think?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support
2025-01-29 16:02 ` Quentin Schulz
@ 2025-01-29 16:28 ` Quentin Schulz
2025-01-29 17:03 ` Marek Vasut
2025-01-29 17:00 ` Marek Vasut
1 sibling, 1 reply; 19+ messages in thread
From: Quentin Schulz @ 2025-01-29 16:28 UTC (permalink / raw)
To: Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/29/25 5:02 PM, Quentin Schulz wrote:
> Hi Marek,
>
> On 1/12/25 11:36 PM, Marek Vasut wrote:
>> Implement custom U_BOOT_FIT_LOADABLE_HANDLER and
>> armv8_switch_to_el2_prep()
>> handling in case the TFA was loaded. The loadables handler sets up custom
>> handoff structure used by Renesas TFA fork in fixed location in DRAM and
>> indicates the TFA has been loaded.
>>
>> The custom armv8_switch_to_el2_prep() handling tests whether the TFA BL31
>> was previously loaded and the custom handoff structure was set up, and if
>> so, jumps to TFA BL31 which switches from EL3 to EL2 and then returns to
>> U-Boot just past bl in armv8_switch_to_el2() to finish starting the Linux
>> kernel.
>>
>> The jump to Linux through TFA works in such a way that the custom
>> armv8_switch_to_el2_prep() handler configures the custom handoff
>> structure
>> such that the target jump address of the TFA BL31 on exit is set to the
>> armv8_switch_to_el2() + 4, which is just past the bl, and just before the
>> U-Boot code which implements the Linux kernel boot from either EL. The
>> registers passed through the TFA BL31 are all the registers passed into
>> armv8_switch_to_el2_prep() to assure maximum compatibility with all the
>> boot modes. The armv8_switch_to_el2_prep() handler jumps to the TFA BL31,
>> which does its setup, drops EL from EL3 to EL2 and finally jumps to the
>> armv8_switch_to_el2() + 4 entry point, which then allows U-Boot to boot
>> the Linux kernel the usual way.
>>
>> In order to build suitable kernel fitImage, build TFA first, temporarily
>> from downstream repository:
>> remote: https://eur02.safelinks.protection.outlook.com/?
>> url=https%3A%2F%2Fgithub.com%2Frenesas-rcar%2Farm-trusted-
>> firmware.git&data=05%7C02%7Cquentin.schulz%40cherry.de%7C6ab2eb623e32425379f108dd407e5a7c%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638737633628498421%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DWQfUm5mp9%2FMCUxvFFbO1yfjKlvmtfiOD8VTkN%2BEZKk%3D&reserved=0
>> branch: rcar_gen4_v2.7_v4x
>>
>> ```
>> $ git clean -fqdx
>> $ MBEDTLS_DIR=/path/to/mbedtls/ make -j$(nproc) bl31 \
>> PLAT=rcar_gen4 ARCH=aarch64 LSI=V4H SPD=none \
>> CTX_INCLUDE_AARCH32_REGS=0 MBEDTLS_COMMON_MK=1 \
>> PTP_NONSECURE_ACCESS=1 LOG_LEVEL=20 DEBUG=0 \
>> ENABLE_ASSERTIONS=0 E=0
>> ```
>>
>> Build Linux kernel Image and device tree from current mainline Linux
>> kernel repository, obtain 'Image' and 'r8a779g0-white-hawk.dtb' .
>>
>> Bundle the files together using provided fit-image.its fitImage
>> description:
>> ```
>> $ mkimage -f fit-image.its fitImage
>> ```
>>
>> To start the kernel fiImage generated in previous step, load fitImage
>> to DRAM and use the 'bootm' command to start it:
>> => load 0x58000000 ... fitImage && bootm 0x58000000
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>> ---
>> Cc: Andre Przywara <andre.przywara@arm.com>
>> Cc: Caleb Connolly <caleb.connolly@linaro.org>
>> Cc: Igor Opaniuk <igor.opaniuk@gmail.com>
>> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>> Cc: Julien Masson <jmasson@baylibre.com>
>> Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
>> Cc: Maxim Moskalets <maximmosk4@gmail.com>
>> Cc: Michael Walle <mwalle@kernel.org>
>> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>> Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
>> Cc: Paul Barker <paul.barker.ct@bp.renesas.com>
>> Cc: Paul-Erwan Rio <paulerwan.rio@gmail.com>
>> Cc: Peter Hoyes <Peter.Hoyes@arm.com>
>> Cc: Raymond Mao <raymond.mao@linaro.org>
>> Cc: Sam Protsenko <semen.protsenko@linaro.org>
>> Cc: Simon Glass <sjg@chromium.org>
>> Cc: Sughosh Ganu <sughosh.ganu@linaro.org>
>> Cc: Tom Rini <trini@konsulko.com>
>> Cc: u-boot@lists.denx.de
>> ---
>> board/renesas/common/gen4-common.c | 118 +++++++++++++++++++++++++++++
>> 1 file changed, 118 insertions(+)
>>
>> diff --git a/board/renesas/common/gen4-common.c b/board/renesas/
>> common/gen4-common.c
>> index 52a0639073b..c7f3f9a30ab 100644
>> --- a/board/renesas/common/gen4-common.c
>> +++ b/board/renesas/common/gen4-common.c
>> @@ -7,11 +7,13 @@
>> #include <asm/arch/renesas.h>
>> #include <asm/arch/sys_proto.h>
>> +#include <asm/armv8/mmu.h>
>> #include <asm/global_data.h>
>> #include <asm/io.h>
>> #include <asm/mach-types.h>
>> #include <asm/processor.h>
>> #include <asm/system.h>
>> +#include <image.h>
>> #include <linux/errno.h>
>> #define RST_BASE 0xE6160000 /* Domain0 */
>> @@ -88,3 +90,119 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>> {
>> return 0;
>> }
>> +
>> +/* R-Car Gen4 TFA BL31 handoff structure and handling. */
>> +struct param_header {
>> + u8 type;
>> + u8 version;
>> + u16 size;
>> + u32 attr;
>> +};
>> +
>> +struct tfa_image_info {
>> + struct param_header h;
>> + uintptr_t image_base;
>> + u32 image_size;
>> + u32 image_max_size;
>> +};
>> +
>> +struct aapcs64_params {
>> + u64 arg0;
>> + u64 arg1;
>> + u64 arg2;
>> + u64 arg3;
>> + u64 arg4;
>> + u64 arg5;
>> + u64 arg6;
>> + u64 arg7;
>> +};
>> +
>> +struct entry_point_info {
>> + struct param_header h;
>> + uintptr_t pc;
>> + u32 spsr;
>> + struct aapcs64_params args;
>> +};
>> +
>> +struct bl2_to_bl31_params_mem {
>> + struct tfa_image_info bl32_image_info;
>> + struct tfa_image_info bl33_image_info;
>> + struct entry_point_info bl33_ep_info;
>> + struct entry_point_info bl32_ep_info;
>> +};
>> +
>> +/* Default jump address, return to U-Boot */
>> +#define BL33_BASE 0x44100000
>> +/* Custom parameters address passed to TFA by ICUMXA loader */
>> +#define PARAMS_BASE 0x46422200
>> +
>
> Shouldn't we rather set those as offset compared to the load/entry
> address passed in the ITS?
>
>> +/* Usually such a structure is produced by ICUMXA and passed in at
>> 0x46422200 */
>> +static const struct bl2_to_bl31_params_mem blinfo_template = {
>> + .bl33_ep_info.h.type = 1, /* PARAM_EP */
>> + .bl33_ep_info.h.version = 2, /* Version 2 */
>> + .bl33_ep_info.h.size = sizeof(struct entry_point_info),
>> + .bl33_ep_info.h.attr = 0x81, /* Executable | Non-Secure */
>> + .bl33_ep_info.spsr = 0x2c9, /* Mode=EL2, SP=ELX,
>> Exceptions=OFF */
>> + .bl33_ep_info.pc = BL33_BASE,
>> +
>> + .bl33_image_info.h.type = 1, /* PARAM_EP */
>> + .bl33_image_info.h.version = 2, /* Version 2 */
>> + .bl33_image_info.h.size = sizeof(struct image_info),
>> + .bl33_image_info.h.attr = 0,
>> + .bl33_image_info.image_base = BL33_BASE,
>> +};
>> +
>> +static bool tfa_bl31_image_loaded;
>> +static ulong tfa_bl31_image_addr;
>> +
>> +static void tfa_bl31_image_process(ulong image, size_t size)
>> +{
>> + /* Custom parameters address passed to TFA by ICUMXA loader */
>> + struct bl2_to_bl31_params_mem *blinfo = (struct
>> bl2_to_bl31_params_mem *)PARAMS_BASE;
>> +
>> + /* Clear a page and copy template */
>> + memset((void *)PARAMS_BASE, 0, PAGE_SIZE);
>> + memcpy(blinfo, &blinfo_template, sizeof(*blinfo));
>> + tfa_bl31_image_addr = image;
>> + tfa_bl31_image_loaded = true;
>> +}
>> +
>> +U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TFA_BL31, tfa_bl31_image_process);
>> +
>> +void armv8_switch_to_el2_prep(u64 args, u64 mach_nr, u64 fdt_addr,
>> + u64 arg4, u64 entry_point, u64 es_flag)
>> +{
>> + typedef void __noreturn (*image_entry_noargs_t)(void);
>> + image_entry_noargs_t image_entry =
>> + (image_entry_noargs_t)(void *)tfa_bl31_image_addr;
>> + struct bl2_to_bl31_params_mem *blinfo =
>> + (struct bl2_to_bl31_params_mem *)PARAMS_BASE;
>> +
>> + /*
>> + * Destination address in arch/arm/cpu/armv8/transition.S
>> + * right past the first bl in armv8_switch_to_el2() to let
>> + * the rest of U-Boot pre-Linux code run. The code does run
>> + * without stack pointer!
>> + */
>> + const u64 ep = ((u64)(uintptr_t)&armv8_switch_to_el2) + 4;
>> +
>> + /* If TFA BL31 was not part of the fitImage, do regular boot. */
>> + if (!tfa_bl31_image_loaded)
>> + return;
>> +
>> + /*
>> + * Set up kernel entry point and parameters:
>> + * x0 is FDT address, x1..x3 must be 0
>> + */
>> + blinfo->bl33_ep_info.pc = ep;
>> + blinfo->bl33_ep_info.args.arg0 = args;
>> + blinfo->bl33_ep_info.args.arg1 = mach_nr;
>> + blinfo->bl33_ep_info.args.arg2 = fdt_addr;
>> + blinfo->bl33_ep_info.args.arg3 = arg4;
>> + blinfo->bl33_ep_info.args.arg4 = entry_point;
>> + blinfo->bl33_ep_info.args.arg5 = es_flag;
>> + blinfo->bl33_image_info.image_base = ep;
>> +
>> + /* Jump to TFA BL31 */
>> + image_entry();
>> +}
>
> Shouldn't we have a weak implementation that SoC vendor can override if
> they feel like it?
>
> To me this feels like it could be much quicker adopted if we had some
> default people could try out for their boards.
>
> We already have a generic spl_invoke_atf() so why not the same for this
> mechanism? As far as I could tell, we get the load address of TEE and U-
> Boot proper (bl32 and bl33) and pass it the FDT (or nothing if
> SPL_ATF_NO_PLATFORM_PARAM symbol set).
>
> I am not too sure who and how TEE will be started as it needs to be
> executing in EL3 too I believe? So we may still have to provide that
> one? BL33 would be the kernel params like you did in this patch. Then
> the bl31 param could also be either the fdt or nothing if
> ATF_NO_PLATFORM_PARAM is set.
>
Actually, I would highly prefer we don't even have this symbol and have
instead a property in the TF-A image node in the ITS to say whether
we're allowed to pass parameters or not to BL31? The user bundling TF-A
inside the linux.itb should know (well, we should probably know also
when building BL31 within u-boot.itb....).
We actually need this symbol on all Rockchip boards using the Rockchip
blob and not upstream. But this also prevents us from using some
featureset of the upstream TF-A if we rebuild without disabling the
symbol. It'd be nice if we don't have to rebuild U-Boot depending on
which variant of BL31 we use on Rockchip, this info should be stored in
the linux.itb is what I'm saying. This doesn't need to be in this
introducing commit though I believe, we can work something out later I
guess.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support
2025-01-29 16:28 ` Quentin Schulz
@ 2025-01-29 17:03 ` Marek Vasut
0 siblings, 0 replies; 19+ messages in thread
From: Marek Vasut @ 2025-01-29 17:03 UTC (permalink / raw)
To: Quentin Schulz, Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/29/25 5:28 PM, Quentin Schulz wrote:
>
>
> On 1/29/25 5:02 PM, Quentin Schulz wrote:
>> Hi Marek,
>>
>> On 1/12/25 11:36 PM, Marek Vasut wrote:
>>> Implement custom U_BOOT_FIT_LOADABLE_HANDLER and
>>> armv8_switch_to_el2_prep()
>>> handling in case the TFA was loaded. The loadables handler sets up
>>> custom
>>> handoff structure used by Renesas TFA fork in fixed location in DRAM and
>>> indicates the TFA has been loaded.
>>>
>>> The custom armv8_switch_to_el2_prep() handling tests whether the TFA
>>> BL31
>>> was previously loaded and the custom handoff structure was set up,
>>> and if
>>> so, jumps to TFA BL31 which switches from EL3 to EL2 and then returns to
>>> U-Boot just past bl in armv8_switch_to_el2() to finish starting the
>>> Linux
>>> kernel.
>>>
>>> The jump to Linux through TFA works in such a way that the custom
>>> armv8_switch_to_el2_prep() handler configures the custom handoff
>>> structure
>>> such that the target jump address of the TFA BL31 on exit is set to the
>>> armv8_switch_to_el2() + 4, which is just past the bl, and just before
>>> the
>>> U-Boot code which implements the Linux kernel boot from either EL. The
>>> registers passed through the TFA BL31 are all the registers passed into
>>> armv8_switch_to_el2_prep() to assure maximum compatibility with all the
>>> boot modes. The armv8_switch_to_el2_prep() handler jumps to the TFA
>>> BL31,
>>> which does its setup, drops EL from EL3 to EL2 and finally jumps to the
>>> armv8_switch_to_el2() + 4 entry point, which then allows U-Boot to boot
>>> the Linux kernel the usual way.
>>>
>>> In order to build suitable kernel fitImage, build TFA first, temporarily
>>> from downstream repository:
>>> remote: https://eur02.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Fgithub.com%2Frenesas-rcar%2Farm-trusted-
>>> firmware.git&data=05%7C02%7Cquentin.schulz%40cherry.de%7C6ab2eb623e32425379f108dd407e5a7c%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C638737633628498421%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DWQfUm5mp9%2FMCUxvFFbO1yfjKlvmtfiOD8VTkN%2BEZKk%3D&reserved=0
>>> branch: rcar_gen4_v2.7_v4x
>>>
>>> ```
>>> $ git clean -fqdx
>>> $ MBEDTLS_DIR=/path/to/mbedtls/ make -j$(nproc) bl31 \
>>> PLAT=rcar_gen4 ARCH=aarch64 LSI=V4H SPD=none \
>>> CTX_INCLUDE_AARCH32_REGS=0 MBEDTLS_COMMON_MK=1 \
>>> PTP_NONSECURE_ACCESS=1 LOG_LEVEL=20 DEBUG=0 \
>>> ENABLE_ASSERTIONS=0 E=0
>>> ```
>>>
>>> Build Linux kernel Image and device tree from current mainline Linux
>>> kernel repository, obtain 'Image' and 'r8a779g0-white-hawk.dtb' .
>>>
>>> Bundle the files together using provided fit-image.its fitImage
>>> description:
>>> ```
>>> $ mkimage -f fit-image.its fitImage
>>> ```
>>>
>>> To start the kernel fiImage generated in previous step, load fitImage
>>> to DRAM and use the 'bootm' command to start it:
>>> => load 0x58000000 ... fitImage && bootm 0x58000000
>>>
>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>>> ---
>>> Cc: Andre Przywara <andre.przywara@arm.com>
>>> Cc: Caleb Connolly <caleb.connolly@linaro.org>
>>> Cc: Igor Opaniuk <igor.opaniuk@gmail.com>
>>> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>>> Cc: Julien Masson <jmasson@baylibre.com>
>>> Cc: Mattijs Korpershoek <mkorpershoek@baylibre.com>
>>> Cc: Maxim Moskalets <maximmosk4@gmail.com>
>>> Cc: Michael Walle <mwalle@kernel.org>
>>> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>>> Cc: Patrick Rudolph <patrick.rudolph@9elements.com>
>>> Cc: Paul Barker <paul.barker.ct@bp.renesas.com>
>>> Cc: Paul-Erwan Rio <paulerwan.rio@gmail.com>
>>> Cc: Peter Hoyes <Peter.Hoyes@arm.com>
>>> Cc: Raymond Mao <raymond.mao@linaro.org>
>>> Cc: Sam Protsenko <semen.protsenko@linaro.org>
>>> Cc: Simon Glass <sjg@chromium.org>
>>> Cc: Sughosh Ganu <sughosh.ganu@linaro.org>
>>> Cc: Tom Rini <trini@konsulko.com>
>>> Cc: u-boot@lists.denx.de
>>> ---
>>> board/renesas/common/gen4-common.c | 118 +++++++++++++++++++++++++++++
>>> 1 file changed, 118 insertions(+)
>>>
>>> diff --git a/board/renesas/common/gen4-common.c b/board/renesas/
>>> common/gen4-common.c
>>> index 52a0639073b..c7f3f9a30ab 100644
>>> --- a/board/renesas/common/gen4-common.c
>>> +++ b/board/renesas/common/gen4-common.c
>>> @@ -7,11 +7,13 @@
>>> #include <asm/arch/renesas.h>
>>> #include <asm/arch/sys_proto.h>
>>> +#include <asm/armv8/mmu.h>
>>> #include <asm/global_data.h>
>>> #include <asm/io.h>
>>> #include <asm/mach-types.h>
>>> #include <asm/processor.h>
>>> #include <asm/system.h>
>>> +#include <image.h>
>>> #include <linux/errno.h>
>>> #define RST_BASE 0xE6160000 /* Domain0 */
>>> @@ -88,3 +90,119 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>>> {
>>> return 0;
>>> }
>>> +
>>> +/* R-Car Gen4 TFA BL31 handoff structure and handling. */
>>> +struct param_header {
>>> + u8 type;
>>> + u8 version;
>>> + u16 size;
>>> + u32 attr;
>>> +};
>>> +
>>> +struct tfa_image_info {
>>> + struct param_header h;
>>> + uintptr_t image_base;
>>> + u32 image_size;
>>> + u32 image_max_size;
>>> +};
>>> +
>>> +struct aapcs64_params {
>>> + u64 arg0;
>>> + u64 arg1;
>>> + u64 arg2;
>>> + u64 arg3;
>>> + u64 arg4;
>>> + u64 arg5;
>>> + u64 arg6;
>>> + u64 arg7;
>>> +};
>>> +
>>> +struct entry_point_info {
>>> + struct param_header h;
>>> + uintptr_t pc;
>>> + u32 spsr;
>>> + struct aapcs64_params args;
>>> +};
>>> +
>>> +struct bl2_to_bl31_params_mem {
>>> + struct tfa_image_info bl32_image_info;
>>> + struct tfa_image_info bl33_image_info;
>>> + struct entry_point_info bl33_ep_info;
>>> + struct entry_point_info bl32_ep_info;
>>> +};
>>> +
>>> +/* Default jump address, return to U-Boot */
>>> +#define BL33_BASE 0x44100000
>>> +/* Custom parameters address passed to TFA by ICUMXA loader */
>>> +#define PARAMS_BASE 0x46422200
>>> +
>>
>> Shouldn't we rather set those as offset compared to the load/entry
>> address passed in the ITS?
>>
>>> +/* Usually such a structure is produced by ICUMXA and passed in at
>>> 0x46422200 */
>>> +static const struct bl2_to_bl31_params_mem blinfo_template = {
>>> + .bl33_ep_info.h.type = 1, /* PARAM_EP */
>>> + .bl33_ep_info.h.version = 2, /* Version 2 */
>>> + .bl33_ep_info.h.size = sizeof(struct entry_point_info),
>>> + .bl33_ep_info.h.attr = 0x81, /* Executable | Non-Secure */
>>> + .bl33_ep_info.spsr = 0x2c9, /* Mode=EL2, SP=ELX,
>>> Exceptions=OFF */
>>> + .bl33_ep_info.pc = BL33_BASE,
>>> +
>>> + .bl33_image_info.h.type = 1, /* PARAM_EP */
>>> + .bl33_image_info.h.version = 2, /* Version 2 */
>>> + .bl33_image_info.h.size = sizeof(struct image_info),
>>> + .bl33_image_info.h.attr = 0,
>>> + .bl33_image_info.image_base = BL33_BASE,
>>> +};
>>> +
>>> +static bool tfa_bl31_image_loaded;
>>> +static ulong tfa_bl31_image_addr;
>>> +
>>> +static void tfa_bl31_image_process(ulong image, size_t size)
>>> +{
>>> + /* Custom parameters address passed to TFA by ICUMXA loader */
>>> + struct bl2_to_bl31_params_mem *blinfo = (struct
>>> bl2_to_bl31_params_mem *)PARAMS_BASE;
>>> +
>>> + /* Clear a page and copy template */
>>> + memset((void *)PARAMS_BASE, 0, PAGE_SIZE);
>>> + memcpy(blinfo, &blinfo_template, sizeof(*blinfo));
>>> + tfa_bl31_image_addr = image;
>>> + tfa_bl31_image_loaded = true;
>>> +}
>>> +
>>> +U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TFA_BL31, tfa_bl31_image_process);
>>> +
>>> +void armv8_switch_to_el2_prep(u64 args, u64 mach_nr, u64 fdt_addr,
>>> + u64 arg4, u64 entry_point, u64 es_flag)
>>> +{
>>> + typedef void __noreturn (*image_entry_noargs_t)(void);
>>> + image_entry_noargs_t image_entry =
>>> + (image_entry_noargs_t)(void *)tfa_bl31_image_addr;
>>> + struct bl2_to_bl31_params_mem *blinfo =
>>> + (struct bl2_to_bl31_params_mem *)PARAMS_BASE;
>>> +
>>> + /*
>>> + * Destination address in arch/arm/cpu/armv8/transition.S
>>> + * right past the first bl in armv8_switch_to_el2() to let
>>> + * the rest of U-Boot pre-Linux code run. The code does run
>>> + * without stack pointer!
>>> + */
>>> + const u64 ep = ((u64)(uintptr_t)&armv8_switch_to_el2) + 4;
>>> +
>>> + /* If TFA BL31 was not part of the fitImage, do regular boot. */
>>> + if (!tfa_bl31_image_loaded)
>>> + return;
>>> +
>>> + /*
>>> + * Set up kernel entry point and parameters:
>>> + * x0 is FDT address, x1..x3 must be 0
>>> + */
>>> + blinfo->bl33_ep_info.pc = ep;
>>> + blinfo->bl33_ep_info.args.arg0 = args;
>>> + blinfo->bl33_ep_info.args.arg1 = mach_nr;
>>> + blinfo->bl33_ep_info.args.arg2 = fdt_addr;
>>> + blinfo->bl33_ep_info.args.arg3 = arg4;
>>> + blinfo->bl33_ep_info.args.arg4 = entry_point;
>>> + blinfo->bl33_ep_info.args.arg5 = es_flag;
>>> + blinfo->bl33_image_info.image_base = ep;
>>> +
>>> + /* Jump to TFA BL31 */
>>> + image_entry();
>>> +}
>>
>> Shouldn't we have a weak implementation that SoC vendor can override
>> if they feel like it?
>>
>> To me this feels like it could be much quicker adopted if we had some
>> default people could try out for their boards.
>>
>> We already have a generic spl_invoke_atf() so why not the same for
>> this mechanism? As far as I could tell, we get the load address of TEE
>> and U- Boot proper (bl32 and bl33) and pass it the FDT (or nothing if
>> SPL_ATF_NO_PLATFORM_PARAM symbol set).
>>
>> I am not too sure who and how TEE will be started as it needs to be
>> executing in EL3 too I believe? So we may still have to provide that
>> one? BL33 would be the kernel params like you did in this patch. Then
>> the bl31 param could also be either the fdt or nothing if
>> ATF_NO_PLATFORM_PARAM is set.
>>
>
> Actually, I would highly prefer we don't even have this symbol and have
> instead a property in the TF-A image node in the ITS to say whether
> we're allowed to pass parameters or not to BL31? The user bundling TF-A
> inside the linux.itb should know (well, we should probably know also
> when building BL31 within u-boot.itb....).
This is something user should decide in their own board/arch specific
implementation of tfa_bl31_image_process()/armv8_switch_to_el2_prep().
These two functions are architecture/board specific because of the
various forks of TFA BL31 and the need to handle those various handoff
structures.
> We actually need this symbol on all Rockchip boards using the Rockchip
> blob and not upstream. But this also prevents us from using some
> featureset of the upstream TF-A if we rebuild without disabling the
> symbol. It'd be nice if we don't have to rebuild U-Boot depending on
> which variant of BL31 we use on Rockchip, this info should be stored in
> the linux.itb is what I'm saying. This doesn't need to be in this
> introducing commit though I believe, we can work something out later I
> guess.
Maybe this comment is not really applicable ?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support
2025-01-29 16:02 ` Quentin Schulz
2025-01-29 16:28 ` Quentin Schulz
@ 2025-01-29 17:00 ` Marek Vasut
2025-01-29 17:32 ` Quentin Schulz
1 sibling, 1 reply; 19+ messages in thread
From: Marek Vasut @ 2025-01-29 17:00 UTC (permalink / raw)
To: Quentin Schulz, Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/29/25 5:02 PM, Quentin Schulz wrote:
> Hi Marek,
Hi,
[...]
>> +void armv8_switch_to_el2_prep(u64 args, u64 mach_nr, u64 fdt_addr,
>> + u64 arg4, u64 entry_point, u64 es_flag)
>> +{
>> + typedef void __noreturn (*image_entry_noargs_t)(void);
>> + image_entry_noargs_t image_entry =
>> + (image_entry_noargs_t)(void *)tfa_bl31_image_addr;
>> + struct bl2_to_bl31_params_mem *blinfo =
>> + (struct bl2_to_bl31_params_mem *)PARAMS_BASE;
>> +
>> + /*
>> + * Destination address in arch/arm/cpu/armv8/transition.S
>> + * right past the first bl in armv8_switch_to_el2() to let
>> + * the rest of U-Boot pre-Linux code run. The code does run
>> + * without stack pointer!
>> + */
>> + const u64 ep = ((u64)(uintptr_t)&armv8_switch_to_el2) + 4;
>> +
>> + /* If TFA BL31 was not part of the fitImage, do regular boot. */
>> + if (!tfa_bl31_image_loaded)
>> + return;
>> +
>> + /*
>> + * Set up kernel entry point and parameters:
>> + * x0 is FDT address, x1..x3 must be 0
>> + */
>> + blinfo->bl33_ep_info.pc = ep;
>> + blinfo->bl33_ep_info.args.arg0 = args;
>> + blinfo->bl33_ep_info.args.arg1 = mach_nr;
>> + blinfo->bl33_ep_info.args.arg2 = fdt_addr;
>> + blinfo->bl33_ep_info.args.arg3 = arg4;
>> + blinfo->bl33_ep_info.args.arg4 = entry_point;
>> + blinfo->bl33_ep_info.args.arg5 = es_flag;
>> + blinfo->bl33_image_info.image_base = ep;
>> +
>> + /* Jump to TFA BL31 */
>> + image_entry();
>> +}
>
> Shouldn't we have a weak implementation that SoC vendor can override if
> they feel like it?
We do have one. Please do have a look at 1/3 in this series:
WEAK(armv8_switch_to_el2_prep)
> To me this feels like it could be much quicker adopted if we had some
> default people could try out for their boards.
>
> We already have a generic spl_invoke_atf() so why not the same for this
> mechanism? As far as I could tell, we get the load address of TEE and U-
> Boot proper (bl32 and bl33) and pass it the FDT (or nothing if
> SPL_ATF_NO_PLATFORM_PARAM symbol set).
Looking at spl_invoke_atf(), it _almost_ looks like something I could
use, but from what I see there and here, the handoff structure layout is
slightly different, it seems to be board specific.
But that is fine, as this is a board specific strong implementation of
weak armv8_switch_to_el2_prep function.
> I am not too sure who and how TEE will be started as it needs to be
> executing in EL3 too I believe? So we may still have to provide that
> one? BL33 would be the kernel params like you did in this patch. Then
> the bl31 param could also be either the fdt or nothing if
> ATF_NO_PLATFORM_PARAM is set.
>
> I guess the issue is that Renesas doesn't use any of that generic stuff?
>
> What do you think?
The board does ship with a custom loader which starts on a security
core, which starts the BL31 on an application core. That custom loader
does set up the handoff structure before releasing the application core
from reset, and then the application core jumps right into the BL31 .
But mainline U-Boot now has SPL which can run on another realtime core,
bring up DRAM, application core, start U-Boot on it ... and then U-Boot
has to set up the handoff structure before starting TFA, in the same
form like the custom loader.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support
2025-01-29 17:00 ` Marek Vasut
@ 2025-01-29 17:32 ` Quentin Schulz
0 siblings, 0 replies; 19+ messages in thread
From: Quentin Schulz @ 2025-01-29 17:32 UTC (permalink / raw)
To: Marek Vasut, Marek Vasut, u-boot
Cc: Andre Przywara, Caleb Connolly, Igor Opaniuk, Ilias Apalodimas,
Julien Masson, Mattijs Korpershoek, Maxim Moskalets,
Michael Walle, Nobuhiro Iwamatsu, Patrick Rudolph, Paul Barker,
Paul-Erwan Rio, Peter Hoyes, Raymond Mao, Sam Protsenko,
Simon Glass, Sughosh Ganu, Tom Rini
On 1/29/25 6:00 PM, Marek Vasut wrote:
> On 1/29/25 5:02 PM, Quentin Schulz wrote:
>>> +void armv8_switch_to_el2_prep(u64 args, u64 mach_nr, u64 fdt_addr,
>>> + u64 arg4, u64 entry_point, u64 es_flag)
>>> +{
>>> + typedef void __noreturn (*image_entry_noargs_t)(void);
>>> + image_entry_noargs_t image_entry =
>>> + (image_entry_noargs_t)(void *)tfa_bl31_image_addr;
>>> + struct bl2_to_bl31_params_mem *blinfo =
>>> + (struct bl2_to_bl31_params_mem *)PARAMS_BASE;
>>> +
>>> + /*
>>> + * Destination address in arch/arm/cpu/armv8/transition.S
>>> + * right past the first bl in armv8_switch_to_el2() to let
>>> + * the rest of U-Boot pre-Linux code run. The code does run
>>> + * without stack pointer!
>>> + */
>>> + const u64 ep = ((u64)(uintptr_t)&armv8_switch_to_el2) + 4;
>>> +
>>> + /* If TFA BL31 was not part of the fitImage, do regular boot. */
>>> + if (!tfa_bl31_image_loaded)
>>> + return;
>>> +
>>> + /*
>>> + * Set up kernel entry point and parameters:
>>> + * x0 is FDT address, x1..x3 must be 0
>>> + */
>>> + blinfo->bl33_ep_info.pc = ep;
>>> + blinfo->bl33_ep_info.args.arg0 = args;
>>> + blinfo->bl33_ep_info.args.arg1 = mach_nr;
>>> + blinfo->bl33_ep_info.args.arg2 = fdt_addr;
>>> + blinfo->bl33_ep_info.args.arg3 = arg4;
>>> + blinfo->bl33_ep_info.args.arg4 = entry_point;
>>> + blinfo->bl33_ep_info.args.arg5 = es_flag;
>>> + blinfo->bl33_image_info.image_base = ep;
>>> +
>>> + /* Jump to TFA BL31 */
>>> + image_entry();
>>> +}
>>
>> Shouldn't we have a weak implementation that SoC vendor can override
>> if they feel like it?
>
> We do have one. Please do have a look at 1/3 in this series:
>
> WEAK(armv8_switch_to_el2_prep)
>
Well yes, and it's completely empty :)
>> To me this feels like it could be much quicker adopted if we had some
>> default people could try out for their boards.
>>
>> We already have a generic spl_invoke_atf() so why not the same for
>> this mechanism? As far as I could tell, we get the load address of TEE
>> and U- Boot proper (bl32 and bl33) and pass it the FDT (or nothing if
>> SPL_ATF_NO_PLATFORM_PARAM symbol set).
>
> Looking at spl_invoke_atf(), it _almost_ looks like something I could
> use, but from what I see there and here, the handoff structure layout is
> slightly different, it seems to be board specific.
>
I believe it's common to any board with SPL_ATF symbol enabled.
That would be...
$ git grep CONFIG_SPL_ATF= configs | cut -f1 -d ':' | sort
configs/anbernic-rgxx3-rk3566_defconfig
configs/bpi-r2-pro-rk3568_defconfig
configs/cm3588-nas-rk3588_defconfig
configs/coolpi-4b-rk3588s_defconfig
configs/coolpi-cm5-evb-rk3588_defconfig
configs/coolpi-cm5-genbook-rk3588_defconfig
configs/evb-px30_defconfig
configs/evb-px5_defconfig
configs/evb-rk3328_defconfig
configs/evb-rk3568_defconfig
configs/evb-rk3588_defconfig
configs/firefly-px30_defconfig
configs/generic-rk3568_defconfig
configs/generic-rk3588_defconfig
configs/jaguar-rk3588_defconfig
configs/khadas-edge2-rk3588s_defconfig
configs/lubancat-2-rk3568_defconfig
configs/nanopc-t6-rk3588_defconfig
configs/nanopi-r2c-plus-rk3328_defconfig
configs/nanopi-r2c-rk3328_defconfig
configs/nanopi-r2s-plus-rk3328_defconfig
configs/nanopi-r2s-rk3328_defconfig
configs/nanopi-r3s-rk3566_defconfig
configs/nanopi-r5c-rk3568_defconfig
configs/nanopi-r5s-rk3568_defconfig
configs/nanopi-r6c-rk3588s_defconfig
configs/nanopi-r6s-rk3588s_defconfig
configs/neu6a-io-rk3588_defconfig
configs/neu6b-io-rk3588_defconfig
configs/nova-rk3588s_defconfig
configs/odroid-go2_defconfig
configs/odroid-m1-rk3568_defconfig
configs/odroid-m1s-rk3566_defconfig
configs/odroid-m2-rk3588s_defconfig
configs/orangepi-3b-rk3566_defconfig
configs/orangepi-5-plus-rk3588_defconfig
configs/orangepi-5-rk3588s_defconfig
configs/orangepi-r1-plus-lts-rk3328_defconfig
configs/orangepi-r1-plus-rk3328_defconfig
configs/pinetab2-rk3566_defconfig
configs/powkiddy-x55-rk3566_defconfig
configs/px30-core-ctouch2-of10-px30_defconfig
configs/px30-core-ctouch2-px30_defconfig
configs/px30-core-edimm2.2-px30_defconfig
configs/qnap-ts433-rk3568_defconfig
configs/quartz64-a-rk3566_defconfig
configs/quartz64-b-rk3566_defconfig
configs/quartzpro64-rk3588_defconfig
configs/radxa-cm3-io-rk3566_defconfig
configs/radxa-e25-rk3568_defconfig
configs/radxa-zero-3-rk3566_defconfig
configs/ringneck-px30_defconfig
configs/roc-cc-rk3328_defconfig
configs/rock-3a-rk3568_defconfig
configs/rock-3b-rk3568_defconfig
configs/rock-3c-rk3566_defconfig
configs/rock5a-rk3588s_defconfig
configs/rock5b-rk3588_defconfig
configs/rock-5c-rk3588s_defconfig
configs/rock-5-itx-rk3588_defconfig
configs/rock64-rk3328_defconfig
configs/rock-pi-e-rk3328_defconfig
configs/rock-pi-e-v3-rk3328_defconfig
configs/sige7-rk3588_defconfig
configs/socfpga_agilex5_defconfig
configs/socfpga_agilex_atf_defconfig
configs/socfpga_agilex_vab_defconfig
configs/socfpga_n5x_atf_defconfig
configs/socfpga_n5x_vab_defconfig
configs/socfpga_stratix10_atf_defconfig
configs/soquartz-blade-rk3566_defconfig
configs/soquartz-cm4-rk3566_defconfig
configs/soquartz-model-a-rk3566_defconfig
configs/tiger-rk3588_defconfig
configs/toybrick-rk3588_defconfig
configs/turing-rk1-rk3588_defconfig
configs/xilinx_zynqmp_kria_defconfig
configs/xilinx_zynqmp_virt_defconfig
Essentially Rockchip boards + some socfpga and Xilinx ZynqMP boards.
... which I guess confirms what you've been saying, I don't feel like
it's generic enough to warrant making it the default, weak, implementation.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 1/3] arm64: Add late jump to kernel board hook
2025-01-12 22:36 [PATCH 1/3] arm64: Add late jump to kernel board hook Marek Vasut
2025-01-12 22:36 ` [PATCH 2/3] image: Add support for starting TFA BL31 as fitImage loadables Marek Vasut
2025-01-12 22:36 ` [PATCH 3/3] arm64: renesas: Add TFA BL31 handoff support Marek Vasut
@ 2025-01-15 1:13 ` Tom Rini
2 siblings, 0 replies; 19+ messages in thread
From: Tom Rini @ 2025-01-15 1:13 UTC (permalink / raw)
To: Marek Vasut
Cc: u-boot, Andre Przywara, Caleb Connolly, Igor Opaniuk,
Ilias Apalodimas, Julien Masson, Mattijs Korpershoek,
Maxim Moskalets, Michael Walle, Nobuhiro Iwamatsu,
Patrick Rudolph, Paul Barker, Paul-Erwan Rio, Peter Hoyes,
Raymond Mao, Sam Protsenko, Simon Glass, Sughosh Ganu
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
On Sun, Jan 12, 2025 at 11:36:57PM +0100, Marek Vasut wrote:
> Add empty weak assembler function armv8_switch_to_el2_prep() which is
> jumped to just before U-Boot determines which EL it is running in and
> decides which path to take to boot the Linux kernel.
>
> This weak function is meant to be used by architecture specific code
> to implement jump to a firmware blob, which then returns right past
> this weak function and continues execution of U-Boot code which then
> boots the Linux kernel. One example of such use case is when U-Boot
> jump tp TFA BL31, which switches from EL3 to EL2 and then returns to
> U-Boot code newly running in EL2 and starts the Linux kernel.
>
> The weak function is called with caches already disabled and DM shut
> down. Any preparatory work or even loading of more data must be done
> in board_prep_linux(), this hook is meant only for the final jump to
> the firmware and return to U-Boot before booting Linux.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread