Hi all,
I am trying to raise a question about SDS.
As you know, SDS (Shared data storage) is used to communicate or exhcange info among different processor units like AP, SCP, RSE, etc.
So, do we need to add some lock mechanisms to protect the data when one processor entity is accessing it? After I reviewed the open source Trusted Firmware and SCP firmware
it looks to me that both Trusted Firmware and SCP directly access the shared memory region without any limitation. Currently, it just uses the 'valid' flag to identify if the data is ready to use,
is this good enough?
Looking forwared to your response! Thank you!!!
Best Regards,
Bob
Hi Marc,
In TF-A, the FF-A version is currently set to v1.2, but I am unable to find the corresponding implementation for EL3 SPMC configuration.
I'm particularly interested in the support for FF-A Notification Mechanism. Could you please provide the timeline for when this will be added to the TF-A EL3 SPMC configuration?
Thank You!
Akshay Belsare
Hello,
I would like to use PSA calls for an application on STM32MP2 platform.
I've seen the psa_call() API that I could use, in
drivers/arm/rse/rse_comms.c.
The problem is that it is based on MHU mailbox, which I don't have on
STM32MP2.
So I was planning plan to disentangle RSE comms and MHU, having a new
file in the same directory to manage MHU.
This code should then be under a flag, I could re-use PLAT_MHU_VERSION.
Setting it to 0, would mean no MHU.
AFAICT TF-M uses that split with a dedicated file:
rse_comms_hal.c: Abstracts MHU message sending and receiving.
(see
https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html).
Do you think this approach sounds right?
Thanks,
Yann
Hi,
Cancelling today's Sep 19th instance as no topic proposed.
Regards,
Olivier.
________________________________
From: Trusted Firmware Public Meetings
Sent: 24 July 2024 17:36
To: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Canceled event: TF-A Tech Forum @ Thu Sep 19, 2024 5pm - 6pm (GMT+2) (tf-a(a)lists.trustedfirmware.org)
When: 19 September 2024 17:00-18:00.
Where:
This event has been canceled.
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/<https://www.google.com/url?q=https%3A%2F%2Fwww.trustedfirmware.org%2Fmeetin…>
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvd…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fmy%2Ftruste…>
One 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-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…>
When
Thursday Sep 19, 2024 ⋅ 5pm – 6pm (Central European Time - Paris)
Guests
tf-a(a)lists.trustedfirmware.org<mailto:tf-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>
This event has been canceled.
TF-A Tech Forum
Thursday Sep 19, 2024 ⋅ 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 here:
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Trusted
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://linaro-org.zoom.us/my/trustedfirmware?pwd=VktXcm5MNUUyVVM4R0k3ZUtvdU84QT09
One 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
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 experts,
I tried to allocate a physical memory address in Linux Kernel, and
pass the memory address to tf-a using smc call. As I asked in previous
mails
(https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…),
tf-a can not access the physical memory address directly, so I try to
use the `mmap_add_dynamic_region_alloc_va` function in `xlat_table_v2`
Library, and map the physical memory in tf-a.
After calling the function, It does return a new virtual memory
address, but I still failed to access the address, is there any details
I have missed? Here is the code:
```
NOTICE("phys_addr: 0x%lx, virt_addr: 0x%lx\n", phys_addr, virt_addr);
int rc = mmap_add_dynamic_region_alloc_va(phys_addr, ptr_virt_addr,
size, MT_NS | MT_RW_DATA);
if (rc) {
WARN("Failed to map memory at 0x%lx: %d\n", phys_addr, rc);
return;
}
NOTICE("virt_addr_el3: 0x%lx\n", virt_addr_el3);
NOTICE("virt_addr_el3[0] = 0x%x\n", *((uint32_t *)virt_addr_el3));
```
Here is the output:
```
NOTICE: phys_addr: 0x40f0000, virt_addr: 0xffff0000040f0000
NOTICE: mm.base_va: 0
NOTICE: mm.base_va: 100000000
NOTICE: virt_addr_el3: 0x100000000
[ 38.540464] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 38.546584] rcu: 4-...0: (1 ticks this GP)
idle=4224/1/0x4000000000000000 softirq=125/125 fqs=2625
[ 38.555651] (detected by 0, t=5252 jiffies, g=-779, q=16 ncpus=8)
[ 38.561843] Task dump for CPU 4:
[ 38.565075] task:main state:R running task stack:0
pid:195 ppid:181 flags:0x00000002
[ 38.575015] Call trace:
[ 38.577464] __switch_to+0xe4/0x160
[ 38.580975] 0x42
```
I would be grateful for any advice or suggestions you may have.
Sincerely,
Feifan