- TF-A - lists.trustedfirmware.org

Re: [TF-A] gerrit issues: not able to add additional email

by Yann Gautier

Hi Gyorgy, I've added a new mail address in gerrit last month. I can see both addresses in gerrit Email Addresses. I've chosen the new one as my preferred address. And I only receive gerrit mails on this preferred address. Best regards, Yann On 3/10/21 4:26 PM, Gyorgy Szing via TF-A wrote: > Hi, > > I just tried it and got the notification e-mail. > > Note: I filled the "New email address" text box and pressing "Send Verification" below. If that adds an additional email or replaces the current one is unknown to me. > > /George > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Igor Opaniuk via TF-A > Sent: 10 March 2021 13:44 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] gerrit issues: not able to add additional email > > Hi, > > Gerrit for some reason doesn't send verification emails when adding additional email in account settings [1]. > I've tried to add two different emails, in both cases with no success. > Anyone could quickly check if you can receive verification? > > Thanks > > [1] https://review.trustedfirmware.org/settings#EmailAddresses > > -- > Best regards - Freundliche Grüsse - Meilleures salutations > > Igor Opaniuk > > mailto: igor.opaniuk(a)gmail.com > skype: igor.opanyuk > +380 (93) 836 40 67 > http://ua.linkedin.com/in/iopaniuk > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

4 years, 3 months

2
1
0 0

Re: [TF-A] gerrit issues: not able to add additional email

by Gyorgy Szing

Hi, I just tried it and got the notification e-mail. Note: I filled the "New email address" text box and pressing "Send Verification" below. If that adds an additional email or replaces the current one is unknown to me. /George -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Igor Opaniuk via TF-A Sent: 10 March 2021 13:44 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] gerrit issues: not able to add additional email Hi, Gerrit for some reason doesn't send verification emails when adding additional email in account settings [1]. I've tried to add two different emails, in both cases with no success. Anyone could quickly check if you can receive verification? Thanks [1] https://review.trustedfirmware.org/settings#EmailAddresses -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opaniuk(a)gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 3 months

1
0
0 0

gerrit issues: not able to add additional email

by Igor Opaniuk

Hi, Gerrit for some reason doesn't send verification emails when adding additional email in account settings [1]. I've tried to add two different emails, in both cases with no success. Anyone could quickly check if you can receive verification? Thanks [1] https://review.trustedfirmware.org/settings#EmailAddresses -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opaniuk(a)gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk

4 years, 3 months

1
0
0 0

CANCELLED: TF-A Tech Forum Agenda @ Thr 11th March 2021 16:00-1700 GMT

by Joanna Farley

Apologies for the late notice I am cancelling this weeks TF-A Tech forum tomorrow as we don’t have any subjects ready to present this week. We expect to have subjects for the next two sessions on 25th March and 8th April. Any subjects for future Tech-Forums from the contributor community always welcome so please reach out and I will help schedule. These can be more formal presentations or led discussions on subjects of interest to the TF-A project community. Cancellation of the calendar invite will come from trustedformware.org as I don’t own the invite so it may not appear in your calendars until that is sent out. Thanks Joanna

4 years, 3 months

1
0
0 0

Deprecating Arm's sgm775 platform

by Manish Pandey2

Hi, The purpose of the email is to notify about deprecation of sgm775 platform and proposed process for deprecating a platform. Arm's System Guidance for Mobile(SGM-775) is an old platform and no longer maintained. It is superseded by Total Compute(tc0) platform. Proposal for deprecating a platform: 1. Keep the code in repository. (at least for 2 release cycles) 2. Don't allow it to be built by default. (introducing PLATFORM_DEPRECATED build macro) 3. Disable CI testing. 4. Create appropriate documentation for deprecated platforms. Let me know if you have any suggestions. Thanks Manish P

