From fb297405d4b225137f35c19070423d1d48aa79df Mon Sep 17 00:00:00 2001
From: Andrei Gherzan <andrei.gherzan@huawei.com>
Date: Thu, 9 Dec 2021 17:18:46 +0100
Subject: [PATCH] Remove support for stm32mp1-av96 (96Boards Avenger96)
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
.gitlab-ci.yml | 12 -
.oniro-ci/machines-and-flavours.yaml | 7 -
docs/build-flavours/linux-flavour.rst | 1 -
docs/ci/machines-and-flavours.rst | 14 -
docs/hardware-support/boards/96b-Avenger.rst | 351 ------------------
docs/hardware-support/boards/index.rst | 1 -
flavours/linux/bblayers.conf.sample | 3 -
flavours/linux/conf-notes.txt | 1 -
flavours/linux/local.conf.sample | 1 -
manifests/default.xml | 5 -
meta-oniro-core/classes/oniro-image.bbclass | 39 --
.../u-boot/u-boot-stm32mp-extlinux.bbappend | 16 -
.../linux/linux-stm32mp_%.bbappend | 7 -
meta-oniro-core/wic/x-avenger96.wks.in | 28 --
.../tf-a-tools_2.4.bbappend | 12 -
.../optee/optee-os-stm32mp_3.12.0.bbappend | 7 -
16 files changed, 505 deletions(-)
delete mode 100644 docs/hardware-support/boards/96b-Avenger.rst
delete mode 100644 meta-oniro-core/recipes-bsp/u-boot/u-boot-stm32mp-extlinux.bbappend
delete mode 100644 meta-oniro-core/recipes-kernel/linux/linux-stm32mp_%.bbappend
delete mode 100644 meta-oniro-core/wic/x-avenger96.wks.in
delete mode 100644 meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-bsp/trusted-firmware-a/tf-a-tools_2.4.bbappend
delete mode 100644 meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-security/optee/optee-os-stm32mp_3.12.0.bbappend
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 6352db27..93d164cf 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -122,18 +122,6 @@ aggregate-docs:
##
## 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:
needs: [linux-qemu-x86]
stage: test
diff --git a/.oniro-ci/machines-and-flavours.yaml b/.oniro-ci/machines-and-flavours.yaml
index d8d355d0..c885ab3d 100644
--- a/.oniro-ci/machines-and-flavours.yaml
+++ b/.oniro-ci/machines-and-flavours.yaml
@@ -43,13 +43,6 @@ linux-seco-imx8mm-c61:
# See build-generic.yaml for explanation of CI_ONIRO_BB_LOCAL_CONF_ variables.
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:
extends: .build-wic-image
variables:
diff --git a/docs/build-flavours/linux-flavour.rst b/docs/build-flavours/linux-flavour.rst
index f3c38da2..8b6c29cb 100644
--- a/docs/build-flavours/linux-flavour.rst
+++ b/docs/build-flavours/linux-flavour.rst
@@ -25,7 +25,6 @@ Supported machines (default in **bold**):
* qemuarm
* qemuarm64
* seco-intel-b68 (SECO SBC-B68)
-* stm32mp1-av96 (96Boards Avenger96)
* seco-imx8mm-c61 (SECO SBC-C61)
Build steps example:
diff --git a/docs/ci/machines-and-flavours.rst b/docs/ci/machines-and-flavours.rst
index cbf868a5..8d86ada7 100644
--- a/docs/ci/machines-and-flavours.rst
+++ b/docs/ci/machines-and-flavours.rst
@@ -66,20 +66,6 @@ architecture.
The cache for this job is not public, as it contains proprietary elements
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
.....................
diff --git a/docs/hardware-support/boards/96b-Avenger.rst b/docs/hardware-support/boards/96b-Avenger.rst
deleted file mode 100644
index f2183eab..00000000
--- a/docs/hardware-support/boards/96b-Avenger.rst
+++ /dev/null
@@ -1,351 +0,0 @@
-.. 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>`.
diff --git a/docs/hardware-support/boards/index.rst b/docs/hardware-support/boards/index.rst
index 431f365d..9fbbdd58 100644
--- a/docs/hardware-support/boards/index.rst
+++ b/docs/hardware-support/boards/index.rst
@@ -14,7 +14,6 @@ This section details the boards supported as part of |main_project_name|.
.. toctree::
:maxdepth: 1
- 96b-Avenger
96b-nitrogen
seco-intel-b68
seco-imx8mm-c61
diff --git a/flavours/linux/bblayers.conf.sample b/flavours/linux/bblayers.conf.sample
index f9a90606..48fdbf0d 100644
--- a/flavours/linux/bblayers.conf.sample
+++ b/flavours/linux/bblayers.conf.sample
@@ -27,9 +27,6 @@ BBLAYERS ?= " \
##OEROOT##/../meta-openembedded/meta-perl \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-python-mixin \
- ##OEROOT##/../meta-st-stm32mp \
- ##OEROOT##/../meta-st-stm32mp-addons \
- ##OEROOT##/../meta-av96/meta-av96-core \
##OEROOT##/../meta-raspberrypi \
##OEROOT##/../meta-security \
##OEROOT##/../meta-linaro/meta-optee \
diff --git a/flavours/linux/conf-notes.txt b/flavours/linux/conf-notes.txt
index fb5ea48a..ea66c1af 100644
--- a/flavours/linux/conf-notes.txt
+++ b/flavours/linux/conf-notes.txt
@@ -16,7 +16,6 @@ Supported machines (first is the default):
- qemux86
- seco-intel-b68 (SECO SBC-B68)
- seco-imx8mm-c61 (SECO SBC-C61)
-- stm32mp1-av96 (96Boards Avenger96)
- raspberrypi4-64
MACHINE variable can be set up in conf/local.conf file under build directory
diff --git a/flavours/linux/local.conf.sample b/flavours/linux/local.conf.sample
index 6a6d8f77..a387b6f5 100644
--- a/flavours/linux/local.conf.sample
+++ b/flavours/linux/local.conf.sample
@@ -22,7 +22,6 @@
#
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
-#MACHINE ?= "stm32mp1-av96"
#MACHINE ?= "seco-intel-b68"
#MACHINE ?= "seco-imx8mm-c61"
#MACHINE ?= "raspberrypi4-64"
diff --git a/manifests/default.xml b/manifests/default.xml
index add9504f..033dafe1 100644
--- a/manifests/default.xml
+++ b/manifests/default.xml
@@ -23,7 +23,6 @@ SPDX-FileCopyrightText: Huawei Inc.
<remote name="aehs29" fetch="https://github.com/aehs29" />
<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="stm" fetch="https://github.com/STMicroelectronics" />
<remote name="linaro" fetch="https://git.linaro.org/openembedded" />
<remote name="oe" fetch="git://git.openembedded.org" />
@@ -42,15 +41,11 @@ SPDX-FileCopyrightText: Huawei Inc.
<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-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-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-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-raspberrypi" remote="yocto" revision="934064a01903b2ba9a82be93b3f0efdb4543a0e8" path="meta-raspberrypi" />
<project name="meta-security" remote="yocto" revision="b76698c788cb8ca632077a972031899ef15025d6" path="meta-security" />
diff --git a/meta-oniro-core/classes/oniro-image.bbclass b/meta-oniro-core/classes/oniro-image.bbclass
index 127846d2..ca5c48f0 100644
--- a/meta-oniro-core/classes/oniro-image.bbclass
+++ b/meta-oniro-core/classes/oniro-image.bbclass
@@ -24,28 +24,6 @@ IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_mask_getty;' if bb.utils.contai
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
#
@@ -57,23 +35,6 @@ WKS_FILE_raspberrypi4-64 ?= "x-raspberrypi.wks.in"
WKS_FILE_seco-intel-b68 ?= "x-efi-systemd-microcode.wks.in"
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
# specific partition table provided through the wic configuration.
IMAGE_FSTYPES_qemux86 ?= "wic wic.bz2"
diff --git a/meta-oniro-core/recipes-bsp/u-boot/u-boot-stm32mp-extlinux.bbappend b/meta-oniro-core/recipes-bsp/u-boot/u-boot-stm32mp-extlinux.bbappend
deleted file mode 100644
index 368f1e5d..00000000
--- a/meta-oniro-core/recipes-bsp/u-boot/u-boot-stm32mp-extlinux.bbappend
+++ /dev/null
@@ -1,16 +0,0 @@
-# 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
diff --git a/meta-oniro-core/recipes-kernel/linux/linux-stm32mp_%.bbappend b/meta-oniro-core/recipes-kernel/linux/linux-stm32mp_%.bbappend
deleted file mode 100644
index 04be9ac1..00000000
--- a/meta-oniro-core/recipes-kernel/linux/linux-stm32mp_%.bbappend
+++ /dev/null
@@ -1,7 +0,0 @@
-# SPDX-FileCopyrightText: Huawei Inc.
-#
-# SPDX-License-Identifier: Apache-2.0
-
-FILESEXTRAPATHS_prepend := "${THISDIR}/linux:"
-
-SRC_URI += "file://squashfs.cfg"
diff --git a/meta-oniro-core/wic/x-avenger96.wks.in b/meta-oniro-core/wic/x-avenger96.wks.in
deleted file mode 100644
index db5d903f..00000000
--- a/meta-oniro-core/wic/x-avenger96.wks.in
+++ /dev/null
@@ -1,28 +0,0 @@
-# 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}
diff --git a/meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-bsp/trusted-firmware-a/tf-a-tools_2.4.bbappend b/meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-bsp/trusted-firmware-a/tf-a-tools_2.4.bbappend
deleted file mode 100644
index 1da37b26..00000000
--- a/meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-bsp/trusted-firmware-a/tf-a-tools_2.4.bbappend
+++ /dev/null
@@ -1,12 +0,0 @@
-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
-}
diff --git a/meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-security/optee/optee-os-stm32mp_3.12.0.bbappend b/meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-security/optee/optee-os-stm32mp_3.12.0.bbappend
deleted file mode 100644
index 3353bcab..00000000
--- a/meta-oniro-staging/dynamic-layers/meta-st-stm32mp/recipes-security/optee/optee-os-stm32mp_3.12.0.bbappend
+++ /dev/null
@@ -1,7 +0,0 @@
-# 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}"
--
GitLab