Hi,
(BCC:ing Antonio as well)
not sure if someone gets notified, but I pushed a patch set to add
Raspberry Pi 4 support to Trusted Firmware:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1629
This port is quite a departure from the existing RPi3 port, that's why I
wanted to start a discussion about it here.
I originally started by copying files. But for the sake of simplicity,
also to get away without a BL33 loader, it turned into just a BL31-only port
(for now?). This ties more into the existing RPi Foundation boot style, as
the resulting bl31.bin is a drop-in replacement for the existing
armstub8.bin. So you put your AArch64 kernel into kernel8.img and copy
bl31.bin to armstub8.bin (or use the respective config.txt options to
point to any other filename), and it should work (TM). The code will pick up
the actual kernel and DTB load address from the GPU firmware, patch the DT
to use PSCI instead of spin tables, then will drop into EL2 at the kernel
load address. There could (should?) be U-Boot or EDK-II there as well, or
any other kernel, for that matter. The only thing Linux specific we do is
to put the DTB address into x0. I guess this doesn't hurt, even if the BL33
payload does not use this information.
I would be grateful to hear some opinions about this approach.
Does that sound sensible?
Is the split of the platform directory (plat/rpi3 -> plat/rpi/rpi[34])
reasonable?
Shall we add this design as a build option to RPi3 as well?
Shall we add the "full featured" RPi3 design to RPi4 also?
Looking forward to any feedback!
Cheers,
Andre.
Hi,
On 7/3/19 11:15 AM, Sandrine Bailleux via TF-A wrote:
> We would need help from the TF-A community for analyzing and fixing
> them, especially those in platform ports and drivers. Note that there
> might be false positives, in which case we would just triage them as
> such in the tool's database.
>
> Hopefully everyone should be able to view the defects, according to the
> tool's settings. You might need to create an account on
> https://scan.coverity.com for that.
We've received a couple of requests from users to get access to the TF-A
defects database in the Coverity Scan Online service. I think it's worth
clarifying the different levels of access the tool offers and how we
envisage the defects triaging.
In Coverity Scan Online, users can have any of the following 4 roles (in
ascending order of permissions):
- Observer/User: Only sees defects summary.
- Defect Viewer.
- Contributor/Member: Can also triage defects.
- Maintainer/Owner: Also has some admin powers, like managing users and
submitting builds to be analyzed.
Right now, all users should be able to see the project summary and view
the defects in read-only mode so this is equivalent to the "Defect
viewer" role. I suspect people still need to create an account in
Coverity Scan Online and be logged in to see the data.
We would expect subsystems and platforms maintainers (i.e. people listed
in docs/maintainers.rst [1]) to manage the defects in the part of the
codebase they own, as they know best how to assess the severity of these
defects and how to fix or triage them. As such, they need to have the
"contributor/member" role in the tool. If you are such a maintainer,
please feel free to create an account and request this role.
If you would like to delegate part/all of the triaging process to a
peer, that is also possible. In this case, could you please send me an
email to indicate who you have chosen for this task? This is just to
make sure that whoever requests the "contributor/member" role has done
so with the relevant maintainer's approval.
Please be aware that those with "contributor/member" role will be able
to triage any defects in any part of the codebase, and not just in the
subsystem/platform they maintain.
"Maintainer/Owner" role will be reserved to the main maintainers (i.e.
people listed at the top of docs/maintainers.rst) for now.
Best regards,
Sandrine
[1]
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/maint…
Hi Jun,
On 7/16/19 11:30 AM, John Tsichritzis via TF-A wrote:
> Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself.
>
> When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch.
To add on top of what John said, I would like to mention that we are
working with Linaro to have the CI loop opened up to all contributors in
the future. When this day comes, you will be able to check the error log
by yourself. In the meantime, I'm afraid you'll have to rely on Arm
maintainers to give you the details, as John said. If they forget,
please feel free to ping them in Gerrit (like you've already done for
this patch).
Best regards,
Sandrine
Dear Jun,
Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself.
When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch.
Kind regards,
John
--
John Tsichritzis | Graduate Software Engineer
Email: john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com>
110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom
https://www.arm.com/
On 16/07/2019 09.24, Jun Nie via TF-A wrote:
Hi,
I see below failure in this link:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367
How can I check the error log? I am not sure it is due to lack of
earlier patch in patch set or something. Because local build is OK.
Patch Set 4: Verified-1
Build Failed
https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE
Jun
Hi Everyone,
This is regarding the header file re-organization patch that was submitted by Julius https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/1207/.
It is necessary for the headers which form the ABI/handover interface for BL31 to be able to copied separately and included in other projects. The current approach taken in the patch is to define a "raw" version of such headers and have the original header include them. This certainly is the easiest way to solve the problem. But if it possible to have a more refined solution, that would be preferable. For that I have the following questions :
1. Should the project recognize these special headers and have them organized together in a folder ? It is important to recognize that the ABI can be extended by the platform. I would expect even if these "common" headers are organized into a folder, the platform specific ones need not go together with them.
2. Should the header be restricted from including standard C library headers ?
3. Should these ABI headers be allowed to include each other ? Forward declaration might be able to solve some of the issues, but good to have a policy on this.
The current patch as such can be treated as step towards the ideal solution, if that solution needs more work/churn in the code base.
Comments welcome.
Best Regards
Soby Mathew
Hi Soby Mathew,
Thanks for your reply.
IMHO, the isolate pagetable is much more heavy. It looks like a big idea.
And if we have a dynamic mapping function, which map the service's
needed memory in the service's call can also mitigate this. But this can
be more slower.
For accessing limited resource, what's your idea?
-Feng
On 2019/7/9 4:27 下午, Soby Mathew wrote:
> Hi Feng,
> Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a(a)lists.trustedfirmware.org , so we can continue conversation on the list ?
>
> The mailing list info can be found here :
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
> Thanks & Regards
> Soby Mathew
>
>> -----Original Message-----
>> From: feng chen <puck.chen(a)foxmail.com>
>> Sent: 08 July 2019 16:24
>> To: Dan Handley <Dan.Handley(a)arm.com>; Soby Mathew
>> <Soby.Mathew(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>;
>> Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Paul Beesley
>> <Paul.Beesley(a)arm.com>; John Tsichritzis <John.Tsichritzis(a)arm.com>
>> Subject: [RFC] isolate the memory into different pagetable for TF-A
>>
>> Hello maintainers,
>>
>> Is it possible for mapping the memory into different page-tables for TF-A?
>>
>> Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs.
>>
>> And for security reason, once one service provided in TF has some
>> vulnerabilities, It can access all the memory TF mapped. And it could be more
>> acceptable.
>>
>> Thinking about the userland goto kernelland, the process use isolated page
>> tables.
>>
>> So I want to implement this for TF-A, different memory-mapping for different
>> service, and it can also use a shared mem-mapping space which all the service
>> need to use.
>>
>>
>> I want to know how do you think about this? Does this make sense to you?
>>
>>
>> Cherrs,
>>
>> Feng
>>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
Move this folk to list
> 在 2019年7月9日，下午4:27，Soby Mathew <Soby.Mathew(a)arm.com> 写道：
>
> Hi Feng,
> Thanks for your email. This is an interesting topic and this is an active area of work for us but in a slightly different manner. Could you please send this message to the mailing list tf-a(a)lists.trustedfirmware.org , so we can continue conversation on the list ?
>
> The mailing list info can be found here :
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
> Thanks & Regards
> Soby Mathew
>
>> -----Original Message-----
>> From: feng chen <puck.chen(a)foxmail.com>
>> Sent: 08 July 2019 16:24
>> To: Dan Handley <Dan.Handley(a)arm.com>; Soby Mathew
>> <Soby.Mathew(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>;
>> Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Paul Beesley
>> <Paul.Beesley(a)arm.com>; John Tsichritzis <John.Tsichritzis(a)arm.com>
>> Subject: [RFC] isolate the memory into different pagetable for TF-A
>>
>> Hello maintainers,
>>
>> Is it possible for mapping the memory into different page-tables for TF-A?
>>
>> Since the ATF is running in EL3 mode, which is the highest level of ARM SoCs.
>>
>> And for security reason, once one service provided in TF has some
>> vulnerabilities, It can access all the memory TF mapped. And it could be more
>> acceptable.
>>
>> Thinking about the userland goto kernelland, the process use isolated page
>> tables.
>>
>> So I want to implement this for TF-A, different memory-mapping for different
>> service, and it can also use a shared mem-mapping space which all the service
>> need to use.
>>
>>
>> I want to know how do you think about this? Does this make sense to you?
>>
>>
>> Cherrs,
>>
>> Feng
>>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
As you may be aware, Trusted Firmware-A source code regularly gets
analyzed by Coverity Scan Online [1]. This is a free service offered by
Synopsys for open source projects, that TF-A has used since 2015.
The analysis currently gets driven by Arm's internal CI system. We've
recently made some improvements to this setup, which led to the tool
analyzing more files. The latest analysis report from this morning shows
65 newly-found defects, scattered across the code base.
We would need help from the TF-A community for analyzing and fixing
them, especially those in platform ports and drivers. Note that there
might be false positives, in which case we would just triage them as
such in the tool's database.
Hopefully everyone should be able to view the defects, according to the
tool's settings. You might need to create an account on
https://scan.coverity.com for that.
Best regards,
Sandrine
[1] https://scan.coverity.com/projects/arm-software-arm-trusted-firmware
Hi,
Probably, I should have asked this
before pushing my code.
I have a question about
finalize_console_register.
Platforms call console_*_register() from C code.
I do not know why we need to fill the callbacks
in the assembler macro, finalize_console_register.
We could call console_register() directly from
C code, like this:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1426/3/plat/…
Maybe, we may want to register the console
so early in order to enable
plat/common/aarch64/crash_console_helpers.S
in the boot-up code?
