Hello,
I am planning to upgrade libfdt library source files in TF-A. They haven't been updated for a while. As the project moves towards improving the fconf framework and adding more properties in device tree source files, we rely more on libfdt APIs. I have done some preliminary investigation to check if there is any performance penalty in upgrading the libfdt source files integrated into TF-A from the current version(which corresponds to commit aadd0b6 in the dtc repo [1]) to master commit (85e5d83). I have run some basics tests on both x86 and aarch64 machines and I have not seen any performance degradation. I plan to push a patch shortly to integrate the latest version of libfdt files in TF-A.
Please let me know if you are aware of any performance issues or have other concerns.
[1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git
Thanks,
Madhu
Hello Matteo,
Apologies for still using an outdated term. I have trained myself to get used to "TF-A" - looks like I am still not there.
>> The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers
That is good to hear. For the exact scope, I think we can assume the usual expectations from any LTS software stack - stability, performance, security, bug fixes along with maintenance support. We are open to discussing the cadence and any other operational commitments.
@Francois, from the description of Trusted Substrate looks like you also expect the sub-projects to provide LTS versions for the project as a whole to succeed (?)
-Varun
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Matteo Carlini via TF-A
Sent: Thursday, June 11, 2020 4:25 AM
To: tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] ATF LTS version
External email: Use caution opening links or attachments
Hi Francois,
> I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...).
> Do you have other firmware LTS needs?
Agree. That’s precisely what I was hinting to Varun, when mentioning concrete requirements for the LTS scheme.
> Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }.
> Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project.
First time I heard about it. Good to know, but I guess we'll need to discuss the intersection and collaboration with the Trusted Firmware project at some point.
Having a LTS versioning scheme for the Trusted Firmware hosted projects should be theoretically either in the scope of the Project itself or, if the Board agrees, appointed to some other project/entity.
> Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2.
Fair, but IMHO this has little to do with Arm Secure world software LTS releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, this is not in scope of what Varun is raising.
Thanks
Matteo
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
I should also mention the Release processes we follow and the attempt to indicated the deprecation of interfaces in advance in the effort to maintain compatibility https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…
On 11/06/2020, 14:47, "TF-A on behalf of Joanna Farley via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi Varun,
I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings.
I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know.
One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests.
Thanks
Joanna
On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote:
Hi Varun,
Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ).
Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space).
The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project.
I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme.
Thanks
Matteo
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A
> Sent: 10 June 2020 22:47
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] ATF LTS version
>
> Hello team,
>
> To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain.
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies.
>
> It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally?
>
> -Varun
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Varun,
I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings.
I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know.
One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests.
Thanks
Joanna
On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote:
Hi Varun,
Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ).
Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space).
The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project.
I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme.
Thanks
Matteo
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A
> Sent: 10 June 2020 22:47
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] ATF LTS version
>
> Hello team,
>
> To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain.
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies.
>
> It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally?
>
> -Varun
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Francois,
> I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...).
> Do you have other firmware LTS needs?
Agree. That’s precisely what I was hinting to Varun, when mentioning concrete requirements for the LTS scheme.
> Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }.
> Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project.
First time I heard about it. Good to know, but I guess we'll need to discuss the intersection and collaboration with the Trusted Firmware project at some point.
Having a LTS versioning scheme for the Trusted Firmware hosted projects should be theoretically either in the scope of the Project itself or, if the Board agrees, appointed to some other project/entity.
> Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2.
Fair, but IMHO this has little to do with Arm Secure world software LTS releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, this is not in scope of what Varun is raising.
Thanks
Matteo
Hi Varun,
Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ).
Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space).
The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project.
I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme.
Thanks
Matteo
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A
> Sent: 10 June 2020 22:47
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] ATF LTS version
>
> Hello team,
>
> To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain.
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies.
>
> It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally?
>
> -Varun
Hi Varun,
There are early discussions in Linaro on what would mean setting up
"Collaborative LTS" for what we call Trusted Substrate (see below
signature).
I'd be happy to know more about what you see as TFA LTS: exact scope,
number of versions, duration, operational commitments (zero-day...).
Do you have other firmware LTS needs?
Cheers
François-Frédéric Ozog
Linaro
Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such
as firmwareTPM, U-Boot }.
Trusted Substrate effort is led by Linaro members and is going to be set up
as a more open project.
Our end goal is to enable unified, transactional, robust (anti-bricking,
anti rollback) UEFI OTA on both U-Boot and EDK2.
On Wed, 10 Jun 2020 at 23:47, Varun Wadekar via TF-A <
tf-a(a)lists.trustedfirmware.org> wrote:
> Hello team,
>
>
>
> To extend the discussion around version upgrades from our last call, I
> would like to understand if there is enough interest around generating a
> LTS version of the TF-A to alleviate the pain.
>
>
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for
> our devices in the field. The LTS version will guarantee security fixes,
> bug fixes, stability fixes for the longer term and we won’t have to upgrade
> the entire firmware to get these goodies.
>
>
>
> It would be interesting to see what OEMs and maintainers think about this?
> Has this been discussed at tf.org or Arm internally?
>
>
>
> -Varun
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
This event has been changed with this note:
"Starting 18th June, the TF-A Tech Forum will be moved earlier by 1 hour to
1600 UK time (1500 UTC). This change is to avoid overlapping the TF
Technical Steering Committee call.
A new invite will be posted to the TF-A mailing list and on the
trustedfirmware.org website."
Title: TF-A Tech Forum
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One 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-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
When: Every 2 weeks from 17:00 to 18:00 on Thursday from Thu 26 Mar to Wed
17 Jun United Kingdom Time (changed)
Where: Zoom
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
(Guest list has been hidden at organiser's request)
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=N3ZoNDBuZzZnM2k4cGszY…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-a(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
This event has been changed with this note:
"Starting 18th June, the TF-A Tech Forum will be moved earlier by 1 hour to
1600 UK time (1500 UTC). This change is to avoid overlapping the TF
Technical Steering Committee call.
A new invite will be posted to the TF-A mailing list and on the
trustedfirmware.org website."
Title: TF-A Tech Forum
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One 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-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
When: Every 2 weeks from 17:00 to 18:00 on Thursday from Thu 7 May to Wed
17 Jun United Kingdom Time (changed)
Where: Zoom
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
(Guest list has been hidden at organiser's request)
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=N3ZoNDBuZzZnM2k4cGszY…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-a(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
This event has been cancelled.
Title: TF-A Tech Forum
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One 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-freeMeeting ID: 915 970 4974Find your
local number: https://zoom.us/u/ad27hc6t7h
When: United Kingdom Time
Where: Zoom
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
(Guest list has been hidden at organiser's request)
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
tf-a(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hi all,
Starting 18th June, the TF-A Tech Forum will be moved earlier by 1 hour to
1600 UK time (1500 UTC). This change is to avoid overlapping with the TF
Technical Steering Committee call.
We'll delete the existing invite and send a new one to this list.
Regards
Bill
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Hello team,
To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain.
For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won't have to upgrade the entire firmware to get these goodies.
It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally?
-Varun
Dear all,
As part of a patchset series review (topic scmi-msg), change [1]
imports confine_array_index.h header file from OP-TEE OS repository.
The file originates from the open source Fuschia project, see link in
commit message of [1].
As being imported for external packages, the header file inherits
Fushca and OP-TEE notices.
The helper function can protect some data structure from side channel
attacks leveraging index indirect access overflows during speculative
execution.
It is not Arm copyright. It is BSD-3-Clause license.
I'll add an entry in the docs/license.rst for the file.
Where to locate the file?
It is ok to add such a file in include/common?
Does it deserve a specific lib path, like
include/lib/speculconfie_array_index.h?
Maybe add as include/lib/cpus/confine_array_index.h as it is CPU
speculative matters?
Could you help [1] review to progress?
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4055
Regards,
Etienne
> On 6 Jun 2020, at 17:52, Heiko Stübner via TF-A <tf-a(a)lists.trustedfirmware.org> wrote:
>
> Hi Walter,
>
> Am Freitag, 5. Juni 2020, 22:45:25 CEST schrieb Walter Lozano via TF-A:
>> I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE
>> defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot
>> default value and most documentation points to a value of 1500000 for
>> console.
>
> console baudrate on rk3399 differ a lot between boards. There are a
> number using the 1.5MHz and another big number using 115200
> (including but not limited to the ChromeOS devices from the Gru line).
>
> Hence we have the code that selects the actual baudrate from the
> devicetree attached by u-boot when calling TF-A.
>
> So I guess it should stay as it is right now.
On the RK3399 there are currently a couple of roadblocks preventing
this selection of the baudrate from the devicetree from working.
Firstly in U-Boot, SPL_ATF_NO_PLATFORM_PARAM is forced on when
selecting ROCKCHIP_RK3399 in Kconfig [1].
Secondly in TF-A the 64K buffer used to store the passed devicetree
isn't large enough to fit some of the RK3399 device tree blobs, as I
found when removing SPL_ATF_NO_PLATFORM_PARAM from U-Boot.
I guess the issue in TF-A needs to be fixed first before passing the
platform parameter can be enabled in U-Boot, I've submitted a TF-A
patch to increase the buffer size [2].
[1]: https://gitlab.denx.de/u-boot/u-boot/-/blob/61853a7ac7e167d90899ec4e99d2e07…
[2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4512
> Heiko
>
>
>> This of course means that messages printed by ATF are not visible by
>> default in this context.
>>
>> The change from 1500000 to 115200 was introduced in
>> 0c05748bdebfad9fa43a80962186438bb8fbce62,
>>
>> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05…
>>
>> with the following message
>>
>> commit 0c05748bdebfad9fa43a80962186438bb8fbce62
>> Author: Caesar Wang <wxt(a)rock-chips.com>
>> Date: Tue Apr 19 20:42:17 2016 +0800
>>
>> rockchip: fixes for the required
>>
>> This patch has the following change for rk3399.
>>
>> * Set the uart to 115200 since the loader decide to set
>> uart baud to 115200Hz. So the ATF also should set uart baud to 115200.
>> [..]
>>
>> However, I'm not sure it this still applies.
>>
>> I'll be happy to submit a patch to update the value if it is OK.
>>
>> Regards,
>>
>> Walter
>>
>>
>
>
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hello,
Sorry for chiming in late. Are we sure that the msr/mrs to the GICv3 EOI
register is not a context synchronizing event or ensures ordering itself
? Also did the addition of DSB() fix the issue ? If yes, can you try
adding a delay or a few NOP's/dummy instructions or an ISB to see if the
issue goes away?
We need to know the right thing to do architecturally and confirm that
the issue is really due to reordering at the core before adding the DSB.
Adding a DSB might be masking a timing issue.
-Raghu
On 6/8/20 4:47 AM, Sandeep Tripathy via TF-A wrote:
>> -----Original Message-----
>> From: Soby Mathew [mailto:Soby.Mathew@arm.com]
>> Sent: Monday, June 08, 2020 3:36 PM
>> To: Sandeep Tripathy; Olivier Deprez; tf-a(a)lists.trustedfirmware.org
>> Cc: nd
>> Subject: RE: [TF-A] GICV3: system interface EOI ordering RFC
>>
>> Just some inputs from my side:
>> I agree we need at least a dsb() after the write to MMIO region to silence
>> the
>> peripheral and before the EOI at GIC sysreg interface. Adding it to the
>> GIC EOI
>
> Thanks for the confirmation. Now it’s about choosing the right place.
>
>> API seems the logical thing to do but as Olivier mentions, there are
>> interrupt
>> handler which do not deal with MMIO (eg: the Systimer interrupt) so adding
>> it
>> to GICv3 API might be arduous for such handlers.
>>
>> So there is a choice here to let the interrupt handlers to deal with
>> ensuring
>> completeness before EOI at sysreg interface or adding it to GICv3 EOI API
>> and
>> take the overhead for interrupt handlers which do not have to deal with
>> MMIO.
>>
>
> Yes I feel either of these is a must to guarantee functionality
> architecturally though
> both approach end up with some unnecessary overhead.
>
> If GICv3 api takes care then it is an overhead for some ISRs dealing with
> non-MMIO.
> At present I do not see an active use case in reference implementation where
> sys timer
> ISR is in a performance intensive path where one additional DSB will be
> perceivable.
> But there may be some I could be totally wrong in this assumption (pmu/debug
> or.. not sure).
> Whereas I can certainly imagine some MMIO ISRs in performance critical path
> where unnecessary
> DSB is not acceptable at all.
>
> If the interrupt handler needs to ensure then it will generically add 'DSB'
> as I think
> the driver cannot and should not make assumptions about how EOI is done
> afterwards.
> That will be overhead for the ISRs dealing with MMIO peripherals and non
> GIC-v3.
> If we consider only GICv3+ then good. Otherwise I would prefer the
> 'plat_ic_end_of_interrupt'
> like Olivier mentioned with a #if GICv3 instead of each ISRs dealing with
> it.
>
>> The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys
>> interface is the only one GICv3 driver in TF-A supports.
>
> Right we can ignore the GICv3 legacy mode but GICv2 will still remain ?
>
>>
>> Best Regards
>> Soby Mathew
>>
>
> Thanks
> Sandeep
>
>>> -----Original Message-----
>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep
>>> Tripathy via TF-A
>>> Sent: 08 June 2020 10:34
>>> To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-
>> a(a)lists.trustedfirmware.org
>>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC
>>>
>>> Hi Olivier,
>>>> -----Original Message-----
>>>> From: Olivier Deprez [mailto:Olivier.Deprez@arm.com]
>>>> Sent: Monday, June 08, 2020 1:14 PM
>>>> To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy
>>>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC
>>>>
>>>> Hi Sandeep,
>>>>
>>>> gicv3_end_of_interrupt_sel1 is a static access helper macro. Its
>>>> naming precisely tells what it does at gicv3 module level. It is
>>>> called from
>>> the weak
>>>> plat_ic_end_of_interrupt function for BL32 image.
>>>>
>>>> I tend to think it is the driver responsibility to ensure the module
>>> interrupt
>>>> acknowledge register write is reaching HW in order (or "be visible to
>>> all
>>>> observers").
>>>
>>> The driver should be agnostic of what interrupt controller is used and
>>> its
>>> behavior.
>>> And since 'all' writes were to mmio ranges mapped Device(nGnRE)
>>> /strongly-ordered(nGnRnE)
>>> there was no such need. This is a special case for GICv3 system
>>> interface only.
>>> Adding at driver level a DSB is unnecessary for other interrupt
>>> controllers.
>>>
>>>> Also I suspect adding a dsb might not be required generically for all
>>> kind of IP.
>>>
>>> Here are you referring to the peripheral IP or interrupt controller IP ?
>>> The issue is reordering at arm core itself (STR to device address Vs
>>> msr(sysreg
>>> write)).
>>> So I think Its applicable for all IP.
>>>
>>>> Adding a barrier in generic code might incur an unnecessary
>>>> bottleneck.
>>>
>>> But if there is a need to *ensure* presence of at least one DSB between
>>> the
>>> write transfer from core to device clear and gicv3 eoi icc register
>>> write in a
>>> generic way then what other option we have.
>>>>
>>>> Thus wouldn't it be better to add the barrier to the overridden
>>>> platform function rather than in generic gicv3 code?
>>>
>>> That can be done but I feel this is more to do with gicv3 system
>>> interface only.
>>> Inside plat_xxx one has to check #if GICV3 ...and system interface.
>>>>
>>>> I have a put a comment in the review, we can continue the discussion
>>> there.
>>>>
>>>> Regards,
>>>> Olivier.
>>>>
>>> Thanks
>>> Sandeep
>>>> ________________________________________
>>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of
>>>> Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org>
>>>> Sent: 05 June 2020 19:43
>>>> To: tf-a(a)lists.trustedfirmware.org
>>>> Subject: [TF-A] GICV3: system interface EOI ordering RFC
>>>>
>>>> Hi,
>>>> In a typical interrupt handling sequence we do 1-Read IAR
>>>> 2-Do interrupt handling
>>>> 3-Clear the interrupt at source , so that the device de-asserts IRQ
>>> request to
>>>> GIC
>>>> >> I am suggesting a need of DSB here in case of GICv3 +.
>>>> 4-Write to GIC cpu interface to do EOI.
>>>>
>>>> Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write
>>>> over
>>> AMBA
>>>> interface. The
>>>> Addresses are mapped with (nR) attribute. Hence the write transfers
>>> from the
>>>> core will be
>>>> generated at step 3 and 4 in order. Please ignore the additional
>>> buffers/bridges
>>>> in path from
>>>> core till peripheral which has to be dealt separately as per SOC.
>>>>
>>>> Query: I understand GICv3 system interface accesses are not over this
>>> protocol
>>>> and core will not
>>>> follow the ordering rule ?
>>>>
>>>> I have observed spurious interrupt issue/manifestation ( I don't have
>>> the
>>>> transfers probed) in
>>>> RTOS environment where I have a primitive GICv3 driver but I wonder
>>>> why things does not fail in Linux or tf-a. If it is working because
>>>> from step(3) to
>>> step(4) we have
>>>> barriers by chace
>>>> due to other device register writes then I would suggest to have one
>>>> in
>>> the EOI
>>>> clearing API itself.
>>>>
>>>> RFC:
>>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454
>>>>
>>>> Thanks
>>>> Sandeep
>>> --
>>> TF-A mailing list
>>> TF-A(a)lists.trustedfirmware.org
>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
> -----Original Message-----
> From: Soby Mathew [mailto:Soby.Mathew@arm.com]
> Sent: Monday, June 08, 2020 3:36 PM
> To: Sandeep Tripathy; Olivier Deprez; tf-a(a)lists.trustedfirmware.org
> Cc: nd
> Subject: RE: [TF-A] GICV3: system interface EOI ordering RFC
>
> Just some inputs from my side:
> I agree we need at least a dsb() after the write to MMIO region to silence
> the
> peripheral and before the EOI at GIC sysreg interface. Adding it to the
> GIC EOI
Thanks for the confirmation. Now it’s about choosing the right place.
> API seems the logical thing to do but as Olivier mentions, there are
> interrupt
> handler which do not deal with MMIO (eg: the Systimer interrupt) so adding
> it
> to GICv3 API might be arduous for such handlers.
>
> So there is a choice here to let the interrupt handlers to deal with
> ensuring
> completeness before EOI at sysreg interface or adding it to GICv3 EOI API
> and
> take the overhead for interrupt handlers which do not have to deal with
> MMIO.
>
Yes I feel either of these is a must to guarantee functionality
architecturally though
both approach end up with some unnecessary overhead.
If GICv3 api takes care then it is an overhead for some ISRs dealing with
non-MMIO.
At present I do not see an active use case in reference implementation where
sys timer
ISR is in a performance intensive path where one additional DSB will be
perceivable.
But there may be some I could be totally wrong in this assumption (pmu/debug
or.. not sure).
Whereas I can certainly imagine some MMIO ISRs in performance critical path
where unnecessary
DSB is not acceptable at all.
If the interrupt handler needs to ensure then it will generically add 'DSB'
as I think
the driver cannot and should not make assumptions about how EOI is done
afterwards.
That will be overhead for the ISRs dealing with MMIO peripherals and non
GIC-v3.
If we consider only GICv3+ then good. Otherwise I would prefer the
'plat_ic_end_of_interrupt'
like Olivier mentioned with a #if GICv3 instead of each ISRs dealing with
it.
> The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys
> interface is the only one GICv3 driver in TF-A supports.
Right we can ignore the GICv3 legacy mode but GICv2 will still remain ?
>
> Best Regards
> Soby Mathew
>
Thanks
Sandeep
> > -----Original Message-----
> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep
> > Tripathy via TF-A
> > Sent: 08 June 2020 10:34
> > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-
> a(a)lists.trustedfirmware.org
> > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC
> >
> > Hi Olivier,
> > > -----Original Message-----
> > > From: Olivier Deprez [mailto:Olivier.Deprez@arm.com]
> > > Sent: Monday, June 08, 2020 1:14 PM
> > > To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy
> > > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC
> > >
> > > Hi Sandeep,
> > >
> > > gicv3_end_of_interrupt_sel1 is a static access helper macro. Its
> > > naming precisely tells what it does at gicv3 module level. It is
> > > called from
> > the weak
> > > plat_ic_end_of_interrupt function for BL32 image.
> > >
> > > I tend to think it is the driver responsibility to ensure the module
> > interrupt
> > > acknowledge register write is reaching HW in order (or "be visible to
> > all
> > > observers").
> >
> > The driver should be agnostic of what interrupt controller is used and
> > its
> > behavior.
> > And since 'all' writes were to mmio ranges mapped Device(nGnRE)
> > /strongly-ordered(nGnRnE)
> > there was no such need. This is a special case for GICv3 system
> > interface only.
> > Adding at driver level a DSB is unnecessary for other interrupt
> > controllers.
> >
> > > Also I suspect adding a dsb might not be required generically for all
> > kind of IP.
> >
> > Here are you referring to the peripheral IP or interrupt controller IP ?
> > The issue is reordering at arm core itself (STR to device address Vs
> > msr(sysreg
> > write)).
> > So I think Its applicable for all IP.
> >
> > > Adding a barrier in generic code might incur an unnecessary
> > > bottleneck.
> >
> > But if there is a need to *ensure* presence of at least one DSB between
> > the
> > write transfer from core to device clear and gicv3 eoi icc register
> > write in a
> > generic way then what other option we have.
> > >
> > > Thus wouldn't it be better to add the barrier to the overridden
> > > platform function rather than in generic gicv3 code?
> >
> > That can be done but I feel this is more to do with gicv3 system
> > interface only.
> > Inside plat_xxx one has to check #if GICV3 ...and system interface.
> > >
> > > I have a put a comment in the review, we can continue the discussion
> > there.
> > >
> > > Regards,
> > > Olivier.
> > >
> > Thanks
> > Sandeep
> > > ________________________________________
> > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of
> > > Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org>
> > > Sent: 05 June 2020 19:43
> > > To: tf-a(a)lists.trustedfirmware.org
> > > Subject: [TF-A] GICV3: system interface EOI ordering RFC
> > >
> > > Hi,
> > > In a typical interrupt handling sequence we do 1-Read IAR
> > > 2-Do interrupt handling
> > > 3-Clear the interrupt at source , so that the device de-asserts IRQ
> > request to
> > > GIC
> > > >> I am suggesting a need of DSB here in case of GICv3 +.
> > > 4-Write to GIC cpu interface to do EOI.
> > >
> > > Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write
> > > over
> > AMBA
> > > interface. The
> > > Addresses are mapped with (nR) attribute. Hence the write transfers
> > from the
> > > core will be
> > > generated at step 3 and 4 in order. Please ignore the additional
> > buffers/bridges
> > > in path from
> > > core till peripheral which has to be dealt separately as per SOC.
> > >
> > > Query: I understand GICv3 system interface accesses are not over this
> > protocol
> > > and core will not
> > > follow the ordering rule ?
> > >
> > > I have observed spurious interrupt issue/manifestation ( I don't have
> > the
> > > transfers probed) in
> > > RTOS environment where I have a primitive GICv3 driver but I wonder
> > > why things does not fail in Linux or tf-a. If it is working because
> > > from step(3) to
> > step(4) we have
> > > barriers by chace
> > > due to other device register writes then I would suggest to have one
> > > in
> > the EOI
> > > clearing API itself.
> > >
> > > RFC:
> > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454
> > >
> > > Thanks
> > > Sandeep
> > --
> > TF-A mailing list
> > TF-A(a)lists.trustedfirmware.org
> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Just some inputs from my side:
I agree we need atleast a dsb() after the write to MMIO region to silence the peripheral and before the EOI at GIC sysreg interface. Adding it to the GIC EOI API seems the logical thing to do but as Olivier mentions, there are interrupt handler which do not deal with MMIO (eg: the Systimer interrupt) so adding it to GICv3 API might be arduous for such handlers.
So there is a choice here to let the interrupt handlers to deal with ensuring completeness before EOI at sysreg interface or adding it to GICv3 EOI API and take the overhead for interrupt handlers which do not have to deal with MMIO.
The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys interface is the only one GICv3 driver in TF-A supports.
Best Regards
Soby Mathew
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep
> Tripathy via TF-A
> Sent: 08 June 2020 10:34
> To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org
> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC
>
> Hi Olivier,
> > -----Original Message-----
> > From: Olivier Deprez [mailto:Olivier.Deprez@arm.com]
> > Sent: Monday, June 08, 2020 1:14 PM
> > To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy
> > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC
> >
> > Hi Sandeep,
> >
> > gicv3_end_of_interrupt_sel1 is a static access helper macro. Its
> > naming precisely tells what it does at gicv3 module level. It is
> > called from
> the weak
> > plat_ic_end_of_interrupt function for BL32 image.
> >
> > I tend to think it is the driver responsibility to ensure the module
> interrupt
> > acknowledge register write is reaching HW in order (or "be visible to
> all
> > observers").
>
> The driver should be agnostic of what interrupt controller is used and its
> behavior.
> And since 'all' writes were to mmio ranges mapped Device(nGnRE)
> /strongly-ordered(nGnRnE)
> there was no such need. This is a special case for GICv3 system interface only.
> Adding at driver level a DSB is unnecessary for other interrupt controllers.
>
> > Also I suspect adding a dsb might not be required generically for all
> kind of IP.
>
> Here are you referring to the peripheral IP or interrupt controller IP ?
> The issue is reordering at arm core itself (STR to device address Vs msr(sysreg
> write)).
> So I think Its applicable for all IP.
>
> > Adding a barrier in generic code might incur an unnecessary bottleneck.
>
> But if there is a need to *ensure* presence of at least one DSB between the
> write transfer from core to device clear and gicv3 eoi icc register write in a
> generic way then what other option we have.
> >
> > Thus wouldn't it be better to add the barrier to the overridden
> > platform function rather than in generic gicv3 code?
>
> That can be done but I feel this is more to do with gicv3 system interface only.
> Inside plat_xxx one has to check #if GICV3 ...and system interface.
> >
> > I have a put a comment in the review, we can continue the discussion
> there.
> >
> > Regards,
> > Olivier.
> >
> Thanks
> Sandeep
> > ________________________________________
> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of
> > Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org>
> > Sent: 05 June 2020 19:43
> > To: tf-a(a)lists.trustedfirmware.org
> > Subject: [TF-A] GICV3: system interface EOI ordering RFC
> >
> > Hi,
> > In a typical interrupt handling sequence we do 1-Read IAR
> > 2-Do interrupt handling
> > 3-Clear the interrupt at source , so that the device de-asserts IRQ
> request to
> > GIC
> > >> I am suggesting a need of DSB here in case of GICv3 +.
> > 4-Write to GIC cpu interface to do EOI.
> >
> > Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write
> > over
> AMBA
> > interface. The
> > Addresses are mapped with (nR) attribute. Hence the write transfers
> from the
> > core will be
> > generated at step 3 and 4 in order. Please ignore the additional
> buffers/bridges
> > in path from
> > core till peripheral which has to be dealt separately as per SOC.
> >
> > Query: I understand GICv3 system interface accesses are not over this
> protocol
> > and core will not
> > follow the ordering rule ?
> >
> > I have observed spurious interrupt issue/manifestation ( I don't have
> the
> > transfers probed) in
> > RTOS environment where I have a primitive GICv3 driver but I wonder
> > why things does not fail in Linux or tf-a. If it is working because
> > from step(3) to
> step(4) we have
> > barriers by chace
> > due to other device register writes then I would suggest to have one
> > in
> the EOI
> > clearing API itself.
> >
> > RFC:
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454
> >
> > Thanks
> > Sandeep
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Sandeep,
gicv3_end_of_interrupt_sel1 is a static access helper macro. Its naming precisely tells what it does at gicv3 module level. It is called from the weak plat_ic_end_of_interrupt function for BL32 image.
I tend to think it is the driver responsibility to ensure the module interrupt acknowledge register write is reaching HW in order (or "be visible to all observers").
Also I suspect adding a dsb might not be required generically for all kind of IP. Adding a barrier in generic code might incur an unnecessary bottleneck.
Thus wouldn't it be better to add the barrier to the overridden platform function rather than in generic gicv3 code?
I have a put a comment in the review, we can continue the discussion there.
Regards,
Olivier.
________________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 05 June 2020 19:43
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] GICV3: system interface EOI ordering RFC
Hi,
In a typical interrupt handling sequence we do
1-Read IAR
2-Do interrupt handling
3-Clear the interrupt at source , so that the device de-asserts IRQ request to GIC
>> I am suggesting a need of DSB here in case of GICv3 +.
4-Write to GIC cpu interface to do EOI.
Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over AMBA interface. The
Addresses are mapped with (nR) attribute. Hence the write transfers from the core will be
generated at step 3 and 4 in order. Please ignore the additional buffers/bridges in path from
core till peripheral which has to be dealt separately as per SOC.
Query: I understand GICv3 system interface accesses are not over this protocol and core will not
follow the ordering rule ?
I have observed spurious interrupt issue/manifestation ( I don’t have the transfers probed) in
RTOS environment where I have a primitive GICv3 driver but I wonder why things does
not fail in Linux or tf-a. If it is working because from step(3) to step(4) we have barriers by chace
due to other device register writes then I would suggest to have one in the EOI clearing API itself.
RFC: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454
Thanks
Sandeep
Hi Walter,
Am Freitag, 5. Juni 2020, 22:45:25 CEST schrieb Walter Lozano via TF-A:
> I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE
> defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot
> default value and most documentation points to a value of 1500000 for
> console.
console baudrate on rk3399 differ a lot between boards. There are a
number using the 1.5MHz and another big number using 115200
(including but not limited to the ChromeOS devices from the Gru line).
Hence we have the code that selects the actual baudrate from the
devicetree attached by u-boot when calling TF-A.
So I guess it should stay as it is right now.
Heiko
> This of course means that messages printed by ATF are not visible by
> default in this context.
>
> The change from 1500000 to 115200 was introduced in
> 0c05748bdebfad9fa43a80962186438bb8fbce62,
>
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05…
>
> with the following message
>
> commit 0c05748bdebfad9fa43a80962186438bb8fbce62
> Author: Caesar Wang <wxt(a)rock-chips.com>
> Date: Tue Apr 19 20:42:17 2016 +0800
>
> rockchip: fixes for the required
>
> This patch has the following change for rk3399.
>
> * Set the uart to 115200 since the loader decide to set
> uart baud to 115200Hz. So the ATF also should set uart baud to 115200.
> [..]
>
> However, I'm not sure it this still applies.
>
> I'll be happy to submit a patch to update the value if it is OK.
>
> Regards,
>
> Walter
>
>
I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE
defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot
default value and most documentation points to a value of 1500000 for
console.
This of course means that messages printed by ATF are not visible by
default in this context.
The change from 1500000 to 115200 was introduced in
0c05748bdebfad9fa43a80962186438bb8fbce62,
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05…
with the following message
commit 0c05748bdebfad9fa43a80962186438bb8fbce62
Author: Caesar Wang <wxt(a)rock-chips.com>
Date: Tue Apr 19 20:42:17 2016 +0800
rockchip: fixes for the required
This patch has the following change for rk3399.
* Set the uart to 115200 since the loader decide to set
uart baud to 115200Hz. So the ATF also should set uart baud to 115200.
[..]
However, I'm not sure it this still applies.
I'll be happy to submit a patch to update the value if it is OK.
Regards,
Walter
Hi,
In a typical interrupt handling sequence we do
1-Read IAR
2-Do interrupt handling
3-Clear the interrupt at source , so that the device de-asserts IRQ
request to GIC
>> I am suggesting a need of DSB here in case of GICv3 +.
4-Write to GIC cpu interface to do EOI.
Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over
AMBA interface. The
Addresses are mapped with (nR) attribute. Hence the write transfers from
the core will be
generated at step 3 and 4 in order. Please ignore the additional
buffers/bridges in path from
core till peripheral which has to be dealt separately as per SOC.
Query: I understand GICv3 system interface accesses are not over this
protocol and core will not
follow the ordering rule ?
I have observed spurious interrupt issue/manifestation ( I don’t have the
transfers probed) in
RTOS environment where I have a primitive GICv3 driver but I wonder why
things does
not fail in Linux or tf-a. If it is working because from step(3) to step(4)
we have barriers by chace
due to other device register writes then I would suggest to have one in the
EOI clearing API itself.
RFC: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454
Thanks
Sandeep
Hi Okash,
These are generally provided on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ however they are missing from 7th May onwards at the moment. I have an update pending approval on tf.org for adding the details of that session and then I need to add the information from the session on 21st May and the session yesterday.
Joanna
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Okash Khawaja via TF-A <tf-a(a)lists.trustedfirmware.org>
Reply to: Okash Khawaja <okash.khawaja(a)gmail.com>
Date: Friday, 5 June 2020 at 11:29
To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Slides for recent TF-A Forums
Hi,
Where can I find slides for recent TF-A Forum presentations?
Thanks,
Okash
Hi Bill,
I continue to the error while trying to invoke “Allow-CI” or other votes as part of gerrit review. I tried multiple browsers as well and logged out before attempting again.
Thanks,
Madhu
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-A
Sent: Tuesday, June 2, 2020 12:13 PM
To: Varun Wadekar <vwadekar(a)nvidia.com>
Cc: tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] Gerrit seems to be broken
Hi Varun,
Do you still see the problem? It has been reported before.
Regards
Bill
On Tue, 2 Jun 2020 at 18:01, Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote:
Hello,
The TF gerrit review dashboard seems to be broken this morning. I see “Server error” and it does not allow me to post scores or comments. Tried different browsers, but same issue persists.
Anyone else seeing the same problem? Is this is a known issue? If yes, is anyone working on it?
-Varun
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
[Image removed by sender. Linaro]<http://www.linaro.org/>
Bill Fletcher | Field Engineering
T: +44 7833 498336<tel:+44+7833+498336>
bill.fletcher(a)linaro.org<mailto:bill.fletcher@linaro.org> | Skype: billfletcher2020
