- TF-A - lists.trustedfirmware.org

[RFC] New feature in TF-A to load encrypted FIP payloads

by Sumit Garg

Hi Everyone, The motivation behind this new feature comes from DRM robustness rules. DRM content vendors want to make it even harder to reverse engineer Trusted Execution Environment (TEE) and therefore would like to see that Trusted OS (BL32 payload) is not just signed, but also encrypted. Dan, Matteo, In continuation to our discussions at Linaro Connect SAN19 regarding support for encrypted firmwares (especially encrypted Trusted OS as BL32 payload) in TF-A. I have tried to come up with below RFC patch-set based on TBBR [1] optional requirement: R070_TBBR_FUNCTION. RFC patch-set: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2494 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2496 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2497 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2498 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2499 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2500 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2501 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2502 Also, I have used QEMU as a reference platform to test this feature (instructions documented as part of "[PATCH 9/9] docs: qemu: Add instructions to boot using FIP image"). So that it's easier for people interested in this feature to test. I look forward to hear feedback/comments on this new feature. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… Regards, Sumit

5 years, 11 months

1
0
0 0

Notice of SPCI-SPM Prototype Removal

by Paul Beesley

Hello, This message is to provide advance notice that the experimental Secure Partition Manager (SPM) component - based around the SPCI Alpha 1 specification - will be removed from the codebase within the next few weeks. This component was deprecated for the v2.2 release. Normally a component stays in the codebase for one full release cycle after being deprecated but that does not apply to experimental and/or prototype features such as this one. The intention is not to replace this component directly with a similar SPM component but to instead implement an EL3 SPCI dispatcher component that enables the use of secure partitions with an SPM at either S-EL1 or at S-EL2 (v8.4 or later). This dispatcher would be compliant with the latest public draft of the Secure Partition Client Interface (SPCI) specification at the time. Please note that the SPM-MM (Management Mode) component is *not* going to be removed as part of this work. If you have any questions or concerns about this change then please get in touch either via this mailing list or via your Arm partner manager (where applicable). Thanks, Paul

5 years, 11 months

1
0
0 0

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

by Lionel DEBIEVE

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.

5 years, 11 months

1
0
0 0

[RFC] Multiple Signing Domains

by Sandrine Bailleux

Hello all, As you may know, the Trusted Board Boot (TBB) code relies on the platform to define a chain of trust (CoT). Today, the only example of CoT present in the code base is the one used on Arm platforms, which is described: - in the TBBR specification [1]. - in the TF-A documentation [2] [3]. The entire TBBR CoT is built upon the root-of-trust public key (ROTPK), which is used to authenticate all subsequent firmware binaries and certificates, either directly or indirectly through some intermediate certificates. The TBBR CoT is only one example of a possible certificate chain and key ownership model. It might not suit all platforms and market segments but the TBBR implementation in TF-A leaves some freedom for other CoTs. Today, we are publishing some proof-of-concept code that shows one way the existing TBBR CoT may be modified in order to detach the BL33 image from the rest of the CoT. This effectively splits it into 2 CoTs: - 1 CoT for all secure world images (BL2, BL31, BL32). - 1 CoT for the normal world bootloader (BL33). If you are interested, please have a look at the related patch as well as the companion documentation: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443 https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ Note that at this stage, this is only prototype code and we do not plan to integrate it in the code base as is, because it does not implement what we would consider as a clean solution and uses a number of workarounds. We are considering cleaning this patch up and providing it as an alternate CoT on FVP platform in the future. For now, the intent is to provide some material, which we can base a discussion on. We're hoping to gather feedback from interested parties on the suitability of this approach. Regards, Sandrine [1] https://developer.arm.com/docs/den0006/d/trusted-board-boot-requirements-cl… (see page 21) [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boo… [3] https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht…

5 years, 11 months

1
0
0 0

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

by Gyorgy Szing

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

5 years, 12 months

1
0
0 0

New "memory map" tool

by Louis Mayencourt

Hi all, We are introducing a new "memory map" tool part of the build system. The tool parse the blx.map files and print a representation of the memory layout for the latest build. It can be invoked by adding "memmap" in the make build command. If you are interested, please have a look at the related patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2413/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.

5 years, 12 months

1
0
0 0

Design proposal: firmware debugfs interface

by Olivier Deprez

Hi All, We are proposing a new firmware debug interface in the form of a "debug filesystem". The intent is to expose live firmware data or firmware driver HAL to the upper layers, in debug builds. For people interested, please review and comment the design proposal: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2381 The design is not closed, the intent is to collect opinions, and have a discussion on options and implications. Thanks & Regards, Olivier. 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.

6 years

1
0
0 0

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

by Olivier Deprez

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.

