Hello,
I'm working on a project for ChromeOS where we would like to be able to
load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted
rather than during the usual BL32 stage. We would do this via an SMC we
would add which would take the OpTee image from linux and then have EL3
load it and perform the init for SEL-1 at that time.
The reasoning behind this is that it's much easier to update the rootfs
than the FW on our devices, and we can still ensure the integrity of the
OpTee image if we load it early enough after the kernel boots.
The main questions I have are if there are any issues people would be aware
of by loading it after linux boots rather than during the usual BL32 stage?
And I would definitely want to upstream this work if it's something we can
do.
Thanks,
Jeffrey Kardatzke
Google, Inc.
Hi,
Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback.
This activity followed the request of some members of the Arm ecosystem [2].
The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot.
The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden.
The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data.
New types are meant to be added, following the needs and use-cases of the different communities.
Thus, these communities should be empowered to request new types!
To enable community contributions, the specification must be hosted in a location that is friendly to change requests.
We propose to host the spec in trustedfirmware.org (tf.org).
Tf.org hosts several open-source projects and already has an open governance model.
TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date.
Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.).
We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed!
If anyone has objections, we are happy to consider alternatives and associated trade-offs.
Regards
[1] https://developer.arm.com/documentation/den0135/latest
[2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>
According to the Generic Names Recommendation in the Devicetree
Specification Release v0.3, and the DT Bindings for the Renesas Reduced
Pin Count Interface, the node name for a Renesas RPC-IF device should be
"spi". The node name matters, as the node is enabled by passing a DT
fragment from TF-A to subsequent software.
Fix this by renaming the device nodes from "rpc" to "spi".
Fixes: 12c75c8886a0ee69 ("feat(plat/rcar3): emit RPC status to DT fragment if RPC unlocked")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
---
Background:
On Renesas R-Car Gen3 platforms, the SPI Multi I/O Bus Controllers
(RPC-IF) provide access to HyperFlash or QSPI storage. On production
systems, they are typically locked by the TF-A firmware, unless TF-A is
built with RCAR_RPC_HYPERFLASH_LOCKED=0. When unlocked, TF-A
communicates this to subsequent software by passing a DT fragment that
sets the "status" property of the RPC-IF device node to "okay".
Unfortunately there are several issues preventing this from working all
the way to Linux:
1. TF-A (and U-Boot on the receiving side) uses a device node name
that does not conform to the DT specification nor the DT bindings
for RPC-IF,
2. While U-Boot receives the RPC-IF enablement from TF-A, it does not
propagate it to Linux yet,
3. The DTS files that are part of Linux do not have RPC HyperFlash
support yet.
This patch takes care of the first issue in TF-A.
The related patches for U-Boot are [1].
Patches to enable RPC-IF support in Linux are available at [2].
Thanks for your comments!
[1] "[PATCH u-boot 0/3] renesas: Fix RPC-IF enablement"
https://lore.kernel.org/r/cover.1648544792.git.geert+renesas@glider.be
[2] "[PATCH 0/5] arm64: dts: renesas: rcar-gen3: Enable HyperFlash support"
https://lore.kernel.org/r/cover.1648548339.git.geert+renesas@glider.be
---
plat/renesas/rcar/bl2_plat_setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plat/renesas/rcar/bl2_plat_setup.c b/plat/renesas/rcar/bl2_plat_setup.c
index bbfa16927d6c2384..f85db8d650c6b1a5 100644
--- a/plat/renesas/rcar/bl2_plat_setup.c
+++ b/plat/renesas/rcar/bl2_plat_setup.c
@@ -574,7 +574,7 @@ static void bl2_add_rpc_node(void)
goto err;
}
- node = ret = fdt_add_subnode(fdt, node, "rpc@ee200000");
+ node = ret = fdt_add_subnode(fdt, node, "spi@ee200000");
if (ret < 0) {
goto err;
}
--
2.25.1
TL;DR: Attached is the TF-A LTS proposal doc. Please review and share
your thoughts.
Hello everyone,
Long term support for TF-A has a long history. As a community we have
flirted with it for a while, and like any flirtation, it started with
gossip -- in our case, over mailing list [1] -- more than two years
ago. Then Varun Wadekar did a wonderful tech forum presentation [2]
which demonstrated interest in the topic and raised interesting
questions about LTS.
After some time, the affair lost headline status, only to be revived
again [3], earlier this year. This time however, there is a formal
proposal (no pun intended). After the mailing list discussion and
feedback from TF-A tech forum [4], we have put together a draft which
attempts to give a concrete idea about what the TF-A LTS will look
like.
Please spare some time to read through it and share your feedback. The
plan is to put LTS into action this November.
Cheers!
Okash
[1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…
[2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf
[3] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[4] https://www.trustedfirmware.org/docs/TForg_LTS_proposal.pdf
Hi all,
I want to test how to trap the aborts caused by TZASC.
For example, when I use NS-EL1 (e.g., OS) to access a Secure region
(configured in TZASC), it will generate an abort.
But I am not sure how to trap it. I think it is an external abort, so
I enable the SCR_EL3.EA=1 and write a handler. However I cannot trap
it. Also, my other handlers in EL3 still do not report the abort.
Thus, how can I trap a TZASC abort? If I want to route it into EL3 to
handle, how can I do it?
Sincerely,
WANG Chenxu
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 3 of 3 defect(s)
** CID 380536: Control flow issues (NO_EFFECT)
/bl32/tsp/tsp_ffa_main.c: 220 in test_memory_send()
________________________________________________________________________________________________________
*** CID 380536: Control flow issues (NO_EFFECT)
/bl32/tsp/tsp_ffa_main.c: 220 in test_memory_send()
214 ERROR("Failed [%u] mmap_add_dynamic_region %u (%lx) (%lx) (%x)!\n",
215 i, ret,
216 (uint64_t)composite->address_range_array[i].address,
217 size, mem_attrs);
218
219 /* Remove mappings created in this transaction. */
>>> CID 380536: Control flow issues (NO_EFFECT)
>>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "i >= 0U".
220 for (i--; i >= 0U; i--) {
221 ret = mmap_remove_dynamic_region(
222 (uint64_t)ptr,
223 composite->address_range_array[i].page_count * PAGE_SIZE);
224
225 if (ret != 0) {
** CID 380535: Null pointer dereferences (REVERSE_INULL)
/bl32/tsp/ffa_helpers.c: 154 in memory_retrieve()
________________________________________________________________________________________________________
*** CID 380535: Null pointer dereferences (REVERSE_INULL)
/bl32/tsp/ffa_helpers.c: 154 in memory_retrieve()
148 uint32_t *total_length)
149 {
150 smc_args_t ret;
151 uint32_t descriptor_size;
152 struct ffa_mtd *memory_region = (struct ffa_mtd *)mb->tx_buffer;
153
>>> CID 380535: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "mb" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
154 if (retrieved == NULL || mb == NULL) {
155 ERROR("Invalid parameters!\n");
156 return false;
157 }
158
159 /* Clear TX buffer. */
** CID 380534: API usage errors (SWAPPED_ARGUMENTS)
________________________________________________________________________________________________________
*** CID 380534: API usage errors (SWAPPED_ARGUMENTS)
/bl32/tsp/tsp_ffa_main.c: 476 in handle_partition_message()
470
471 default:
472 INFO("TSP Tests: Unknown request ID %d--\n", (int) arg3);
473 }
474
475 /* Swap the sender and receiver in the response. */
>>> CID 380534: API usage errors (SWAPPED_ARGUMENTS)
>>> The positions of arguments in the call to "ffa_msg_send_direct_resp" do not match the ordering of the parameters:
* "receiver" is passed to "sender".
* "sender" is passed to "receiver".
476 return ffa_msg_send_direct_resp(receiver, sender, status, 0, 0, 0, 0);
477 }
478
479 /*******************************************************************************
480 * This function implements the event loop for handling FF-A ABI invocations.
481 ******************************************************************************/
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
This event has been canceled with a note:
"Apologies for the short notice. We have no topic this week and some key
folks are out on vacations. I'm hoping the Techforum on the 8th September
can be a followup LTS discussion on the proposal submitted to the Mailing
list. I'll formally organise that for the 8th next week."
TF-A Tech Forum
Thursday Aug 25, 2022 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi all,
I want to perform some encryption/decryption in TF-A.
I find that Arm provides some hardware-assisted instructions for
encryption and integrity verification (e.g., AESE, SHA1...). But it
seems that FVP does not support them.
I recently read Armv9 and know that Arm purposes SVE/SVE2 to
accelerate the matrix computation. It seems that it can be another
approach to accelerate the encryption.
Since I am a novice in Armv9 (and in FVP), thus, I want to ask:
(1) Do FVP and TF-A support the SVE? If yes, how to configure it?
(2) Do FVP and TF-A support the SVE2? If yes, how to configure it?
Looking forward to your reply!
Sincerely,
WANG Chenxu
Hi,
I am trying to setup and run the RME support in TF-A, using the steps described
here,
https://trustedfirmware-a.readthedocs.io/en/latest/components/realm-managem…
Build goes smoothly and when I launch FVP to run the RME tests using
the command line mentioned in the link, the FVP terminal_0 seems to
be get stuck at the below line,
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.7(debug):v2.7.0-235-g1631f9c75
NOTICE: BL1: Built : 11:44:37, Aug 22 2022
INFO: BL1: RAM 0x4035000 - 0x403c000
INFO: Loading image id=31 at address 0x4001010
INFO: Image id=31 loaded: 0x4001010 - 0x4001258
INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010
INFO: Loading image id=24 at address 0x4001300
INFO: Image id=24 loaded: 0x4001300 - 0x40015e4
INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300
INFO: BL1: Loading BL2
INFO: Loading image id=1 at address 0x4022000
INFO: Image id=1 loaded: 0x4022000 - 0x402cca1
NOTICE: BL1: Booting BL2
INFO: Entry point address = 0x4022000
INFO: SPSR = 0x3cd
INFO: Configuring TrustZone Controller
INFO: Total 6 regions set.
Both the tf-a-tests.git and trusted-firmware-a.git are master branch and
I am using the FVP_Base_RevC-2xAEMvA v11.18.16.
I am totally new to this setup and maybe I am missing something here.
Appreciate any help to get this resolved or tips to debug further.
Thanks,
Shameer