Skip to content
Snippets Groups Projects
Verified Commit fb297405 authored by Andrei Gherzan's avatar Andrei Gherzan :penguin:
Browse files

Remove support for stm32mp1-av96 (96Boards Avenger96) 


Signed-off-by: Andrei Gherzan's avatarAndrei Gherzan <andrei.gherzan@huawei.com>
parent 376aaab9
No related branches found
No related tags found
1 merge request!30flavours/zephyr/local.conf.sample: Bump CONF_VERSION
Hide whitespace changes
Inline Side-by-side
Showing
with 0 additions and 505 deletions
.gitlab-ci.yml
+ 0
− 12
View file @ fb297405
...@@ -122,18 +122,6 @@ aggregate-docs: ...@@ -122,18 +122,6 @@ aggregate-docs:
## ##
## Submit jobs to LAVA ## Submit jobs to LAVA
## ##
lava-linux-avenger96:
needs: [linux-stm32mp1-av96]
stage: test
extends: .lava-test
variables:
MACHINE: stm32mp1-av96
CI_BUILD_JOB_NAME: linux-stm32mp1-av96
CI_LAVA_JOB_DEFINITION: "https://git.ostc-eu.org/OSTC/infrastructure/lava/lava-config/-/raw/master/lava.ostc-eu.org/job-definitions/ci/avenger96-acts.yaml"
CI_REPORT_JOB_NAME: lava-report
rules:
- when: never
lava-qemu-x86: lava-qemu-x86:
needs: [linux-qemu-x86] needs: [linux-qemu-x86]
stage: test stage: test
......
.oniro-ci/machines-and-flavours.yaml
+ 0
− 7
View file @ fb297405
...@@ -43,13 +43,6 @@ linux-seco-imx8mm-c61: ...@@ -43,13 +43,6 @@ linux-seco-imx8mm-c61:
# See build-generic.yaml for explanation of CI_ONIRO_BB_LOCAL_CONF_ variables. # See build-generic.yaml for explanation of CI_ONIRO_BB_LOCAL_CONF_ variables.
CI_ONIRO_BB_LOCAL_CONF_ACCEPT_FSL_EULA: 1 CI_ONIRO_BB_LOCAL_CONF_ACCEPT_FSL_EULA: 1
linux-stm32mp1-av96:
extends: .build-recipe
variables:
CI_ONIRO_BUILD_FLAVOUR: linux
CI_ONIRO_RECIPE_NAME: oniro-image-base-tests
MACHINE: stm32mp1-av96
linux-raspberrypi4-64: linux-raspberrypi4-64:
extends: .build-wic-image extends: .build-wic-image
variables: variables:
......
docs/build-flavours/linux-flavour.rst
+ 0
− 1
View file @ fb297405
...@@ -25,7 +25,6 @@ Supported machines (default in **bold**): ...@@ -25,7 +25,6 @@ Supported machines (default in **bold**):
* qemuarm * qemuarm
* qemuarm64 * qemuarm64
* seco-intel-b68 (SECO SBC-B68) * seco-intel-b68 (SECO SBC-B68)
* stm32mp1-av96 (96Boards Avenger96)
* seco-imx8mm-c61 (SECO SBC-C61) * seco-imx8mm-c61 (SECO SBC-C61)
Build steps example: Build steps example:
......
docs/ci/machines-and-flavours.rst
+ 0
− 14
View file @ fb297405
...@@ -66,20 +66,6 @@ architecture. ...@@ -66,20 +66,6 @@ architecture.
The cache for this job is not public, as it contains proprietary elements The cache for this job is not public, as it contains proprietary elements
that cannot be redistributed without an agreement with Freescale. that cannot be redistributed without an agreement with Freescale.
linux-stm32mp1-av96
...................
This job extends `.build-linux` job from the manifest repository and builds
``oniro-image-base-tests`` and ``oniro-image-extra-tests`` using the Linux
flavour of |main_project_name| and ``MACHINE=stm32mp1-av96``. This job checks
that |main_project_name| software can be built for the 96Boards Avenger
development board, which contains the STM32MP157 SoC, which implements 32bit
ARMv7 architecture.
.. note::
The cache for this job is not public, pending legal review of any firmware
that may be included.
linux-raspberrypi4-64 linux-raspberrypi4-64
..................... .....................
......
docs/hardware-support/boards/96b-Avenger.rst deleted 100644 → 0
+ 0
− 351
View file @ 376aaab9
.. SPDX-FileCopyrightText: Huawei Inc.
..
.. SPDX-License-Identifier: CC-BY-4.0
.. _SupportedBoardAvenger96:
96Boards Avenger96
##################
.. contents::
:depth: 3
Overview
********
Avenger96 is a STM32MP157xx (Cortex-A7 + Cortex-M4) development board designed
by the 96Boards initiative. Due to presence of the application processors and
the microcontroller, Avenger96 can simultaneously run Linux and Zephyr kernels.
The application processor is responsible for powering up and programming the
microcontroller with the appropriate image. Linux provides interfaces to
communicate with the program running on the microcontroller.
Hardware
********
* For detailed specification, see `Avenger96 product page on the 96Boards website <https://www.96boards.org/product/avenger96/>`_.
* For hardware user manual and schematics, see `96Boards GitHub documentation repository <https://github.com/96boards/documentation/blob/master/consumer/avenger96/hardware-docs/files/avenger96-hardware-user-manual.pdf>`_.
For more details on Avenger96 board, see `Avenger96 product page <https://www.96boards.org/product/avenger96/>`_.
Working with the Board
**********************
Building an Oniro image
=======================
To clone the source code, perform the procedure in: :ref:`Setting up a repo workspace <RepoWorkspace>`.
Linux image
-----------
1. Source the environment with proper template settings, flavour being *linux*
and target machine being *stm32mp1-av96*. Pay attention to how relative
paths are constructed. The value of *TEMPLATECONF* is relative to the
location of the build directory *./build-linux*, that is going
to be created after this step:
.. code-block:: console
$ TEMPLATECONF=../oniro/flavours/linux . ./oe-core/oe-init-build-env build-oniro-linux
2. You will find yourself in the newly created build directory. Call *bitbake*
to build the image. For example, if you are using *oniro-image-base*
run the following command:
.. code-block:: console
$ MACHINE=stm32mp1-av96 bitbake oniro-image-base
To generate images for eMMC on SD card, refer to the :ref:`Flashing an Oniro image <Flashing_oniro>`.
Zephyr image
------------
1. Source the environment with proper template settings, flavour being *zephyr*
and target machine being *96b-avenger96*:
.. code-block:: console
$ TEMPLATECONF=../oniro/flavours/zephyr . ./oe-core/oe-init-build-env build-oniro-zephyr
2. You will find yourself in the newly created build directory. Call *bitbake*
to build the image. The image name is the name of the Zephyr application.
.. code-block:: console
$ MACHINE=96b-avenger96 bitbake zephyr-philosophers
3. The output file will be located in the build directory
*./tmp-newlib/deploy/images/96b-avenger96/*.
.. _Flashing_oniro:
Flashing an Oniro image
***********************
For Linux, `bmaptool <https://github.com/intel/bmap-tools>` is recommended to
create an SD card image. The images we provide also create wic files (disk
images) that you can use directly. You can also use the `STM32 Cube Programmer <https://wiki.dh-electronics.com/index.php/Avenger96_Image_Programming>`__.
For Zephyr, there is no automation as for now. To have the ELF file in the filesystem:
* Copy the image manually to the filesystem using a method of your choice
* Include it in the image before flashing the card/eMMC
* Copy the file manually to the card or just *scp* it to the board after you set up networking.
Linux image
===========
SD Card
-------
The Avenger96 board supports multiple boot options which are selected by the
DIP-switch S3. Make sure the boot switch is set to boot from the SD-Card.
To set the boot option from the SD card using DIP-switch S3, set the BOOT 0
(Switch 1) and BOOT 2 (Switch 3) to 1 and set BOOT 1 (Switch 2) to 0 on the
circuit board.
For more information on Avenger96 boot options, see `Getting Started with the Avenger96 <https://www.96boards.org/documentation/consumer/avenger96/getting-started/#starting-the-board-for-the-first-time>`__.
1. After the image is built, you are ready to burn the generated image onto the
SD card. We recommend using `bmaptool <https://github.com/intel/bmap-tools>`
and the instructions below will use it. For example, if you are building
oniro-image-base run the following command replacing (or defining)
``$DEVNODE`` accordingly:
.. code-block:: console
$ cd tmp/deploy/images/stm32mp1-av96
$ bmaptool copy oniro-image-base-stm32mp1-av96.wic.bz2 $DEVNODE
2. Put the card to the board and turn it on.
STM32 Cube Programmer
---------------------
After you build the image, follow the instructions in `Avenger96 Image Programming <https://wiki.dh-electronics.com/index.php/Avenger96_Image_Programming>`_,
pointing the program to the
*./tmp/deploy/images/stm32mp1-av96/flashlayout_oniro-image-base/trusted/FlashLayout_emmc_stm32mp157a-av96-trusted.tsv*
flash layout file.
.. _zephyr-image-1:
Zephyr image
============
**Prerequisites**
* Linux is running on the board.
* Make sure that Linux is built with *remoteproc* support. To check status of remoteproc do:
.. code-block:: console
root@stm32mp1-av96:~# dmesg | grep remoteproc
[ 2.336231] remoteproc remoteproc0: m4 is available
1. Copy the Zephyr image to the board using a method of your choice.
2. Check what the ``remoteproc`` framework knows about the name and location of
the firmware file. The default values are presented as follows. Empty path
defaults to ``/lib/firmware``:
::
root@stm32mp1-av96:~# cat /sys/module/firmware_class/parameters/path
<empty>
root@stm32mp1-av96:~# cat /sys/class/remoteproc/remoteproc0/firmware
rproc-m4-fw
3. Configure the name and the location to suit your needs. For example, the
firmware is located in ``/root/zephyr.elf``:
::
root@stm32mp1-av96:~# echo "/root" > /sys/module/firmware_class/parameters/path
root@stm32mp1-av96:~# echo "zephyr.elf" > /sys/class/remoteproc/remoteproc0/firmware
4. Power up the Cortex-M4 core:
::
root@stm32mp1-av96:~# echo start > /sys/class/remoteproc/remoteproc0/state
remoteproc remoteproc0: powering up m4
remoteprocroc remoteproc0: Booting fw image rproc-m4-fw, size 591544
rproc-srm-core m4@0:m4_system_resources: bound m4@0:m4_system_resources:m4_led (ops 0xc0be1210)
remoteproc remoteproc0: remote processor m4 is now
5. Firmware output can be inspected with:
::
root@stm32mp1-av96:~# cat /sys/kernel/debug/remoteproc/remoteproc0/trace0
Philosopher 5 [C:-2] STARVING
Philosopher 3 [P: 0] DROPPED ONE FORK
Philosopher 3 [P: 0] THINKING [ 25 ms ]
Philosopher 2 [P: 1] EATING [ 425 ms ]
Philosopher 3 [P: 0] STARVING
Philosopher 4 [C:-1] STARVING
Philosopher 4 [C:-1] HOLDING ONE FORK
Philosopher 4 [C:-1] EATING [ 800 ms ]
Philosopher 3 [P: 0] HOLDING ONE FORK
Philosopher 2 [P: 1] DROPPED ONE FORK
Philosopher 2 [P: 1] THINKING [ 725 ms ]
Philosopher 1 [P: 2] EATING [ 225 ms ]
There is no fully-featured console available in Linux yet, so typing commands
to the Zephyr application is not possible.
Testing the Board
*****************
Serial Port
===========
To connect the USB converter serial port to the low-speed connector, see `Hardware User Manual <https://github.com/96boards/documentation/blob/master/consumer/avenger96/hardware-docs/files/avenger96-hardware-user-manual.pdf>`__.
.. warning::
* The low speed connector is 1.8V tolerant, therefore the converter must be 1.8V tolerant.
* Do not connect 5V or 3.3V tolerant devices to the connector to avoid SoC damage.
Ethernet
========
Wired connection works out of the box. You can use standard tools like ``ip``,
``ifconfig`` to configure the connection. The connection seems to have stable
1Gb/s bandwidth.
For any fault in the hardware device, see :ref:`How to handle faulty hardware device <FallbackSupport>`.
USB Host
========
Just plug something to the USB port. The board seems to work fine with an
external 500GB USB 3.0 HDD.
::
root@stm32mp1-av96:~# lsusb
Bus 002 Device 003: ID 0930:0b1f Toshiba Corp.
Bus 002 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@stm32mp1-av96:~# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
root@stm32mp1-av96:~# mount | grep sda
/dev/sda1 on /home/root/sda1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
USB OTG
=======
The board supports that feature. For now it only works in DFU mode with STM32
Cube Programmer. Using the board as USB Gadget is currently under development.
eMMC
====
It can be used to store the firmware with STM32 Cube Programmer. It can also be
mounted under Linux booted from another medium:
::
root@stm32mp1-av96:~# mount /dev/mmcblk2p4 emmc/
[ 3006.721643] EXT4-fs (mmcblk2p4): recovery complete
[ 3006.726627] EXT4-fs (mmcblk2p4): mounted filesystem with ordered data mode. Opts: (null)
[ 3006.733931] ext4 filesystem being mounted at /home/root/emmc supports timestamps until 2038 (0x7fffffff)
root@stm32mp1-av96:~# ls -l emmc
drwxr-xr-x 2 root root 1024 Mar 9 12:34 bin
drwxr-xr-x 2 root root 1024 Mar 9 12:34 boot
drwxr-xr-x 2 root root 1024 Mar 9 12:34 dev
drwxr-xr-x 17 root root 1024 Mar 9 12:34 etc
drwxr-xr-x 3 root root 1024 Mar 9 12:34 home
drwxr-xr-x 3 root root 1024 Mar 9 12:34 lib
drwx------ 2 root root 12288 Jan 12 2021 lost+found
drwxr-xr-x 2 root root 1024 Mar 9 12:34 media
drwxr-xr-x 2 root root 1024 Mar 9 12:34 mnt
dr-xr-xr-x 2 root root 1024 Mar 9 12:34 proc
drwxr-xr-x 2 root root 1024 Jan 1 2000 run
drwxr-xr-x 2 root root 1024 Mar 9 12:34 sbin
dr-xr-xr-x 2 root root 1024 Mar 9 12:34 sys
lrwxrwxrwx 1 root root 8 Mar 9 12:34 tmp -> /var/tmp
drwxr-xr-x 10 root root 1024 Mar 9 12:34 usr
drwxr-xr-x 8 root root 1024 Mar 9 12:34 var
Radio
=====
Radio relies on proprietary BRCM firmware. It is already included in the image.
WiFi
----
WiFi can be controlled with ``wpa_supplicant``, which is a standard Linux tool.
Please refer to the tool manual for the details.
Example ``wpa_suppliant`` configs look like below. Assuming the config is saved
in a file named ``wpa.conf`` and the interface is named ``wlan0``, WiFi can be
brought up with ``wpa_supplicant -i wlan0 -c ./wpa.conf``:
::
# Access Point mode example configuration
fast_reauth=1
update_config=1
ap_scan=2
network={
ssid="Avenger96 AP"
mode=2
frequency=2412
key_mgmt=WPA-PSK
proto=RSN
pairwise=CCMP
psk="PlaintextPasswordsAreGreat"
}
::
# Connection to an open network with broadcasted SSID
network={
ssid="0xDEADBEEF"
key_mgmt=NONE
}
For any fault in the hardware device, see :ref:`How to handle faulty hardware device <FallbackSupport>`.
Bluetooth
---------
Bluetooth be controlled with ``bluetoothctl``, which is a standard Linux tool.
Please refer to the tool manual for the details. Devices scanning can be
enabled as follows:
::
root@stm32mp1-av96:~# bluetoothctl
Agent registered
[CHG] Controller 00:9D:6B:AA:77:68 Pairable: yes
[bluetooth]# power on
Changing power on succeeded
[CHG] Controller 00:9D:6B:AA:77:68 Powered: yes
[bluetooth]# discoverable on
Changing discoverable on succeeded
[CHG] Controller 00:9D:6B:AA:77:68 Discoverable: yes
[bluetooth]# scan on
Discovery started
[CHG] Controller 00:9D:6B:AA:77:68 Discovering: yes
[NEW] Device E2:A0:50:99:C9:61 Hue Lamp
[NEW] Device 57:2D:D5:48:8C:D0 57-2D-D5-48-8C-D0
[NEW] Device E4:04:39:65:9C:2A TomTom GPS Watch
[NEW] Device C0:28:8D:49:67:7E C0-28-8D-49-67-7E
Pairing and establishing connection is possible with ``pair`` and ``connect``
commands.
For any fault in the hardware device, see :ref:`How to handle faulty hardware device <FallbackSupport>`.
docs/hardware-support/boards/index.rst
+ 0
− 1
View file @ fb297405
...@@ -14,7 +14,6 @@ This section details the boards supported as part of |main_project_name|. ...@@ -14,7 +14,6 @@ This section details the boards supported as part of |main_project_name|.
.. toctree:: .. toctree::
:maxdepth: 1 :maxdepth: 1
96b-Avenger
96b-nitrogen 96b-nitrogen
seco-intel-b68 seco-intel-b68
seco-imx8mm-c61 seco-imx8mm-c61
......
flavours/linux/bblayers.conf.sample
+ 0
− 3
View file @ fb297405
...@@ -27,9 +27,6 @@ BBLAYERS ?= " \ ...@@ -27,9 +27,6 @@ BBLAYERS ?= " \
##OEROOT##/../meta-openembedded/meta-perl \ ##OEROOT##/../meta-openembedded/meta-perl \
##OEROOT##/../meta-openembedded/meta-python \ ##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-python-mixin \ ##OEROOT##/../meta-python-mixin \
##OEROOT##/../meta-st-stm32mp \
##OEROOT##/../meta-st-stm32mp-addons \
##OEROOT##/../meta-av96/meta-av96-core \
##OEROOT##/../meta-raspberrypi \ ##OEROOT##/../meta-raspberrypi \
##OEROOT##/../meta-security \ ##OEROOT##/../meta-security \
##OEROOT##/../meta-linaro/meta-optee \ ##OEROOT##/../meta-linaro/meta-optee \
......
flavours/linux/conf-notes.txt
+ 0
− 1
View file @ fb297405
...@@ -16,7 +16,6 @@ Supported machines (first is the default): ...@@ -16,7 +16,6 @@ Supported machines (first is the default):
- qemux86 - qemux86
- seco-intel-b68 (SECO SBC-B68) - seco-intel-b68 (SECO SBC-B68)
- seco-imx8mm-c61 (SECO SBC-C61) - seco-imx8mm-c61 (SECO SBC-C61)
- stm32mp1-av96 (96Boards Avenger96)
- raspberrypi4-64 - raspberrypi4-64
MACHINE variable can be set up in conf/local.conf file under build directory MACHINE variable can be set up in conf/local.conf file under build directory
......
flavours/linux/local.conf.sample
+ 0
− 1
View file @ fb297405
...@@ -22,7 +22,6 @@ ...@@ -22,7 +22,6 @@
# #
#MACHINE ?= "qemux86" #MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64" #MACHINE ?= "qemux86-64"
#MACHINE ?= "stm32mp1-av96"
#MACHINE ?= "seco-intel-b68" #MACHINE ?= "seco-intel-b68"
#MACHINE ?= "seco-imx8mm-c61" #MACHINE ?= "seco-imx8mm-c61"
#MACHINE ?= "raspberrypi4-64" #MACHINE ?= "raspberrypi4-64"
......
manifests/default.xml
+ 0
− 5
View file @ fb297405
...@@ -23,7 +23,6 @@ SPDX-FileCopyrightText: Huawei Inc. ...@@ -23,7 +23,6 @@ SPDX-FileCopyrightText: Huawei Inc.
<remote name="aehs29" fetch="https://github.com/aehs29" /> <remote name="aehs29" fetch="https://github.com/aehs29" />
<remote name="seco-intel" fetch="https://git.seco.com/pub/intel/yocto" /> <remote name="seco-intel" fetch="https://git.seco.com/pub/intel/yocto" />
<remote name="seco-imx" fetch="https://git.seco.com/pub/i.mx/yocto/5.x" /> <remote name="seco-imx" fetch="https://git.seco.com/pub/i.mx/yocto/5.x" />
<remote name="stm" fetch="https://github.com/STMicroelectronics" />
<remote name="linaro" fetch="https://git.linaro.org/openembedded" /> <remote name="linaro" fetch="https://git.linaro.org/openembedded" />
<remote name="oe" fetch="git://git.openembedded.org" /> <remote name="oe" fetch="git://git.openembedded.org" />
...@@ -42,15 +41,11 @@ SPDX-FileCopyrightText: Huawei Inc. ...@@ -42,15 +41,11 @@ SPDX-FileCopyrightText: Huawei Inc.
<project name="openembedded-core" remote="oe" revision="90a07178ea26be453d101c2e8b33d3a0f437635d" path="oe-core" /> <project name="openembedded-core" remote="oe" revision="90a07178ea26be453d101c2e8b33d3a0f437635d" path="oe-core" />
<project name="meta-openembedded" remote="openembedded" revision="7889158dcd187546fc5e99fd81d0779cad3e8d17" path="meta-openembedded" /> <project name="meta-openembedded" remote="openembedded" revision="7889158dcd187546fc5e99fd81d0779cad3e8d17" path="meta-openembedded" />
<project name="meta-freertos" remote="aehs29" revision="f3c2edb0f22c34b35a775c5d17ea1424d44bee21" path="meta-freertos" /> <project name="meta-freertos" remote="aehs29" revision="f3c2edb0f22c34b35a775c5d17ea1424d44bee21" path="meta-freertos" />
<project name="meta-st-stm32mp" remote="stm" revision="b25a2b0daa6e9e1e3ce76b9fdf5bd7cbf30e90fc" path="meta-st-stm32mp" />
<project name="meta-st-stm32mp-addons" remote="stm" revision="81065195a63e98be8f423ab422960e9d7896f4d5" path="meta-st-stm32mp-addons" />
<project name="meta-intel" remote="yocto" revision="b4e5d33affeaa223459c0935a853485137b4591d" path="meta-intel" /> <project name="meta-intel" remote="yocto" revision="b4e5d33affeaa223459c0935a853485137b4591d" path="meta-intel" />
<project name="meta-seco-intel" remote="seco-intel" revision="baf4cd3237bdf4f4999b7d44c6992dbcab93d5e3" path="meta-seco-intel" /> <project name="meta-seco-intel" remote="seco-intel" revision="baf4cd3237bdf4f4999b7d44c6992dbcab93d5e3" path="meta-seco-intel" />
<project name="meta-freescale" remote="yocto" revision="11170950b155168ec414bbde48e3a4427fcac4bd" path="meta-freescale" /> <project name="meta-freescale" remote="yocto" revision="11170950b155168ec414bbde48e3a4427fcac4bd" path="meta-freescale" />
<project name="meta-seco-imx" remote="seco-imx" revision="986dd20885277df45d2acc6e38823bf4c64f0085" path="meta-seco-imx" /> <project name="meta-seco-imx" remote="seco-imx" revision="986dd20885277df45d2acc6e38823bf4c64f0085" path="meta-seco-imx" />
<project name="meta-av96" revision="a4b2b45efcbad1882227eac54b5023ff6b736b10" path="meta-av96" />
<project name="meta-python-mixin" revision="7bda3c1e5d6876375a8bf865ed9fcce2622c1715" path="meta-python-mixin" /> <project name="meta-python-mixin" revision="7bda3c1e5d6876375a8bf865ed9fcce2622c1715" path="meta-python-mixin" />
<project name="meta-raspberrypi" remote="yocto" revision="934064a01903b2ba9a82be93b3f0efdb4543a0e8" path="meta-raspberrypi" /> <project name="meta-raspberrypi" remote="yocto" revision="934064a01903b2ba9a82be93b3f0efdb4543a0e8" path="meta-raspberrypi" />
<project name="meta-security" remote="yocto" revision="b76698c788cb8ca632077a972031899ef15025d6" path="meta-security" /> <project name="meta-security" remote="yocto" revision="b76698c788cb8ca632077a972031899ef15025d6" path="meta-security" />
......
meta-oniro-core/classes/oniro-image.bbclass
+ 0
− 39
View file @ fb297405
...@@ -24,28 +24,6 @@ IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_mask_getty;' if bb.utils.contai ...@@ -24,28 +24,6 @@ IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_mask_getty;' if bb.utils.contai
IMAGE_FEATURES_append = " read-only-rootfs" IMAGE_FEATURES_append = " read-only-rootfs"
# Convert all KERNEL_DEVICETREE enties to IMAGE_BOOT_FILES entries
def dtb_boot_files(d):
k_dt = d.getVar('KERNEL_DEVICETREE')
if not k_dt:
return ''
return ' '.join(['kernel/{dtb};{dtb}'.format(dtb=dt) for dt in k_dt.split()])
# Convert all extlinux files to IMAGE_BOOT_FILES entries
def extlinux_boot_files(d):
import os
deploy_dir_image = d.getVar('DEPLOY_DIR_IMAGE')
deploy_extlinux_files = os.path.join(deploy_dir_image, 'bootloader/extlinux')
boot_files = []
for root, _, files in os.walk(deploy_extlinux_files):
for file in files:
src = os.path.relpath(os.path.join(root, file), deploy_dir_image)
dst = os.path.relpath(os.path.join(root, file), deploy_extlinux_files)
boot_files.append('{0};{1}'.format(src, dst))
if not boot_files:
return ''
return ' '.join(boot_files)
# #
# wic configuration with support for system update partition setup # wic configuration with support for system update partition setup
# #
...@@ -57,23 +35,6 @@ WKS_FILE_raspberrypi4-64 ?= "x-raspberrypi.wks.in" ...@@ -57,23 +35,6 @@ WKS_FILE_raspberrypi4-64 ?= "x-raspberrypi.wks.in"
WKS_FILE_seco-intel-b68 ?= "x-efi-systemd-microcode.wks.in" WKS_FILE_seco-intel-b68 ?= "x-efi-systemd-microcode.wks.in"
IMAGE_FSTYPES_append_seco-intel-b68 = " wic.bz2 wic.bmap" IMAGE_FSTYPES_append_seco-intel-b68 = " wic.bz2 wic.bmap"
WKS_FILE_stm32mp1-av96 ?= "x-avenger96.wks.in"
IMAGE_BOOT_FILES_stm32mp1-av96 ?= " \
kernel/${KERNEL_IMAGETYPE};${KERNEL_IMAGETYPE} \
${@dtb_boot_files(d)} \
${@extlinux_boot_files(d)} \
"
IMAGE_FSTYPES_append_stm32mp1-av96 = " wic.bz2 wic.bmap"
WKS_FILE_DEPENDS_stm32mp1-av96 ?= " \
u-boot-stm32mp-extlinux \
virtual/bootloader \
virtual/trusted-firmware-a \
virtual/kernel \
"
# TODO: ST u-boot hardcodes this value. Configure wic as well so it matches the
# uboot configuration.
WIC_ROOTA_PARTITION_EXTRA_ARGS_stm32mp1-av96 ?= "--uuid e91c4e10-16e6-4c0e-bd0e-77becf4a3582"
# We avoid any other fstypes (for qemu) by default as the OS depends on a # We avoid any other fstypes (for qemu) by default as the OS depends on a
# specific partition table provided through the wic configuration. # specific partition table provided through the wic configuration.
IMAGE_FSTYPES_qemux86 ?= "wic wic.bz2" IMAGE_FSTYPES_qemux86 ?= "wic wic.bz2"
......
meta-oniro-core/recipes-bsp/u-boot/u-boot-stm32mp-extlinux.bbappend deleted 100644 → 0
+ 0
− 16
View file @ 376aaab9
# SPDX-FileCopyrightText: Huawei Inc.
#
# SPDX-License-Identifier: Apache-2.0
UBOOT_EXTLINUX_KERNEL_ARGS = "rootwait ro"
inherit deploy
do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}/bootloader/extlinux"
do_deploy() {
# Deploy files too so wic can pick them up from DEPLOYDIR
if ! [ -z "$(ls -A ${B})" ]; then
cp -r --reflink=auto ${B}/* ${DEPLOYDIR}
fi
}
addtask deploy before do_build after do_compile
meta-oniro-core/recipes-kernel/linux/linux-stm32mp_%.bbappend deleted 100644 → 0
+ 0
− 7
View file @ 376aaab9
# SPDX-FileCopyrightText: Huawei Inc.
#
# SPDX-License-Identifier: Apache-2.0
FILESEXTRAPATHS_prepend := "${THISDIR}/linux:"
SRC_URI += "file://squashfs.cfg"
meta-oniro-core/wic/x-avenger96.wks.in deleted 100644 → 0
+ 0
− 28
View file @ 376aaab9
# SPDX-FileCopyrightText: Huawei Inc.
#
# SPDX-License-Identifier: Apache-2.0
# short-description: Disk image for Avenger96 boards
# long-description: Creates a GPT partitioned SD image using a
# FlashLayout_sdcard_stm32mp157a-av96-extensible.tsv setup for the bootloader
# partitions and common partitions for the rest of the entries.
#
# Disk layout:
# -- ------- ------- ------ ------ ------- ------- --------- --------- ---------
# | | fsbl1 | fsbl2 | ssbl | boot | sys-a | sys-b | devdata | sysdata | appdata |
# -- ------- ------- ------ ------ ------- ------- --------- --------- ---------
# ^ ^ ^ ^ ^
# | | | | |
# 0 17KiB 273KiB 529KiB 4096KiB
bootloader --ptable gpt
part fsbl1 --source rawcopy --sourceparams="file=arm-trusted-firmware/tf-a-stm32mp157a-av96-sdcard.stm32" --part-name fsbl1 --part-type 8DA63339-0007-60C0-C436-083AC8230908 --offset 17
part fsbl2 --source rawcopy --sourceparams="file=arm-trusted-firmware/tf-a-stm32mp157a-av96-sdcard.stm32" --part-name fsbl2 --part-type 8DA63339-0007-60C0-C436-083AC8230908 --offset 273
part fip --source rawcopy --sourceparams="file=fip/fip-stm32mp157a-av96-trusted.bin" --part-name fip --part-type 8DA63339-0007-60C0-C436-083AC8230908 --offset 529
part --source bootimg-partition --fstype=ext4 --label ${BOOT_PARTITION_LABEL} --align 4096 --fixed-size ${BOOT_PARTITION_SIZE} --active --offset 4096
${WIC_ROOTA_PARTITION}
${WIC_ROOTB_PARTITION}
${WIC_DEVDATA_PARTITION}
${WIC_SYSDATA_PARTITION}
${WIC_APPDATA_PARTITION}
meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-bsp/trusted-firmware-a/tf-a-tools_2.4.bbappend deleted 100644 → 0
+ 0
− 12
View file @ 376aaab9
DEPENDS += "openssl-native"
EXTRA_OEMAKE += "OPENSSL_DIR=${STAGING_DIR_NATIVE}/${prefix_native}"
do_compile() {
# These changes are needed to have the native tools compiling and executing properly
# https://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a.inc#n162
sed -i '/^LDLIBS/ s,$, \$\{BUILD_LDFLAGS},' ${S}/tools/fiptool/Makefile
sed -i '/^INCLUDE_PATHS/ s,$, \$\{BUILD_CFLAGS},' ${S}/tools/fiptool/Makefile
oe_runmake certtool fiptool
}
meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-security/optee/optee-os-stm32mp_3.12.0.bbappend deleted 100644 → 0
+ 0
− 7
View file @ 376aaab9
# This is only safe because this recipes uses out-of-tree builds. The package's
# make design caches sysroot paths as make dependencies (see the .d files).
# Some of these paths are versioned (gcc for example) so recompiling after a
# gcc bump would make those dependencies fail. Forcing a clean build directory
# when configure task is invalidated (which happens when native sysroot is
# regenerated), fixes the dependency issue.
do_configure[cleandirs] = "${B}"
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

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent