Skip to content

GitLab

Commit 7cefb56d authored by danh-arm's avatar danh-arm Committed by GitHub
Browse files

Merge pull request #1011 from douglas-raillard-arm/dr/doc_convert_to_rst 

Convert Markdown to reStructuredText
parents aa5b843f 06fb4278
Expand all Hide whitespace changes
Inline Side-by-side
acknowledgements.md → acknowledgements.rst
View file @ 7cefb56d
......@@ -3,6 +3,7 @@ Contributor Acknowledgements
Companies
---------
Linaro Limited
NVIDIA Corporation
......
contributing.md deleted 100644 → 0
View file @ aa5b843f
Contributing to ARM Trusted Firmware
====================================
Getting Started
---------------
* Make sure you have a [GitHub account].
* Create an [issue] for your work if one does not already exist. This gives
everyone visibility of whether others are working on something similar. ARM
licensees may contact ARM directly via their partner managers instead if
they prefer.
* Note that the [issue] tracker for this project is in a separate
[issue tracking repository]. Please follow the guidelines in that
repository.
* If you intend to include Third Party IP in your contribution, please
raise a separate [issue] for this and ensure that the changes that
include Third Party IP are made on a separate topic branch.
* [Fork][] [arm-trusted-firmware][] on GitHub.
* Clone the fork to your own machine.
* Create a local topic branch based on the [arm-trusted-firmware][] `master`
branch.
Making Changes
--------------
* Make commits of logical units. See these general [Git guidelines] for
contributing to a project.
* Follow the [Linux coding style]; this style is enforced for the ARM Trusted
Firmware project (style errors only, not warnings).
* Use the checkpatch.pl script provided with the Linux source tree. A
Makefile target is provided for convenience (see section 2 in the
[User Guide]).
* Keep the commits on topic. If you need to fix another bug or make another
enhancement, please create a separate [issue] and address it on a separate
topic branch.
* Avoid long commit series. If you do have a long series, consider whether
some commits should be squashed together or addressed in a separate topic.
* Make sure your commit messages are in the proper format. If a commit fixes
a GitHub [issue], include a reference (e.g.
"fixes arm-software/tf-issues#45"); this ensures the [issue] is
[automatically closed] when merged into the [arm-trusted-firmware] `master`
branch.
* Where appropriate, please update the documentation.
* Consider whether the [User Guide], [Porting Guide], [Firmware Design] or
other in-source documentation needs updating.
* Ensure that each changed file has the correct copyright and license
information. Files that entirely consist of contributions to this
project should have the copyright notice and BSD-3-Clause SPDX license
identifier as shown in [license.md](./license.md). Files that contain
changes to imported Third Party IP should contain a notice as follows,
with the original copyright and license text retained:
```
Portions copyright (c) [XXXX-]YYYY, ARM Limited and Contributors. All rights reserved.
```
where XXXX is the year of first contribution (if different to YYYY) and
YYYY is the year of most recent contribution.
* If not done previously, you may add your name or your company name to
the [Acknowledgements] file.
* If you are submitting new files that you intend to be the technical
sub-maintainer for (for example, a new platform port), then also update
the [Maintainers] file.
* For topics with multiple commits, you should make all documentation
changes (and nothing else) in the last commit of the series. Otherwise,
include the documentation changes within the single commit.
* Please test your changes. As a minimum, ensure UEFI boots to the shell on
the Foundation FVP. See the "[Running the software]" section of the
[User Guide] for more information.
Submitting Changes
------------------
* Ensure that each commit in the series has at least one `Signed-off-by:`
line, using your real name and email address. The names in the
`Signed-off-by:` and `Author:` lines must match. If anyone else contributes
to the commit, they must also add their own `Signed-off-by:` line.
By adding this line the contributor certifies the contribution is made under
the terms of the [Developer Certificate of Origin (DCO)][DCO].
* Push your local changes to your fork of the repository.
* Submit a [pull request] to the [arm-trusted-firmware] `integration` branch.
* The changes in the [pull request] will then undergo further review and
testing by the [Maintainers]. Any review comments will be made as
comments on the [pull request]. This may require you to do some rework.
* When the changes are accepted, the [Maintainers] will integrate them.
* Typically, the [Maintainers] will merge the [pull request] into the
`integration` branch within the GitHub UI, creating a merge commit.
* Please avoid creating merge commits in the [pull request] itself.
* If the [pull request] is not based on a recent commit, the [Maintainers]
may rebase it onto the `master` branch first, or ask you to do this.
* If the [pull request] cannot be automatically merged, the [Maintainers]
will ask you to rebase it onto the `master` branch.
* After final integration testing, the [Maintainers] will push your merge
commit to the `master` branch. If a problem is found during integration,
the merge commit will be removed from the `integration` branch and the
[Maintainers] will ask you to create a new pull request to resolve the
problem.
* Please do not delete your topic branch until it is safely merged into
the `master` branch.
- - - - - - - - - - - - - - - - - - - - - - - - - -
_Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved._
[User Guide]: ./docs/user-guide.md
[Running the software]: ./docs/user-guide.md#6--running-the-software
[Porting Guide]: ./docs/porting-guide.md
[Firmware Design]: ./docs/firmware-design.md
[Acknowledgements]: ./acknowledgements.md "Contributor acknowledgements"
[DCO]: ./dco.txt
[Maintainers]: ./maintainers.md
[GitHub account]: https://github.com/signup/free
[Fork]: https://help.github.com/articles/fork-a-repo
[issue tracking repository]: https://github.com/ARM-software/tf-issues
[issue]: https://github.com/ARM-software/tf-issues/issues
[pull request]: https://help.github.com/articles/using-pull-requests
[automatically closed]: https://help.github.com/articles/closing-issues-via-commit-messages
[Git guidelines]: http://git-scm.com/book/ch5-2.html
[Linux coding style]: https://www.kernel.org/doc/Documentation/CodingStyle
[arm-trusted-firmware]: https://github.com/ARM-software/arm-trusted-firmware
contributing.rst 0 → 100644
View file @ 7cefb56d
Contributing to ARM Trusted Firmware
====================================
Getting Started
---------------
- Make sure you have a `GitHub account`_.
- Create an `issue`_ for your work if one does not already exist. This gives
everyone visibility of whether others are working on something similar. ARM
licensees may contact ARM directly via their partner managers instead if
they prefer.
- Note that the `issue`_ tracker for this project is in a separate
`issue tracking repository`_. Please follow the guidelines in that
repository.
- If you intend to include Third Party IP in your contribution, please
raise a separate `issue`_ for this and ensure that the changes that
include Third Party IP are made on a separate topic branch.
- `Fork`_ `arm-trusted-firmware`_ on GitHub.
- Clone the fork to your own machine.
- Create a local topic branch based on the `arm-trusted-firmware`_ ``master``
branch.
Making Changes
--------------
- Make commits of logical units. See these general `Git guidelines`_ for
contributing to a project.
- Follow the `Linux coding style`_; this style is enforced for the ARM Trusted
Firmware project (style errors only, not warnings).
- Use the checkpatch.pl script provided with the Linux source tree. A
Makefile target is provided for convenience (see section 2 in the
`User Guide`_).
- Keep the commits on topic. If you need to fix another bug or make another
enhancement, please create a separate `issue`_ and address it on a separate
topic branch.
- Avoid long commit series. If you do have a long series, consider whether
some commits should be squashed together or addressed in a separate topic.
- Make sure your commit messages are in the proper format. If a commit fixes
a GitHub `issue`_, include a reference (e.g.
"fixes arm-software/tf-issues#45"); this ensures the `issue`_ is
`automatically closed`_ when merged into the `arm-trusted-firmware`_ ``master``
branch.
- Where appropriate, please update the documentation.
- Consider whether the `User Guide`_, `Porting Guide`_, `Firmware Design`_ or
other in-source documentation needs updating.
- Ensure that each changed file has the correct copyright and license
information. Files that entirely consist of contributions to this
project should have the copyright notice and BSD-3-Clause SPDX license
identifier as shown in `license.rst`_. Files that contain
changes to imported Third Party IP should contain a notice as follows,
with the original copyright and license text retained:
::
Portions copyright (c) [XXXX-]YYYY, ARM Limited and Contributors. All rights reserved.
where XXXX is the year of first contribution (if different to YYYY) and
YYYY is the year of most recent contribution.
- If not done previously, you may add your name or your company name to
the `Acknowledgements`_ file.
- If you are submitting new files that you intend to be the technical
sub-maintainer for (for example, a new platform port), then also update
the `Maintainers`_ file.
- For topics with multiple commits, you should make all documentation
changes (and nothing else) in the last commit of the series. Otherwise,
include the documentation changes within the single commit.
- Please test your changes. As a minimum, ensure UEFI boots to the shell on
the Foundation FVP. See `Running the software on FVP`_ for more information.
Submitting Changes
------------------
- Ensure that each commit in the series has at least one ``Signed-off-by:``
line, using your real name and email address. The names in the
``Signed-off-by:`` and ``Author:`` lines must match. If anyone else contributes
to the commit, they must also add their own ``Signed-off-by:`` line.
By adding this line the contributor certifies the contribution is made under
the terms of the `Developer Certificate of Origin (DCO)`_.
- Push your local changes to your fork of the repository.
- Submit a `pull request`_ to the `arm-trusted-firmware`_ ``integration`` branch.
- The changes in the `pull request`_ will then undergo further review and
testing by the `Maintainers`_. Any review comments will be made as
comments on the `pull request`_. This may require you to do some rework.
- When the changes are accepted, the `Maintainers`_ will integrate them.
- Typically, the `Maintainers`_ will merge the `pull request`_ into the
``integration`` branch within the GitHub UI, creating a merge commit.
- Please avoid creating merge commits in the `pull request`_ itself.
- If the `pull request`_ is not based on a recent commit, the `Maintainers`_
may rebase it onto the ``master`` branch first, or ask you to do this.
- If the `pull request`_ cannot be automatically merged, the `Maintainers`_
will ask you to rebase it onto the ``master`` branch.
- After final integration testing, the `Maintainers`_ will push your merge
commit to the ``master`` branch. If a problem is found during integration,
the merge commit will be removed from the ``integration`` branch and the
`Maintainers`_ will ask you to create a new pull request to resolve the
problem.
- Please do not delete your topic branch until it is safely merged into
the ``master`` branch.
--------------
*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.*
.. _GitHub account: https://github.com/signup/free
.. _issue: https://github.com/ARM-software/tf-issues/issues
.. _issue tracking repository: https://github.com/ARM-software/tf-issues
.. _Fork: https://help.github.com/articles/fork-a-repo
.. _arm-trusted-firmware: https://github.com/ARM-software/arm-trusted-firmware
.. _Git guidelines: http://git-scm.com/book/ch5-2.html
.. _Linux coding style: https://www.kernel.org/doc/Documentation/CodingStyle
.. _User Guide: ./docs/user-guide.rst
.. _automatically closed: https://help.github.com/articles/closing-issues-via-commit-messages
.. _Porting Guide: ./docs/porting-guide.rst
.. _Firmware Design: ./docs/firmware-design.rst
.. _license.rst: ./license.rst
.. _Acknowledgements: ./acknowledgements.rst
.. _Maintainers: ./maintainers.rst
.. _Running the software on FVP: ./docs/user-guide.rst#user-content-running-the-software-on-fvp
.. _Developer Certificate of Origin (DCO): ./dco.txt
.. _pull request: https://help.github.com/articles/using-pull-requests
docs/arm-sip-service.md → docs/arm-sip-service.rst
View file @ 7cefb56d
ARM SiP Service
===============
This document enumerates and describes the ARM SiP (Silicon Provider) services.
SiP services are non-standard, platform-specific services offered by the silicon
implementer or platform provider. They are accessed via. `SMC` ("SMC calls")
implementer or platform provider. They are accessed via. ``SMC`` ("SMC calls")
instruction executed from Exception Levels below EL3. SMC calls for SiP
services:
* Follow [SMC Calling Convention][SMCCC];
* Use SMC function IDs that fall in the SiP range, which are `0xc2000000` -
`0xc200ffff` for 64-bit calls, and `0x82000000` - `0x8200ffff` for 32-bit
calls.
- Follow `SMC Calling Convention`_;
- Use SMC function IDs that fall in the SiP range, which are ``0xc2000000`` -
``0xc200ffff`` for 64-bit calls, and ``0x82000000`` - ``0x8200ffff`` for 32-bit
calls.
The ARM SiP implementation offers the following services:
* Performance Measurement Framework (PMF)
* Execution State Switching service
- Performance Measurement Framework (PMF)
- Execution State Switching service
Source definitions for ARM SiP service are located in the `arm_sip_svc.h` header
Source definitions for ARM SiP service are located in the ``arm_sip_svc.h`` header
file.
Performance Measurement Framework (PMF)
---------------------------------------
The [Performance Measurement Framework](./firmware-design.md#13--performance-measurement-framework)
The `Performance Measurement Framework`_
allows callers to retrieve timestamps captured at various paths in ARM Trusted
Firmware execution. It's described in detail in [Firmware Design document][Firmware Design].
Firmware execution. It's described in detail in `Firmware Design document`_.
Execution State Switching service
---------------------------------
......@@ -37,9 +36,12 @@ Exception Level (either EL2, or NS EL1 if EL2 isn't implemented) to request to
switch its execution state (a.k.a. Register Width), either from AArch64 to
AArch32, or from AArch32 to AArch64, for the calling CPU. This service is only
available when ARM Trusted Firmware is built for AArch64 (i.e. when build option
`ARCH` is set to `aarch64`).
``ARCH`` is set to ``aarch64``).
``ARM_SIP_SVC_EXE_STATE_SWITCH``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
### `ARM_SIP_SVC_EXE_STATE_SWITCH`
::
Arguments:
uint32_t Function ID
......@@ -51,19 +53,19 @@ available when ARM Trusted Firmware is built for AArch64 (i.e. when build option
Return:
uint32_t
The function ID parameter must be `0x82000020`. It uniquely identifies the
The function ID parameter must be ``0x82000020``. It uniquely identifies the
Execution State Switching service being requested.
The parameters _PC hi_ and _PC lo_ defines upper and lower words, respectively,
The parameters *PC hi* and *PC lo* defines upper and lower words, respectively,
of the entry point (physical address) at which execution should start, after
Execution State has been switched. When calling from AArch64, _PC hi_ must be 0.
Execution State has been switched. When calling from AArch64, *PC hi* must be 0.
When execution starts at the supplied entry point after Execution State has been
switched, the parameters _Cookie hi_ and _Cookie lo_ are passed in CPU registers
0 and 1, respectively. When calling from AArch64, _Cookie hi_ must be 0.
switched, the parameters *Cookie hi* and *Cookie lo* are passed in CPU registers
0 and 1, respectively. When calling from AArch64, *Cookie hi* must be 0.
This call can only be made on the primary CPU, before any secondaries were
brought up with `CPU_ON` PSCI call. Otherwise, the call will always fail.
brought up with ``CPU_ON`` PSCI call. Otherwise, the call will always fail.
The effect of switching execution state is as if the Exception Level were
entered for the first time, following power on. This means CPU registers that
......@@ -71,21 +73,24 @@ have a defined reset value by the Architecture will assume that value. Other
registers should not be expected to hold their values before the call was made.
CPU endianness, however, is preserved from the previous execution state. Note
that this switches the execution state of the calling CPU only. This is not a
substitute for PSCI `SYSTEM_RESET`.
substitute for PSCI ``SYSTEM_RESET``.
The service may return the following error codes:
- `STATE_SW_E_PARAM`: If any of the parameters were deemed invalid for
a specific request.
- `STATE_SW_E_DENIED`: If the call is not successful, or when ARM Trusted
Firmware is built for AArch32.
- ``STATE_SW_E_PARAM``: If any of the parameters were deemed invalid for
a specific request.
- ``STATE_SW_E_DENIED``: If the call is not successful, or when ARM Trusted
Firmware is built for AArch32.
If the call is successful, the caller wouldn't observe the SMC returning.
Instead, execution starts at the supplied entry point, with the CPU registers 0
and 1 populated with the supplied _Cookie hi_ and _Cookie lo_ values,
and 1 populated with the supplied *Cookie hi* and *Cookie lo* values,
respectively.
- - - - - - - - - - - - - - - - - - - - - - - - - -
--------------
*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.*
[Firmware Design]: ./firmware-design.md
[SMCCC]: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html "SMC Calling Convention PDD (ARM DEN 0028A)"
.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
.. _Performance Measurement Framework: ./firmware-design.rst#user-content-performance-measurement-framework
.. _Firmware Design document: ./firmware-design.rst
docs/change-log.md deleted 100644 → 0
View file @ aa5b843f
This diff is collapsed.
docs/change-log.rst 0 → 100644
View file @ 7cefb56d
This diff is collapsed.
docs/cpu-specific-build-macros.md deleted 100644 → 0
View file @ aa5b843f
ARM CPU Specific Build Macros
=============================
Contents
--------
1. [Introduction](#1--introduction)
2. [CPU Errata Workarounds](#2--cpu-errata-workarounds)
3. [CPU Specific optimizations](#3--cpu-specific-optimizations)
1. Introduction
----------------
This document describes the various build options present in the CPU specific
operations framework to enable errata workarounds and to enable optimizations
for a specific CPU on a platform.
2. CPU Errata Workarounds
--------------------------
ARM Trusted Firmware exports a series of build flags which control the
errata workarounds that are applied to each CPU by the reset handler. The
errata details can be found in the CPU specific errata documents published
by ARM:
* [Cortex-A53 MPCore Software Developers Errata Notice][A53 Errata Notice]
* [Cortex-A57 MPCore Software Developers Errata Notice][A57 Errata Notice]
The errata workarounds are implemented for a particular revision or a set of
processor revisions. This is checked by the reset handler at runtime. Each
errata workaround is identified by its `ID` as specified in the processor's
errata notice document. The format of the define used to enable/disable the
errata workaround is `ERRATA_<Processor name>_<ID>`, where the `Processor name`
is for example `A57` for the `Cortex_A57` CPU.
Refer to the section _CPU errata status reporting_ in [Firmware Design
guide][Firmware Design] for information on to write errata workaround functions.
All workarounds are disabled by default. The platform is responsible for
enabling these workarounds according to its requirement by defining the
errata workaround build flags in the platform specific makefile. In case
these workarounds are enabled for the wrong CPU revision then the errata
workaround is not applied. In the DEBUG build, this is indicated by
printing a warning to the crash console.
In the current implementation, a platform which has more than 1 variant
with different revisions of a processor has no runtime mechanism available
for it to specify which errata workarounds should be enabled or not.
The value of the build flags are 0 by default, that is, disabled. Any other
value will enable it.
For Cortex-A53, following errata build flags are defined :
* `ERRATA_A53_826319`: This applies errata 826319 workaround to Cortex-A53
CPU. This needs to be enabled only for revision <= r0p2 of the CPU.
* `ERRATA_A53_836870`: This applies errata 836870 workaround to Cortex-A53
CPU. This needs to be enabled only for revision <= r0p3 of the CPU. From
r0p4 and onwards, this errata is enabled by default in hardware.
* `ERRATA_A53_855873`: This applies errata 855873 workaround to Cortex-A53
CPUs. Though the erratum is present in every revision of the CPU,
this workaround is only applied to CPUs from r0p3 onwards, which feature
a chicken bit in CPUACTLR_EL1 to enable a hardware workaround.
Earlier revisions of the CPU have other errata which require the same
workaround in software, so they should be covered anyway.
For Cortex-A57, following errata build flags are defined :
* `ERRATA_A57_806969`: This applies errata 806969 workaround to Cortex-A57
CPU. This needs to be enabled only for revision r0p0 of the CPU.
* `ERRATA_A57_813419`: This applies errata 813419 workaround to Cortex-A57
CPU. This needs to be enabled only for revision r0p0 of the CPU.
* `ERRATA_A57_813420`: This applies errata 813420 workaround to Cortex-A57
CPU. This needs to be enabled only for revision r0p0 of the CPU.
* `ERRATA_A57_826974`: This applies errata 826974 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
* `ERRATA_A57_826977`: This applies errata 826977 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
* `ERRATA_A57_828024`: This applies errata 828024 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
* `ERRATA_A57_829520`: This applies errata 829520 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p2 of the CPU.
* `ERRATA_A57_833471`: This applies errata 833471 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p2 of the CPU.
3. CPU Specific optimizations
------------------------------
This section describes some of the optimizations allowed by the CPU micro
architecture that can be enabled by the platform as desired.
* `SKIP_A57_L1_FLUSH_PWR_DWN`: This flag enables an optimization in the
Cortex-A57 cluster power down sequence by not flushing the Level 1 data
cache. The L1 data cache and the L2 unified cache are inclusive. A flush
of the L2 by set/way flushes any dirty lines from the L1 as well. This
is a known safe deviation from the Cortex-A57 TRM defined power down
sequence. Each Cortex-A57 based platform must make its own decision on
whether to use the optimization.
* `A53_DISABLE_NON_TEMPORAL_HINT`: This flag disables the cache non-temporal
hint. The LDNP/STNP instructions as implemented on Cortex-A53 do not behave
in a way most programmers expect, and will most probably result in a
significant speed degradation to any code that employs them. The ARMv8-A
architecture (see ARM DDI 0487A.h, section D3.4.3) allows cores to ignore
the non-temporal hint and treat LDNP/STNP as LDP/STP instead. Enabling this
flag enforces this behaviour. This needs to be enabled only for revisions
<= r0p3 of the CPU and is enabled by default.
* `A57_DISABLE_NON_TEMPORAL_HINT`: This flag has the same behaviour as
`A53_DISABLE_NON_TEMPORAL_HINT` but for Cortex-A57. This needs to be
enabled only for revisions <= r1p2 of the CPU and is enabled by default,
as recommended in section "4.7 Non-Temporal Loads/Stores" of the
[Cortex-A57 Software Optimization Guide][A57 SW Optimization Guide].
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_Copyright (c) 2014-2016, ARM Limited and Contributors. All rights reserved._
[A57 SW Optimization Guide]: http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Cortex_A57_Software_Optimization_Guide_external.pdf
[A53 Errata Notice]: http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/index.html
[A57 Errata Notice]: http://infocenter.arm.com/help/topic/com.arm.doc.epm049219/cortex_a57_mpcore_software_developers_errata_notice.pdf
[Firmware Design]: firmware-design.md
docs/cpu-specific-build-macros.rst 0 → 100644
View file @ 7cefb56d
ARM CPU Specific Build Macros
=============================
.. section-numbering::
:suffix: .
.. contents::
This document describes the various build options present in the CPU specific
operations framework to enable errata workarounds and to enable optimizations
for a specific CPU on a platform.
CPU Errata Workarounds
----------------------
ARM Trusted Firmware exports a series of build flags which control the
errata workarounds that are applied to each CPU by the reset handler. The
errata details can be found in the CPU specific errata documents published
by ARM:
- `Cortex-A53 MPCore Software Developers Errata Notice`_
- `Cortex-A57 MPCore Software Developers Errata Notice`_
The errata workarounds are implemented for a particular revision or a set of
processor revisions. This is checked by the reset handler at runtime. Each
errata workaround is identified by its ``ID`` as specified in the processor's
errata notice document. The format of the define used to enable/disable the
errata workaround is ``ERRATA_<Processor name>_<ID>``, where the ``Processor name``
is for example ``A57`` for the ``Cortex_A57`` CPU.
Refer to the section *CPU errata status reporting* in
`Firmware Design guide`_ for information on to write errata workaround functions.
All workarounds are disabled by default. The platform is responsible for
enabling these workarounds according to its requirement by defining the
errata workaround build flags in the platform specific makefile. In case
these workarounds are enabled for the wrong CPU revision then the errata
workaround is not applied. In the DEBUG build, this is indicated by
printing a warning to the crash console.
In the current implementation, a platform which has more than 1 variant
with different revisions of a processor has no runtime mechanism available
for it to specify which errata workarounds should be enabled or not.
The value of the build flags are 0 by default, that is, disabled. Any other
value will enable it.
For Cortex-A53, following errata build flags are defined :
- ``ERRATA_A53_826319``: This applies errata 826319 workaround to Cortex-A53
CPU. This needs to be enabled only for revision <= r0p2 of the CPU.
- ``ERRATA_A53_836870``: This applies errata 836870 workaround to Cortex-A53
CPU. This needs to be enabled only for revision <= r0p3 of the CPU. From
r0p4 and onwards, this errata is enabled by default in hardware.
- ``ERRATA_A53_855873``: This applies errata 855873 workaround to Cortex-A53
CPUs. Though the erratum is present in every revision of the CPU,
this workaround is only applied to CPUs from r0p3 onwards, which feature
a chicken bit in CPUACTLR\_EL1 to enable a hardware workaround.
Earlier revisions of the CPU have other errata which require the same
workaround in software, so they should be covered anyway.
For Cortex-A57, following errata build flags are defined :
- ``ERRATA_A57_806969``: This applies errata 806969 workaround to Cortex-A57
CPU. This needs to be enabled only for revision r0p0 of the CPU.
- ``ERRATA_A57_813419``: This applies errata 813419 workaround to Cortex-A57
CPU. This needs to be enabled only for revision r0p0 of the CPU.
- ``ERRATA_A57_813420``: This applies errata 813420 workaround to Cortex-A57
CPU. This needs to be enabled only for revision r0p0 of the CPU.
- ``ERRATA_A57_826974``: This applies errata 826974 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
- ``ERRATA_A57_826977``: This applies errata 826977 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
- ``ERRATA_A57_828024``: This applies errata 828024 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
- ``ERRATA_A57_829520``: This applies errata 829520 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p2 of the CPU.
- ``ERRATA_A57_833471``: This applies errata 833471 workaround to Cortex-A57
CPU. This needs to be enabled only for revision <= r1p2 of the CPU.
CPU Specific optimizations
--------------------------
This section describes some of the optimizations allowed by the CPU micro
architecture that can be enabled by the platform as desired.
- ``SKIP_A57_L1_FLUSH_PWR_DWN``: This flag enables an optimization in the
Cortex-A57 cluster power down sequence by not flushing the Level 1 data
cache. The L1 data cache and the L2 unified cache are inclusive. A flush
of the L2 by set/way flushes any dirty lines from the L1 as well. This
is a known safe deviation from the Cortex-A57 TRM defined power down
sequence. Each Cortex-A57 based platform must make its own decision on
whether to use the optimization.
- ``A53_DISABLE_NON_TEMPORAL_HINT``: This flag disables the cache non-temporal
hint. The LDNP/STNP instructions as implemented on Cortex-A53 do not behave
in a way most programmers expect, and will most probably result in a
significant speed degradation to any code that employs them. The ARMv8-A
architecture (see ARM DDI 0487A.h, section D3.4.3) allows cores to ignore
the non-temporal hint and treat LDNP/STNP as LDP/STP instead. Enabling this
flag enforces this behaviour. This needs to be enabled only for revisions
<= r0p3 of the CPU and is enabled by default.
- ``A57_DISABLE_NON_TEMPORAL_HINT``: This flag has the same behaviour as
``A53_DISABLE_NON_TEMPORAL_HINT`` but for Cortex-A57. This needs to be
enabled only for revisions <= r1p2 of the CPU and is enabled by default,
as recommended in section "4.7 Non-Temporal Loads/Stores" of the
`Cortex-A57 Software Optimization Guide`_.
--------------
*Copyright (c) 2014-2016, ARM Limited and Contributors. All rights reserved.*
.. _Cortex-A53 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/index.html
.. _Cortex-A57 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm049219/cortex_a57_mpcore_software_developers_errata_notice.pdf
.. _Firmware Design guide: firmware-design.rst
.. _Cortex-A57 Software Optimization Guide: http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/Cortex_A57_Software_Optimization_Guide_external.pdf
docs/firmware-update.md → docs/firmware-update.rst
View file @ 7cefb56d
ARM Trusted Firmware - Firmware Update Design Guide
===================================================
Contents :
1. [Introduction](#1--introduction)
2. [FWU Overview](#2--fwu-overview)
3. [Image Identification](#3--image-identification)
4. [FWU State Machine](#4--fwu-state-machine)
5. [BL1 SMC Interface](#5--bl1-smc-interface)
.. section-numbering::
:suffix: .
- - - - - - - - - - - - - - - - - -
.. contents::
1. Introduction
----------------
--------------
Introduction
------------
This document describes the design of the Firmware Update (FWU) feature, which
enables authenticated firmware to update firmware images from external
......@@ -24,19 +22,19 @@ be complemented by other, higher level firmware update software.
FWU implements a specific part of the Trusted Board Boot Requirements (TBBR)
specification, ARM DEN0006C-1. It should be used in conjunction with the
[Trusted Board Boot] design document, which describes the image authentication
`Trusted Board Boot`_ design document, which describes the image authentication
parts of the Trusted Firmware (TF) TBBR implementation.
### Scope
Scope
~~~~~
This document describes the secure world FWU design. It is beyond its scope to
describe how normal world FWU images should operate. To implement normal world
FWU images, please refer to the "Non-Trusted Firmware Updater" requirements in
the TBBR.
2. FWU Overview
----------------
FWU Overview
------------
The FWU boot flow is primarily mediated by BL1. Since BL1 executes in ROM, and
it is usually desirable to minimize the amount of ROM code, the design allows
......@@ -44,65 +42,65 @@ some parts of FWU to be implemented in other secure and normal world images.
Platform code may choose which parts are implemented in which images but the
general expectation is:
* BL1 handles:
* Detection and initiation of the FWU boot flow.
* Copying images from non-secure to secure memory
* FWU image authentication
* Context switching between the normal and secure world during the FWU
process.
* Other secure world FWU images handle platform initialization required by
the FWU process.
* Normal world FWU images handle loading of firmware images from external
interfaces to non-secure memory.
- BL1 handles:
- Detection and initiation of the FWU boot flow.
- Copying images from non-secure to secure memory
- FWU image authentication
- Context switching between the normal and secure world during the FWU
process.
- Other secure world FWU images handle platform initialization required by
the FWU process.
- Normal world FWU images handle loading of firmware images from external
interfaces to non-secure memory.
The primary requirements of the FWU feature are:
1. Export a BL1 SMC interface to interoperate with other FWU images executing
at other Exception Levels.
2. Export a platform interface to provide FWU common code with the information
it needs, and to enable platform specific FWU functionality. See the
[Porting Guide] for details of this interface.
#. Export a BL1 SMC interface to interoperate with other FWU images executing
at other Exception Levels.
#. Export a platform interface to provide FWU common code with the information
it needs, and to enable platform specific FWU functionality. See the
`Porting Guide`_ for details of this interface.
TF uses abbreviated image terminology for FWU images like for other TF images.
An overview of this terminology can be found [here][TF Image Terminology].
An overview of this terminology can be found `here`_.
The following diagram shows the FWU boot flow for ARM development platforms.
ARM CSS platforms like Juno have a System Control Processor (SCP), and these
use all defined FWU images. Other platforms may use a subset of these.
![Flow Diagram](diagrams/fwu_flow.png?raw=true)
|Flow Diagram|
3. Image Identification
------------------------
Image Identification
--------------------
Each FWU image and certificate is identified by a unique ID, defined by the
platform, which BL1 uses to fetch an image descriptor (`image_desc_t`) via a
call to `bl1_plat_get_image_desc()`. The same ID is also used to prepare the
Chain of Trust (Refer to the [Authentication Framework Design][Auth Framework]
platform, which BL1 uses to fetch an image descriptor (``image_desc_t``) via a
call to ``bl1_plat_get_image_desc()``. The same ID is also used to prepare the
Chain of Trust (Refer to the `Authentication Framework Design`_
for more information).
The image descriptor includes the following information:
* Executable or non-executable image. This indicates whether the normal world
is permitted to request execution of a secure world FWU image (after
authentication). Secure world certificates and non-AP images are examples
of non-executable images.
* Secure or non-secure image. This indicates whether the image is
authenticated/executed in secure or non-secure memory.
* Image base address and size.
* Image entry point configuration (an `entry_point_info_t`).
* FWU image state.
- Executable or non-executable image. This indicates whether the normal world
is permitted to request execution of a secure world FWU image (after
authentication). Secure world certificates and non-AP images are examples
of non-executable images.
- Secure or non-secure image. This indicates whether the image is
authenticated/executed in secure or non-secure memory.
- Image base address and size.
- Image entry point configuration (an ``entry_point_info_t``).
- FWU image state.
BL1 uses the FWU image descriptors to:
* Validate the arguments of FWU SMCs
* Manage the state of the FWU process
* Initialize the execution state of the next FWU image.
- Validate the arguments of FWU SMCs
- Manage the state of the FWU process
- Initialize the execution state of the next FWU image.
4. FWU State Machine
---------------------
FWU State Machine
-----------------
BL1 maintains state for each FWU image during FWU execution. FWU images at lower
Exception Levels raise SMCs to invoke FWU functionality in BL1, which causes
......@@ -110,35 +108,37 @@ BL1 to update its FWU image state. The BL1 image states and valid state
transitions are shown in the diagram below. Note that secure images have a more
complex state machine than non-secure images.
![FWU state machine](diagrams/fwu_states.png?raw=true)
|FWU state machine|
The following is a brief description of the supported states:
* RESET: This is the initial state of every image at the start of FWU.
Authentication failure also leads to this state. A secure
image may yield to this state if it has completed execution.
It can also be reached by using `FWU_SMC_IMAGE_RESET`.
- RESET: This is the initial state of every image at the start of FWU.
Authentication failure also leads to this state. A secure
image may yield to this state if it has completed execution.
It can also be reached by using ``FWU_SMC_IMAGE_RESET``.
* COPYING: This is the state of a secure image while BL1 is copying it
in blocks from non-secure to secure memory.
- COPYING: This is the state of a secure image while BL1 is copying it
in blocks from non-secure to secure memory.
* COPIED: This is the state of a secure image when BL1 has completed
copying it to secure memory.
- COPIED: This is the state of a secure image when BL1 has completed
copying it to secure memory.
* AUTHENTICATED: This is the state of an image when BL1 has successfully
authenticated it.
- AUTHENTICATED: This is the state of an image when BL1 has successfully
authenticated it.
* EXECUTED: This is the state of a secure, executable image when BL1 has
passed execution control to it.
- EXECUTED: This is the state of a secure, executable image when BL1 has
passed execution control to it.
* INTERRUPTED: This is the state of a secure, executable image after it has
requested BL1 to resume normal world execution.
- INTERRUPTED: This is the state of a secure, executable image after it has
requested BL1 to resume normal world execution.
BL1 SMC Interface
-----------------
5. BL1 SMC Interface
---------------------
BL1\_SMC\_CALL\_COUNT
~~~~~~~~~~~~~~~~~~~~~
### BL1_SMC_CALL_COUNT
::
Arguments:
uint32_t function ID : 0x0
......@@ -148,7 +148,10 @@ The following is a brief description of the supported states:
This SMC returns the number of SMCs supported by BL1.
### BL1_SMC_UID
BL1\_SMC\_UID
~~~~~~~~~~~~~
::
Arguments:
uint32_t function ID : 0x1
......@@ -156,10 +159,13 @@ This SMC returns the number of SMCs supported by BL1.
Return:
UUID : 32 bits in each of w0-w3 (or r0-r3 for AArch32 callers)
This SMC returns the 128-bit [Universally Unique Identifier][UUID] for the
This SMC returns the 128-bit `Universally Unique Identifier`_ for the
BL1 SMC service.
### BL1_SMC_VERSION
BL1\_SMC\_VERSION
~~~~~~~~~~~~~~~~~
::
Argument:
uint32_t function ID : 0x3
......@@ -170,7 +176,10 @@ BL1 SMC service.
This SMC returns the current version of the BL1 SMC service.
### BL1_SMC_RUN_IMAGE
BL1\_SMC\_RUN\_IMAGE
~~~~~~~~~~~~~~~~~~~~
::
Arguments:
uint32_t function ID : 0x4
......@@ -184,11 +193,13 @@ This SMC returns the current version of the BL1 SMC service.
if (ep_info not EL3) synchronous exception
This SMC passes execution control to an EL3 image described by the provided
`entry_point_info_t` structure. In the normal TF boot flow, BL2 invokes this SMC
``entry_point_info_t`` structure. In the normal TF boot flow, BL2 invokes this SMC
for BL1 to pass execution control to BL31.
FWU\_SMC\_IMAGE\_COPY
~~~~~~~~~~~~~~~~~~~~~
### FWU_SMC_IMAGE_COPY
::
Arguments:
uint32_t function ID : 0x10
......@@ -214,16 +225,16 @@ for BL1 to pass execution control to BL31.
if (image_size > free secure memory) return -ENOMEM
if (image overlaps another image) return -EPERM
This SMC copies the secure image indicated by `image_id` from non-secure memory
This SMC copies the secure image indicated by ``image_id`` from non-secure memory
to secure memory for later authentication. The image may be copied in a single
block or multiple blocks. In either case, the total size of the image must be
provided in `image_size` when invoking this SMC for the first time for each
provided in ``image_size`` when invoking this SMC for the first time for each
image; it is ignored in subsequent calls (if any) for the same image.
The `image_addr` and `block_size` specify the source memory block to copy from.
The ``image_addr`` and ``block_size`` specify the source memory block to copy from.
The destination address is provided by the platform code.
If `block_size` is greater than the amount of remaining bytes to copy for this
If ``block_size`` is greater than the amount of remaining bytes to copy for this
image then the former is truncated to the latter. The copy operation is then
considered as complete and the FWU state machine transitions to the "COPIED"
state. If there is still more to copy, the FWU state machine stays in or
......@@ -234,8 +245,10 @@ contiguous memory.
Once the SMC is handled, BL1 returns from exception to the normal world caller.
FWU\_SMC\_IMAGE\_AUTH
~~~~~~~~~~~~~~~~~~~~~
### FWU_SMC_IMAGE_AUTH
::
Arguments:
uint32_t function ID : 0x11
......@@ -262,9 +275,9 @@ Once the SMC is handled, BL1 returns from exception to the normal world caller.
if (image_addr/image_size is in secure memory) return -ENOMEM
if (image_addr/image_size not mappped into BL1) return -ENOMEM
This SMC authenticates the image specified by `image_id`. If the image is in the
RESET state, BL1 authenticates the image in place using the provided
`image_addr` and `image_size`. If the image is a secure image in the COPIED
This SMC authenticates the image specified by ``image_id``. If the image is in the
RESET state, BL1 authenticates the image in place using the provided
``image_addr`` and ``image_size``. If the image is a secure image in the COPIED
state, BL1 authenticates the image from the secure memory that BL1 previously
copied the image into.
......@@ -272,8 +285,10 @@ BL1 returns from exception to the caller. If authentication succeeds then BL1
sets the image state to AUTHENTICATED. If authentication fails then BL1 returns
the -EAUTH error and sets the image state back to RESET.
FWU\_SMC\_IMAGE\_EXECUTE
~~~~~~~~~~~~~~~~~~~~~~~~
### FWU_SMC_IMAGE_EXECUTE
::
Arguments:
uint32_t function ID : 0x12
......@@ -291,15 +306,17 @@ the -EAUTH error and sets the image state back to RESET.
if (image_id state is not AUTHENTICATED) return -EPERM
This SMC initiates execution of a previously authenticated image specified by
`image_id`, in the other security world to the caller. The current
``image_id``, in the other security world to the caller. The current
implementation only supports normal world callers initiating execution of a
secure world image.
BL1 saves the normal world caller's context, sets the secure image state to
EXECUTED, and returns from exception to the secure image.
FWU\_SMC\_IMAGE\_RESUME
~~~~~~~~~~~~~~~~~~~~~~~
### FWU_SMC_IMAGE_RESUME
::
Arguments:
uint32_t function ID : 0x13
......@@ -320,11 +337,13 @@ to EXECUTED. For secure world callers, BL1 sets the previously executing secure
image state to INTERRUPTED. In either case, BL1 saves the calling world's
context, restores the resuming world's context and returns from exception into
the resuming world. If the call is successful then the caller provided
`image_param` is returned to the resumed world, otherwise an error code is
``image_param`` is returned to the resumed world, otherwise an error code is
returned to the caller.
FWU\_SMC\_SEC\_IMAGE\_DONE
~~~~~~~~~~~~~~~~~~~~~~~~~~
### FWU_SMC_SEC_IMAGE_DONE
::
Arguments:
uint32_t function ID : 0x14
......@@ -342,8 +361,10 @@ BL1 sets the previously executing secure image state to the RESET state,
restores the normal world context and returns from exception into the normal
world.
FWU\_SMC\_UPDATE\_DONE
~~~~~~~~~~~~~~~~~~~~~~
### FWU_SMC_UPDATE_DONE
::
Arguments:
uint32_t function ID : 0x15
......@@ -353,11 +374,13 @@ world.
N/A
This SMC completes the firmware update process. BL1 calls the platform specific
function `bl1_plat_fwu_done`, passing the optional argument `client_cookie` as
a `void *`. The SMC does not return.
function ``bl1_plat_fwu_done``, passing the optional argument ``client_cookie`` as
a ``void *``. The SMC does not return.
FWU\_SMC\_IMAGE\_RESET
~~~~~~~~~~~~~~~~~~~~~~
### FWU_SMC_IMAGE_RESET
::
Arguments:
uint32_t function ID : 0x16
......@@ -375,14 +398,15 @@ This SMC sets the state of an image to RESET and zeroes the memory used by it.
This is only allowed if the image is not being executed.
--------------
- - - - - - - - - - - - - - - - - - - - - - - - - -
_Copyright (c) 2015-2017, ARM Limited and Contributors. All rights reserved._
*Copyright (c) 2015-2017, ARM Limited and Contributors. All rights reserved.*
.. _Trusted Board Boot: ./trusted-board-boot.rst
.. _Porting Guide: ./porting-guide.rst
.. _here: https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Image-Terminology
.. _Authentication Framework Design: ./auth-framework.rst
.. _Universally Unique Identifier: https://tools.ietf.org/rfc/rfc4122.txt
[Porting Guide]: ./porting-guide.md
[Auth Framework]: ./auth-framework.md
[Trusted Board Boot]: ./trusted-board-boot.md
[TF Image Terminology]: https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Image-Terminology
[UUID]: https://tools.ietf.org/rfc/rfc4122.txt "A Universally Unique IDentifier (UUID) URN Namespace"
.. |Flow Diagram| image:: diagrams/fwu_flow.png?raw=true
.. |FWU state machine| image:: diagrams/fwu_states.png?raw=true
docs/plat/hikey.md deleted 100644 → 0
View file @ aa5b843f
Description
====================
HiKey is one of 96boards. Hisilicon Kirin6220 processor is installed on HiKey.
More information are listed in [link](https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/Quickstart/README.md).
How to build
====================
1. Code Locations
-----------------
* ARM Trusted Firmware:
[link](https://github.com/ARM-software/arm-trusted-firmware)
* edk2:
[link](https://github.com/96boards-hikey/edk2/tree/testing/hikey960_v2.5)
* OpenPlatformPkg:
[link](https://github.com/96boards-hikey/OpenPlatformPkg/tree/testing/hikey960_v1.3.4)
* l-loader:
[link](https://github.com/96boards-hikey/l-loader/tree/testing/hikey960_v1.2)
* uefi-tools:
[link](https://github.com/96boards-hikey/uefi-tools/tree/testing/hikey960_v1)
* atf-fastboot:
[link](https://github.com/96boards-hikey/atf-fastboot/tree/master)
2. Build Procedure
------------------
* Fetch all the above repositories into local host.
Make all the repositories in the same ${BUILD_PATH}.
* Create the symbol link to OpenPlatformPkg in edk2.
<br>`$cd ${BUILD_PATH}/edk2`</br>
<br>`$ln -sf ../OpenPlatformPkg`</br>
* Prepare AARCH64 && AARCH32 toolchain. Prepare python.
* If your hikey hardware is built by CircuitCo, update _uefi-tools/platform.config_ first. _(optional)_
<br>__Uncomment the below sentence. Otherwise, UEFI can't output messages on serial
console on hikey.__</br>
<br>`BUILDFLAGS=-DSERIAL_BASE=0xF8015000`</br>
<br>If your hikey hardware is built by LeMarker, nothing to do.</br>
* Build it as debug mode. Create your own build script file or you could refer to __build_uefi.sh__ in l-loader git repository.
<br>`BUILD_OPTION=DEBUG`</br>
<br>`export AARCH64_TOOLCHAIN=GCC5`</br>
<br>`export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools`<br>
<br>`export EDK2_DIR=${BUILD_PATH}/edk2`</br>
<br>`EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}`</br>
<br>`# Build fastboot for ARM Trust Firmware. It's used for recovery mode.`</br>
<br>`cd ${BUILD_PATH}/atf-fastboot`</br>
<br>`CROSS_COMPILE=aarch64-linux-gnu- make PLAT=hikey DEBUG=1`</br>
<br>`# Convert DEBUG/RELEASE to debug/release`</br>
<br>`FASTBOOT_BUILD_OPTION=$(echo ${BUILD_OPTION} | tr '[A-Z]' '[a-z]')`</br>
<br>`cd ${EDK2_DIR}`</br>
<br>`# Build UEFI & ARM Trust Firmware`</br>
<br>`${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey`</br>
<br>`# Generate l-loader.bin`</br>
<br>`cd ${BUILD_PATH}/l-loader`</br>
<br>`ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin`</br>
<br>`ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin`</br>
<br>`ln -sf ${BUILD_PATH}/atf-fastboot/build/hikey/${FASTBOOT_BUILD_OPTION}/bl1.bin fastboot.bin`</br>
<br>`python gen_loader.py -o l-loader.bin --img_bl1=bl1.bin --img_ns_bl1u=BL33_AP_UEFI.fd`</br>
<br>`arm-linux-gnueabihf-gcc -c -o start.o start.S`</br>
<br>`arm-linux-gnueabihf-ld -Bstatic -Tl-loader.lds -Ttext 0xf9800800 start.o -o loader`</br>
<br>`arm-linux-gnueabihf-objcopy -O binary loader temp`</br>
<br>`python gen_loader_hikey.py -o l-loader.bin --img_loader=temp --img_bl1=bl1.bin --img_ns_bl1u=fastboot.bin`</br>
* Generate partition table for aosp. The eMMC capacity is either 4GB or 8GB. Just change "aosp-4g" to "linux-4g" for debian.
<br>`$PTABLE=aosp-4g SECTOR_SIZE=512 bash -x generate_ptable.sh`</br>
3. Setup Console
----------------
* Install ser2net. Use telnet as the console since UEFI fails to display Boot Manager GUI in minicom. __If you don't need Boot Manager GUI, just ignore this section.__
<br>`$sudo apt-get install ser2net`</br>
* Configure ser2net.
<br>`$sudo vi /etc/ser2net.conf`</br>
<br>Append one line for serial-over-USB in below.</br>
<br>_#ser2net.conf_</br>
<br>`2004:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner`</br>
* Open the console.
<br>`$telnet localhost 2004`</br>
<br>And you could open the console remotely, too.</br>
4. Flush images in recovery mode
-----------------------------
* Make sure Pin3-Pin4 on J15 are connected for recovery mode. Then power on HiKey.
* Remove the modemmanager package. This package may cause the idt tool failure.
<br>`$sudo apt-get purge modemmanager`</br>
* Run the command to download l-loader.bin into HiKey.
<br>`$sudo python hisi-idt.py -d /dev/ttyUSB1 --img1 l-loader.bin`</br>
* Update images. All aosp or debian images could be fetched from [link](https://builds.96boards.org/).
<br>`$sudo fastboot flash ptable prm_ptable.img`</br>
<br>`$sudo fastboot flash fastboot fip.bin`</br>
<br>`$sudo fastboot flash boot boot.img`</br>
<br>`$sudo fastboot flash cache cache.img`</br>
<br>`$sudo fastboot flash system system.img`</br>
<br>`$sudo fastboot flash userdata userdata.img`</br>
5. Boot UEFI in normal mode
-----------------------------
* Make sure Pin3-Pin4 on J15 are open for normal boot mode. Then power on HiKey.
* Reference [link](https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-ATF-UEFI-build-from-source.md)
docs/plat/hikey.rst 0 → 100644
View file @ 7cefb56d
This diff is collapsed.
docs/plat/hikey960.md deleted 100644 → 0
View file @ aa5b843f
Description
====================
HiKey960 is one of 96boards. Hisilicon Hi3660 processor is installed on HiKey960.
More information are listed in [link](http://www.96boards.org/documentation/ConsumerEdition/HiKey960/README.md).
How to build
====================
1. Code Locations
-----------------
* ARM Trusted Firmware:
[link](https://github.com/ARM-software/arm-trusted-firmware)
* edk2:
[link](https://github.com/96boards-hikey/edk2/tree/testing/hikey960_v2.5)
* OpenPlatformPkg:
[link](https://github.com/96boards-hikey/OpenPlatformPkg/tree/testing/hikey960_v1.3.4)
* l-loader:
[link](https://github.com/96boards-hikey/l-loader/tree/testing/hikey960_v1.2)
* uefi-tools:
[link](https://github.com/96boards-hikey/uefi-tools/tree/hikey960_v1)
2. Build Procedure
------------------
* Fetch all the above 5 repositories into local host.
Make all the repositories in the same ${BUILD_PATH}.
* Create the symbol link to OpenPlatformPkg in edk2.
<br>`$cd ${BUILD_PATH}/edk2`</br>
<br>`$ln -sf ../OpenPlatformPkg`</br>
* Prepare AARCH64 toolchain.
* If your hikey960 hardware is v1, update _uefi-tools/platform.config_ first. _(optional)_
<br>__Uncomment the below sentence. Otherwise, UEFI can't output messages on serial
console on hikey960 v1.__</br>
<br>`BUILDFLAGS=-DSERIAL_BASE=0xFDF05000`</br>
<br>If your hikey960 hardware is v2 or newer, nothing to do.</br>
* Build it as debug mode. Create script file for build.
<br>`BUILD_OPTION=DEBUG`</br>
<br>`export AARCH64_TOOLCHAIN=GCC48`</br>
<br>`export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools`<br>
<br>`export EDK2_DIR=${BUILD_PATH}/edk2`</br>
<br>`EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey960/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}`</br>
<br>`cd ${EDK2_DIR}`</br>
<br>`# Build UEFI & ARM Trust Firmware`</br>
<br>`${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey960`</br>
<br>`# Generate l-loader.bin`</br>
<br>`cd ${BUILD_PATH}/l-loader`</br>
<br>`ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin`</br>
<br>`ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin`</br>
<br>`ln -sf ${EDK2_OUTPUT_DIR}/FV/BL33_AP_UEFI.fd`</br>
<br>`python gen_loader.py -o l-loader.bin --img_bl1=bl1.bin --img_ns_bl1u=BL33_AP_UEFI.fd`</br>
* Generate partition table.
<br>_Make sure that you're using the sgdisk in the l-loader directory._</br>
<br>`$PTABLE=aosp-32g SECTOR_SIZE=4096 SGDISK=./sgdisk bash -x generate_ptable.sh`</br>
3. Setup Console
----------------
* Install ser2net. Use telnet as the console since UEFI will output window
that fails to display in minicom.
<br>`$sudo apt-get install ser2net`</br>
* Configure ser2net.
<br>`$sudo vi /etc/ser2net.conf`</br>
<br>Append one line for serial-over-USB in below.</br>
<br>_#ser2net.conf_</br>
<br>`2004:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner`</br>
* Open the console.
<br>`$telnet localhost 2004`</br>
<br>And you could open the console remotely, too.</br>
4. Boot UEFI in recovery mode
-----------------------------
* Fetch that are used in recovery mode. The code location is in below.
[link](https://github.com/96boards-hikey/tools-images-hikey960)
* Generate l-loader.bin.
<br>`$cd tools-images-hikey960`</br>
<br>`$ln -sf ${BUILD_PATH}/l-loader/l-loader.bin`</br>
* Prepare config file.
<br>_$vi config_</br>
<br>_# The content of config file_</br>
<br>`./sec_user_xloader.img 0x00020000`</br>
<br>`./sec_uce_boot.img 0x6A908000`</br>
<br>`./l-loader.bin 0x1AC00000`</br>
* Remove the modemmanager package. This package may causes hikey_idt tool failure.
<br>`$sudo apt-get purge modemmanager`</br>
* Run the command to download l-loader.bin into HiKey960.
<br>`$sudo ./hikey_idt -c config -p /dev/ttyUSB1`</br>
* UEFI running in recovery mode.
<br>When prompt '.' is displayed on console, press hotkey 'f' in keyboard. Then Android fastboot app is running.</br>
<br>The timeout of prompt '.' is 10 seconds.</br>
* Update images.
<br>`$sudo fastboot flash ptable prm_ptable.img`</br>
<br>`$sudo fastboot flash xloader sec_xloader.img`</br>
<br>`$sudo fastboot flash fastboot l-loader.bin`</br>
<br>`$sudo fastboot flash fip fip.bin`</br>
<br>`$sudo fastboot flash boot boot.img`</br>
<br>`$sudo fastboot flash cache cache.img`</br>
<br>`$sudo fastboot flash system system.img`</br>
<br>`$sudo fastboot flash userdata userdata.img`</br>
* Notice: UEFI could also boot kernel in recovery mode, but BL31 isn't loaded in
recovery mode.
5. Boot UEFI in normal mode
-----------------------------
* Make sure "Boot Mode" switch is OFF for normal boot mode. Then power on HiKey960.
* Reference [link](https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-ATF-UEFI-build-from-source.md)
docs/plat/hikey960.rst 0 → 100644
View file @ 7cefb56d
This diff is collapsed.
docs/plat/qemu.md → docs/plat/qemu.rst
View file @ 7cefb56d
This diff is collapsed.
docs/plat/socionext-uniphier.md deleted 100644 → 0
View file @ aa5b843f
This diff is collapsed.
docs/plat/socionext-uniphier.rst 0 → 100644
View file @ 7cefb56d
This diff is collapsed.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment