- TF-A - lists.trustedfirmware.org

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

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 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() ________________________________________________________________________________________________________ *** CID 352832: Uninitialized variables (UNINIT) /plat/nvidia/tegra/soc/t194/drivers/mce/nvg.c: 197 in nvg_update_ccplex_gsc() 191 ret = EINVAL; 192 } else { 193 nvg_set_request_data((uint64_t)TEGRA_NVG_CHANNEL_UPDATE_CCPLEX_GSC, 194 (uint64_t)gsc_idx); 195 } 196 >>> CID 352832: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 197 return ret; 198 } 199 200 /* 201 * Cache clean operation for all CCPLEX caches. 202 */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

6 years, 1 month

1
0
0 0

Re: [TF-A] [Question] Why are the log related macros defined in multiple of 10's

by Olivier Deprez

Hi Sheetal, Your remark/question makes sense. The original requirement is described here: https://github.com/ARM-software/tf-issues/issues/232 We may get further update from Dan, but I sense this was to provision for intermediate log levels (as stated by Sandrine on phabricator). Will you be able to submit a patch for this? Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Sheetal Tigadoli via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 20 December 2019 15:48 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] [Question] Why are the log related macros defined in multiple of 10's Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

2
1
0 0

[Question] Why are the log related macros defined in multiple of 10's

by Sheetal Tigadoli

Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal

6 years, 1 month

1
0
0 0

[Question] Why are the log related macros defined in multiple of 10's

by Sheetal Tigadoli

Hi All, I wanted to understand the reason behind defining LOG_LEVEL_* macros as multiple of 10's, also same goes with LOG_MARKER_* macros. If we set the LOG macros to 1,2,3 and so on, we can avoid the mod and division operation when printing the msgs to console. Please let me your thoughts on this. Link to this question on Phabricator - https://developer.trustedfirmware.org/T624 Thanks Sheetal

6 years, 1 month

1
0
0 0

Re: [TF-A] RPi4 and CPU hotplugging

by Soby Mathew

> > Subject: [PATCH] rpi3/4: Add support for offlining CPUs > From: Jan Kiszka <jan.kiszka(a)siemens.com> > > The hooks were populated but the power down left the CPU in limbo-land. > What we need to do - until there is a way to actually power off - is to > turn off the MMU and enter the spinning loop as if we were cold-booted. > This allows the on-call to pick up the CPU again. > > Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> > --- > plat/rpi/common/rpi3_pm.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/plat/rpi/common/rpi3_pm.c b/plat/rpi/common/rpi3_pm.c > index 8c2d070c4..2a6bf076b 100644 > --- a/plat/rpi/common/rpi3_pm.c > +++ b/plat/rpi/common/rpi3_pm.c > @@ -123,6 +123,15 @@ static void rpi3_pwr_domain_off(const psci_power_state_t *target_state) > #endif > } > > +void __dead2 plat_secondary_cold_boot_setup(void); > + > +static void __dead2 > +rpi3_pwr_domain_pwr_down_wfi(const psci_power_state_t *target_state) > +{ > + disable_mmu_el3(); > + plat_secondary_cold_boot_setup(); > +} > + > /******************************************************************************* > * Platform handler called when a power domain is about to be turned on. The > * mpidr determines the CPU to be turned on. > @@ -224,6 +233,7 @@ static void __dead2 rpi3_system_off(void) > static const plat_psci_ops_t plat_rpi3_psci_pm_ops = { > .cpu_standby = rpi3_cpu_standby, > .pwr_domain_off = rpi3_pwr_domain_off, > + .pwr_domain_pwr_down_wfi = rpi3_pwr_domain_pwr_down_wfi, > .pwr_domain_on = rpi3_pwr_domain_on, > .pwr_domain_on_finish = rpi3_pwr_domain_on_finish, > .system_off = rpi3_system_off, > -- > 2.16.4 > Hi Jan, I have put in a suggestion for the change. Basically, if you are able to do a `reset` before spinning in `plat_secondary_cold_boot_setup()`, that would be ideal. Also, if `plat_secondary_cold_boot_setup()` can trap the primary CPU as well if it were to be offlined, then I think your changes should be good. Best Regards Soby Mathew

6 years, 1 month

2
2
0 0

Re: [TF-A] About disable gic cpuif in psci suspend or off

by Soby Mathew

