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.
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
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.
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/+/2443https://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…
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
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.
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.
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.
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.
