I was looking at imx_hab_handler, which forwards calls into the BootROM on i.MX SoCs
in response to secure monitor calls. The BootROM call (and thus the SiP call) accepts
two pointers as arguments, where it writes data.
The plat/imx/imx8m/imx8m*/imx8m*_bl31_setup.c files map the RAM as MT_MEMORY | MT_RW,
which would mean that not only is it writable from TF-A side, but it's also mapped
I see no explicit cache maintenance in the i.MX SiP code for these two pointer
arguments and haven't been successful to find where in TF-A core code if at all,
complete D-Cache is flushed on SMC exit. Therefore I ask:
- Don't shared non-secure memory buffers between EL3 and lower EL require
explicit cache maintenance?
- Did I miss the place where this cache maintenance is done?
- How did it work so far? barebox does explicit flushing before HAB SiP,
invalidation after. U-Boot doesn't do cache maintenance.
Both apparently work...
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
The next release of the Firmware-A bundle of projects tagged v2.10 has an expected code freeze date of Nov, 7th 2023.
Refer to the Release Cadence section from TF-A documentation (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about…).
Closing out the release takes around 6-10 working days after the code freeze.
Preparations tasks for v2.10 release should start in coming month.
We want to ensure that planned feature patches for the release are submitted in good time for the review process to conclude. As a kind recommendation and a matter of sharing CI resources, please launch CI jobs with care e.g.:
-For simple platform, docs changes, or one liners, use Allow-CI+1 label (no need for a full Allow-CI+2 run).
-For large patch stacks use Allow-CI+2 at top of the patch stack (and if required few individual Allow+CI+1 in the middle of the patch stack).
-Carefully analyze results and fix the change if required, before launching new jobs on the same change.
-If after issuing a Allow-CI+1 or Allow-CI+2 label a Build start notice is not added as a gerrit comment on the patch right away please be patient as under heavy load CI jobs can be queued and in extreme conditions it can be over an hour before the Build start notice is issued. Issuing another Allow-CI+1 or Allow-CI+2 label will just result in an additional job being queued.
Thanks & Regards,
I just sent a series to gerrit:
I'm writing this email to add more context to this series, as I didn't
find how to to it with gerrit.
This series is only the TF-A part to add suspend to RAM support for the
TI K3 J7200 target.
Some modifications are also needed in Linux kernel, U-Boot (R5 SPL) and
During the suspend sequence, TF-A save itself in DRAM, in a reserved
memory region dedicated to lpm.
TF-A will be restored by R5 SPL.
We need to save it in DRAM (which will be in retention mode during
suspend) because as it runs in SRAM, it will be lost once the SOC is
powered-off by the PMIC.
Thomas Richard, Bootlin
Embedded Linux and Kernel engineering
There are multiple occurrences in TFA Code where assert statements are used to handle function arguments. But these assert statements are currently enabled only in debug mode. So, I wanted to know that will there be any harm in continuing to use assert statements in production code as well for handling failures?
This event has been canceled with a note:
"Hi, Cancelling as no topic proposed for this instance. Regards, Olivier."
TF-A Tech Forum
Thursday Oct 5, 2023 ⋅ 5pm – 6pm
Central European Time - Paris
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
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
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