Hello,
when building TF-M you get the same result no matter what
computer you build from assuming all the tooling is the same version.
The builds are reproducible in other words.
But when building TF-M together with the tests, e.g. by building the regression test suite
you will get a different binary depending on where in the filesystem the tf-m-tests repository
has been installed.
This is because the TEST_FAIL macro uses the gcc macro _FILE_ which injects the absolute paths of source files
into strings in the binary.
This is a big problem for people using CI systems as a different sized binary can affect race conditions,
flash region usage overflows, etc..
I think we should make builds reproducible by default, possibly with a configuration for adding absolute paths
into the binary for those that prefer so.
I would like to write a patch to this affect, but would prefer to get some feedback now so I don't have to re-write it in review.
The simplest solution is to remove __FILE__ from the TEST_FAIL macro,but this would remove useful information and may also fail in the future if someone else uses __FILE__.
The more common way of solving this problem is to add a flag to the compiler that instructs it to replace any occurrences of the absolute path with something else during macro expansion. For instance replace "C:/repos/tf-m-tests/source_file.c" with "TFM_TESTS/source_file.c". For gcc the flag is -fmacro-prefix-map=<old_string>=<new_string>. I don't know what the flag is for the other supported compilers or if they support it at all.
Would it be OK to only support reproducible builds for the compilers that support an equivalent of macro-prefix-map?
Hello,
TF-M has many options to configure. All of them are declared as a CMake variables and many of them translated to compiler definitions later.
Since the idea of TF-M configuration via config header file(s) was warmly received on the last tech forum I would like to check with community opinion on such hypothetical move: Configure TF-M via definitions in header files while leave CMake for a building control only.
Please share your thoughts, opinions and the possible dependencies.
Thanks,
Anton
Hello,
The FIH functionality reference implementation on AN521 was there before, and then get turned off last year because it increases the effort of updating the HAL interface.
Now the HAL interface update is done, this functionality is re-enabled on AN521, based on the updated HAL. The patches are pushed for your review:
https://review.trustedfirmware.org/q/topic:%22FIH_AN521_RE%22+(status:open%…
The mechanism is mainly the same as the previous implementation, The document is under modifying to reflect the re-enablement changes but still can be read to recall the general concept:
https://tf-m-user-guide.trustedfirmware.org/technical_references/design_doc…
Please leave your comments in the patches or do overall discussions in this mail thread.
Thanks!
/Ken
Hi All :
I'm developing Flash Driver for TF-M AN524 demo , and trobuled by some code logic .
It's that :
For , AN524 , PS storage Area is redirect to BRAM , so PS area related read and write can be done using memcpy without Flash driver being implementened .
see : platform/ext/target/arm/mps3/an524/cmsis_driver/Driver_Flash.c
/* Redirecting PS storage to BRAM */
if (addr >= FLASH_REDIRECT_BASE && addr <= FLASH_REDIRECT_LIMIT) {
start_addr = FLASH_REDIRECT_DEST + (addr - FLASH_REDIRECT_BASE);
/* PS Flash is emulated over BRAM. use memcpy function. */
memcpy((void *)start_addr, data, cnt);
} else {
/* Flash driver for QSPI is not ready */
return ARM_DRIVER_ERROR_UNSUPPORTED;
}
My question is : What the purpose of "else" branch above ?
After I implement QSPI driver , in "if" branch , I remove redirect operation , and use Flash Write APIs to replace memcpy func. Then , shoud "else" branch be removed?
Or , should I put Flash write driver in "else" branch , and keep "if" branch the same with origion?
Best regards,
Jidong Mei
TF-M includes platform/ext/cmsis, which is CMSIS v5.9.0 with some TF-M-specific changes.
Looking at the history for that directory, it seems that we periodically update it and have to re-apply the TF-M-specific changes (which looks to be the naming of the stack and the copy table size).
I'm wondering whether there's a plan to either push the TF-M changes into upstream CMSIS or to change TF-M so that they're not needed? It would be nice to just pull CMSIS from upstream like we do with other external libraries...
Chris Brand
Cypress Semiconductor (Canada), Inc.
An Infineon Technologies Company
Sr Prin Software Engr
CSCA CSS ICW SW PSW 1
Office: +1 778 234 0515
Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>
International Place 13700
V6V 2X8 Richmond
Canada
www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies>
Part of your life. Part of tomorrow.
NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.
Hello all,
I made a patch (https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16214) that reorganize interaction between ITS partition, ITS file system and ITS flash driver.
1. ITS flash driver interface is decoupled from ITS file system.
2. ITS flash driver interface isn't dependent on upper layers like ITS FS or ITS.
3. ITS flash driver emulated in RAM (its_flash_ram) can be used without CMSIS flash driver even in production environment if needed.
4. Target can provide own implementation of ITS flash driver without implementing CMSIS flash driver. Which can be more flexible or simple in some cases.
5. Allocation of ITS flash driver instance by ITS partition is not dependent on lower layers like CMSIS driver. ITS partition uses abstract flash driver interface to bind ITS file system and driver instance.
This changes gives following benefits.
1. Vendors can provide ITS flash driver without need to create an intermediate CMSIS flash driver.
2. It's possible to implement ITS encryption by adding a new ITS flash driver that performs encryption and uses existing drivers (NOR, NAND, RAM, platform specific) as the storage backend.
3. It's possible to use ITS file system + ITS encryption driver (b) for Protected Storage directly without additional context switching during access to PS file system handled by ITS partition. I think it should improve performance of PS.
4. Use ITS file system directly in application specific custom partitions by allocating ITS file system context and ITS flash driver.
Best regards,
Roman.
Hi everyone,
From what I see manifest lists (e.g. tools/tfm_manifest_list.yaml) describe partitions, but "name" field there (which is a description of the partition) uses "Service" word, for example:
"name": "Protected Storage Service",
Shouldn't this be "name": "Protected Storage Partition" ?
Why do TFM uses Service when describing the Partition?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi,
TF-M coding standard<https://tf-m-user-guide.trustedfirmware.org/contributing/coding_guide.html> mandates up to 80 characters per line. This looks a bit too restrictive nowadays with no punch cards or text terminals.
I propose to increase this limit to 120 or 140 characters. Personally like 128.
Are there any thoughts or objections against it?
Thanks,
Anton