4 years, 3 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 367340: Control flow issues (MISSING_BREAK) /plat/mediatek/mt8192/drivers/spm/mt_spm_vcorefs.c: 372 in spm_vcorefs_args() ________________________________________________________________________________________________________ *** CID 367340: Control flow issues (MISSING_BREAK) /plat/mediatek/mt8192/drivers/spm/mt_spm_vcorefs.c: 372 in spm_vcorefs_args() 366 uint64_t spm_vcorefs_args(uint64_t x1, uint64_t x2, uint64_t x3, uint64_t *x4) 367 { 368 uint64_t cmd = x1; 369 uint64_t spm_flags; 370 371 switch (cmd) { >>> CID 367340: Control flow issues (MISSING_BREAK) >>> The case for value "VCOREFS_SMC_CMD_INIT" is not terminated by a "break" statement. 372 case VCOREFS_SMC_CMD_INIT: 373 /* vcore_dvfs init + kick */ 374 mmio_write_32(DVFSRC_SW_REQ5, SW_REQ5_INIT_VAL); 375 spm_dvfsfw_init(0ULL, 0ULL); 376 spm_vcorefs_vcore_setting(x3 & 0xF); 377 spm_flags = SPM_FLAG_RUN_COMMON_SCENARIO; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 3 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Joanna Farley

I was away last week for the tech forum and not had time to watch the recording which I need to do before joining some of this discussions but I can clarify the purpose of the Changelog and the difference with the git history. The Changelog is part of the release documentation that summarises the main feature and changes that the release delivers. Its not expected every change in the git log history is included it is about recording the main themes of changes grouped together rather than chronologically. Most importantly it meant to be readable and understandable. I would expect as with any such documentation that some manual editing may be needed but the ask was for suggestions to make this task easier. As it stands today creating the Changelog can take days of manually reading the git history and re-writing, infact it’s the most labour intensive single task we do in a release. So guidance, formatting and tooling in creating commit messages so we can reuse them in release documentation is the ask. If this helps consumption of the git log history for other purposes that’s a great bonus. Tooling and automation makes things more efficient for all. Making submitting patches from developers harder is defiantly not the goal, hopefully the tooling makes the effort easier or at least the same level of effort for the developer, if not the solution being sought needs improving. Now we could do away with the release Changelog as it is today but the git log history is not a replacement for user facing release documentation. Before you know it we do away with all documentation and tell consumers to just read the source code 😉 Quote: “… documentation may mean different things to people in different roles.” Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Gyorgy Szing via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Gyorgy Szing <Gyorgy.Szing(a)arm.com> Date: Wednesday, 3 March 2021 at 13:26 To: Chris Kay <Chris.Kay(a)arm.com>, Varun Wadekar <vwadekar(a)nvidia.com>, "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-A] Adoption of Conventional Commits Hi, I think the basic question is: what is the difference between the change-log and the git history? Depending on how we draw the line between the release notes and the change log the answer can be: not much. The change log mostly filters and extends the git history. And this filtering and extending needs a lot of manual work currently. But why we wanted to have two change-logs then? The real difference is the presentation format (reST/HTML vs git log), and the tooling you need to be able to read. If the above is true, then the git log -> changelog transformation can be automated, but that needs the git history being machine readable. For developers this creates the requirement to properly format the commit message, and for reviewers adds extra work too. But that can be automated too right? And this is why we need tooling. Tooling on commit message authoring can be optional, but validation tools are mandatory. Otherwise we will end up with badly formatted commit messages (yes, manual validation is boring an error prone), failing automated translation, and the whole effort misses it’s main point. (And as a side effect we also get a git hook framework, which is making a step forward with standardizing distributed automation.) /George From: Chris Kay <Chris.Kay(a)arm.com> Sent: 03 March 2021 03:56 To: Varun Wadekar <vwadekar(a)nvidia.com>; Gyorgy Szing <Gyorgy.Szing(a)arm.com>; tf-a(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-A] Adoption of Conventional Commits Hi Varun, > I think you just increased the scope of the problem. We should add that as a new requirement – the commit message header should be pretty. I don't think the scope has increased, but perhaps the requirement that we are able to generate the changelog was lacking clarity; it's not necessarily that the commit message headers should be pretty, but that the changelog should remain so to the extent that it can - it is still user-facing documentation, after all. By extension, we gain nothing from using the commit log to generate the changelog if they just mirror one another. > Honestly, we should also check if in an effort to make the changelog “pretty”, are we losing the traditional git log formatting. Honestly, the git log gets used more than the changelog, so your proposal of changing the commit header has a greater impact. I would like to make this low impact to the developers that create patches on a daily basis. The point I'm trying to emphasise is that there is no traditional Git log formatting - as it stands today, our commit guidelines make no mention of tags. As a result, the tags we do see vary drastically, from none at all to generic "TF-A:" tags, to platforms, drivers and sometimes to specific files. Everybody has their own status quo which they obviously want to maintain, but at some point we have to try to bring everybody onto the same page - commit style rules are not particularly rare for the same reasons code style rules aren't. I don't think the CC rules deviate all that much from the styles we most often see today. > Introducing a completely new way of creating the commit message header or introducing more scripts to create that format is a no-no. There are no mandatory scripts involved - you can continue to write your commits as you do today. The only tangible difference is that we are standardising the tag syntax. > Personally, I feel that you are getting the required information from the git log by just adding tags, which to me, seems like a very low impact approach. Incidentally, it was this very disagreement that brought on this investigation - you can see exactly what the v2.4 changelog looked like<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/6654/1/docs/…> after basic categorisation, which is where it was decided that a straight dump of the commit log did not suffice for user documentation. > Isnt that an easy fix? We just don’t add tags to such commits. I don’t see how “Conventional Commits” is better. You can avoid tagging the revert commit, but you still need to detect whether the probably-tagged commit it reverts was merged before or after last release, and remove it from the log if the latter. I would suggest Conventional Commits is "better" because we don't even have to consider edge cases like these - we've done the configuration, we know it sorts this out for us, and there's nothing more we need to do to make it just work. > As a maintainer, I feel that forcing developers to unlearn the standard way used by almost all other OSS projects, is disruptive. I am all for automating as long as the process does not get in my way every day. But there is no "standard way" - some projects use "component: xyz" (e.g. Linux), others "[component] xyz" (e.g. LLVM), others yet don't use a tag at all (e.g. Mbed TLS), and I would argue most are like us: lax enough that it's largely down to individual contributors to determine their own. This just happens to be one style among many (and, as far as I know, the only one with an entire tooling ecosystem). I appreciate that you have a favoured variant, but I don't think it's any more useful to debate the most popular commit styles than it is to debate the most popular code styles. As we can see today though, TF-A's existing commit guidelines go largely ignored, and it's our intention to rectify that in a way that allows us to do something useful with information that was previously inaccessible. I won't try to argue that enforcing something that wasn't previously enforced takes some initial getting used to, but I think the emphasis on the "extra work for committers" is severely overrepresented here - realistically, it's a minimal change to how we format the tags that we already write, and it's something some of us have already had to get used to (and have, honestly with very little effort). > I think any proposal should be scalable and forward looking. I’m sure we will hit a scenario where someone needs custom tags and this proposal does not allow us that flexibility. It does afford us that flexibility - we can extend the list of supported types, I'm just unsure of why we might. We would not have settled on this solution if we did not believe it to be scalable and, considering it does already see widespread usage, I would argue it's a relatively safe bet that it can handle most, if not all, of what we need now and in the future. Chris ________________________________ From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Sent: 03 March 2021 01:26 To: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>>; Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-A] Adoption of Conventional Commits Hi Chris, I think you just increased the scope of the problem. We should add that as a new requirement – the commit message header should be pretty. Honestly, we should also check if in an effort to make the changelog “pretty”, are we losing the traditional git log formatting. Honestly, the git log gets used more than the changelog, so your proposal of changing the commit header has a greater impact. I would like to make this low impact to the developers that create patches on a daily basis. Introducing a completely new way of creating the commit message header or introducing more scripts to create that format is a no-no. Personally, I feel that you are getting the required information from the git log by just adding tags, which to me, seems like a very low impact approach. On the two examples, I don’t see a big difference in the supposedly human readable log you posted. But the proposal to get that is disruptive. >> You can see here that it emphasises the scope for each change for human readability, and also omits both the revert commit and the commit it reverts because neither of them have been part of a release Isnt that an easy fix? We just don’t add tags to such commits. I don’t see how “Conventional Commits” is better. >> I think burdening reviewers with additional work is likely to prove unreliable, and certainly counter-productive if we can both largely automate the problem away and provide rapid feedback to developers before ever even having to push for review As a maintainer, I feel that forcing developers to unlearn the standard way used by almost all other OSS projects, is disruptive. I am all for automating as long as the process does not get in my way every day. >> The tooling I proposed does already offer some flexibility for defining our own types and scopes, though the default set is already pretty extensive I think any proposal should be scalable and forward looking. I’m sure we will hit a scenario where someone needs custom tags and this proposal does not allow us that flexibility. -Varun From: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Sent: Tuesday, March 2, 2021 4:21 PM To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Hi guys, Note: a lot of this email relies on HTML formatting to force monospace fonts and emphasis – it probably won’t show up correctly on the mailing lists archives. One major point of contention with this model is that it’s not immediately clear what goes into the changelog. The obvious first answer is “the commit subject”, but let’s investigate that. Here are the last 17 commits from upstream as of right now: plat/marvell/armada: cleanup MSS SRAM if used for copy plat/marvell: cn913x: allow CP1/CP2 mapping at BLE stage plat/marvell/armada/common/mss: use MSS SRAM in secure mode libc: memset: Fix MISRA issues plat:xilinx:zynqmp: Remove the custom crash implementation lib: cpus: aarch32: sanity check pointers before use Revert "spmd: ensure SIMD context is saved/restored on SPMC entry/exit" plat/arm/css: rename rd_n1e1_edge_scmi_plat_info array docs: stm32mp1: correct formatting issues marvell: uart: a3720: Increase TX FIFO EMPTY timeout from 2ms to 3ms marvell: uart: a3720: Update delay code to be compatible with 1200 MHz CPU marvell: uart: a3720: Fix comments in console_a3700_core_init() function nxp: added the makefile helper macros spmd: ensure SIMD context is saved/restored on SPMC entry/exit nand: stm32_fmc_nand: remove dead code plat/arm: juno: Refactor juno_getentropy() bl32: Enable TRNG service build Here it is if we applied Conventional Commits to it: feat(marvell armada): cleanup MSS SRAM if used for copy feat(marvell cn913x): allow CP1/CP2 mapping at BLE stage feat(marvell armada): use MSS SRAM in secure mode fix(libc): fix MISRA issues refactor(xilinx zynqmp): remove the custom crash implementation refactor(aarch32): add sanity check pointers before use revert: fix(spmd): ensure SIMD context is saved/restored on SPMC entry/exit refactor(arm css): rename rd_n1e1_edge_scmi_plat_info array docs(stm32mp1): correct formatting issues refactor(marvell a3720): increase TX FIFO EMPTY timeout from 2ms to 3ms refactor(marvell a3720): update delay code to be compatible with 1200 MHz CPU fix(marvell a3720): fix comments in console_a3700_core_init() function build(nxp): add Makefile helper macros fix(spmd): ensure SIMD context is saved/restored on SPMC entry/exit refactor(stm32 fmc_nand): remove dead code refactor(arm juno): Refactor juno_getentropy() feat(bl32): Enable TRNG service build Side note: the “screen real estate” concern some raised does not actually seem to manifest itself in any meaningful way – the longest line only increases by 3 characters, and the shortest line is actually reduced by 3 characters. To me, immediately, the single subject style is much less mentally taxing to parse. Without it, there are at least four different schemes at play here that we need to interpret for every commit (and we’re only 17 commits deep!): foo/bar/baz: xyz foo: bar: baz: xyz foo/bar: baz: xyz Revert “xyz” So, if we just forget about trying to read the history manually for a moment, without a standardised subject format we end up with a changelog that looks like this: Features: - plat/marvell/armada: cleanup MSS SRAM if used for copy - plat/marvell: cn913x: allow CP1/CP2 mapping at BLE stage - plat/marvell/armada/common/mss: use MSS SRAM in secure mode - bl32: Enable TRNG service build Bug Fixes: - libc: memset: Fix MISRA issues - marvell: uart: a3720: Fix comments in console_a3700_core_init() function - spmd: ensure SIMD context is saved/restored on SPMC entry/exit Build System: - nxp: added the makefile helper macros Code Refactoring: - plat:xilinx:zynqmp: Remove the custom crash implementation - lib: cpus: aarch32: sanity check pointers before use - plat/arm/css: rename rd_n1e1_edge_scmi_plat_info array - marvell: uart: a3720: Increase TX FIFO EMPTY timeout from 2ms to 3ms - marvell: uart: a3720: Update delay code to be compatible with 1200 MHz CPU - nand: stm32_fmc_nand: remove dead code - plat/arm: juno: Refactor juno_getentropy() Documentation: - docs: stm32mp1: correct formatting issues Reverts: - Revert "spmd: ensure SIMD context is saved/restored on SPMC entry/exit" This, in my opinion, still suffers from the same problem: as a human, it’s difficult to interpret. Compare that to how we expect that to look with Conventional Commits: Features: - bl32: enable TRNG service build - marvell armada: cleanup MSS SRAM if used for copy - marvell armada: use MSS SRAM in secure mode - marvell cn913x: allow CP1/CP2 mapping at BLE stage Bug Fixes: - libc: fix MISRA issues - marvell a3720: fix comments in console_a3700_core_init() function Build System: - nxp: add Makefile helper macros Code Refactoring: - aarch32: add sanity check pointers before use - arm css: rename rd_n1e1_edge_scmi_plat_info array - arm juno: refactor juno_getentropy() - marvell a3720: increase TX FIFO EMPTY timeout from 2ms to 3ms - marvell a3720: update delay code to be compatible with 1200 MHz CPU - stm32 fmc_nand: remove dead code - xilinx zynqmp: remove the custom crash implementation Documentation: - stm32mp1: correct formatting issues … and I feel like the value prop of using robust tooling becomes more obvious – this tooling is intended not just to categorise commits, but to understand them. You can see here that it emphasises the scope for each change for human readability, and also omits both the revert commit and the commit it reverts because neither of them have been part of a release. Additionally, without a way to enforce this, we’re not necessarily solving one of the current fundamental problems: our changelogs do not accurately and reliably reflect the changes to the project. I think burdening reviewers with additional work is likely to prove unreliable, and certainly counter-productive if we can both largely automate the problem away and provide rapid feedback to developers before ever even having to push for review. Just a quick note on one of your points: 3. Flexibility to define project specific tags The tooling I proposed does already offer some flexibility for defining our own types and scopes, though the default set is already pretty extensive: * build (Build System) * ci (Continuous Integration) * docs (Documentation) * feat (Features) * fix (Bug Fixes) * perf (Performance Improvements) * refactor (Code Refactoring) * revert (Reverts) * style (Styles) * test (Tests) Chris From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Date: Tuesday, 2 March 2021 at 22:31 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>, Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>, nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-A] Adoption of Conventional Commits Hi George, Few clarifications. >> it would need significant investments on tooling [VW] I am not sure why you say that. The only expectation form tooling perspective is to run the ‘git log’ command before the release. >> There is no tool which could help developers crafting the commit message in the right format [VW] I don’t think we need a tool to generate commit messages with the right tags. I expect developers to add the tag manually as the footer. Maintainers will have to check that tags exist as part of the reviews. >> Possibly the easiest would be to modify the javascript machinery available for Conventional Commits [VW] I don’t think we need any tools from the “Conventional Commits” toolbox for this to work. My proposal was from the requirements I heard from Chris in the meeting. If there are any implicit or obvious requirements that I missed, I propose we freeze them first. A solution can only work if the requirements are frozen. -Varun From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Sunday, February 28, 2021 11:14 PM To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Hi Varun, I really like your proposal, but it would need significant investments on tooling. There is no tool which could help developers crafting the commit message in the right format, there is no tool, which can validate the format (and be used i.e. as a git-hook), and there is no tool, which can generate the change history document from git history. Can you please extend the proposal and turn it to be an end-to-end solution? Can you contribute tooling for commit message editing and validation, and for change log document generation? Possibly the easiest would be to modify the javascript machinery available for Conventional Commits. Can you contribute the needed changes? /George From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Varun Wadekar via TF-A Sent: 26 February 2021 00:39 To: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Adoption of Conventional Commits Hi, I really like the idea of using tags in the commit message, but the rigidity of the spec puts me off. Frankly, I believe we just need a way to identify commits and their intent. So, I would like to propose an approach that builds on the “Conventional Commits” spec. The approach would be 1. Add an identifier (e.g. Tags: fix) to the commit message footer. 2. At the start of the release window run “git log”* to print a list of features, bug fixes, performance improvements, deprecations etc. 3. Either update the main changelog manually or use a script to append individual sections. *git log v2.4...HEAD --no-merges --pretty='- %s (%C(auto)%h)' --grep "Tags: fix"> ‘git log’ can be easily modified to look for other metadata as long as we agree to add it to the commit message. Advantages 1. Light(er) 2. No impact to the subject header 3. Flexibility to define project specific tags 4. Training needs at par with “Conventional Commits” proposal Thoughts? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 25, 2021 9:31 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Thanks to all those who attended the Tech Forum today! It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved. If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Adoption of Conventional Commits Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You’ll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly. Chris

4 years, 3 months

3
2
0 0

Re: [TF-A] ATF currently does not use proper printf format specifiers for fixed width types

by Chris Kay

Perhaps we ought to look at doing away with maintaining our own version of freestanding headers like stdint.h in the first place – they’re part of the freestanding portion of the C standard library for good reason (the implementations necessarily come directly from the compiler), and reimplementing them is really prone to portability errors like this (and can frequently confuse static analysers). If we are to continue using it, we should at least look into replacing the definitions with the builtin values provided by the compilers we use, e.g. typedef __UINT64_TYPE__ uint64_t;. Using inttypes.h is the traditional wisdom for this particular specifier issue – `ll` for `long long`, `PRIu64` for `uint64_t. While it’s not particularly pleasant to read/write, it was the solution that the C standards committee came up with, so I approve of the principle of this change but I think a permanent solution would serve us better in the long run. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Wednesday, 3 March 2021 at 15:43 To: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Cc: Scott Branden <scott.branden(a)broadcom.com> Subject: [TF-A] ATF currently does not use proper printf format specifiers for fixed width types Hi All, Back in September Scott posted a query to the group related to a patch he has created relating to printf format specifiers and some of the maintainers from Arm have reservations about and we asked him to get opinions from the broader project community as his patch changes a number of different platforms as well as core code. I’m trying to help him reinvigorate the discussion so reposting his request with patch link below that had stalled. Joanna ________________________________ Scott Branden scott.branden at broadcom.com <mailto:tf-a%40lists.trustedfirmware.org?Subject=Re%3A%20%5BTF-A%5D%20ATF%20currently%20does%20not%20use%20proper%20printf%20format%20specifiers%0A%20for%20fixed%20width%20types&In-Reply-To=%3Cbd3b49f4-e8f9-9016-d11b-d08b81e6b43d%40broadcom.com%3E> Mon Sep 14 18:34:45 UTC 2020 Hello, ATF currently uses non-portable printf format specifiers for fixed width types defined in stdint.h In addition, ATF redefines types defined in gcc for stdint.h with its own custom types causing additional issues. This causes compilation issues when porting code to/from ATF. AND, generates coverity parse errors as int64_t and uint64_t are incorrectly defined in ATF vs. gcc for aarch64. The printf format specifiers in inttypes.h are to be used for the proper format specifiers. And, uint64_t/int64_t should be defined the same as in gcc. I tried fixing up all the instances of int64 printf format specifiers by introducing inttypes.h and redefined the stdint types correctly here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5437 We have checked the change into our local tree so that everything compiles and runs in our system. Please accept change upstream. Regards, Scott

4 years, 3 months

2
2
0 0

ATF currently does not use proper printf format specifiers for fixed width types

by Joanna Farley

Hi All, Back in September Scott posted a query to the group related to a patch he has created relating to printf format specifiers and some of the maintainers from Arm have reservations about and we asked him to get opinions from the broader project community as his patch changes a number of different platforms as well as core code. I’m trying to help him reinvigorate the discussion so reposting his request with patch link below that had stalled. Joanna ________________________________ Scott Branden scott.branden at broadcom.com <mailto:tf-a%40lists.trustedfirmware.org?Subject=Re%3A%20%5BTF-A%5D%20ATF%20currently%20does%20not%20use%20proper%20printf%20format%20specifiers%0A%20for%20fixed%20width%20types&In-Reply-To=%3Cbd3b49f4-e8f9-9016-d11b-d08b81e6b43d%40broadcom.com%3E> Mon Sep 14 18:34:45 UTC 2020 Hello, ATF currently uses non-portable printf format specifiers for fixed width types defined in stdint.h In addition, ATF redefines types defined in gcc for stdint.h with its own custom types causing additional issues. This causes compilation issues when porting code to/from ATF. AND, generates coverity parse errors as int64_t and uint64_t are incorrectly defined in ATF vs. gcc for aarch64. The printf format specifiers in inttypes.h are to be used for the proper format specifiers. And, uint64_t/int64_t should be defined the same as in gcc. I tried fixing up all the instances of int64 printf format specifiers by introducing inttypes.h and redefined the stdint types correctly here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5437 We have checked the change into our local tree so that everything compiles and runs in our system. Please accept change upstream. Regards, Scott

4 years, 3 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Gyorgy Szing

Hi Varun, I really like your proposal, but it would need significant investments on tooling. There is no tool which could help developers crafting the commit message in the right format, there is no tool, which can validate the format (and be used i.e. as a git-hook), and there is no tool, which can generate the change history document from git history. Can you please extend the proposal and turn it to be an end-to-end solution? Can you contribute tooling for commit message editing and validation, and for change log document generation? Possibly the easiest would be to modify the javascript machinery available for Conventional Commits. Can you contribute the needed changes? /George From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: 26 February 2021 00:39 To: Chris Kay <Chris.Kay(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits Hi, I really like the idea of using tags in the commit message, but the rigidity of the spec puts me off. Frankly, I believe we just need a way to identify commits and their intent. So, I would like to propose an approach that builds on the “Conventional Commits” spec. The approach would be 1. Add an identifier (e.g. Tags: fix) to the commit message footer. 2. At the start of the release window run “git log”* to print a list of features, bug fixes, performance improvements, deprecations etc. 3. Either update the main changelog manually or use a script to append individual sections. *git log v2.4...HEAD --no-merges --pretty='- %s (%C(auto)%h)' --grep "Tags: fix"> ‘git log’ can be easily modified to look for other metadata as long as we agree to add it to the commit message. Advantages 1. Light(er) 2. No impact to the subject header 3. Flexibility to define project specific tags 4. Training needs at par with “Conventional Commits” proposal Thoughts? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 25, 2021 9:31 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Thanks to all those who attended the Tech Forum today! It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved. If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Adoption of Conventional Commits Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You’ll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly. Chris

4 years, 3 months

3
5
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. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 367327: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 367327: Uninitialized variables (UNINIT) /services/std_svc/trng/trng_main.c: 32 in trng_rnd32() 26 uint64_t ent[2]; 27 28 if (nbits == 0U || nbits > 96U) { 29 SMC_RET1(handle, TRNG_E_INVALID_PARAMS); 30 } 31 >>> CID 367327: Uninitialized variables (UNINIT) >>> Using uninitialized value "ent[0]" when calling "trng_pack_entropy". 32 if (!trng_pack_entropy(nbits, &ent[0])) { 33 SMC_RET1(handle, TRNG_E_NO_ENTROPY); 34 } 35 36 if ((nbits % 32U) != 0U) { 37 mask >>= 32U - (nbits % 32U); ** CID 367326: Uninitialized variables (UNINIT) ________________________________________________________________________________________________________ *** CID 367326: Uninitialized variables (UNINIT) /services/std_svc/trng/trng_main.c: 68 in trng_rnd64() 62 uint64_t ent[3]; 63 64 if (nbits == 0U || nbits > 192U) { 65 SMC_RET1(handle, TRNG_E_INVALID_PARAMS); 66 } 67 >>> CID 367326: Uninitialized variables (UNINIT) >>> Using uninitialized value "ent[0]" when calling "trng_pack_entropy". 68 if (!trng_pack_entropy(nbits, &ent[0])) { 69 SMC_RET1(handle, TRNG_E_NO_ENTROPY); 70 } 71 72 /* Mask off higher bits if only part of register requested */ 73 if ((nbits % 64U) != 0U) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 4 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Varun Wadekar

Hi, I really like the idea of using tags in the commit message, but the rigidity of the spec puts me off. Frankly, I believe we just need a way to identify commits and their intent. So, I would like to propose an approach that builds on the “Conventional Commits” spec. The approach would be 1. Add an identifier (e.g. Tags: fix) to the commit message footer. 2. At the start of the release window run “git log”* to print a list of features, bug fixes, performance improvements, deprecations etc. 3. Either update the main changelog manually or use a script to append individual sections. *git log v2.4...HEAD --no-merges --pretty='- %s (%C(auto)%h)' --grep "Tags: fix"> ‘git log’ can be easily modified to look for other metadata as long as we agree to add it to the commit message. Advantages 1. Light(er) 2. No impact to the subject header 3. Flexibility to define project specific tags 4. Training needs at par with “Conventional Commits” proposal Thoughts? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 25, 2021 9:31 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Thanks to all those who attended the Tech Forum today! It’s become apparent that the initial 2 week deadline for alternative proposals or implementations is too short, so – as agreed – we’ll push the deadline for the investigation period to the end of March. This period is dedicated to evaluating the changelog automation proposal made, or to identifying alternative solutions. If you have an alternative proposal, any proof-of-concept tooling would be highly appreciated so we can get a clear idea of what sort of work and maintenance is going to be involved. If you do find a solution you wish to propose, please give it just a short name (e.g. “Update it manually”) and make it obvious you want to propose it formally – I’ll collect up the proposals made on the mailing list thread at the end of March and set up a Wiki poll so we can get a clear picture of where the community wants to take this. Chris From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> on behalf of Chris Kay via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Reply to: Chris Kay <Chris.Kay(a)arm.com<mailto:Chris.Kay@arm.com>> Date: Thursday, 11 February 2021 at 13:59 To: "tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>" <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Adoption of Conventional Commits Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it’s to only a relatively minor extent - it does involve an adjustment to everybody’s workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to “something that looks like Conventional Commits”, so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You’ll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody’s on board, we can look to have this upstreamed shortly. Chris

4 years, 4 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 25h February 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 25th February 2021 16:00 – 17:00 (GMT). Agenda: * Cross Project: Conventional Commits Sign-off Discussions * Lead by Chris Kay * Following on from the TF-A Mailing list posting last week https://lists.trustedfirmware.org/pipermail/tf-a/2021-February/000972.html and the ongoing discussion on the WIKI page https://developer.trustedfirmware.org/w/tf_a/conventional_commits/ comments section the plan is to use this weeks TF-A Tech forum to have a live discussion about agreeing a common solution that can be used for TF-A and other Trustedfirmware.org projects. If you wish to participate please read the mailing list thread and the WIKI page including the comments. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

4 years, 4 months

1
0
0 0

TF-A OpenCI : Followup to last Tech Forum meeting

by Joanna Farley

Hi All, After the TF-A Tech-forum on 11th February 2021 (https://www.trustedfirmware.org/meetings/tf-a-technical-forum/) introducing the TF-A OpenCI I wanted to follow up with a posting on how we want to incorporate this new CI workflow into the TF-A project environment and who will have the ability to instigate OpenCI runs for the project. Some guidelines we are looking to follow are: * Be consistent across all Trustedfirmware.org hosted projects (TF-A, TF-M, Hafnium etc) * Be as open as possible to allow project contributors access to the CI. * Protect backend server resources from security attacks. * Be open to tune the workflow process as needs demand. As mentioned in the Tech-forum session the main day to day developer interface with the OpenCI is through Gerrit reviews with the CI+1/CI+2 gerrit labels for patches under review that start two levels of CI coverage. There is also a daily CI run on the integration branch that is started automatically. OpenCI runs for gerrit patch reviews are shown in the patch comments as links into https://ci.trustedfirmware.org/view/TF-A/ where all the Jenkin jobs including the daily build can be found. In addition there is the occasional need to re-trigger CI jobs directly in the Jenkins UI shown above. This can occur if there is an intermittent failure in the CI infrastructure or due to some other cause however its hoped this is only needed to be used rarely and most contributors will not need to use this. The initial plan is allow OpenCI invocation (through Gerrit and Jenkins) to all the TF-A maintainers and Code Owners listed in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/about… as a list of known project contributors. This list can be extended over time with other individuals nominated by anybody on the initial list. The OpenCI will become the primary and only CI for setting the Gerrit verified label for patches under review. The existing ArmCI will become advisory and triggered separately and will not directly influence the Gerrit verified label for patches under review. The ArmCI will be maintained in parallel for those areas not yet migrated to the OpenCI and will be disabled once the next phases of the OpenCI development complete. Any CI results from the ArmCI will be communicated in patch review comments from Arm contributors as required. Project documentation will be updated to incorporate OpenCI usage and a further Tech-forum will be held to go through the CI usage in more detail once the OpenCI is ready to take over as the primary TF-A CI. This is expected and hoping to take place in the next week or two as the final OpenCI deployment issues are resolved but exactly when will be communicated to this list once we have a firm date. Thanks Joanna

4 years, 4 months

1
0
0 0

Re: [TF-A] Adoption of Conventional Commits

by Varun Wadekar

Hi Chris, This seems like a good proposal to alleviate some of the pain around releases. Some observations/questions. 1. Introducing additional tags will eat into precious real estate. This will be a problem for some changes and developers. 2. In the transition period, the proposal has the potential to "pollute" the history 3. The proposal will add more work for patches cherry-picked from other projects e.g. libfdt 4. How do we handle scenarios where platforms donot want to switch to this policy? I can see how #1 might be of concern to many, but we will have to implement some policy to see how many commits really fall in this category. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Chris Kay via TF-A Sent: Thursday, February 11, 2021 5:59 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Adoption of Conventional Commits External email: Use caution opening links or attachments Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it's to only a relatively minor extent - it does involve an adjustment to everybody's workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to "something that looks like Conventional Commits", so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You'll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody's on board, we can look to have this upstreamed shortly. Chris

4 years, 4 months

2
4
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. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 14 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() ________________________________________________________________________________________________________ *** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() 117 tmp = ((mr1_val >> 2) & 1) | ((mr1_val >> 5) & 1) | 118 ((mr1_val >> 7) & 1); 119 if (tmp == 0) 120 drv_config->dram_side_dq_odt = 0; 121 else if (tmp == 1) 122 drv_config->dram_side_dq_odt = 60; >>> CID 366362: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (tmp == 3U) drv_config...". 123 else if (tmp == 3) 124 drv_config->dram_side_dq_odt = 40; 125 else 126 drv_config->dram_side_dq_odt = 120; 127 break; 128 case LPDDR3: ** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() ________________________________________________________________________________________________________ *** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() 197 * tSETUP_MEM > tDS - (tWAIT - tHIZ) 198 */ 199 tset_mem = hclkp; 200 if ((twait < NAND_TCS_MIN) && (tset_mem < (NAND_TCS_MIN - twait))) { 201 tset_mem = NAND_TCS_MIN - twait; 202 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_mem < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 203 if ((twait < NAND_TALS_MIN) && (tset_mem < (NAND_TALS_MIN - twait))) { 204 tset_mem = NAND_TALS_MIN - twait; 205 } 206 if ((twait > thiz) && ((twait - thiz) < NAND_TDS_MIN) && 207 (tset_mem < (NAND_TDS_MIN - (twait - thiz)))) { 208 tset_mem = NAND_TDS_MIN - (twait - thiz); /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } 253 if ((thold_mem < NAND_TRHW_MIN) && 254 (tset_att < (NAND_TRHW_MIN - thold_mem))) { 255 tset_att = NAND_TRHW_MIN - thold_mem; /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() 241 * tSETUP_ATT > tDS - (tWAIT - tHIZ) 242 */ 243 tset_att = hclkp; 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } ** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 87 in gunzip() /lib/zlib/tf_gunzip.c: 83 in gunzip() ________________________________________________________________________________________________________ *** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 87 in gunzip() 81 } 82 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.msg". 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); 89 ERROR("zlib: inflate failed (ret = %d)\n", zret); 90 ret = (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 91 } 92 /lib/zlib/tf_gunzip.c: 83 in gunzip() 77 zret = inflateInit(&stream); 78 if (zret != Z_OK) { 79 ERROR("zlib: inflate init failed (ret = %d)\n", zret); 80 return (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 81 } 82 >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.total_out" when calling "inflate". [Note: The source code implementation of the function has been overridden by a builtin model.] 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); ** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() ________________________________________________________________________________________________________ *** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() 562 if( bs.len < 1 ) 563 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 564 MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 565 566 /* Get actual bitstring */ 567 *key_usage = 0; >>> CID 366283: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "bs.len" as a loop boundary. 568 for( i = 0; i < bs.len && i < sizeof( unsigned int ); i++ ) 569 { 570 *key_usage |= (unsigned int) bs.p[i] << (8*i); 571 } 572 573 return( 0 ); ** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() ________________________________________________________________________________________________________ *** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() 152 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 153 /* This is a cryptography library. Reject negative integers. */ 154 if( ( **p & 0x80 ) != 0 ) 155 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 156 157 /* Skip leading zeros. */ >>> CID 366277: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "len" as a loop boundary. 158 while( len > 0 && **p == 0 ) 159 { 160 ++( *p ); 161 --len; 162 } 163 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 4 months

1
0
0 0

Re: [TF-A] Getting BUILD_STRING from FIP file

by Manish Pandey2

Hi Daniele, TBBR specification, from where fip format was introduced, is not very clear about usage of serial number and it can be used in IMP DEFINED manner "ToC Serial Number - 32 - The serial number of this ToC". So, theoretically it's possible to use serial number for the purpose you described and it's a valid use of currently (un)used serial number. Currently, at boot time serial number is checked against a non-zero value, which certainly will hold true if you put a valid timstamp instead of "0x12345678". IMO you can go ahead and implement a mechanism to feed Build timestamp to be used as serial number. Thanks Manish P ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Manish Badarkhe via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 11 February 2021 11:39 To: Daniele Alessandrelli <daniele.alessandrelli(a)linux.intel.com>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Getting BUILD_STRING from FIP file Hi Daniele Please see my replies inline. Thanks Manish Badarkhe From: Daniele Alessandrelli <daniele.alessandrelli(a)linux.intel.com> Date: Thursday, 11 February 2021 at 11:22 To: Manish Badarkhe <Manish.Badarkhe(a)arm.com>, tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Getting BUILD_STRING from FIP file Hi Manish, Thank you very much for the information. 16 bits are not enough to store an epoch, but I'll see if I can encode some other unique build information into 16 bits. Just a question, from your answer I assume that I shouldn't use the 'serial_number' field for what I want to do; so I wonder: what is that field meant to be used for? 'serial_number' field is non-zero number provided by the fip creation tool. It is hardcoded value i.e. TOC_HEADER_SERIAL_NUMBER=0x12345678 as of now. Specifically used during the validation of the TOC header in the code. Regards, Daniele On Thu, 2021-02-11 at 10:14 +0000, Manish Badarkhe wrote: > Hi Daniele > > You can use the ‘flag’ field to mention the platform-specific data(in > your case, a build number). Usage of the ‘flag’ field(64 bit) in the > toc_header are as below: > Bits 0-31 -> reserved > Bits 32-47 -> platform defined data > Bits 48-63 -> reserved > You can make use of the flag[32:47] to put build information. I am > not sure if you can accommodate epoch (converted timestamp) into this > field but, you can encode any data to fit into this 16bit flag field > to identify the FIP build. > > You can use a build command: fiptool update/create --plat-toc-flags > <platform defined data> <your fip bin path> to put the platform > defined data in the FIP image. > > Thanks > Manish Badarkhe > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > Daniele Alessandrelli via TF-A <tf-a(a)lists.trustedfirmware.org> > Date: Wednesday, 10 February 2021 at 17:04 > To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > Subject: [TF-A] Getting BUILD_STRING from FIP file > > Hi, > > Is there a way to get BUILD_STRING (or a similar string / number that > uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) > from > the FIP file? > > Basically, I'm trying to find a way to know the build number of a FIP > without flashing it. > > I've seen that the FIP TOC header has a 32-bit field named > 'serial_number'. Can it be used to this end? I'm considering > converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as > 'serial number', but I'm worried that might be an unintended usage of > the 'serial_number' field. > > Regards, > Daniele > > >

4 years, 4 months

3
3
0 0

Adoption of Conventional Commits

by Chris Kay

Hi all, Recently we had an internal discussion on the merits of introducing semantics to commit messages pushed to the main TF-A repository, the conclusion being that we would look to adopting the Conventional Commits<https://www.conventionalcommits.org/en/v1.0.0/> specification in the near future. There was one major reason for this, which was to help us in automating the changelog in future releases, but it might also help us to dramatically reduce the overall amount of work needed to make a formal release in the future. This requires some buy-in (or buy-out, in this case) from maintainers because - even though it's to only a relatively minor extent - it does involve an adjustment to everybody's workflow. Notably, commit messages will be expected to adopt the structure defined by the specification, which will be enforced by the CI. Most commits that go upstream today adhere to "something that looks like Conventional Commits", so the change is not exactly sweeping, but any change has the potential be an inconvenience. With that in mind, I propose the following: * We collectively adopt the specification, enforced only for @arm.com contributors until such a time that the majority of maintainers are familiar with the new demands * We suggest - in the prerequisites documentation - the installation of two helper tools: * Commitizen<https://github.com/commitizen/cz-cli> * Commitlint<https://github.com/conventional-changelog/commitlint> Installation of these tools will be optional, but I believe they can help with the transition. In the patches currently in review, they are installed as Git hooks automatically upon execution of npm install, so it requires no manual installation or configuration (other than a relatively up-to-date Node.js installation). You'll find the patches here<https://review.trustedfirmware.org/q/topic:%22ck%252Fconventional-commits%2…>, and specifically the changes to the prerequisites documentation here<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8224/1/docs/…>. Feel free to review these changes if you have comments specifically on their implementation. Let me know if you have any questions or concerns. If everybody's on board, we can look to have this upstreamed shortly. Chris

4 years, 4 months

1
0
0 0

Re: [TF-A] Getting BUILD_STRING from FIP file

by Manish Badarkhe

Hi Daniele You can use the ‘flag’ field to mention the platform-specific data(in your case, a build number). Usage of the ‘flag’ field(64 bit) in the toc_header are as below: 1. Bits 0-31 -> reserved 2. Bits 32-47 -> platform defined data 3. Bits 48-63 -> reserved You can make use of the flag[32:47] to put build information. I am not sure if you can accommodate epoch (converted timestamp) into this field but, you can encode any data to fit into this 16bit flag field to identify the FIP build. You can use a build command: fiptool update/create --plat-toc-flags <platform defined data> <your fip bin path> to put the platform defined data in the FIP image. Thanks Manish Badarkhe From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Daniele Alessandrelli via TF-A <tf-a(a)lists.trustedfirmware.org> Date: Wednesday, 10 February 2021 at 17:04 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Getting BUILD_STRING from FIP file Hi, Is there a way to get BUILD_STRING (or a similar string / number that uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) from the FIP file? Basically, I'm trying to find a way to know the build number of a FIP without flashing it. I've seen that the FIP TOC header has a 32-bit field named 'serial_number'. Can it be used to this end? I'm considering converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as 'serial number', but I'm worried that might be an unintended usage of the 'serial_number' field. Regards, Daniele -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 4 months

2
2
0 0

Getting BUILD_STRING from FIP file

by Daniele Alessandrelli

Hi, Is there a way to get BUILD_STRING (or a similar string / number that uniquely identifies the TF-A build, e.g., BUILD_MESSAGE_TIMESTAMP) from the FIP file? Basically, I'm trying to find a way to know the build number of a FIP without flashing it. I've seen that the FIP TOC header has a 32-bit field named 'serial_number'. Can it be used to this end? I'm considering converting BUILD_MESSAGE_TIMESTAMP into an epoch and adding it as 'serial number', but I'm worried that might be an unintended usage of the 'serial_number' field. Regards, Daniele

4 years, 4 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 11h February 2021 16:00-1700 GMT

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 11th February 2021 16:00 – 17:00 (GMT). Agenda: * TF-A: Open-CI Introduction & Status * Presented by Joanna Farley with support from Linaro OpenCI Enablement Team * Having a Public CI (Continuous Integration) extensible system has been a goal for a while and this presentation will give an introduction and a high level overview along with the current status. A brief walk through what CI jobs are available, when they are run and how results can be accessed will be shown/demoed. Deeper dives into the OpenCI results and how to analyse will be the subject of future Tech Forum sessions. If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting on the TF-A mailing list. Join Zoom Meeting https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…> Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…> Thanks Joanna

4 years, 4 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. 7 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 5 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 7 of 7 defect(s) ** CID 366311: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 366311: Memory - corruptions (OVERRUN) /drivers/renesas/rzg/ddr/ddr_b/boot_init_dram.c: 3156 in rdqdm_man1() 3150 } 3151 } 3152 } 3153 if ((prr_product == PRR_PRODUCT_M3) && 3154 (prr_cut <= PRR_PRODUCT_10)) { 3155 for (slice = 0U; slice < SLICE_CNT; slice++) { >>> CID 366311: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 32 by passing argument "slice" (which evaluates to 24) in call to "rdqdm_man1_set". 3156 rdqdm_man1_set(ddr_csn, ch, slice); 3157 } 3158 } 3159 } 3160 ddrphy_regif_idle(); 3161 ** CID 361221: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 361221: Insecure data handling (TAINTED_SCALAR) /plat/arm/board/arm_fpga/fpga_bl31_setup.c: 238 in fpga_prepare_dtb() 232 233 if (node >= 0) { 234 fdt_del_node(fdt, node); 235 } 236 } 237 >>> CID 361221: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 238 err = fdt_pack(fdt); 239 if (err < 0) { 240 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, err); 241 } 242 243 clean_dcache_range((uintptr_t)fdt, fdt_blob_size(fdt)); ** CID 360537: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360537: Insecure data handling (TAINTED_SCALAR) /plat/qemu/common/qemu_bl2_setup.c: 72 in update_dt() 66 67 if (dt_add_psci_cpu_enable_methods(fdt)) { 68 ERROR("Failed to add PSCI cpu enable methods in Device Tree\n"); 69 return; 70 } 71 >>> CID 360537: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 72 ret = fdt_pack(fdt); 73 if (ret < 0) 74 ERROR("Failed to pack Device Tree at %p: error %d\n", fdt, ret); 75 } 76 77 void bl2_platform_setup(void) ** CID 360536: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360536: (TAINTED_SCALAR) /plat/rpi/rpi4/rpi4_bl31_setup.c: 214 in rpi4_prepare_dtb() 208 int ret, offs; 209 210 /* Return if no device tree is detected */ 211 if (fdt_check_header(dtb) != 0) 212 return; 213 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->totalsize" to a tainted sink. 214 ret = fdt_open_into(dtb, dtb, 0x100000); 215 if (ret < 0) { 216 ERROR("Invalid Device Tree at %p: error %d\n", dtb, ret); 217 return; 218 } 219 /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 214 in rpi4_prepare_dtb() 208 int ret, offs; 209 210 /* Return if no device tree is detected */ 211 if (fdt_check_header(dtb) != 0) 212 return; 213 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_strings" to a tainted sink. 214 ret = fdt_open_into(dtb, dtb, 0x100000); 215 if (ret < 0) { 216 ERROR("Invalid Device Tree at %p: error %d\n", dtb, ret); 217 return; 218 } 219 /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); /plat/rpi/rpi4/rpi4_bl31_setup.c: 243 in rpi4_prepare_dtb() 237 gic_int_prop[2] = cpu_to_fdt32(0x0f04); // all cores, level high 238 fdt_setprop(dtb, offs, "interrupts", gic_int_prop, 12); 239 240 offs = fdt_path_offset(dtb, "/chosen"); 241 fdt_setprop_string(dtb, offs, "stdout-path", "serial0"); 242 >>> CID 360536: (TAINTED_SCALAR) >>> Passing tainted variable "dtb->size_dt_struct" to a tainted sink. 243 ret = fdt_pack(dtb); 244 if (ret < 0) 245 ERROR("Failed to pack Device Tree at %p: error %d\n", dtb, ret); 246 247 clean_dcache_range((uintptr_t)dtb, fdt_blob_size(dtb)); 248 INFO("Changed device tree to advertise PSCI.\n"); ** CID 360535: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 360535: Insecure data handling (TAINTED_SCALAR) /plat/renesas/rcar/bl2_plat_setup.c: 1005 in bl2_el3_early_platform_setup() 999 bl2_lossy_setting(1, LOSSY_ST_ADDR1, LOSSY_END_ADDR1, 1000 LOSSY_FMT1, LOSSY_ENA_DIS1, fcnlnode); 1001 bl2_lossy_setting(2, LOSSY_ST_ADDR2, LOSSY_END_ADDR2, 1002 LOSSY_FMT2, LOSSY_ENA_DIS2, fcnlnode); 1003 #endif 1004 >>> CID 360535: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "fdt->size_dt_struct" to a tainted sink. 1005 fdt_pack(fdt); 1006 NOTICE("BL2: FDT at %p\n", fdt); 1007 1008 if (boot_dev == MODEMR_BOOT_DEV_EMMC_25X1 || 1009 boot_dev == MODEMR_BOOT_DEV_EMMC_50X8) 1010 rcar_io_emmc_setup(); ** CID 346762: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 346762: (TAINTED_SCALAR) /lib/libfdt/fdt_empty_tree.c: 33 in fdt_create_empty_tree() 27 return err; 28 29 err = fdt_end_node(buf); 30 if (err) 31 return err; 32 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_strings" to a tainted sink. 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_struct" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->totalsize" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); /lib/libfdt/fdt_empty_tree.c: 37 in fdt_create_empty_tree() 31 return err; 32 33 err = fdt_finish(buf); 34 if (err) 35 return err; 36 >>> CID 346762: (TAINTED_SCALAR) >>> Passing tainted variable "buf->size_dt_strings" to a tainted sink. 37 return fdt_open_into(buf, buf, bufsize); ** CID 342997: (TAINTED_SCALAR) /plat/st/common/stm32mp_dt.c: 79 in fdt_get_status() /plat/st/common/stm32mp_dt.c: 89 in fdt_get_status() ________________________________________________________________________________________________________ *** CID 342997: (TAINTED_SCALAR) /plat/st/common/stm32mp_dt.c: 79 in fdt_get_status() 73 { 74 uint8_t status = DT_DISABLED; 75 int len; 76 const char *cchar; 77 78 cchar = fdt_getprop(fdt, node, "status", &len); >>> CID 342997: (TAINTED_SCALAR) >>> Passing tainted variable "(size_t)len" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 79 if ((cchar == NULL) || 80 (strncmp(cchar, "okay", (size_t)len) == 0)) { 81 status |= DT_NON_SECURE; 82 } 83 84 cchar = fdt_getprop(fdt, node, "secure-status", &len); /plat/st/common/stm32mp_dt.c: 89 in fdt_get_status() 83 84 cchar = fdt_getprop(fdt, node, "secure-status", &len); 85 if (cchar == NULL) { 86 if (status == DT_NON_SECURE) { 87 status |= DT_SECURE; 88 } >>> CID 342997: (TAINTED_SCALAR) >>> Passing tainted variable "(size_t)len" to a tainted sink. [Note: The source code implementation of the function has been overridden by a builtin model.] 89 } else if (strncmp(cchar, "okay", (size_t)len) == 0) { 90 status |= DT_SECURE; 91 } 92 93 return status; 94 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 4 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. 5 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 14 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() ________________________________________________________________________________________________________ *** CID 366362: Control flow issues (DEADCODE) /plat/rockchip/rk3399/drivers/dram/dfs.c: 123 in get_dram_drv_odt_val() 117 tmp = ((mr1_val >> 2) & 1) | ((mr1_val >> 5) & 1) | 118 ((mr1_val >> 7) & 1); 119 if (tmp == 0) 120 drv_config->dram_side_dq_odt = 0; 121 else if (tmp == 1) 122 drv_config->dram_side_dq_odt = 60; >>> CID 366362: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (tmp == 3U) drv_config...". 123 else if (tmp == 3) 124 drv_config->dram_side_dq_odt = 40; 125 else 126 drv_config->dram_side_dq_odt = 120; 127 break; 128 case LPDDR3: ** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() ________________________________________________________________________________________________________ *** CID 366361: (DEADCODE) /drivers/st/fmc/stm32_fmc2_nand.c: 247 in stm32_fmc2_nand_setup_timing() 241 * tSETUP_ATT > tDS - (tWAIT - tHIZ) 242 */ 243 tset_att = hclkp; 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } /drivers/st/fmc/stm32_fmc2_nand.c: 250 in stm32_fmc2_nand_setup_timing() 244 if ((twait < NAND_TCS_MIN) && (tset_att < (NAND_TCS_MIN - twait))) { 245 tset_att = NAND_TCS_MIN - twait; 246 } 247 if ((twait < NAND_TCLS_MIN) && (tset_att < (NAND_TCLS_MIN - twait))) { 248 tset_att = NAND_TCLS_MIN - twait; 249 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_att < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 250 if ((twait < NAND_TALS_MIN) && (tset_att < (NAND_TALS_MIN - twait))) { 251 tset_att = NAND_TALS_MIN - twait; 252 } 253 if ((thold_mem < NAND_TRHW_MIN) && 254 (tset_att < (NAND_TRHW_MIN - thold_mem))) { 255 tset_att = NAND_TRHW_MIN - thold_mem; /drivers/st/fmc/stm32_fmc2_nand.c: 203 in stm32_fmc2_nand_setup_timing() 197 * tSETUP_MEM > tDS - (tWAIT - tHIZ) 198 */ 199 tset_mem = hclkp; 200 if ((twait < NAND_TCS_MIN) && (tset_mem < (NAND_TCS_MIN - twait))) { 201 tset_mem = NAND_TCS_MIN - twait; 202 } >>> CID 366361: (DEADCODE) >>> Execution cannot reach the expression "tset_mem < 50000UL - twait" inside this statement: "if (twait < 50000UL && tset...". 203 if ((twait < NAND_TALS_MIN) && (tset_mem < (NAND_TALS_MIN - twait))) { 204 tset_mem = NAND_TALS_MIN - twait; 205 } 206 if ((twait > thiz) && ((twait - thiz) < NAND_TDS_MIN) && 207 (tset_mem < (NAND_TDS_MIN - (twait - thiz)))) { 208 tset_mem = NAND_TDS_MIN - (twait - thiz); ** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 83 in gunzip() /lib/zlib/tf_gunzip.c: 87 in gunzip() ________________________________________________________________________________________________________ *** CID 366360: (UNINIT) /lib/zlib/tf_gunzip.c: 83 in gunzip() 77 zret = inflateInit(&stream); 78 if (zret != Z_OK) { 79 ERROR("zlib: inflate init failed (ret = %d)\n", zret); 80 return (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 81 } 82 >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.total_out" when calling "inflate". [Note: The source code implementation of the function has been overridden by a builtin model.] 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); /lib/zlib/tf_gunzip.c: 87 in gunzip() 81 } 82 83 zret = inflate(&stream, Z_NO_FLUSH); 84 if (zret == Z_STREAM_END) { 85 ret = 0; 86 } else { >>> CID 366360: (UNINIT) >>> Using uninitialized value "stream.msg". 87 if (stream.msg) 88 ERROR("%s\n", stream.msg); 89 ERROR("zlib: inflate failed (ret = %d)\n", zret); 90 ret = (zret == Z_MEM_ERROR) ? -ENOMEM : -EIO; 91 } 92 ** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() ________________________________________________________________________________________________________ *** CID 366283: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/x509_crt.c: 568 in x509_get_key_usage() 562 if( bs.len < 1 ) 563 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 564 MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 565 566 /* Get actual bitstring */ 567 *key_usage = 0; >>> CID 366283: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "bs.len" as a loop boundary. 568 for( i = 0; i < bs.len && i < sizeof( unsigned int ); i++ ) 569 { 570 *key_usage |= (unsigned int) bs.p[i] << (8*i); 571 } 572 573 return( 0 ); ** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() ________________________________________________________________________________________________________ *** CID 366277: Insecure data handling (TAINTED_SCALAR) /mbedtls/library/asn1parse.c: 158 in asn1_get_tagged_int() 152 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 153 /* This is a cryptography library. Reject negative integers. */ 154 if( ( **p & 0x80 ) != 0 ) 155 return( MBEDTLS_ERR_ASN1_INVALID_LENGTH ); 156 157 /* Skip leading zeros. */ >>> CID 366277: Insecure data handling (TAINTED_SCALAR) >>> Using tainted variable "len" as a loop boundary. 158 while( len > 0 && **p == 0 ) 159 { 160 ++( *p ); 161 --len; 162 } 163 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 4 months

1
0
0 0

Re: [TF-A] 1023 INTID - closed

by AT&T

All right. Thank you Manish and Olivier for your feedback. You can close this topic. Oliver answered the concern I had regarding implementing a vector table during boot time. Ian Burres Cybersecurity R&D > On Feb 3, 2021, at 3:14 AM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: 1023 spurious interrupt (AT&T) > 2. Re: 1023 spurious interrupt (Olivier Deprez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 18:15:25 -0700 > From: AT&T <iburres(a)att.net> > To: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] 1023 spurious interrupt > Message-ID: <04497C24-78D2-460F-BCC0-535998937145(a)att.net> > Content-Type: text/plain; charset=utf-8 > > Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. > > Ian Burres > Cybersecurity R&D > > >> On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: >> >> Send TF-A mailing list submissions to >> tf-a(a)lists.trustedfirmware.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> or, via email, send a message with subject or body 'help' to >> tf-a-request(a)lists.trustedfirmware.org >> >> You can reach the person managing the list at >> tf-a-owner(a)lists.trustedfirmware.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of TF-A digest..." >> >> >> Today's Topics: >> >> 1. Re: Spurious interrupt 1023 (Ian Burres) >> 2. Re: Spurious interrupt 1023 (Manish Pandey2) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 2 Feb 2021 14:03:05 -0700 >> From: Ian Burres <iburres(a)att.net> >> To: Olivier Deprez <Olivier.Deprez(a)arm.com>, >> "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> >> Subject: Re: [TF-A] Spurious interrupt 1023 >> Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> >> Content-Type: text/plain; charset="utf-8" >> >> UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. >> >> As for your questions Olivier: >> >> The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. >> >> Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. >> >> Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. >> >> Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 >> >> Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. >> >> Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. >> >> Sent from Mail for Windows 10 >> >> From: Olivier Deprez >> Sent: Monday, February 1, 2021 2:36 AM >> To: tf-a(a)lists.trustedfirmware.org; AT&T >> Subject: Re: [TF-A] Spurious interrupt 1023 >> >> Hi Ian, >> >> I guess we'll need a bit more details in order to help you. >> Which platform are you using? which GIC version is it using (looks like GICv2?) ? >> How did you built TF-A for this platform (command line arguments)? >> What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? >> Are you trying to route the UART RX interrupt to EL3? >> Is this UART instance only owned by the SWd? >> How did you setup the interrupt handler? >> Which function are you using to read the INTID? >> >> Regards, >> Olivier. >> >> ________________________________________ >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> >> Sent: 29 January 2021 21:08 >> To: tf-a(a)lists.trustedfirmware.org >> Subject: [TF-A] Spurious interrupt 1023 >> >> I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. >> >> I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? >> >> >> >> Ian Burres >> Cybersecurity R&D >> >> >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> >>

4 years, 4 months

1
0
0 0

Re: [TF-A] 1023 spurious interrupt

by Olivier Deprez

Hi, Stepping back to the initial thread, I now miss the rationale for routing interrupts to EL3. "I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ). I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient." If your intent is to dump user process page tables, that's something to do using the linux kernel mm framework, and not necessarily at EL3. Not sure why a "linux driver is not sufficient". More inputs on this may be beneficial. Nevertheless if you need a service in EL3 to do "introspection", you would rather write a form of SiP service accessed through SMC (not necessarily routing interrupts through FIQ). As for the code snippets, replacing vbar_el3 with your own vector table looks wrong. This will break any service call back into EL3 when linux is booted (e.g. PSCI calls....) If you really want to route interrupts to EL3 you shall use the Interrupt Handling Framework as Manish suggested. e.g. uint64_t fiq_handler(uint32_t id, uint32_t flags, void *handle, void *cookie) { [...] return 0; } void register_my_interrupt(void) { int32_t rc, flags = 0; plat_ic_set_interrupt_type(intid, INTR_TYPE_EL3); set_interrupt_rm_flag(flags, NON_SECURE); rc = register_interrupt_type_handler(INTR_TYPE_EL3, fiq_handler, flags); NOTICE("register_interrupt_type_handler %d\n", rc); } Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 03 February 2021 02:15 To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] 1023 spurious interrupt Yep, I had an O not a zero. Don’t see a difference yet, but that definitely needed to be fixed. Thank you. Ian Burres Cybersecurity R&D > On Feb 2, 2021, at 3:53 PM, tf-a-request(a)lists.trustedfirmware.org wrote: > > Send TF-A mailing list submissions to > tf-a(a)lists.trustedfirmware.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > or, via email, send a message with subject or body 'help' to > tf-a-request(a)lists.trustedfirmware.org > > You can reach the person managing the list at > tf-a-owner(a)lists.trustedfirmware.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TF-A digest..." > > > Today's Topics: > > 1. Re: Spurious interrupt 1023 (Ian Burres) > 2. Re: Spurious interrupt 1023 (Manish Pandey2) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Feb 2021 14:03:05 -0700 > From: Ian Burres <iburres(a)att.net> > To: Olivier Deprez <Olivier.Deprez(a)arm.com>, > "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> > Subject: Re: [TF-A] Spurious interrupt 1023 > Message-ID: <20210202210320.2C48741B32(a)lists.trustedfirmware.org> > Content-Type: text/plain; charset="utf-8" > > UPDATE: I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome. > > As for your questions Olivier: > > The vector table is loaded during bl31 (its called in the bl31_main.c main() function, right after bl31_platform_setup()). The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip. > > Right now both my irq and fiq handlers use: ID = gicv2_get_pending_interrupt_id(); to read the INTID. > > Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG(). Nothing returns for irq. > > Build options are: PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1 > > Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) . However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved. > > Questions: Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly? If you do not, then I think I can take it from here. > > Sent from Mail for Windows 10 > > From: Olivier Deprez > Sent: Monday, February 1, 2021 2:36 AM > To: tf-a(a)lists.trustedfirmware.org; AT&T > Subject: Re: [TF-A] Spurious interrupt 1023 > > Hi Ian, > > I guess we'll need a bit more details in order to help you. > Which platform are you using? which GIC version is it using (looks like GICv2?) ? > How did you built TF-A for this platform (command line arguments)? > What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE? > Are you trying to route the UART RX interrupt to EL3? > Is this UART instance only owned by the SWd? > How did you setup the interrupt handler? > Which function are you using to read the INTID? > > Regards, > Olivier. > > ________________________________________ > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of AT&T via TF-A <tf-a(a)lists.trustedfirmware.org> > Sent: 29 January 2021 21:08 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Spurious interrupt 1023 > > I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops. > > I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code? > > > > Ian Burres > Cybersecurity R&D > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > >

4 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A