Do you have any idea when the recording of yesterday’s  tech forum will be available?

 

Thanks,

 

Chris

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Friday, September 3, 2021 9:54 AM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL

 

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe.

 

We should diversify test scenarios between platforms by having a common = mandatory part and an optional one, depending on a  platform capabilities/ features.

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Friday, September 3, 2021 11:44 AM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL

 

I think it is the FPGA_IO in the core test partition. This is quite platform-specific, so we may need to decide such kinds of test cases are applicable for all platforms – we may need to remove these test cases.

 

/Ken

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Mingyang Sun via TF-M
Sent: Friday, September 3, 2021 6:37 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL

 

Hi,

 

Some partitions declare MMIOs that do not exist on specific platforms. While implementing, platform owners need to note that, if the configuration involves a partition, the platform must support MMIOs declared in the partition manifest. Or the HAL will panic TF-M.

 

The previous HAL implementation skips the undeclared MMIO, which may bring potential runtime issues when the partitions access these un-initialized peripherals. Please consider if these MMIO-specific test cases need to be excluded from your platform.

 

 

Thanks,

Mingyang

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Friday, September 3, 2021 1:27 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL

 

Hi,

 

Another reminder to mention the MMIO binding patches. Several platforms are changed to pass the CI, please platform owners to review the patches, such as:

 

PSOC: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187

STM: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11186

 

Some of other platform patches are created as well.

 

This is a significant change for platform which helps much easier integration. After the first series of patches, the problems not covered by the CI need to be fixed adhoc.

 

Please read the tech forum topic on 2nd Sep for more details or you can just scroll down to check the previous content.

 

Thanks.

 

/Ken

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Monday, August 30, 2021 5:18 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL

 

The patchset has updated and now CI passed okay:

 

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187

 

BR

 

/Ken

 

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 19, 2021 2:16 PM
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] [Request Platform Support] Abstracted MMIO HAL

 

Hi everyone,

 

The existing HAL interface for isolation hardware is not unified, we have to call several  interfaces to setup isolation boundaries.

 

Hence, a deeper abstracted interface are provided. Here are the details:

 

- It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources.

- When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this).

- A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform.

- When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things.

- Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved.

 

We created a patch to showcase the usage on AN521:

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036

 

This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable.

 

Now come to the request:

Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms.

 

Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform.

 

Any feedbacks are welcome.

Thank you very much!

 

/Ken