6 years

1
0
0 0

Re: [TF-A] compile toolchain

by Alexei Fedorov

Hi Feng, user-guide.rst references GCC 9.1 and later versions. The code was also tested with GCC 10.0.0. Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chen Feng via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 24 October 2019 14:32 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] compile toolchain hi expects， from the atf2.2 release notes,I can see the tf-a already supported pac bti and mte feature. I want to enable and test it on fvp platform. I want to know which tool chain to use for compiling code for theses. Cheers Feng -- 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.

6 years

1
0
0 0

compile toolchain

by Chen Feng

hi expects， from the atf2.2 release notes,I can see the tf-a already supported pac bti and mte feature. I want to enable and test it on fvp platform. I want to know which tool chain to use for compiling code for theses. Cheers Feng

6 years

1
0
0 0

Trusted Firmware version 2.2 is now available

by Bipin Ravi

Hi all, Trusted Firmware version 2.2 is now available and can be found here: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.2 Please refer to the readme and change log for further information. Thanks & best regards, [cid:image001.jpg@01D588EA.577B7090] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Joshua.Sunil@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

6 years

1
0
0 0

[RFC] BL2 MTD frameworks

by Lionel DEBIEVE

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

6 years

1
0
0 0

Re: [TF-A] Boot getting stuck on RK3399 Rockpro64 board

by Joanna Farley

Hi Hugh, Ccing the Rockchip maintainers from https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/maint… as neither appear to be subscribed to this mailing list. Joanna On 08/10/2019, 21:45, "TF-A on behalf of Hugh Cole-Baker via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi folks, I've been using TF-A with mainline U-Boot recently as firmware & boot loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based on this guide [1], using gcc 8.3.0 from Debian. TF-A v2.1 works fine for this, but I recently tried to switch to TF-A latest master and found U-Boot gets stuck with this version. The symptoms are: U-Boot TPL and SPL print starting messages like this: U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000) Trying to boot from MMC2 ...and then there is no more output when normally U-Boot proper would start, and go on to load the Linux kernel, etc. Starting from v2.1, with git bisect I found the first 'bad' commit is: 0aad563c7480 rockchip: Update BL31_BASE to 0x40000 and that commit does change some RK3399-related files so seems likely. I'm not sure how to debug further, any ideas on why boot is hanging after that change or how to get more debugging information? Best regards, Hugh Cole-Baker [1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip -- 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.

6 years

2
1
0 0

Re: [TF-A] Hercules-AE I$ problems

by Olivier Deprez

