Hi,
Patrick has sent 2 correction patches for PSCI stack in OSI mode there:
https://review.trustedfirmware.org/q/topic:%22fix_psci_osi%22
But when running CI+2, there are 2 platforms for which 2 PSCI OSI tests
are failing:
fvp-ext-pstate-ea-el3|fvp-default|fvp-tftf-fip.tftf-cortexa57x4a53x4-debug
fvp-ext-pstate-ea-el3|fvp-default|fvp-tftf-fip.tftf-aemv8a-debug
I'm not familiar with those test configs, but when checking lava logs,
I see those traces for failing tests:
2024-01-11T14:21:59 > Executing 'CPU suspend to powerdown at level 1 in
OSI mode'
2024-01-11T14:21:59 INFO: Booting
2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:21:59 INFO: Booting
2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:21:59 INFO: Booting
2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:21:59 INFO: Booting
2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:21:59 INFO: Booting
2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:21:59 INFO: Booting
2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:21:59 INFO: Booting
2024-01-11T14:21:59 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:21:59 INFO: Going into suspend state
2024-01-11T14:22:00 INFO: Going into suspend state
2024-01-11T14:22:00 INFO: Going into suspend state
2024-01-11T14:22:00 INFO: Going into suspend state
2024-01-11T14:22:00 INFO: Going into suspend state
2024-01-11T14:22:00 INFO: Going into suspend state
2024-01-11T14:22:00 INFO: Going into suspend state
2024-01-11T14:22:00 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 TEST COMPLETE Failed
2024-01-11T14:22:03 Wrong value: expected 0, got -3
2024-01-11T14:22:03 > Executing 'CPU suspend to powerdown at level 2 in
OSI mode'
2024-01-11T14:22:03 INFO: Booting
2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:22:03 INFO: Booting
2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:22:03 INFO: Booting
2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:22:03 INFO: Booting
2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:22:03 INFO: Booting
2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:22:03 INFO: Booting
2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:22:03 INFO: Booting
2024-01-11T14:22:03 INFO: Registered IRQ handler 0x8801b274 for IRQ #7
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Going into suspend state
2024-01-11T14:22:03 INFO: Saving system context
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Unregistered IRQ handler for IRQ #7
2024-01-11T14:22:03 INFO: Powering off
2024-01-11T14:22:03 INFO: Restoring system context
2024-01-11T14:22:03 INFO: Resumed from suspend state
2024-01-11T14:22:03 TEST COMPLETE Failed
2024-01-11T14:22:03 Wrong value: expected 0, got -3
The "Resumed from suspend state" message interleaved with "Going into
suspend state" seem strange, but I cannot say what could be wrong there.
Maybe there is something wrong with the TF-A patches?
Or the platforms tests or configs need to be updated?
If you have any clue that would be very helpful!
Thanks,
Yann
Hi,
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
cacheable.
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...
Thanks,
Ahmad
---
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 |
This event has been canceled with a note:
"Hi, Cancelling as no topic proposed. Thanks & Regards, Olivier. "
TF-A Tech Forum
Thursday Jan 11, 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/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
1. misra_c_2012_rule_15_1_violation: Using "goto" statement.
In the file common/bl_common.c and other related files, getting misra_c_2012_rule_15_1_violation: Using "goto" statement. during the Coverity MISRA-C analysis.
if (...) {
goto exit;
}
exit:
some operation
Resolution: goto statement is replaced with exit_func() and new variable is introduced to store the return value of exit_func().
exit_func()
some operation
int ret;
if (...) {
ret = return value of exit func()
}
return ret;
Is it possible to fix MISRA 15.1 like this in open source? Please suggest.
2. misra_c_2012_rule_15_5_violation: This return statement is not the final statement in the compound statement that forms the body of the function.
In the file common/bl_common.c, lib/xlat_tables/aarch64/xlat_tables.c and other related files, getting misra_c_2012_rule_15_5_violation: This return statement is not the final statement in the compound statement that forms the body of the function. during the Coverity MISRA-C analysis.
if (...) {
return <something>
}
if (...) {
return <something>
}
return;
Resolution: Taken new variable and assign the return result to new variable and calling only one return statement in end of the function.
int result;
if (...) {
result = <something>
} else {
if (...) {
result = <something>
}
}
return result;
Is it possible to fix MISRA 15.5 like this in open source? Please suggest.
Thanks & Regards,
Nithin G
Hello,
Trusted Firmware-A LTS version 2.8.14 is now available. This release introduces errata workarounds for Cortex-A520, Cortex-A710, and Neoverse X2 CPUs.
The complete list of changes can be found here<https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.14/change-log.html>.
Thanks.
Hello TF-A and TF-M communities,
I've done 2 minor updates to the generic tf.org project maintenance
process, which TF-A and TF-M both use. Please see the pull request here:
https://github.com/TrustedFirmware/tf_docs/pull/1
Please provide your feedback on the pull request, if any.
Happy end-of-year celebrations to all!
Best regards,
Sandrine
Dear all,
we want analyze stack usage details when we build TF-A for armclang compiler but we are not able generate stack usage details.
sorry for long thread and question please go through and suggest way forward to perform stack analysis with TF-A armclang build.
as per https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… (section 2.3)
when CC is set to armclang, GCC linker is used default (since the TF-A build system doesn’t currently support Arm Scatter files)
So when we try to generate stack usage details we will not be able to use GCC -fstack-usage and -fdump-ipa-calgraph since CC is set to armclang and these flags will be un-recognized.
Since we are building this for armclang we attempted to use following armlinker flags along with -g compiler flag (refer link:https://developer.arm.com/documentation/100748/0607/writing-optimized-…).
--info=stack, --calgrapth, --calgraph_output=text
But we end up with unrecognized options error for --info=stack, --calgrapth, --calgraph_output=text
This error occurs because GCC linker is used default as per above link section 2.3 (since the TF-A build system doesn’t currently support Arm Scatter files)
So we end up with not having stack usage details generated.
Q1: Any suggestion to generate stack usage when CC=armclang and GCC linker is used by default.
Q2: if we attempt to change LD with armlink we will end up with "Fatal error: L6031U: Could not open scatter description file."
https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/initial-… section 2.3 suggest that "that the default linker may be manually overridden using the LD variable" can you please let us know how to override LD with armlinker without getting scatter issue.
Using: armclang 6.6.2 version.
Thank you
Shivakumar Diggi
This event has been canceled with a note:
"Hi, Cancelling the TF-A Tech Forum as no topic planned. Thanks & Regards,
Olivier. "
TF-A Tech Forum
Thursday Dec 14, 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
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
Hello,
In the file common/bl_common.c and other related files, there are instances where function parameters are being modified. This leads to violations when running the Coverity MISRA-C analysis for the ZynqMP platform.
To address this issue a new variable is declared and used to store the value from the argument in the code. Is it possible to fix by taking a new variable? Please provide your suggestions.
Regards,
Nithin G
Hello,
In the file lib/xlat_tables/xlat_tables_common.c and other related files, the condition clause of the for loop does not use the loop counter variable "mm". This leads to violations when running the Coverity MISRA-C analysis for the ZynqMP platform.
Addressing this issue added mm as part of loop counter and this belongs to core translational table logic and other violations also related to this. Is it possible to address this issue? Please provide your suggestions.
Regards,
Nithin G
Hello,
Trusted Firmware-A LTS version 2.8.13 is now available. This release introduces workarounds for new CPU errata for Cortex-A78C, Cortex-X3, and Neoverse V1/V2. It also adds support for the SLS mitigation.
The complete list of changes can be found here<https://trustedfirmware-a.readthedocs.io/en/lts-v2.8.13/change-log.html>.
Thanks.
Hello,
In the file bl31/bl31_main.c, there is a function named bl31_lib_init with its definition. Simultaneously, the declaration of this function is included in include/bl31/bl31.h since the function bl31_lib_init used only in one translational unit. leading to a violation when running the Coverity MISRA-C analysis for the ZynqMP.
Addressing this issue need to remove the declaration of the function from the bl31.h file and making its definition static. To maintain visibility, included a static declaration in the bl31_main.c file. However, it will may impact in future modifications due to the removal of the declaration in bl31.h. Please provide your suggestions.
Regards,
Nithin
Dear All,
We would like to announce that we have published an experimental project called rust-spmc which is a S-EL1 FF-A Secure Partition Manager Core implementation in Rust. We started this as a free time project and now we had the opportunity to publish it on trustedfirmware.org. In its current state it has a partial implementation of the FF-A protocol, and it is able to run the secure partitions of Trusted Services with all tests passing on Arm FVP. It also provides the required compartmentalization between the S-EL0 secure partitions.
Please note that the project is experimental (i.e. PoC, not suitable for production) and it is currently not scheduled by Arm for further development.
The Rust language is an ideal language for implementing firmware components given its lack of undefined behavior and its memory safety guarantees. Our goal was to demonstrate the capabilities of language in a security critical firmware environment and to gather feedback from partners which could open up the possibility of further development of the project.
The repository is available here: https://git.trustedfirmware.org/rust-spmc/rust-spmc.git/
We also prepared a readme with instructions for testing the project: https://git.trustedfirmware.org/rust-spmc/rust-spmc.git/about/
Please reach out to us if you are interested in the project or if you have any questions.
Regards,
Bálint Dobszay & Imre Kis
This event has been canceled with a note:
"Hi, Cancelling the TF-A Tech Forum as no topic. Thanks & Regards,
Olivier. "
TF-A Tech Forum
Thursday Nov 30, 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
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
When booting my Pine64 Rock64 (rk3328), I see the following warning:
WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
That warning is present in u-boot 2023.01 and also in 2023.07.
Asking on their IRC channel and they indicated it should be fixed in TF-A.
In the source code I saw various commits which all seem a variation of
74665119f04de0cd7c735fa741aff607a4a9fde8
titled "Enable workaround for Cortex-A53 erratum 1530924"
But such a commit seems to be missing for the rk3328 platform.
I guess a patch like this is needed to fix that?
```patch
diff --git a/plat/rockchip/rk3328/platform.mk b/plat/rockchip/rk3328/
platform.mk
index 5b4766d51..bd86a1cc8 100644
--- a/plat/rockchip/rk3328/platform.mk
+++ b/plat/rockchip/rk3328/platform.mk
@@ -65,6 +65,7 @@ include lib/libfdt/libfdt.mk
# Enable workarounds for selected Cortex-A53 errata
ERRATA_A53_855873 := 1
+ERRATA_A53_1530924 := 1
$(eval $(call add_define,PLAT_EXTRA_LD_SCRIPT))
$(eval $(call add_define,PLAT_SKIP_OPTEE_S_EL1_INT_REGISTER))
```
The Contributor’s Guide indicates that it requires a Microsoft Github account,
so I opted to post a patch to this list.
Cheers,
Diederik
PS: https://developer.trustedfirmware.org/ seems to be full of spam; you may
want to look into that.
Hello,
Trusted Firmware-A LTS version 2.8.12 is now available. This release removes the Cryptocell driver support and contains fixes for the Tegra platform, the SMCCC library, and SDEI.
The complete list of changes can be found here<https://ci-builds.trustedfirmware.org/static-files/DcqMVUzlEWpu-LYx_0-RuHeu…>.
Thanks.
TL;DR: move Mandatory features to be runtime checked (value 2)
Month ago there was changeset from Govindraj Raja merged [1]. The plan
was to enable all mandatory features based on architecture version set
by plaform (using ARM_ARCH_{MAJOR,MINOR} variables).
1. https://review.trustedfirmware.org/q/topic:%22gr/build_refactor%22
The idea is nice. But only for final products. If you are working on
silicon bring up or on virtualization platform (QEMU or other) then you
got hit badly...
I am working on SBSA Reference Platform in QEMU. It can have one of
several cpu models. From old v8.0 cores up to v9.0 ones. And then there
is also 'max' core which cannot be mapped to any architecture level
because it contains all Arm cpu features QEMU can emulate. We need to
support all of them in one TF-A binary. Whenever something fails we
have some cpu cores in non-bootable state.
We had to enable FGT to get 'max' boot Linux. Now we have to move DIT to
be runtime checked to boot anything below Neoverse-V1 at all. And HCX to
get 'max' boot Linux again.
At current state of TF-A we cannot handle it. Toplevel Makefile includes
platform.mk which sets ARM_ARCH_{MAJOR,MINOR} and then
make_helpers/arch_features.mk enables mandatory options by setting them
to value "1" which means "present, no need to check".
Due to this we have those changes in Gerrit:
DIT: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24870
TRF: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23648
And instead of sending another one to switch FGT, RNG and HCX I decided
to write this email.
I have spent half of day today bisecting TF-A, booting several tools and
operating systems to check how we are and where the problem is. Still
have to get Neoverse-N2 booting properly but other than then I got to
the point where all cpu cores boot into Linux.
We need to change make_helpers/arch_features.mk to stop enabling mandatory
features as "present, no need to check" (value '1') but to use runtime
check (value '2') instead. This way any platform which contains CPU not
yet fully developed can boot TF-A. Or platform where one firmware can boot
different cpu models.
I am sorry that I bring it so late in release cycle but was unable to use
computer for a development for some time.
We have executed below command on terminal to get stack size using ARMCLANG compiler. but we are getting "undefined symbol".
armclang --target=arm-arm-none-eabi -march=armv8-a -c -g file.c -o file.o
armlink file.o --info=stack
armlink file.o --callgraph -o FileImage.axf
Could anyone answer me that how to get stack size using ARMCLANG compiler for TFA code.
This event has been canceled with a note:
"Hi, Cancelling this week as no topic. Thanks & Regards, Olivier."
TF-A Tech Forum
Thursday Nov 16, 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
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
Hello,
Trusted Firmware-A LTS version 2.8.11 is now available. This release contains the workarounds for CPU errata, platform errata, and fixes for Versal/Versal-NET security vulnerabilities.
The complete list of changes can be found here<https://ci-builds.trustedfirmware.org/static-files/NdY070C96xYcXq0KeqQzbFaI…>.
Thanks.
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 405370: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_stat.c: 210 in psci_get_stat()
________________________________________________________________________________________________________
*** CID 405370: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_stat.c: 210 in psci_get_stat()
204 /* Get the index into the stats array */
205 local_state = state_info.pwr_domain_state[pwrlvl];
206 stat_idx = get_stat_idx(local_state, pwrlvl);
207
208 if (pwrlvl > PSCI_CPU_PWR_LVL) {
209 /* Get the power domain index */
>>> CID 405370: Memory - illegal accesses (OVERRUN)
>>> Overrunning array "psci_cpu_pd_nodes" of 16 16-byte elements at element index 4294967295 (byte offset 68719476735) using index "target_idx" (which evaluates to 4294967295).
210 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node);
211 for (lvl = PSCI_CPU_PWR_LVL + 1U; lvl < pwrlvl; lvl++)
212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node);
213
214 /* Get the non cpu power domain stats */
215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx];
** CID 405369: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_stat.c: 218 in psci_get_stat()
________________________________________________________________________________________________________
*** CID 405369: Memory - illegal accesses (OVERRUN)
/lib/psci/psci_stat.c: 218 in psci_get_stat()
212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node);
213
214 /* Get the non cpu power domain stats */
215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx];
216 } else {
217 /* Get the cpu power domain stats */
>>> CID 405369: Memory - illegal accesses (OVERRUN)
>>> Overrunning array "psci_cpu_stat" of 16 32-byte elements at element index 4294967295 (byte offset 137438953471) using index "target_idx" (which evaluates to 4294967295).
218 *psci_stat = psci_cpu_stat[target_idx][stat_idx];
219 }
220
221 return PSCI_E_SUCCESS;
222 }
223
** CID 405368: (NEGATIVE_RETURNS)
/lib/psci/psci_stat.c: 210 in psci_get_stat()
/lib/psci/psci_stat.c: 218 in psci_get_stat()
________________________________________________________________________________________________________
*** CID 405368: (NEGATIVE_RETURNS)
/lib/psci/psci_stat.c: 210 in psci_get_stat()
204 /* Get the index into the stats array */
205 local_state = state_info.pwr_domain_state[pwrlvl];
206 stat_idx = get_stat_idx(local_state, pwrlvl);
207
208 if (pwrlvl > PSCI_CPU_PWR_LVL) {
209 /* Get the power domain index */
>>> CID 405368: (NEGATIVE_RETURNS)
>>> Using variable "target_idx" as an index to array "psci_cpu_pd_nodes".
210 parent_idx = SPECULATION_SAFE_VALUE(psci_cpu_pd_nodes[target_idx].parent_node);
211 for (lvl = PSCI_CPU_PWR_LVL + 1U; lvl < pwrlvl; lvl++)
212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node);
213
214 /* Get the non cpu power domain stats */
215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx];
/lib/psci/psci_stat.c: 218 in psci_get_stat()
212 parent_idx = SPECULATION_SAFE_VALUE(psci_non_cpu_pd_nodes[parent_idx].parent_node);
213
214 /* Get the non cpu power domain stats */
215 *psci_stat = psci_non_cpu_stat[parent_idx][stat_idx];
216 } else {
217 /* Get the cpu power domain stats */
>>> CID 405368: (NEGATIVE_RETURNS)
>>> Using variable "target_idx" as an index to array "psci_cpu_stat".
218 *psci_stat = psci_cpu_stat[target_idx][stat_idx];
219 }
220
221 return PSCI_E_SUCCESS;
222 }
223
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…