Changes to support new j784s4-hs platform in:
1) ti-sci-fw_git: Update firmware prefix for j784s4-hs
2) atf: sign the image
4) optee: sign the image
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Machine conf for J784S4 HS platform.
Used J721S2 hs as reference.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Having signed firmware is needed for the HS platforms, but does not
cause any issues for non-HS. To keep things simple, let's deploy
both sets unconditionally. This prevents mistakes when adding HS
support and further reduces the image delta between the two types.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Firmware belongs in the nonarch lib directory. Use the right variable.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Using a table makes it easier to see what firmware is included with
each machine build. It also helps prevent errors here.
Since the same functions run across machines we now sign all the firmware
without needing to add a new signing function for each new machine.
Another fix is that we install the DM firmware to the deploy directory
for all machines that use need it. This was added for J7x machines
but missed for AM62x.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
This allows us to change the name in one spot and avoid duplication.
It also helps prevent hard to see changes/typos in the firmware names.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
If we rename files in the source directory the next time we need to rebuild
the original files will be gone and build will fail. Use symlinks instead.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
The firmware for AM64x and AM62x are renamed to match the other platforms,
but we don't actually change them to match. Remove baremetal from the
names.
These are only referenced to by softlink, so this change will have no
effect on Linux users.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Since these TARGET defines are only used on the machine for which
an ALTERNATIVE is defined and always have the same name, these
provide nothing. Drop them.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Since this directory path will not change, let's avoid use
of ti-paths.inc which is set to be removed.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
For K3 machines the SECDEV selection happens in the recipes that use it.
This assignment is therefor no longer needed. Remove it.
Suggested-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Use the new ti-k3-secdev package to pull in the signing tools if they are
not provided by the environment.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Use ti-k3-secdev native package to provide secure-binary-image.sh script
when it is not passed on as an environment variable. This fixes an issue
with AM64xx which is always HS but should not require TI_SECURE_DEV_PKG
when building for HS-FS or GP platforms.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Use the new ti-k3-secdev package to pull in the signing tools if they are
not provided by the environment. This allows us to use these tools
unconditionally. Remove the checks for the script and do the signing
for all K3 machines. The signature is automatically stripped from
the binaries on non-HS devices at boot time as needed so this change
is harmless for GP devices.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Use the new ti-k3-secdev package to pull in the signing tools if they are
not provided by the environment. This allows us to use these tools
unconditionally. Remove the checks for the script and do the signing
for all K3 machines. The signature is automatically stripped from
the binaries on non-HS devices at boot time as needed so this change
is harmless for GP devices.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Use the new ti-k3-secdev package to pull in the signing tools if they are
not provided by the environment. This allows us to use these tools
unconditionally. Remove the checks for the script and do the signing
for all K3 machines. The signature is automatically stripped from
the binaries on non-HS devices at boot time as needed so this change
is harmless for GP devices.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
The setup here is common to all packages that require signing with
the TI Security Development Tools. Add a helper class to factor out
this commonality.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
While here update FW versions and remove those no longer used.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Denys Dmytriyenko <denys@konsulko.com>
Tested-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
The ti-img-rogue-umlibs package is not obeying usrmerge distro feature. /lib should be relocated to /usr. [usrmerge]
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Some machine configs didn't specify their use of screen and touchscreen
machine features correctly, fix them.
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
While we are working to update our platforms to support Weston 10 and
beyond, we are falling back to software rendering for platforms that do
not currently have a solution for GPU drivers (namely the boards that
use SGX).
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Set SGX display controller alias variables accordingly, as SGX has a few
different aliases across platforms.
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Remove default preferences for virtual/egl, virtual/libgles and virtual/libgbm
from machine configs to follow the new dependency chains via mesa in oder to
support accelerated and software-rendered graphics, which is selected by
virtual/gpudriver preference.
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Patched mesa will now be configured based on what virtual/gpudriver
preferred provider is selected. The gpu drivers will now runtime
recommend the associated UM components.
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Locally overlay verbatim copies of mesa 22.0 patches from oe-core/kirkstone,
so the same codebase works in kirkstone and master. Since upstream version
of mesa in master is now 22.3 and no longer carries these patches, but they
are still needed for 22.0-based PVR fork of mesa used with Rogue driver.
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
While we are working to update our platforms to support Weston 10 and
beyond, we are falling back to software rendering for platforms that do
not currently have a solution for GPU drivers (namely the boards that
use SGX).
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Attempt to update the SGX display controller alias variable according to
what Andrew told me. SGX apparently had a few different aliases across
platforms.
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Remove all gpu machine features and instead rely on the new dependency
chain for resolving gpu dependencies. Set preferred providers for
virtual/gpudriver where needed.
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Patched mesa will now be configured based on what virtual/gpudriver
preferred provider is selected. The gpu drivers will now runtime
recommend the associated um components.
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Original READMEs with bootflows were reworked and moved to a dedicated doc/
folder in more recent U-boot versions. Update links in the k3r5 config file
accordingly to provide some basic explanation of K3 bootflows.
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
UIO drivers are generally frowned upon in the community, and for PRU
we now have much better alternatives in RProc, RPmsg, and PRU-Consumer.
Let's not send the wrong message by continuing to support this crufty
interface. Remove the kernel module, DTBs, and test recipe.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
BeagleBone AI-64 (https://beagleboard.org/ai-64) uses Texas Instruments
Jacinto TDA4VM/J721e SoC. Officially BeagleBone AI-64 supports Debian
Linux and builds its BSP on top of meta-ti and TI SDK, but adds custom
DTBs and DTBO overlays, plus integrates other drivers and features.
Let's add corresponding recipes for beagleboard.org kernel and u-boot
along with the BeagleBone AI-64 machine config.
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
The ti-sgx-ddk driver requires an additional userspace initialization
step after the kernel module has probed the device. Without this
initialization, no EGL context can be created and Weston etc. will fail to
start.
The driver package contains an init script, but this does not work on pure
systemd-based systems without sysvinit compat support (as provided by the
systemd-compat-units package). Introduce an enabled-by-default
PACKAGECONFIG that installs a udev rule instead to run the init command
automatically when the driver is loaded, solving the issue without
depending on a specific init system. On builds without udev, this
PACKAGECONFIG can be disabled, reverting to the old init script-based
solution.
udev reports several events when the pvrsrvkm module is loaded:
- add event for the kernel module
- add events for two DRM devices
- bind event for the GPU platform device
The DRM devices aren't nice to match on, and the kernel module add is
too early to run `pvrsrvctl --start`, so we trigger on the platform
device bind.
Tested with Weston 9.0.0 on the AM65x-based TQ-Systems MBa65xx.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
These URIs have been updated in dunfell, but two instances were
forgotten in kirkstone/master.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
The TI_K3_SECDEV_INSTALL_DIR is defined on the meta-ti-extras layer
so when the layer is not used the variable is undefined.
For such cases we can use default value that is the same defined
on the recipes-ti/includes/ti-paths.inc
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
The TI_K3_SECDEV_INSTALL_DIR_RECIPE is defined on the meta-ti-extras layer
so when the layer is not used the variable is undefined.
For such cases we can use default value that is the same defined
on the recipes-ti/includes/ti-paths.inc
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
The meta-ti-bsp layer is still broken for K3 HS platforms.
The patch [1] makes the check-layer happy again as it does not
fail any more during bitbake parsing but it will be difficult
for the end user to discover this dependency on meta-ti-extras.
On the other side, meta-ti-extras depends on meta-ti-bsp so
this is a circular dependency.
Currently the layer is broken for am62xx-evm/am64xx-evm machines:
| ERROR: Nothing PROVIDES 'ti-k3-secdev-native' (but mc:k3r5:/srv/oe/build/conf/../../layers/meta-ti/meta-ti-bsp/recipes-bsp/ti-sci-fw/ti-sci-fw_git.bb DEPENDS on or otherwise requires it). Close matches:
| libtspi-dev-native
| makedevs-native
[1] - 8e43835c ti-sci-fw: make dependency on meta-ti-extras soft
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
The WIC image for K3 depends on the TI-SCI firmware, on AM65x and J721e
also the bootloader. Make this clear by only depending on firmware in
the base k3.inc file, then adding the bootloader dependency in AM65x and
J721e specific includes.
Remove unneeded overrides from the evm level files.
Remove do_image_tar dependencies as the tar files do not include
the bootloader nor TI-SCI firmware, only the boot partition of
the WIC file needs these.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
These defines are specific to a SoC, not a SoC family (K3) nor
any specific board. Move these to the SoC level for all boards
to be consistent with boards already doing this correctly.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
This was used in the base Linaro optee-os_git.bb recipe, it is
no longer used, remove it from our boards.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
J7 is an unneeded level of grouping that is now causing issues and
leading to mistakes when adding new J7 based platforms. Each J7x
family device should use the SoC name specifically to prevent
accidentally adding or removing features that are not meant
for the new SoC.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Now that we have SoC names, we can avoid adding features based on the
board name. We expect folks to create their own boards based on these
SoCs, and so using the TI made EVM board name everywhere adds extra churn
when adding a new board. Plus it is more correct for most of these
features as they depend on the SoC, not on the EVM board.
One other thing we do here is to not use the generic "j7" name,
the current and future J7 devices are far to feature diverse
to group at this level. Grouping like that will lead to the wrong
things getting enabled as new J7 SoCs are added.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Like we do with J721e, J7200, and J721s2, use a SoC header include file
to define common properties. This eases adding new boards based on these
SoC.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Multi-cert is already now the default, no need to add a comment on that.
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Kamlesh Gurudasani
Manorit Chawdhry
Andrew Davis
Jose Quaresma
Denys Dmytriyenko
Ryan Eatmon
Randolph Sapp
Matthias Schiffer