We have just pushed a large update to meta-xilinx and meta-xilinx-tools
repositories. The purpose of this is to continue updating Honister development,
as well as bring in some restructuring and improvements.
We still have a short list of items in github that have been reported that still
need to be resolved, but updating things had to come first. So expect
additional changes in the near future, primarily to address those items.
Due to the large number of changes I do expect some problems to be found.
Please let us know what is not working for you, or things that may not be listed
below that need clarification.
Major Changes:
* meta-xilinx-bsp: has been split into meta-xilinx-bsp and meta-xilinx-core
As part of this work, a number of items have been moved from different layers to
better organize them.
* BOARD / BOARD_VARIANT:
In past versions, we expected people to be including zynq-generic,
zynqmp-generic or versal-generic from their defined MACHINE.conf files.
However, in practice few people did this. So we have deprecated BOARD and
BOARD_VARIANT configurations. This has been replaced with a new inheritance model.
* MACHINE inheritance:
The system is now build that your MACHINE.conf file should "require" one
of the following:
- conf/machine/microblaze-generic
- conf/machine/zynq-generic
- conf/machine/zynqmp-generic
- conf/machine/versal-generic
Microblaze: Prior to the require you need to define your TUNE_FEATURES.
This will ensure the correct machine and archs are used.
Zynq, ZynqMP, Versal: If not using the default SOC_VARIANT this must be
defined prior to the require as well.
Examples are present in meta-xilinx-bsp.
* Microblaze toolchain update:
Honister toolchain versions are now used to build for Microblaze. Note, we are
aware of some sort of issue (still being investigated) that causes bash and
sysvinit not to work properly in the filesystem. Due to this, it is not
recommended to use Honister for Microblaze Linux systems at this time.
* Baremetal Machines
The baremetal machines (other then toolchain multilibs) have been removed. You
should use a standard machine, or generic such as zynqmp-generic and then set
the DEFAULTTUNE, DISTRO and other options in your local.conf configuration.
* ZynqMP QEMU pmu-rom
The pmu-rom, necessary to boot on qemu for zynqmp is available for download
without having to be signed in. The new recipe "pmu-rom-native" will fetch this
component and make it available. The component though has a Xilinx specific
license which you must enable in your local.conf file via:
LICENSE_FLAGS_WHITELIST:append = " xilinx"
As usual when using any software, please be sure to read and understand the
included software license.
Notes:
The four generic machines are included to provide a foundation for the system.
The intention is each of them microblaze-generic, zynq-generic, zynqmp-generic
and versal-generic will (eventually) enable a QEMU foundation with reasonable
defaults. Currently QEMU may not work in all configurations, but the defaults
have been updated to match what we believe are current Honister and Vivado
design parameters.
The DEFAULTTUNE for these generic machines may not be as optimal as you may
want. The system defaults to allow for binaries to be shared between zynqmp and
versal using cortexa72-cortexa53 tuning. You can override this in your
local.conf or your MACHINE.conf file to a more desired tune if required.
As mentioned above, the Microblaze tune should be changed using:
DEFAULTTUNE = "microblaze"
TUNE_FEATURES:microblaze = "...."
This will allow the system to determine, at parse time, the correct toolchain
configuration.
Microblaze does not support DISTRO_FEATURES of seccomp, wayland, vulkan or
opengl.
Workflows:
The following workflows are being designed into these layers. While we can't
test each workflow to 100%, if you find issues in any of the workflows we will
do out best to address them. The "XSCT" workflow is the default workflow used
by PetaLinux today and has the most testing.
*) Provided DTB/binaries
In this workflow the user will provide the necessary DTB and prebuilt binary
firmware components.
The PLM, PSM, PMU and FSBL firmware component paths specified below do NOT
include the .elf and .bin suffixes. Many of them will require you to provide
BOTH the .bin and .elf versions.
The CONFIG_DTFILE, parts of the system expect the file provided to be named
"system-top.dtb".
Versal:
CONFIG_DTFILE:versal = "<path to .dtb>"
PLM_FILE:versal = "<path to plm firmware WITHOUT .elf and .bin suffix>"
PSM_FILE:versal = "<path to psm firmware WITHOUT .elf and .bin suffix>"
PDI_PATH:versal = "<path to base-design.pdi file>"
ZynqMP:
CONFIG_DTFILE:zynqmp = "<path to .dtb>"
FSBL_FILE:zynqmp = "<path to fsbl firmware WITHOUT .elf suffix>"
PMU_FILE:zynqmp = "<path to pmu firmware WTIHOUT .elf and .bin suffix>"
Zynq:
CONFIG_DTFILE:zynq = "<path to .dtb>"
$ ./poky/oe-init-build-env build
$ bitbake-layers add-layer .../meta-xilinx/meta-xilinx-core
(optional)
$ bitbake-layers add-layer .../meta-xilinx/meta-xilinx-bsp
(configure local.conf)
$ MACHINE=<machine> bitbake <target image>
*) Multiconfig w/ Generic Firmware
In this workflow, you would need to provide the device tree (and PDI file for
versal), but the system would attempt to build and use a "generic" firmware for
your system. This workflow is primarily used for testing purposes, and will not
work for many boards due to lack of configuration for the firmware components.
As in the previous workflow description the user must set CONFIG_DTFILE, and on
versal PDI_PATH. Additionally, this configuration requires meta-microblaze to
be added as well.
The following Multiconfigs are required
Versal:
BBMULTICONFIG += "versal-fw"
ZynqMP:
BBMULTICONFIG += "fsbl-fw zynqmp-pmufw"
$ ./poky/oe-init-build-env build
$ bitbake-layers add-layer .../meta-xilinx/meta-xilinx-core
../meta-xilinx/meta-microblaze ../meta-xilinx/meta-xilinx-standalone
# (if additional layers are required/desired add them here)
(configure local.conf)
$ MACHINE=<machine> bitbake <target image>
*) XSCT Workflow (most tested)
In this workflow, we will use the XSCT tool, provided as part of
meta-xilinx-tools, to process the .XSA file and construct the necessary components.
A specific XSA can be provided using:
HDF_BASE = "file://"
HDF_PATH = "<path to XSA>"
HDF_NAME = "<filename of XSA>"
$ ./poky/oe-init-build-env build
$ bitbake-layers add-layer .../meta-xilinx/meta-xilinx-core
.../meta-xilinx/meta-xilinx-standalone .../meta-xilinx-tools
(configure local.conf with the XSA if necessary)
$ MACHINE=<machine> bitbake <target image>
*) XSCT Workflow variant (Multiconfig)
This is essentially the same as the XSCT workflow above, except that it can use
the Yocto Project toolchain for Microblaze instead of the included one for
building. This is useful when doing toolchain development work, but otherwise
is not recommended.
The following Multiconfigs are required
Versal:
BBMULTICONFIG += "versal-fw"
ZynqMP:
BBMULTICONFIG += "fsbl-fw zynqmp-pmufw"
HDF configuration is the same as in the previous step.
$ ./poky/oe-init-build-env build
$ bitbake-layers add-layer .../meta-xilinx/meta-xilinx-core
.../meta-xilinx/meta-xilinx-standalone .../meta-xilinx-tools .../meta-microblaze
(configure local.conf with the BBMULTICONFIG and XSA if necessary)
$ MACHINE=<machine> bitbake <target image>
*) DTB based Workflow (experimental)
This workflow uses the meta-xilinx-standalone-experimental layer instead of the
meta-xilinx-tools to construct the necessary firmware.
Follow the instructions located in the README file for this layer.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4953):
https://lists.yoctoproject.org/g/meta-xilinx/message/4953
Mute This Topic: https://lists.yoctoproject.org/mt/88652649/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
