This is to inform you all that the TF-A Techforum for Thursday, 19th May 2022 is cancelled as we didn't receive any topic for this week.
The next meeting will now be Thursday, 2nd June 2022 at 16:00 - 17:00 BST.
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
Arm worked to draft a firmware handoff  specification, evolving it based on community feedback.
This activity followed the request of some members of the Arm ecosystem .
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.
 Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://firstname.lastname@example.org.…>
I would like to introduce "Manish Badarkhe" <Manish.Badarkhe(a)arm.com> who has been added to the list of maintainers. This is based on his contribution to the project recently.
Congratulations Manish B!
A project I’m working on requires write capability for a NOR flash device in BL2 (to update a small boot mux partition). I am considering adding this capability to the IO MTD layer (https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/io…), but before doing so wanted to confirm this is in line with the architecture of this subsystem. Can someone confirm if this is an acceptable change?
It looks like TF-A contains zlib 1.2.11 e.g. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/zlib/z…zlib.net gives their last release as 1.2.12 (March 27, 2022) with the following changelog:
"Fix a deflate bug when using the Z_FIXED strategy that can result in out-of-bound accesses.
Fix a deflate bug when the window is full in deflate_stored().
Speed up CRC-32 computations by a factor of 1.5 to 3.
Use the hardware CRC-32 instruction on ARMv8 processors.
Speed up crc32_combine() with powers of x tables.
Add crc32_combine_gen() and crc32_combine_op() for fast combines.
Due to the bug fixes, any installations of 1.2.11 should be replaced with 1.2.12."
I'm not sure if this is significant as I couldn't find usages of deflate, but thought I would mention it in case others are relying on this functionality and wish to update.
You have been invited to the following event with this note:
"An additional TF-A Techforum this week."
Title: TF-A Tech Forum (additional)
I'm creating an additional TF-A Techforum this week as we have a batch of
topics coming up so this is an additional meeting to our normal bi weekly
meetings. This session will. be recorded and made available on our TF0 Tech
forum pagesThis week we would like to present on: Arm CCA RMM
<-> EL3 interfacePresenter : Javier Almansa Sobrino Description:
Covering the communication interface between RMM and EL3. This comprises of
the Boot Interface and the RMM-EL3 runtime interface.Patches under review.
This will also cover the RMM <> EL3 world switch register
conventionRelated patch stack under
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
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 Organizer: Trusted
Firmware Public MeetingsTrusted Firmware Public Meetings
When: Thu Jun 23, 2022 4pm – 5pm United Kingdom Time
* joanna.farley(a)arm.com - organizer
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account
tf-a(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
Thanks for the detailed documentation about how to enable RME in tf-a. I try to replace the tftf.bin with the normal boot firmware (edk2) to load the Linux in the normal world, but it fails. The log message from terminal_0 is shown below:
INFO: RMM init start.
INFO: RMM init end.
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x88000000
INFO: SPSR = 0x3c9
I found a possible solution from the archives:
I try to modify the dts file under edk2-platform/Platform/ARM/VExpressPkg/DeviceTree/ to change the DDR memory range, which is similar to the modification for RME in [https://github.com/ARM-software/arm-trusted-firmware/blob/master/fdts/fvp-b…], but it does not solve the problem.
So, how can I boot Linux in the normal world with RME enabled?