- TF-A - lists.trustedfirmware.org

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, 5 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, 6 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, 6 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, 6 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, 6 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, 6 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, 6 months

2
1
0 0

License

by Tristan Muntsinger

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

5 years, 6 months

1
0
0 0

Re: [TF-A] About next release

by Joanna Farley

Hi Yann, You are quite correct. We will be looking to create a v2.2 tag release sometime early to mid October. You can expect a more formal notification and a request to get any patches submitted in the next week or so. As in previous releases master will be generally locked for a week or so while closedown testing is performed although we will assess incoming patches to see if they can be taken with low risk. Joanna On 16/09/2019, 13:19, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon. But the exact timeframe is not yet published. The wiki page might be updated if you have more information. When do you expect to release tag v2.2? What will be the deadline to send patches upstream? Thanks, Yann -- 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, 6 months

1
0
0 0

About next release

by Yann GAUTIER

Hi, >From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon. But the exact timeframe is not yet published. The wiki page might be updated if you have more information. When do you expect to release tag v2.2? What will be the deadline to send patches upstream? Thanks, Yann

5 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A