| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This is the result of automated script (0.9.0) conversion:
oe-core/scripts/contrib/convert-overrides.py .
converting the metadata to use ":" as the override character instead of "_".
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The latest embeddedsw components no longer need integration workarounds,
other then the couple of patches being applied. This simplifies eliminates
the custom do_configure, and simplifies the do_compile.
EXTRA_COMPILER_FLAGS is now different then the default version.
The versal defaults were also adjusted to match the expected output.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
| |
|
|
| |
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
| |
|
|
|
|
|
| |
Update the PMU machine and multiconfig files to match the current version
of the embeddedsw.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following the example of the psm, pmu and plm, we split the FSBL into both
a packaging component (fsbl) and the build of the firmware (fsbl-firmware).
This also adds an additional multilib, fsbl-fw, that is used to handle the
multiconfig version, as the Linux and baremetal builds are done differently.
Typical build approach is:
Add to local.conf:
BBMULTICONFIG += "fsbl-fw"
then build using:
MACHINE=zynqmp-generic bitbake fsbl
Note, while 'zynq' is implemented, it does not currently function. To
build the fsbl for zynq, you must use the meta-xilinx-tools version.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
|
In order to allow standalone (meta-xilinx-standalone), XSCT
(meta-xilinx-tools), and future items to work in the same way
the recipes have been restructured.
A *-firmware recipe will generate the firmware and stage it to do_deploy.
A *fw recipe will take the deployed version and package it for the Linux
side of things. This allows the firmware generation to be easily extended
without requiring packaging knowledge. Similarly packaging can be
extended for alternative boot/upgrade mechanisms as required.
In all cases, the MACHINE configuration will specify the default way
the components are to be built, along with the names of the item in
the deploy directory.
The PLM/PSM/PMU_IMAGE_NAME is the name for the generated firmware.
PLM/PSM/PMU_DEPLOY_DIR is the path to the constructed firmware. This along
with the IMAGE_NAME above can be used to specify the location of an
externally generated set of firmware.
Addtionally the dependencies for building the plmfw/psmfw/pmufw can be
changed easily using PLM/PSM/PMU_DEPENDS and PLM/PSM/PMU_MCDEPENDS. The
former specifies dependencies in the same multiconfig, while the later
allows the component to require another multiconfig to have finihed.
The system has a referenced default, if multiconfig is enabled it will
automatically use it, otherwise it will try to use the recipe in the
main configuration. (This will fail unless meta-xilinx-tools is available.)
Also two multiconfigs hve been implemented: versal-fw and zynqmp-pmufw
They can be enabled using BBMULITCONFIG += "zynqmp-pmufw" or versal-fw.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
