Greetings,
Armv9 introduces the RME and GPT technology. The GPT will separates
the memory into unlimited regions with specific attributes. However,
when I read the Armv9 manual and source code of TF-A, I still have
some problems:
1. It seems that GPT is a feature on CPU, but not on a specific device
(e.g.,TZC-400). Thus, will GPT conflict with TZC-400? I mean, when
performing VA->PA on RAM, what is the detailed process if I enable
both GPT and TZC-400?
2. I use the Arm FVP with Armv9 and RME extension enabled, and TF-A is
"arm_cca" branch (with TF-A v2.5). Thus, in this version, what is the
configuration for TZC-400 and GPT? Will it disable TZC-400 (I mean,
GPT only) when booting Normal World?
3. Does GPT handle peripheral access (e.g., from DMA, GPU, Sensors...
etc.)? I know TZC-400 will do it with NSAID.
4. Will GPT configures Read/Write/Execute features?
All comments are valuable!
SIncerely,
WANG Chenxu
All,
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.
Thanks,
Bipin Ravi
Hi,
I have tried this before, there is a problem.
on Armv8, when MMU disabled, the default attribute of memory is device,
and device memory access has alignment requirements. For example,
accessing address (0x1) will result in fault.
Ben via TF-A <tf-a(a)lists.trustedfirmware.org> 于2022年7月19日周二 17:02写道:
> Hello,
>
> To decrease feature in BL1, I plan to disable MMU in BL1 stage.
> Are there any potential issues besides performance issues?
>
> BRs
>
> ------------------------------
> Ben(a)tsingmicro.com
> --
> TF-A mailing list -- tf-a(a)lists.trustedfirmware.org
> To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org
>
Hi,
Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 379362: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_common.c: 1046 in psci_is_last_on_cpu_safe()
________________________________________________________________________________________________________
*** CID 379362: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_common.c: 1046 in psci_is_last_on_cpu_safe()
1040 unsigned int i = 0;
1041
1042 /*
1043 * Traverse the forest of PSCI nodes, nodes with no parents
1044 * (invalid-nodes) are the root nodes.
1045 */
>>> CID 379362: Memory - illegal accesses (OVERRUN)
>>> Overrunning array "psci_non_cpu_pd_nodes" of 5 16-byte elements at element index 5 (byte offset 95) using index "i" (which evaluates to 5).
1046 while ((psci_non_cpu_pd_nodes[i].parent_node ==
1047 PSCI_PARENT_NODE_INVALID) &&
1048 (i < PSCI_NUM_NON_CPU_PWR_DOMAINS)) {
1049 psci_get_parent_pwr_domain_nodes(
1050 psci_non_cpu_pd_nodes[i].cpu_start_idx,
1051 PLAT_MAX_PWR_LVL, parent_nodes);
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…
Hello,
To decrease feature in BL1, I plan to disable MMU in BL1 stage.
Are there any potential issues besides performance issues?
BRs
Ben(a)tsingmicro.com
Hi All,
Is there any public BL31 memory usage data, such as static image size
and runtime memory usage, with different feature enabled?
For example,
typical PSCI feature would require image size XXKB, runtime memory XXKB.
enabling FFA would enlarge image size by XXKB, runtime memory enlarge XXKB.
we are evaluating how much On-Chip RAM could be assigned for BL31,
if there are any public data available, that would be great.
Thanks,
Peng.
Hi,
There have been discussions about having long term support releases
for TF-A, e.g. the email thread [1] and a tech forum [2]. For partners
releasing TF-A in their production devices, LTS is very much needed.
From the previous discussions, it seems like there is an agreement
that LTS is a good idea but we need to build consensus on how to
support it. Any thoughts on this?
Thanks,
Okash
[1] https://lists.trustedfirmware.org/archives/search?mlist=tf-a%40lists.truste…
[2] https://www.trustedfirmware.org/docs/TF-A-LTS.pdf
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.…>
Hi all,
I am using FVP base RevC. Recently I heard that this FVP supports a
Mali G76 GPU, and I want to test it.
To configure it, initially I add a node in
linux/arch/arm64/boot/dts/arm/fvp-base-aemv8a-aemv8a.dtsi, but it
doesn't work. Finally, I find that I should configure
trusted-firmware-a/fdts/fvp-base-gicv3-psci-1t.dts, and I can see a
mali GPU node in /proc/device-tree.
One of my booting command (sorry, the entire booting command is TOO
long) is "--data
cluster0.cpu0=arm-reference-platform/output/fvp/fvp-oe/uboot/fvp-base-aemv8a-aemv8a.dtb@0x82000000".
And I use the following shell command to compile the TF-A: make
PLAT=fvp all CROSS_COMPILE=aarch64-none-elf- ENABLE_RME=1 DEBUG=1
ARCH=aarch64 fip
BL33=arm-reference-platform/output/fvp/components/fvp/uboot.bin
FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts
ARM_DISABLE_TRUSTED_WDOG=1.
So, I wonder, why the real DTS is in TF-A, instead of Linux?
BTW, I wanna ask another question (although it is not proper to ask
here, I cannot find FVP's mailing list): Can someone provide a proper
dts configurations for FVP's Mali G76 GPU?
Sincerely,
WANG Chenxu