Hi Jisheng, This is due to the power management requirement of GICv3. In section 7.1 of GICv3 specification : https://static.docs.arm.com/ihi0069/c/IHI0069C_gic_architecture_specificati… It says the that " Before powering down the CPU interface and the PE when the Redistributor is powered up, software must put the interface between the CPU interface and the Redistributor into the quiescent state or the system will become UNPREDICTABLE". In order to put the Redistributor in a quiescent state, all the group enables in CPU interface must be disabled , otherwise "setting GICR_WAKER.ProcessorSleep to 1 when the physical group enables in the CPU interface are set to 1 results in UNPREDICTABLE behavior." Hope that clarifies. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Jisheng > Zhang via TF-A > Sent: 05 December 2019 10:31 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] About disable gic cpuif in psci suspend or off > > Hi, > > In ATF-A, I usually see below code in psci suspend or off code path: > > /* Prevent interrupts from spuriously waking up this cpu */ > plat_arm_gic_cpuif_disable(); > > But per my understanding, before calling psci_suspend(), the NW, e.g linux > kernel has disabled all interrupts from cpu level, so here preventing interrupt is > to prevent the interrupts from secure world? > > Another question is: for Cortex A55, this is not necessary. Because > CA55 TRM says when the core_pwrdn_en bit is set, executing WFI > automatically masks all interrupts and wake-up events in the core. Am I right? > > Thanks in advance > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

2
1
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Joanna Farley

Julius, On the subject of DebugFS's purpose it was envisages and is today as Sandrine describes as a debug build only capability. Saying that though there has been some early thoughts that it could evolve into a Secure Debug feature where this type of capability or something like it is always on requiring debug certificates for authenticated access. This is something very much for a possible future evolution and is not in the patches available today. We would welcome any thoughts on such an evolution in this space. Joanna On 13/12/2019, 13:01, "TF-A on behalf of Sandrine Bailleux via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Julius, OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems. One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information. Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation. Julius, you wrote: > It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features. Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

2
1
0 0

Re: [TF-A] Design proposal: Property Access Layer

by Abhishek Pandit

Hi Louis, The term PAL is also used for platform abstraction layer so it "could" be confusing to have this being used for something different. Not necessarily suggesting to change anything but it might be worth considering this aspect. Thanks, Abhishek -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Louis Mayencourt via TF-A Sent: 19 November 2019 13:40 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Design proposal: Property Access Layer Hi everyone, Please let me introduce the `Property Access Layer` prototype: The Property Access Layer (PAL) is an abstraction layer for platform specific data, allowing a "property" to be queried and a value retrieved without the requesting entity knowing what backing store is being used to hold the data. It is used to bridge new and old ways of providing platform-specific data: Today, information like the Chain of Trust is held within several, nested platform-defined tables. In the future, it may be provided as part of a device tree blob, along with the information about images to load. Introducing this abstraction layer will make migration easier and will preserve functionality for platforms that cannot / don't want to use device tree. Please have a look at the patches: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2559/1 Regards, Louis IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

2
2
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Sandrine Bailleux

Hi Julius, OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems. One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information. Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation. Julius, you wrote: > It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS. So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features. Regards, Sandrine

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] BL2 MTD frameworks

by Olivier Deprez

