Hi David/ATF Support,
An excerpt from the commit message to CVE-2017-15031 is "Additionally,
PMCR_EL0 is added to the list of registers that are saved and restored
during a world switch."
My question is why it is only being saved/restored across the world
switch and not during a "normal" SMC call? When I do modify the
PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR
counter counts during the smc call and does expose secure world
timing information to NonSecure in that matter.
Thanks,
Marek
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?
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Gutierrez,
> Hernan Ildefonso (Boise R&D, FW) via TF-A
> Sent: 24 June 2019 22:35
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] Armv8A Suspend/Resume reference code
>
> Hi,
>
> I am looking for reference code for ArmV8A core suspend/resume.
> Are there code references that are suggested to look for?
> Application notes to read?
>
Hi Hernan,
The PSCI Spec[1] specifies power management on ARM CPUs and this includes suspend and resume. The TF-A provides an implementation of PSCI with appropriate hooks to plug-in in platform specifics. There are documents in the `docs` folder which cover different aspects of PSCI implementation like PSCI topology [2], CPU specifics [3], and platform porting guide [4].
In terms of adding support for a new platform, it is most likely that all the architectural (as in ARMv8A reference manual) and the CPU specific power management as specified in the TRM are covered already (see lib/cpus/ folder for CPUs already supported). So it’s a matter of implementing the platform hooks as mentioned in the porting guide [4].
With respect to implementing platform hooks, the ARM reference platforms like FVP provide an example of how the hooks can be implemented (see fvp_pm.c/fvp_topology.c ). So if you platform is a GICv3 system and the power controller already uses SCMI as the protocol for communication, then most of the code in FVP can be reused for your platform.
Hope that provides a starting point for you to begin.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coord…
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/desi…
[3] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/desi… (see CPU specific operations framework)
[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/gett… (see Power State Coordination Interface)
> Any pointers will be appreciated, thanks.
>
> Hernan
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I am looking for reference code for ArmV8A core suspend/resume.
Are there code references that are suggested to look for?
Application notes to read?
Any pointers will be appreciated, thanks.
Hernan
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Thor
> Thayer via TF-A
> Sent: 20 June 2019 09:05
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] Can 1 Core in EL3 elevate other 3 cores to EL3?
>
> Hi,
>
> I have a quad-core ARM64 Cortex-A53 where 1 core is executing in EL3 while
> the other 3 cores are in EL1. The 3 cores in EL1 are spinning in a WFI loop. The
> EL3 CPU transitioned to EL3 as a result of the PSCI RESET2 call from Linux.
>
> Is there a way for the EL3 core to switch the other cores into EL3 easily?
Hi Thor,
One way to do this to configure an IPI (SGI in GICv3 terminology) to be an EL3 interrupt (Group 0). Trigger this IPI from the first core to all the other 3 cores. This will cause the 3 cores to transition to EL3 to handle the EL3 interrupt and you will have to configure a suitable interrupt handler.
Implication of this new EL3 IPI is that it can also cause the core to transition to EL3 if triggered when executing in Secure world.
Also be aware that configuration of any EL3 interrupt will affect the routing model and change the behaviour of normal world interrupts when executing in Secure world. The secure world executing a "yielding" SMC request will get pre-empted on occurrence of normal world interrupt and the secure world may not get a chance to do a "controlled exit".
Usually the PSCI_RESET2 can work without all the cores being in EL3. Could you elaborate why the other cores need to be in EL3 for this reset?
>
> As far as I know, the communication between cores takes place through the IPI.
> Unfortunately, in my case, an SError has occurred that is masking the IPI.
>
If I understand correctly, the PSCI_RESET2 is being issued after the SError has happened on other cores. The EL3 IPI should cause these cores to transition to EL3 regardless of the interrupt mask state at lower Els.
> Thanks,
>
> Thor
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I have a quad-core ARM64 Cortex-A53 where 1 core is executing in EL3
while the other 3 cores are in EL1. The 3 cores in EL1 are spinning in a
WFI loop. The EL3 CPU transitioned to EL3 as a result of the PSCI RESET2
call from Linux.
Is there a way for the EL3 core to switch the other cores into EL3 easily?
As far as I know, the communication between cores takes place through
the IPI. Unfortunately, in my case, an SError has occurred that is
masking the IPI.
Thanks,
Thor
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of David
> Cerdeira via TF-A
> Sent: 04 June 2019 10:04
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] Arm trusted firmware reads wrong fip file from flash on
> hikey960v2
>
> Greetings,
> i’m having trouble getting arm trusted firmware to work on hikey960v2 I
> followed all the steps in this guide https://github.com/ARM-software/arm-
> trusted-firmware/blob/master/docs/plat/hikey960.rst,
> and the steps in https://optee.readthedocs.io/building/devices/hikey960.html
> The problem seems to be in reading the fip.bin, or rather the problem is
> writing the fip file as it seems it is not properly flashed.
> ATF bl2 fails to find the UUID of the BL2_SCP image in the fip.bin output by the
> build process, the fip file it reads from flash only has the BL31 and BL33 UUIDs.
>
> I tried checking older versions of ATF, as I figured it might be a problem in
> current versions, but the same problems occurred.
Hi David,
I don’t have much insight into platform specifics. One suggestion is to try with pre-built binaries and once they are working, replace with your custom ones. This page may help : http://releases.linaro.org/96boards/hikey/linaro/debian/15.11/
The Hikey Platform maintainers may be able to help more in this regard.
Best Regards
Soby Mathew
>
> At this moment I feel the problem is in the flashing step.
> I tried moving the partitions in the partition tables, as well as the value of the
> macro HIKEY960_FIP_BASE present in hikey960_def.h to match what I thought
> would be the writing position of the file in the partition, but without success.
>
> If anyone could give me any idea as to what the problem might be, that’d be
> great Best regards, David Cerdeira
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Jun,
Thank you for your patches.
We do not use this mailing list for patch submission/code review,
instead we use Gerrit. Could you please upload these patches on
review.trustedfirmware.org? The following wiki page might be helpful:
https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/
Many thanks,
Sandrine Bailleux
Hello Abel,
What is the status of this workaround? I saw that you had a similar discussion at the kernel mailing list (https://lkml.org/lkml/2019/3/27/542) which, however, has been inactive for some time.
Do you still intend to pursue that solution? If you do so, please submit your patches to review.trustedfirmware.org under the "TF-A/trusted-firmware-a" project. To login you just need your GitHub account. You can find further information about contributions in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proc…, especially the "Submitting Changes" section, or contact us here.
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 2019-03-27 15:35, Abel Vesa via TF-A wrote:
On 19-03-27 13:45:21, Soby Mathew wrote:
Hi Abel,
Thanks for the RFC. On the face of it, this is a new PSCI command that would need further discussion involving Architecture and Kernel teams.
I know this might be a pain. That's why I'm just asking for as many opinions on this as possible.
Just to summarize my understanding:
Currently any interrupt targeted to a suspended core can wake it up, but it seems that this mechanism is broken on i.MX8MQ and hence you need an explicit command to wake it. This assumes that one CPU is always ON within the system ready to poke the suspended CPU back to life. This assumption is not true always as it is legal for all the CPUs to be in suspend state at the same time.
That errata is specifically for IPIs. If all the cores are in suspend, any interrupt will be able to wake one of the cores. That's why the workaround suggested in that document works. But that workaround is waking up all the cores, that's why I added this poking mechanism which is per-core.
Adding the kernel team for their input.
JFYI, We do not intend to review patches via the mailing list and patches should be pushed as mentioned here:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
Currently the project is in github but we expect to migrate to trustedfirmware.org in April.
Hmm, ok. Good to know.
Best Regards
Soby Mathew
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org><mailto:tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Abel Vesa
via TF-A
Sent: 27 March 2019 12:16
To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Subject: [TF-A] [RFC 0/2] psci: Add core wakeup operation
This is more like a workaround for platforms like i.MX8MQ that have an issue
related to the wake_request GIC signal integration.
See E11171 here:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.c…
The workaround mentioned in the document has the dissadvantage of waking
up all the sleeping cores instead of just one.
This patchset adds another psci op for core 'poking' (waking up).
On i.MX8MQ, the plat specific implementation writes the corresponding bits in
GPC to wake up independently each core.
Abel Vesa (2):
psci: Add cpu wake operation
plat: imx8mq: Trigger SW power up per core
include/lib/psci/psci.h | 3 +++
lib/psci/psci_main.c | 17 +++++++++++++++++
lib/psci/psci_setup.c | 2 ++
plat/imx/imx8m/imx8mq/gpc.c | 7 +++++++
plat/imx/imx8m/imx8mq/imx8mq_psci.c | 8 ++++++++
plat/imx/imx8m/include/gpc.h | 2 ++
6 files changed, 39 insertions(+)
--
2.7.4
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
Greetings,
i’m having trouble getting arm trusted firmware to work on hikey960v2
I followed all the steps in this guide
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/…,
and the steps in https://optee.readthedocs.io/building/devices/hikey960.html
The problem seems to be in reading the fip.bin, or rather the problem is
writing the fip file as it seems it is not properly flashed.
ATF bl2 fails to find the UUID of the BL2_SCP image in the fip.bin output
by the build process, the fip file it reads from flash only has the BL31
and BL33 UUIDs.
I tried checking older versions of ATF, as I figured it might be a problem
in current versions, but the same problems occurred.
At this moment I feel the problem is in the flashing step.
I tried moving the partitions in the partition tables, as well as the value
of the macro HIKEY960_FIP_BASE present in hikey960_def.h to match what I
thought would be the writing position of the file in the partition, but
without success.
If anyone could give me any idea as to what the problem might be, that’d be
great
Best regards,
David Cerdeira
Hi Tien,
We recently found a regression on Poplar eMMC in U-Boot, which seems
caused by commit 3d0f30bb544a ("drivers: synopsys: Fix synopsys MMC
driver"). For some reason, the setup of FIFO threshold breaks eMMC
support in U-Boot [1]. Would you please suggest a sensible fix for this
regression? Thanks.
Shawn
[1] https://discuss.96boards.org/t/uboot-mmc-init-problem/8130/3
Hello everyone,
As you already know, Trusted Firmware-A has migrated to trustedfirmware.org. Our GitHub repository is still kept active as a read-only mirror of the project.
However, as of today, the integration branch has been deleted from GitHub.
As a reminder, you can find the TF-A repository here: https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a
as well as all the other projects hosted under trustedfirmware.org: https://review.trustedfirmware.org/admin/repos
We are looking forward to your contributions! Thank you!
Kind regards,
John
--
[cid:part3.A7D3BC4B.2D1B928D@arm.com] <https://www.arm.com/>
John Tsichritzis | Graduate Software Engineer
Email : john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com>
110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom
Hi,
I'd like to make you aware of a set of patches that are currently in review under the "pb/sphinx-doc" topic. These patches do some preparatory work on our documentation so that the reStructured Text (RST) documents can be rendered using a tool called Sphinx (http://www.sphinx-doc.org). This tool will allow us, going forward, to investigate additional output formats and publishing options for the documentation.
The aim of these specific patches is to:
1) Prepare the documentation for building with the Sphinx application
2) Improve the general formatting and naming of the documents
3) Organise the documents into a sensible structure
4) Maintain compatibility with existing renderers
You can find the first patch in the chain on our Gerrit review system, here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1041 . Follow the "Relation Chain" to see all of the related patches in the series.
Please note that documentation for upstream platforms is modified by these patches as part of the reformatting. These changes should all be minor but platform maintainers may wish to give them a quick review, especially this one: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1046 .
As always, any feedback on these changes is welcome and there will always be the opportunity to make further changes beyond the scope of these patches.
Best Regards,
Paul