Hi Varun, TF-A v1.4 is rather old codebase, can you provide the exact patchset you cherry-picked on top of it? e.g. you need the Hercules CPU support patch (a4668c36f1fca75b), but possibly also all which is related to HW_ASSISTED_COHERENCY option? Also, can you pls provide your build cmd line? Thanks & Regards, Olivier. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 11 October 2019 11:21 To: Varun Wadekar <vwadekar(a)nvidia.com>; Joanna Farley <Joanna.Farley(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com> Cc: Julius Werner via TF-A <tf-a(a)lists.trustedfirmware.org>; nd <nd(a)arm.com> Subject: Re: [TF-A] Hercules-AE I$ problems On 10/10/2019 20:46, Varun Wadekar wrote: > Hello, > > First of all, thanks a lot for posting the Hercules-AE patches. > > We picked them up and used them internally. Unfortunately, the CPU sees > garbage in it's I$ when we enable the I cache for the processor. If we > keep I$ disabled, TF-A boots properly. We are using TF-A v1.4 for > verification. > > We booted Linux kernel v4.14 on the processor and don't see this problem > there. So, we suspect something going wrong inside TF-A. Have you seen > this problem internally? Any hints or clues to solve it would be helpful. > > Thanks. Hi Varun, As indicated in the commit message of the patch, we have not tested the CPU support internally due to non-availability of FVP for the CPU. TF-A assumes that I$ will be invalidated when CPU is reset. Perhaps this is not true for your setup. Could you try adding a `IC IALLU` in the CPU reset handler prior to I$ enable and see if that improves anything ? Best Regards Soby Mathew > > > ------------------------------------------------------------------------ > This email message is for the sole use of the intended recipient(s) and > may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all > copies of the original message. > ------------------------------------------------------------------------ -- 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.

6 years

1
0
0 0

Hercules-AE I$ problems

by Varun Wadekar

Hello, First of all, thanks a lot for posting the Hercules-AE patches. We picked them up and used them internally. Unfortunately, the CPU sees garbage in it's I$ when we enable the I cache for the processor. If we keep I$ disabled, TF-A boots properly. We are using TF-A v1.4 for verification. We booted Linux kernel v4.14 on the processor and don't see this problem there. So, we suspect something going wrong inside TF-A. Have you seen this problem internally? Any hints or clues to solve it would be helpful. Thanks. ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

6 years

2
1
0 0

Documentation and Website Updates

by Paul Beesley

Hi everyone, This post is to let you know about some changes to the TrustedFirmware.org website and to the TF-A documentation. It briefly covers what's new, what has moved, and what happens to any existing resources you may be using. First of all, we are making it more obvious where to access the documentation and the Gerrit review system. The front page of trustedfirmware.org has grown new "Documentation" and "Review" menus with links to this content. Dashboard and Wiki items have moved under the Documentation menu. Secondly, the online version of the documentation has moved to www.trustedfirmware.org/docs/tf-a<http://www.trustedfirmware.org/docs/tf-a>. This is a pre-rendered, HTML copy of the content that is found under the "docs" directory of the TF-A repository. The content here will remain synchronised with the master branch of the repository. Following the v2.2 release, you will also be able to access a static version of the documentation that corresponds to that tag, via a version selection drop-down menu on the site. The intention behind this change is to make it easier to find the docs, to improve the output quality and to make the content more modular and readable. The new setup has a persistent table of contents (displayed to the left of the page content) and a search feature, making it easier to find what you're looking for and easier to move between documents and topics. You may be used to viewing the docs through either the git viewer (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/) or through the Github mirror (https://github.com/ARM-software/arm-trusted-firmware/). The landing pages of these sites now contain links to the new content. While you can still use these sites to access other documentation content, you may find that there are some formatting warnings displayed if you do so. Finally, if you prefer to read a local copy of the documentation on your machine then you can build the same HTML output following the instructions at https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/docs-bui… (or docs/getting_started/docs-build.rst, for the equivalent file in the repository). As always, let us know if you have any comments or if there are other changes you would like to see. Thanks, Paul

6 years

1
0
0 0

Boot getting stuck on RK3399 Rockpro64 board

by Hugh Cole-Baker

Hi folks, I've been using TF-A with mainline U-Boot recently as firmware & boot loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based on this guide [1], using gcc 8.3.0 from Debian. TF-A v2.1 works fine for this, but I recently tried to switch to TF-A latest master and found U-Boot gets stuck with this version. The symptoms are: U-Boot TPL and SPL print starting messages like this: U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50) Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000) Trying to boot from MMC2 ...and then there is no more output when normally U-Boot proper would start, and go on to load the Linux kernel, etc. Starting from v2.1, with git bisect I found the first 'bad' commit is: 0aad563c7480 rockchip: Update BL31_BASE to 0x40000 and that commit does change some RK3399-related files so seems likely. I'm not sure how to debug further, any ideas on why boot is hanging after that change or how to get more debugging information? Best regards, Hugh Cole-Baker [1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip

6 years

1
0
0 0

Forthcoming Trusted Firmware-A 2.2 release

by Bipin Ravi

Hi, This is to notify that we are planning to target the Trusted Firmware-A 2.2 release during the third week of October as part of the regular 6 month cadence. The aim is to consolidate all TF-A work since the 2.1 release. As part of this, a release candidate tag will be created and release activities will commence from Monday October 7th. Essentially we will not merge any major enhancements from this date until the release is made. Please ensure any Pull Requests (PR's) desired to make the 2.2 release are submitted in good time to be complete by Friday October 4th. Any major enhancement PR's still open after that date will not be merged until after the release. Thanks & best regards, [cid:image001.jpg@01D57244.98C07530] Bipin Ravi | Principal Design Engineer Bipin.Ravi(a)arm.com<mailto:Joshua.Sunil@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

6 years, 1 month

1
0
0 0

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 349459: (ARRAY_VS_SINGLETON) ________________________________________________________________________________________________________ *** CID 349459: (ARRAY_VS_SINGLETON) /plat/mediatek/mt8183/drivers/sspm/sspm.c: 150 in sspm_alive_show() 144 145 if (sspm_ipi_send_non_blocking(IPI_ID_PLATFORM, &ipi_data) != 0) { 146 ERROR("sspm init send fail! ret=%d\n", ret); 147 return -1; 148 } 149 >>> CID 349459: (ARRAY_VS_SINGLETON) >>> Passing "&ipi_data" to function "sspm_ipi_recv_non_blocking" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 150 while (sspm_ipi_recv_non_blocking(IPI_ID_PLATFORM, 151 &ipi_data, 152 sizeof(ipi_data)) 153 && count) { 154 mdelay(100); 155 count--; 156 } 157 158 return (ipi_data == 1) ? 0 : -1; /plat/mediatek/mt8183/drivers/sspm/sspm.c: 145 in sspm_alive_show() 139 uint32_t ipi_data, count; 140 int ret = 0; 141 142 count = 5; 143 ipi_data = 0xdead; 144 >>> CID 349459: (ARRAY_VS_SINGLETON) >>> Passing "&ipi_data" to function "sspm_ipi_send_non_blocking" which uses it as an array. This might corrupt or misinterpret adjacent memory locations. 145 if (sspm_ipi_send_non_blocking(IPI_ID_PLATFORM, &ipi_data) != 0) { 146 ERROR("sspm init send fail! ret=%d\n", ret); 147 return -1; 148 } 149 150 while (sspm_ipi_recv_non_blocking(IPI_ID_PLATFORM, ________________________________________________________________________________________________________ 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

Coverity Scan subscription confirmation

by scan-admin＠coverity.com

Hi tf-a(a)lists.trustedfirmware.org, Your email was added by sandrine.bailleux(a)arm.com to receive software defect notifications from [1]Coverity Scan for the ARM-software/arm-trusted-firmware project. To confirm and activate these notifications, [2]click here. If you do not wish to receive these emails, you may safely ignore this message. References 1. https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… 2. https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

6 years, 1 month

1
0
0 0

Re: [TF-A] Defects detected by Coverity Scan Online

by Sandrine Bailleux

Hi, We are going to configure Coverity Scan Online to make it send notifications to this mailing list. This way, everyone subscribed on this mailing list will be aware of newly detected/eliminated defects found by the tool. The report will provide a summary of the findings (their nature, location in the source code). In order to look up the details or to triage them, you will still need to access the database through the web portal on https://scan.coverity.com/projects/arm-software-arm-trusted-firmware . As a reminder, you will need to create an account to view the defects there (it's possible to use your Github account). This is expected to generate a low volume of emails, as we typically do 1 analysis per week day. As a heads up, the web interface mentions that "an authorization confirmation will be sent to each newly provided email address and must be acknowledged before notifications will be sent". In which case, please ignore these emails. Regards, Sandrine

6 years, 1 month

1
0
0 0

Re: [TF-A] License

by Joanna Farley

Hi Tristan, Can you please clarify what your exact concern is? Which files and what text exactly? That will help us answer your concern. Thanks Joanna On 16/09/2019, 23:48, "TF-A on behalf of Tristan Muntsinger via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hello all, It looks like the copyright guidance on this project changed about a year ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can this be fixed to make the license valid so the project can be legally redistributed per BSD-3 as intended? Thanks, Tristan Muntsinger -- 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.

6 years, 1 month

2
2
0 0

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

by Julius Werner

Hi Dan, Whoops, sorry, this fell through the cracks for me since I wasn't on the to: line. Thanks for your response! > OK I can see the use of that, although I'd be a bit concerned about such a thing being available as a general service in case it gets used as an attack vector. For example, a test program could aggressively use this service to try to get the firmware to leak secure world information or something about its behaviour. Yes, of course, we can gate this with a build option so it would only be available where desired. > However, I think there might already be support for what you need. PSCI is part of the standard service and the function SYSTEM_RESET2 allows for both architectural and vendor-specific resets. The latter allows for vendor-specific semantics, which could include crashing the firmware as you suggest. > > Chrome OS could specify what such a vendor-specific reset looks like and each Chromebook's platform PSCI hooks could be implemented accordingly. Right, but defining a separate vendor-specific reset type for each platform is roughly the same as defining a separate SiP SMC for each of them. 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. > Alternatively, this could potentially be defined as an additional architectural reset. This would enable a generic implementation but would require approval/definition by Arm's Architecture team. Like me they might have concerns about this being defined at a generic architectural level. Yes, I think that would be the best option. Could you kick off that process with the Architecture team? Or tell me who I should talk to about this? Thanks, Julius

6 years, 1 month

2
1
0 0

License

by Tristan Muntsinger

Hello all, It looks like the copyright guidance on this project changed about a year ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can this be fixed to make the license valid so the project can be legally redistributed per BSD-3 as intended? Thanks, Tristan Muntsinger

6 years, 1 month

1
0
0 0

Re: [TF-A] About next release

by Joanna Farley

Hi Yann, You are quite correct. We will be looking to create a v2.2 tag release sometime early to mid October. You can expect a more formal notification and a request to get any patches submitted in the next week or so. As in previous releases master will be generally locked for a week or so while closedown testing is performed although we will assess incoming patches to see if they can be taken with low risk. Joanna On 16/09/2019, 13:19, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon. But the exact timeframe is not yet published. The wiki page might be updated if you have more information. When do you expect to release tag v2.2? What will be the deadline to send patches upstream? Thanks, Yann -- 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.

6 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A