Hi, Thanks George and Lionel for your answers. Following up and closing on this, the approach used in mentioned patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283) looks ok provided it should now build on all platforms. The original concern was about api breakage in the generic code, and that there might exist inconsistencies among platforms (ones depending on a 32b offset, others on 64 bits). Changing the generic seek api offset parameter from ssize_t to signed long long everywhere as a default makes it better compliant to using larger density storage chips in the long term. This is fine as long as it also still support older lower density chips. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 08 November 2019 18:34 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] [RFC] BL2 MTD frameworks Hi, Just to clarify a little bit more. There is no link here about a 32/64 bit architecture. The content of this change is to take care about new memory introduce (mtd devices) that are not based on size * LBA (where LBA=512) but size * LBA where (LBA=1) and in such case, the size could exceed the 4GB. It is not platform dependent and not architecture dependent, it's link to the connected MTD device only. I'm not sure that a new type is useful except if you want a type is modified regarding a platform flag such as USE_LARGE_MTD_DEVICE. Hope it's more clear. BR, Lionel On 11/5/19 3:20 PM, Gyorgy Szing via TF-A wrote: > Hi, > > I did not investigated all the details so what stays below may contain mistakes, but still I would like to add some comments. > > "using a type for the offset" > The type we use for this purpose seems to be a configuration parameter for the IO layer as it depends on the upper layer being used with the IO library. For example libc uses "long int" to specify the file offset (fseek, ftell), using a different type while running below libc does not seem to be a good idea. > The best option seems to be to define a type like (as Olivier mentioned) lib/zlib does. How we set this configuration parameter during the build is a question. The offset type could be dictated by the platform, the architecture (aarch32 or aarch64) or by the user. Which one is worth to implement needs investigation. > > If it is a good idea to use the same name "off_t" as zlib uses (or even the same type) is be questionable. It may give us more flexibility if we use a dedicated name, and the configuration maps the IO type to the one used by the upper layer. > > "32 bit backward compatibility" > Another angle worth to consider is the 32/64 bit compatibility. I.e.: newlib can use 64 bit offsets even on 32 bit architectures, and they use some wrappers to maintain binary compatibility with old builds. When built in a compatible manner, functions using the standardized names use 32 bit wide offsets and call the real 64 bit implementation as a wrapper. > To solve compatibility issues we could use a similar pattern. Instead of changing the existing function, we could add a new one (i.e. seek64). Then new 64 bit aware code could use the new function if available, and legacy code could call the old one. Longer term it is an option to deprecate the 32 bit version. > > "use stdint.h types" > And a finally: when selecting the type used for off_t (or whatever we are going to call it) please consider using stdint.h types (i.e. int_fast64_t). > > /George > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Olivier Deprez via TF-A > Sent: 25 October 2019 14:42 > To: tf-a(a)lists.trustedfirmware.org; Lionel DEBIEVE <lionel.debieve(a)st.com> > Subject: Re: [TF-A] [RFC] BL2 MTD frameworks > > Hi Lionel, > > On https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283 > I'm extending the discussion to the TF-A ML, to get people's opinion. > > The idea is to extend the io_seek offset parameter from ssize_t to unsigned long long. > There are indeed good reasons for that as flash storage density grows over the years. > > Now on the change, the struct io_dev_funcs seek function pointer is generic for the whole codebase / drivers. > So currently the change breaks the builds for at least rcar, stratix10 (did not check others from that point). > > An alternative is defining offset as an off_t type which is ssize_t by default, and only unsigned long long based on the platform (using _FILE_OFFSET_BITS=64). This pattern actually already exists in lib/zlib > > Other option is to change the generic prototype for all platform drivers (then we ensure all platforms build and supply platform patches). > > What do ML people think? > > Regards, > Olivier. > > > > ________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Lionel DEBIEVE via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 18 October 2019 17:26 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] [RFC] BL2 MTD frameworks > > Hello Maintainers, > > I've sent a patch series around MTD framework management into BL2 stage (cf https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2283). > > This patch series will add following frameworks: > > - a raw NAND framework implementation to support SLC NAND devices. Current implementation is limited to read operations without ECC corrections. Overrides are available to use hardware ECC from controller or low-level drivers. It also supports ONFI detection management but this can also be disabled or overridden by platform specific data. > - a SPI-MEM framework (inspired from kernel/u-boot implementation) that encapsulates all SPI operations to SPI low level drivers. > - a SPI-NAND framework based on SPI-MEM to support SPI NAND devices. This framework is also limited to the read operation. It uses single command, address and data bus width as legacy but can be overridden by platform. > - a SPI-NOR framework based on SPI-MEM to manage SPI NOR devices. It is also limited to read operations using single command, address and data bus width as legacy (override still possible by platform). The framework embeds some specific implementations for manufacturers specific behavior in case of quad mode configuration activation. > > This patch series also includes: > > - a new io_mtd interface to manage a generic access to all these frameworks. > - a NAND core driver that accesses independently to raw NAND or SPI-NAND framework. This core driver requires a scratch buffer defined by platform to manage unaligned pages (could be defined to 0 in case of aligned page) and limits access to a single NAND instance management. > - a complete integration is available based on STM32MP1 platform. > > Tests have been performed with the following devices: > > SLC NAND: > - Micron MT29F8G08ABACAH4 (ONFI) > - Micron MT29F8G16ABACAH4 (ONFI) > - Toshiba TH58NVG3S0HTAI0 (Non ONFI) > - Toshiba TC58BVG1S3HTAI0 (On die ECC) > > SPI NOR: > - Macronix MX25L51245G > - Cypress/Spansion S25FL512 > - Micron n25q512ax3 > > SPI-NAND: > - Micron MT29F2G01ABAGD > > Waiting for your comments. > > Best regards, Lionel > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A