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
Hi all,
Please be noted that the TF-M example Secure Partition has been moved from the tf-m-tools repo to the tf-m-extras<https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/examples/example_…> repo.
It has also been aligned with the latest TF-M. The documentations are improved as well.
It could be a good reference for Secure Partition developer starters.
Best Regards,
Kevin
Hello,
The project documentation will never be ideal and we are continuing improving it.
Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase.
Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful.
Thank you in advance,
Anton
