Complete Yocto mirror with license table for TQMa6UL (2038-compliance)
- 264 license table entries with exact download URLs (224/264 resolved) - Complete sources/ directory with all BitBake recipes - Build configuration: tqma6ul-multi-mba6ulx, spaetzle (musl) - Full traceability for Softwarefreigabeantrag - GCC 13.4.0, Linux 6.6.102, U-Boot 2023.04, musl 1.2.4 - License distribution: GPL-2.0 (24), MIT (23), GPL-2.0+ (18), BSD-3 (16)
This commit is contained in:
Siggi (OpenClaw Agent)
49
sources/meta-arm/documentation/oeqa-fvp.md
Normal file
49
sources/meta-arm/documentation/oeqa-fvp.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# OEQA on Arm FVPs
|
||||
|
||||
OE-Core's [oeqa][OEQA] framework provides a method of performing runtime tests on machines using the `testimage` Yocto task. meta-arm has good support for writing test cases against [Arm FVPs][FVP], meaning the [runfvp][RUNFVP] boot configuration can be re-used.
|
||||
|
||||
Tests can be configured to run automatically post-build by setting the variable `TESTIMAGE_AUTO="1"`, e.g. in your Kas file or local.conf.
|
||||
|
||||
meta-arm provides the OEFVPTarget which must be set up in the machine configuration:
|
||||
```
|
||||
TEST_TARGET = "OEFVPTarget"
|
||||
TEST_SERVER_IP = "127.0.0.1"
|
||||
TEST_TARGET_IP = "127.0.0.1:2222"
|
||||
IMAGE_FEATURES:append = " ssh-server-dropbear"
|
||||
FVP_CONFIG[bp.virtio_net.hostbridge.userNetPorts] ?= "2222=22"
|
||||
FVP_CONSOLES[default] = "terminal_0"
|
||||
FVP_CONSOLES[tf-a] = "s_terminal_0"
|
||||
```
|
||||
|
||||
The test target also generates a log file with the prefix 'fvp_log' in the image recipe's `${WORKDIR}/testimage` containing the FVP's stdout.
|
||||
|
||||
OEFVPTarget supports two different test interfaces - SSH and pexpect.
|
||||
|
||||
## SSH
|
||||
|
||||
As in OEQA in OE-core, tests cases can run commands on the machine using SSH. It therefore requires that an SSH server is installed in the image.
|
||||
|
||||
This uses the `run` method on the target, e.g:
|
||||
```
|
||||
(status, output) = self.target.run('uname -a')
|
||||
```
|
||||
which executes a single command on the target (using `ssh -c`) and returns the status code and the output. It is therefore useful for running tests in a Linux environment.
|
||||
|
||||
For examples of test cases, see meta/lib/oeqa/runtime/cases in OE-Core. The majority of test cases depend on `ssh.SSHTest.test_ssh`, which first validates that the SSH connection is functioning.
|
||||
|
||||
## pexpect
|
||||
|
||||
To support firmware and baremetal testing, OEFVPTarget also allows test cases to make assertions against one or more consoles using the pexpect library.
|
||||
|
||||
Internally, this test target launches a [Pexpect][PEXPECT] instance for each entry in FVP_CONSOLES which can be used with the provided alias. The whole Pexpect API is exposed on the target, where the alias is always passed as the first argument, e.g.:
|
||||
```
|
||||
self.target.expect('default', r'root@.*\:~#', timeout=30)
|
||||
self.assertNotIn(b'ERROR:', self.target.before('tf-a'))
|
||||
```
|
||||
|
||||
For an example of a full test case, see meta-arm/lib/oeqa/runtime/cases/linuxboot.py This test case can be used to minimally verify that a machine boots to a Linux shell. The default timeout is 10 minutes, but this can be configured with the variable TEST_FVP_LINUX_BOOT_TIMEOUT, which expects a value in seconds.
|
||||
|
||||
[OEQA]: https://docs.yoctoproject.org/test-manual/intro.html
|
||||
[FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
|
||||
[RUNFVP]: runfvp.md
|
||||
[PEXPECT]: https://pexpect.readthedocs.io/en/stable/overview.html
|
||||
131
sources/meta-arm/documentation/runfvp.md
Normal file
131
sources/meta-arm/documentation/runfvp.md
Normal file
@@ -0,0 +1,131 @@
|
||||
# Running Images with a FVP
|
||||
|
||||
The `runfvp` tool in meta-arm makes it easy to run Yocto Project disk images inside a [Fixed Virtual Platform (FVP)][FVP]. Some FVPs, such as the [Arm Architecture Models][AEM], are available free to download, but others need registration or are only available commercially. The `fvp-base` machine in meta-arm-bsp uses one of these AEM models.
|
||||
|
||||
## Running images with `runfvp`
|
||||
|
||||
To build images with the FVP integration, the `fvpboot` class needs to be inherited. If the machine does not do this explicitly it can be done in `local.conf`:
|
||||
|
||||
```
|
||||
INHERIT += "fvpboot"
|
||||
```
|
||||
|
||||
The class will download the correct FVP and write a `.fvpconf` configuration file when an image is built.
|
||||
|
||||
To run an image in a FVP, pass either a machine name or a `.fvpconf` path to `runfvp`.
|
||||
|
||||
```
|
||||
$ ./meta-arm/scripts/runfvp tmp/deploy/images/fvp-base/core-image-minimal-fvp-base.fvpconf
|
||||
```
|
||||
|
||||
When a machine name is passed, `runfvp` will start the latest image that has been built for that machine. This requires that the BitBake environment has been initialized (using `oe-init-build-env` or similar) as it will start BitBake to determine where the images are.
|
||||
|
||||
```
|
||||
$ ./meta-arm/scripts/runfvp fvp-base
|
||||
```
|
||||
|
||||
Note that currently meta-arm's `scripts` directory isn't in `PATH`, so a full path needs to be used.
|
||||
|
||||
`runfvp` will automatically start terminals connected to each of the serial ports that the machine specifies. This can be controlled by using the `--terminals` option, for example `--terminals=none` will mean no terminals are started, and `--terminals=tmux` will start the terminals in [`tmux`][tmux] sessions. Alternatively, passing `--console` will connect the serial port directly to the current session, without needing to open further windows.
|
||||
|
||||
The default terminal can also be configured by writing a [INI-style][INI] configuration file to `~/.config/runfvp.conf`:
|
||||
|
||||
```
|
||||
[RunFVP]
|
||||
Terminal=tmux
|
||||
```
|
||||
|
||||
Arbitrary options can be passed directly to the FVP by specifying them after a double dash, for example this will list all of the FVP parameters:
|
||||
|
||||
```
|
||||
$ runfvp fvp-base -- --list-params
|
||||
```
|
||||
|
||||
## Configuring machines with `fvpboot`
|
||||
|
||||
To configure a machine so that it can be ran inside `runfvp`, a number of variables need to be set in the machine configuration file (such as `meta-arm-bsp/conf/machine/fvp-base.conf`).
|
||||
|
||||
Note that at present these variables are not stable and their behaviour may be changed in the future.
|
||||
|
||||
### `FVP_EXE`
|
||||
|
||||
The name of the FVP binary itself, for example `fvp-base` uses `FVP_Base_RevC-2xAEMvA`.
|
||||
|
||||
### `FVP_PROVIDER`
|
||||
|
||||
The name of the recipe that provides the FVP executable set in `FVP_EXE`, for example `fvp-base` uses `fvp-base-a-aem-native`. This *must* be a `-native` recipe as the binary will be executed on the build host.
|
||||
|
||||
There are recipes for common FVPs in meta-arm already, and writing new recipes is trivial. For FVPs which are free to download `fvp-base-a-aem.bb` is a good example. Some FVPs must be downloaded separately as they need an account on Arm's website.
|
||||
|
||||
If `FVP_PROVIDER` is not set then it is assumed that `FVP_EXE` is installed on the host already.
|
||||
|
||||
### `FVP_CONFIG`
|
||||
|
||||
Parameters passed to the FVP with the `--parameter`/`-C` option. These are expressed as variable flags so individual parameters can be altered easily. For example:
|
||||
|
||||
```
|
||||
FVP_CONFIG[bp.flashloader0.fname] = "fip-fvp.bin"
|
||||
```
|
||||
|
||||
### `FVP_DATA`
|
||||
|
||||
Specify raw data to load at the specified address, passed to the FVP with the `--data` option. This is a space-separated list of parameters in the format `[INST=]FILE@[MEMSPACE:]ADDRESS`. For example:
|
||||
|
||||
```
|
||||
FVP_DATA = "cluster0.cpu0=Image@0x80080000 \
|
||||
cluster0.cpu0=fvp-base-revc.dtb@0x83000000"
|
||||
```
|
||||
|
||||
### `FVP_APPLICATIONS`
|
||||
|
||||
Applications to load on the cores, passed to the FVP with the `--application` option. These are expressed as variable flags with the flag name being the instance and flag value the filename, for example:
|
||||
|
||||
```
|
||||
FVP_APPLICATIONS[cluster0] = "linux-system.axf"
|
||||
```
|
||||
|
||||
Note that symbols are not allowed in flag names, so if you need to use a wildcard in the instance then you'll need to use `FVP_EXTRA_ARGS` and `--application` directly.
|
||||
|
||||
### `FVP_TERMINALS`
|
||||
|
||||
Map hardware serial ports to abstract names. For example the `FVP_Base_RevC-2xAEMvA` FVP exposes four serial ports, `terminal_0` to `terminal_3`. Typically only `terminal_0` is used in the `fvp-base` machine so this can be named `"Console"` and the others `""`. When runfvp starts terminals it will only start named serial ports, so instead of opening four windows where only one is useful, it will only open one.
|
||||
|
||||
For example:
|
||||
```
|
||||
FVP_TERMINALS[bp.terminal_0] = "Console"
|
||||
FVP_TERMINALS[bp.terminal_1] = ""
|
||||
FVP_TERMINALS[bp.terminal_2] = ""
|
||||
FVP_TERMINALS[bp.terminal_3] = ""
|
||||
```
|
||||
|
||||
### `FVP_CONSOLES`
|
||||
|
||||
This specifies what serial ports can be used in oeqa tests, along with an alias to be used in the test cases. Note that the values have to be the FVP identifier but without the board prefix, for example:
|
||||
```
|
||||
FVP_CONSOLES[default] = "terminal_0"
|
||||
FVP_CONSOLES[tf-a] = "s_terminal_0"
|
||||
```
|
||||
|
||||
The 'default' console is also used when `--console` is passed to runfvp.
|
||||
|
||||
### `FVP_EXTRA_ARGS`
|
||||
|
||||
Arbitrary extra arguments that are passed directly to the FVP. For example:
|
||||
|
||||
```
|
||||
FVP_EXTRA_ARGS = "--simlimit 60"
|
||||
```
|
||||
|
||||
### `FVP_ENV_PASSTHROUGH`
|
||||
|
||||
The FVP is launched with an isolated set of environment variables. Add the name of a Bitbake variable to this list to pass it through to the FVP environment. For example:
|
||||
|
||||
```
|
||||
FVP_ENV_PASSTHROUGH = "ARMLMD_LICENSE_FILE FM_TRACE_PLUGINS"
|
||||
```
|
||||
|
||||
|
||||
[AEM]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms/arm-ecosystem-models
|
||||
[FVP]: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms
|
||||
[tmux]: https://tmux.github.io/
|
||||
[INI]: https://docs.python.org/3/library/configparser.html
|
||||
70
sources/meta-arm/documentation/trusted-services.md
Normal file
70
sources/meta-arm/documentation/trusted-services.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# The Trusted Services: framework for developing root-of-trust services
|
||||
|
||||
meta-arm layer includes recipes for [Trusted Services][^1] Secure Partitions and Normal World applications
|
||||
in `meta-arm/recipes-security/trusted-services`
|
||||
|
||||
## Secure Partitions recipes
|
||||
|
||||
We define dedicated recipes for all supported Trusted Services (TS) Secure Partitions.
|
||||
These recipes produce ELF and DTB files for SPs.
|
||||
These files are automatically included into optee-os image accordingly to defined MACHINE_FEATURES.
|
||||
|
||||
### How to include TS SPs
|
||||
|
||||
To include TS SPs into optee-os image you need to add into MACHINE_FEATURES
|
||||
features for each [Secure Partition][^2] you would like to include:
|
||||
|
||||
| Secure Partition | MACHINE_FEATURE |
|
||||
| ----------------- | --------------- |
|
||||
| Attestation | ts-attesation |
|
||||
| Crypto | ts-crypto |
|
||||
| Firmware Update | ts-fwu
|
||||
| Internal Storage | ts-its |
|
||||
| Protected Storage | ts-storage |
|
||||
| se-proxy | ts-se-proxy |
|
||||
| smm-gateway | ts-smm-gateway |
|
||||
| spm-test[1-4] | optee-spmc-test |
|
||||
|
||||
Other steps depend on your machine/platform definition:
|
||||
|
||||
1. For communications between Secure and Normal Words Linux kernel option `CONFIG_ARM_FFA_TRANSPORT=y`
|
||||
is required. If your platform doesn't include it already you can add `arm-ffa` into MACHINE_FEATURES.
|
||||
(Please see ` meta-arm/recipes-kernel/arm-tstee`.)
|
||||
|
||||
For running the `uefi-test` or the `xtest -t ffa_spmc` tests under Linux the `arm-ffa-user` drivel is required. This is
|
||||
enabled if the `ts-smm-gateway` and/or the `optee-spmc-test` machine features are enabled.
|
||||
(Please see ` meta-arm/recipes-kernel/arm-ffa-user`.)
|
||||
|
||||
2. optee-os might require platform specific OP-TEE build parameters (for example what SEL the SPM Core is implemented at).
|
||||
You can find examples in `meta-arm/recipes-security/optee/optee-os_%.bbappend` for qemuarm64-secureboot machine
|
||||
and in `meta-arm-bsp/recipes-security/optee/optee-os-n1sdp.inc` and `meta-arm-bsp/recipes-security/optee/optee-os-corstone1000-common.inc`
|
||||
for N1SDP and Corstone1000 platforms accordingly.
|
||||
|
||||
3. trusted-firmware-a might require platform specific TF-A build parameters (SPD and SPMC details on the platform).
|
||||
See `meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend` for qemuarm64-secureboot machine
|
||||
and in `meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-n1sdp.inc` and
|
||||
`meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-corstone1000.inc` for N1SDP and Corstone1000 platforms.
|
||||
|
||||
4. Trusted Services supports an SPMC agonistic binary format. To build SPs to this format the `TS_ENV` variable is to be
|
||||
set to `sp`. The resulting SP binaries should be able to boot under any FF-A v1.1 compliant SPMC implementation.
|
||||
|
||||
|
||||
## Normal World applications
|
||||
|
||||
Optionally for testing purposes you can add `packagegroup-ts-tests` into your image. It includes
|
||||
[Trusted Services test and demo tools][^3] and [xtest][^4] configured to include the `ffa_spmc` tests.
|
||||
|
||||
## OEQA Trusted Services tests
|
||||
|
||||
meta-arm also includes Trusted Service OEQA tests which can be used for automated testing.
|
||||
See `ci/trusted-services.yml` for an example how to include them into an image.
|
||||
|
||||
|
||||
------
|
||||
[^1]: https://trusted-services.readthedocs.io/en/integration/overview/index.html
|
||||
|
||||
[^2]: https://trusted-services.readthedocs.io/en/integration/deployments/secure-partitions.html
|
||||
|
||||
[^3]: https://trusted-services.readthedocs.io/en/integration/deployments/test-executables.html
|
||||
|
||||
[^4]: https://optee.readthedocs.io/en/latest/building/gits/optee_test.html
|
||||
Reference in New Issue
Block a user