zstd is a lot faster when compressing and decompressing, which helps
with iteration speed.
Use the CONVERSIONTYPES machinery builtin rather than re-implementing it
ourselves here.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
Signed-off-by: Matt Madison <matt@madison.systems>
OE-Core master has udpated how the toolchain virtual providers
are handled, so update the layer accordingly.
This affects the gcc-for-nvcc extra toolchain build we have for
CUDA builds, and a few other recipes that have some explicit
references to the old toolchain virtual/<something> names.
Signed-off-by: Matt Madison <matt@madison.systems>
Starting with the BOARDID and BOARDSKU variables.
For our purposes, they need to be fixed at build time,
and if they don't match the actual target machine, we'll
get difficult-to-diagnose boot failures.
Signed-off-by: Matt Madison <matt@madison.systems>
* Move the mostly-common Orin NX settings to a new orin-nx.inc file
* Set TEGRA_FLASHVAR_CHIP_SKU for machines that differ from the
common default, derived from the chip SKU referenced in the
TEGRA_BUPGEN_SPECS setting
* Convert jetson-agx-orin-devkit-industrial config to using the
agx-orin.inc include file
Signed-off-by: Matt Madison <matt@madison.systems>
This change removes rtl8822 from nvidia-kernel-oot to switch to the
driver and firmware from linux-yocto and linux firmware. It includes
updates to tegra-wifi to pull in the needed packages to the image.
Signed-off-by: Kurt Kiefer <kekiefer@gmail.com>
Custom boards wishing to provide their own devicetree sources will
want to be a provider of virtual/dtb. If this happens, then other
providers of virtual/dtb will not be built. That's a problem, because
the nvidia-kernel-oot recipe also contains device drivers and overlay
devicetree sources that are required.
To solve this, the deployment step of nvidia-kernel-oot is broken
out into a special provider for virtual/dtb. That way, it can easily
be skipped by creating a new virtual/dtb provider and the rest of
nvidia-kernel-oot can still be built and used.
Signed-off-by: Kurt Kiefer <kekiefer@gmail.com>
A number of the out-of-tree modules are named identically to
modules built in-tree, and are intended to replace the in-tree
copies. Mark those with RREPLACES/RCONFLICTS settings when
packaging the modules.
Also add PREFERRED_RPROVIDER settings for those packages,
to point to the out-of-tree copies, to the tegra-common machine
configuration include file.
Signed-off-by: Matt Madison <matt@madison.systems>
* Add a default setting for TEGRA_FLASHVAR_TBCDTB_FILE that resolves
to "@DTBFILE@"
* Update the flash helper to:
- replace @DTBFILE@ with the name of the device tree file in that variable
- remove the TBCDTB-FILE replacement in the storage layout, which isn't needed
- simplify p3701 flashvars handling, similar to what's there for p3767
Signed-off-by: Matt Madison <matt@madison.systems>
The spillover of some boot firmware partitions into
the eMMC was specific to some of the Xavier models,
so we can drop handling of that case.
Signed-off-by: Matt Madison <matt@madison.systems>
This reverts commit 1eec81c883.
With L4T R36.x, we now have a 5.15 kernel as a base, so we no
longer need to do this.
Signed-off-by: Matt Madison <matt@madison.systems>
Drop bup-payload image type from TEGRA_INITRAMFS_FSTYPES, as it's
planned to generate BUP image inside UEFI capsule generation
recipes.
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Starting with R35.5.0, the BUP generator needs the chip SKU passed
to it for generating bootloader updates for Orin modules. Update all
of the Orin configs to reflect that.
Also refactor the AGX Orin configs so we have a separate machine
definition for each of the board SKUs, similar to what's there for
the Orin NX/Nano configs.
Signed-off-by: Matt Madison <matt@madison.systems>
This aligns with the stock L4T/JetPack configuration. Note that
the Android-style separate kernel/kernel-dtb partitions are also
present by default, and will be used by the L4TLauncher UEFI app
to load the kernel and DTB if the extlinux.conf method fails.
Signed-off-by: Matt Madison <matt@madison.systems>
Unlike stock L4T, which has to handle multiple BOARDSKUs for each
module with its prebuilt binary distribution, we can reduce the
number of BUP entries we build per machine, since we have to target
specific BOARDSKUs at build time.
Orin Nano configurations should need to handle only BOARDSKUs 0003
(8GiB) and 0004 (4GiB).
The p3768-0000-p3767-0000 configuration was already trimmed to cover
just the 0000 (16GiB) SKU, so the p3509-a02-p3767-0000 configuration
is updated to match that, since it's just the carrier that's different.
Signed-off-by: Matt Madison <matt@madison.systems>
* Use flash_l4t_t234_nvme.xml as the default layout
* Mark it as having a _rootfs_ab varian
Also, the BUP generation specs for p3768-0000-p3767-0000
are cleaned up to include just the 0000 board SKU, since we
have separate machine configs for the other SKUs.
Signed-off-by: Matt Madison <matt@madison.systems>
R35.5.0 introduces different logic for selecting the PMIC config,
based on board SKU. Update the machine config to expect a sed
rewrite in the flash variable, and update the flash helper to
perform that rewrite.
Signed-off-by: Matt Madison <matt@madison.systems>
As of the nanbield release, OLDEST_KERNEL is set in meta.conf to
version 5.15. This is newer than the version available to us for the
tegra machines in the Jetpack 5 releases. As such, some components
that use this variable (such as glibc) will be build assuming support
for kernel features we don't have.
Override the OLDEST_KERNEL to 5.10, to match the linux-tegra kernel.
Signed-off-by: Kurt Kiefer <kekiefer@gmail.com>
NVIDIA provides redundant flash layouts with A/B support
for most platforms. This commit adds a parameter
USE_REDUNDANT_FLASH_LAYOUT which uses them instead of the
default non-redundant.
* Add a variable USE_REDUNDANT_FLASH_LAYOUT to control whether
to use the default flash layout or the redundant flash layout
for both internal and external layouts. The weak override var
USE_REDUNDANT_FLASH_LAYOUT_DEFAULT can be set at the distro
layer to override the default (off) state if desired.
* Build a PARTITION_LAYOUT_TEMPLATE_REDUNDANT variable
which appends the rootfs_ab string to the partition layout file
for all cases other than when PARTITION_LAYOUT_TEMPLATE_DEFAULT_SUPPORTS_REDUNDANT
is set, where PARTITION_LAYOUT_TEMPLATE_DEFAULT_SUPPORTS_REDUNDANT
is set for nano platforms using flash_t234_qspi.xml which already
contains redundant partitions.
* Build a PARTITION_LAYOUT_EXTERNAL_REDUNDANT variable which
appends the rootfs_ab string to the PARTITION_LAYOUT_EXTERNAL file
for all platforms with the exception of orin nano platforms which
use "flash_l4t_external.xml" by default.
* Add a ROOTFSPART_SIZE_DEFAULT var which sets the default rootfs
partition size for the MACHINE when not using dual redundancy.
* Add a ROOTFSPART_SIZE_REDUNDANT var which divides the
ROOTFSPART_SIZE_DEFAULT by two when USE_REDUNDANT_FLASH_LAYOUT
is specified.
After this commit:
* Custom MACHINE types which need to support multiple flash
layouts for redundancy can name their layouts to match the
NVIDIA syntax, ending with _rootfs_ab, define
PARTITION_LAYOUT_EXTERNAL_DEFAULT as well as
PARTITION_LAYOUT_TEMPLATE_DEAFULT and the
USE_REDUNDANT_FLASH_LAYOUT will function as expected for
these platforms as well to select the appropriate xml files.
* Custom MACHINEs which don't need to support multiple flash
layouts can just define PARTITION_LAYOUT_EXTERNAL and/or
PARTITION_LAYOUT_TEMPLATE as done previously to override
the default assignments for these variables in tegra-common.inc
* Custom MACHINEs which need to specify a custom partition size
can either specify ROOTFSPART_SIZE_DEFAULT to let the size be
set based on USE_REDUNDANT_FLASH_LAYOUT, or set ROOTFSPART_SIZE
to force to a specific size regardless of USE_REDUNDANT_FLASH_LAYOUT
See also https://github.com/OE4T/meta-tegra/wiki/Rendundant-Rootfs-A-B-Partition-Support
Signed-off-by: Dan Walkes <danwalkes@trellis-logic.com>
- Encapsulate knowledge of local signing by moving most TEGRA_UEFI_DB_*
references to tegra-uefi-signing.bbclass.
- All recipes just call the tegra_uefi_* signing functions.
- Recipes that require uefi signing inherit ${TEGRA_UEFI_SIGNING_CLASS}
which defaults to tegra-uefi-signing.bbclass. Users can assign
their own class to override the default uefi signing function
behavior (to use a signing server, as an example).
- Use weak default assignment for TEGRA_UEFI_SIGNING_CLASS and
TEGRA_UEFI_USE_SIGNED_FILES in the event they are not defined.
Signed-off-by: Chad McQuillen <chad.mcquillen@lexmark.com>
from image_types_tegra.bbclass to tegra-common.inc. This enables
a future change in the digsigserver signing class to pass this
value in the MANIFEST to the signing server without having to
inherit from image_types_tegra to get this single value. EMMC_BCT
and EMMC_BCT_OVERRIDES are already defined in machine configuration files
so moving this here for consistency.
Signed-off-by: Chad McQuillen <chad.mcquillen@lexmark.com>
Signed-off-by: Matt Madison <matt@madison.systems>
To prepare for removing the static flashvars files from
the layer and instead generate them from the variable settings
in the config files.
The variables are named the same as in the old flashvars
files, prefixed with TEGRA_FLASHVAR_.
The TEGRA_FLASHVARS variable is in the tegra-common include
file and is the aggregated set of variable names (minus the
prefix) for all supported platforms. Only those variables
that have settings in the current machine config will get
used.
Signed-off-by: Matt Madison <matt@madison.systems>
to the per-SoC machine include files, in preparation
for moving the separate lists out of the bootfiles recipe
and the image_types_tegra class.
Signed-off-by: Matt Madison <matt@madison.systems>
