- TF-A - lists.trustedfirmware.org

Re: [TF-A] How can I check detail error of CI failure?

by John Tsichritzis

Dear Jun, Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself. When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch. Kind regards, John -- John Tsichritzis | Graduate Software Engineer Email: john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com> 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom https://www.arm.com/ On 16/07/2019 09.24, Jun Nie via TF-A wrote: Hi, I see below failure in this link: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367 How can I check the error log? I am not sure it is due to lack of earlier patch in patch set or something. Because local build is OK. Patch Set 4: Verified-1 Build Failed https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE Jun

5 years, 3 months

1
0
0 0

How can I check detail error of CI failure?

by Jun Nie

Hi, I see below failure in this link: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367 How can I check the error log? I am not sure it is due to lack of earlier patch in patch set or something. Because local build is OK. Patch Set 4: Verified-1 Build Failed https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE Jun

5 years, 3 months

1
0
0 0

Header file re-org

by Soby Mathew

Hi Everyone, This is regarding the header file re-organization patch that was submitted by Julius https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/1207/. It is necessary for the headers which form the ABI/handover interface for BL31 to be able to copied separately and included in other projects. The current approach taken in the patch is to define a "raw" version of such headers and have the original header include them. This certainly is the easiest way to solve the problem. But if it possible to have a more refined solution, that would be preferable. For that I have the following questions : 1. Should the project recognize these special headers and have them organized together in a folder ? It is important to recognize that the ABI can be extended by the platform. I would expect even if these "common" headers are organized into a folder, the platform specific ones need not go together with them. 2. Should the header be restricted from including standard C library headers ? 3. Should these ABI headers be allowed to include each other ? Forward declaration might be able to solve some of the issues, but good to have a policy on this. The current patch as such can be treated as step towards the ideal solution, if that solution needs more work/churn in the code base. Comments welcome. Best Regards Soby Mathew

5 years, 3 months

3
8
0 0

Re: [TF-A] [RFC] isolate the memory into different pagetable for TF-A

by feng chen

Hi Soby Mathew, Thanks for your reply. IMHO, the isolate pagetable is much more heavy. It looks like a big idea. And if we have a dynamic mapping function, which map the service's needed memory in the service's call can also mitigate this. But this can be more slower. For accessing limited resource, what's your idea? -Feng On 2019/7/9 4:27 下午, Soby Mathew wrote: > Hi Feng, > Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a(a)lists.trustedfirmware.org , so we can continue conversation on the list ? > > The mailing list info can be found here : > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > Thanks & Regards > Soby Mathew > >> -----Original Message----- >> From: feng chen <puck.chen(a)foxmail.com> >> Sent: 08 July 2019 16:24 >> To: Dan Handley <Dan.Handley(a)arm.com>; Soby Mathew >> <Soby.Mathew(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>; >> Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Paul Beesley >> <Paul.Beesley(a)arm.com>; John Tsichritzis <John.Tsichritzis(a)arm.com> >> Subject: [RFC] isolate the memory into different pagetable for TF-A >> >> Hello maintainers, >> >> Is it possible for mapping the memory into different page-tables for TF-A? >> >> Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs. >> >> And for security reason, once one service provided in TF has some >> vulnerabilities, It can access all the memory TF mapped. And it could be more >> acceptable. >> >> Thinking about the userland goto kernelland, the process use isolated page >> tables. >> >> So I want to implement this for TF-A, different memory-mapping for different >> service, and it can also use a shared mem-mapping space which all the service >> need to use. >> >> >> I want to know how do you think about this? Does this make sense to you? >> >> >> Cherrs, >> >> Feng >> > > 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, 3 months

2
1
0 0

Re: [TF-A] [RFC] isolate the memory into different pagetable for TF-A

by Chen Feng

