- TF-A - lists.trustedfirmware.org

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.

5 years, 8 months

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. -----------------------------------------------------------------------------------

5 years, 8 months

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

5 years, 9 months

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

5 years, 9 months

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

5 years, 9 months

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…

5 years, 9 months

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…

5 years, 9 months

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

5 years, 9 months

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.

5 years, 9 months

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

5 years, 9 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A