Move this folk to list > 在 2019年7月9日，下午4:27，Soby Mathew <Soby.Mathew(a)arm.com> 写道： > > Hi Feng, > Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a(a)lists.trustedfirmware.org , so we can continue conversation on the list ? > > The mailing list info can be found here : > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > Thanks & Regards > Soby Mathew > >> -----Original Message----- >> From: feng chen <puck.chen(a)foxmail.com> >> Sent: 08 July 2019 16:24 >> To: Dan Handley <Dan.Handley(a)arm.com>; Soby Mathew >> <Soby.Mathew(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>; >> Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Paul Beesley >> <Paul.Beesley(a)arm.com>; John Tsichritzis <John.Tsichritzis(a)arm.com> >> Subject: [RFC] isolate the memory into different pagetable for TF-A >> >> Hello maintainers, >> >> Is it possible for mapping the memory into different page-tables for TF-A? >> >> Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs. >> >> And for security reason, once one service provided in TF has some >> vulnerabilities, It can access all the memory TF mapped. And it could be more >> acceptable. >> >> Thinking about the userland goto kernelland, the process use isolated page >> tables. >> >> So I want to implement this for TF-A, different memory-mapping for different >> service, and it can also use a shared mem-mapping space which all the service >> need to use. >> >> >> I want to know how do you think about this? Does this make sense to you? >> >> >> Cherrs, >> >> Feng >> > > 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, 3 months

1
0
0 0

Defects detected by Coverity Scan Online

by Sandrine Bailleux

Hello, As you may be aware, Trusted Firmware-A source code regularly gets analyzed by Coverity Scan Online [1]. This is a free service offered by Synopsys for open source projects, that TF-A has used since 2015. The analysis currently gets driven by Arm's internal CI system. We've recently made some improvements to this setup, which led to the tool analyzing more files. The latest analysis report from this morning shows 65 newly-found defects, scattered across the code base. We would need help from the TF-A community for analyzing and fixing them, especially those in platform ports and drivers. Note that there might be false positives, in which case we would just triage them as such in the tool's database. Hopefully everyone should be able to view the defects, according to the tool's settings. You might need to create an account on https://scan.coverity.com for that. Best regards, Sandrine [1] https://scan.coverity.com/projects/arm-software-arm-trusted-firmware

5 years, 4 months

1
0
0 0

Why is assembly macro used for registering multi-console driver?

by Masahiro Yamada

Hi, Probably, I should have asked this before pushing my code. I have a question about finalize_console_register. Platforms call console_*_register() from C code. I do not know why we need to fill the callbacks in the assembler macro, finalize_console_register. We could call console_register() directly from C code, like this: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1426/3/plat/… Maybe, we may want to register the console so early in order to enable plat/common/aarch64/crash_console_helpers.S in the boot-up code?

5 years, 4 months

2
1
0 0

Re: [TF-A] Armv8A Suspend/Resume reference code

by Soby Mathew

> -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Gutierrez, > Hernan Ildefonso (Boise R&D, FW) via TF-A > Sent: 24 June 2019 22:35 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Armv8A Suspend/Resume reference code > > Hi, > > I am looking for reference code for ArmV8A core suspend/resume. > Are there code references that are suggested to look for? > Application notes to read? > Hi Hernan, The PSCI Spec[1] specifies power management on ARM CPUs and this includes suspend and resume. The TF-A provides an implementation of PSCI with appropriate hooks to plug-in in platform specifics. There are documents in the `docs` folder which cover different aspects of PSCI implementation like PSCI topology [2], CPU specifics [3], and platform porting guide [4]. In terms of adding support for a new platform, it is most likely that all the architectural (as in ARMv8A reference manual) and the CPU specific power management as specified in the TRM are covered already (see lib/cpus/ folder for CPUs already supported). So it’s a matter of implementing the platform hooks as mentioned in the porting guide [4]. With respect to implementing platform hooks, the ARM reference platforms like FVP provide an example of how the hooks can be implemented (see fvp_pm.c/fvp_topology.c ). So if you platform is a GICv3 system and the power controller already uses SCMI as the protocol for communication, then most of the code in FVP can be reused for your platform. Hope that provides a starting point for you to begin. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coord… [2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/desi… [3] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/desi… (see CPU specific operations framework) [4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/gett… (see Power State Coordination Interface) > Any pointers will be appreciated, thanks. > > Hernan > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

1
0
0 0

Armv8A Suspend/Resume reference code

by Gutierrez, Hernan Ildefonso (Boise R&D, FW)

Hi, I am looking for reference code for ArmV8A core suspend/resume. Are there code references that are suggested to look for? Application notes to read? Any pointers will be appreciated, thanks. Hernan

5 years, 4 months

1
0
0 0

Re: [TF-A] New console interface porting examples

by Soby Mathew

Hi, We are planning merge the patch removing support for legacy console support this week. This is a gentle reminder for platforms not yet migrated to the MULTI_CONSOLE_API. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Ambroise > Vincent via TF-A > Sent: 31 May 2019 10:40 > To: jens.wiklander(a)linaro.org; yamada.masahiro(a)socionext.com; > siva.durga.paladugu(a)xilinx.com; vwadekar(a)nvidia.com; > bryan.odonoghue(a)linaro.org; jun.nie(a)linaro.org > Cc: tf-a(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: [TF-A] New console interface porting examples > > Hi, > > An update on the new console API > (https://github.com/ARM-software/tf-issues/issues/692): > > You will find patches below for the platforms that haven't done the migration > to the new interface yet, in order to give them something to test and > potentially adapt if it doesn't work as intended. The commits are independent > from each other and can be easily cherry-picked. > > Tegra: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192/ > > Zynqmp: https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > a/+/1193/ > > Uniphier: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1194/ > > Qemu: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1195/ > > Warp7: a very small patch to look at, removing a soon to be deleted legacy file > from the platform makefile: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1191/ > > > As you know, the old interface is going to be removed at the end of June > by https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/842/ > > > Regards > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 4 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A