On 7/28/23 11:28 AM, Adrian Fiergolski wrote:
Mark,
Thanks for the reply.
For many reasons, I don't want to use meta-xilinx-tools and have a
dependency on xsct. I prefer the ligter flow, U-Boot SPL, etc.
When you write "experimental flow is to use multiconfigs WITHOUT
meta-xilinx-tools", do you mean the use of
meta-xilinx-standalone-experimental or meta-xilinx-standalone layer from
the mickledore branch?
meta-xilinx-standalone is the layer that provides the foundation for _building_
items for baremetal. Primarily used for firmware construction, by itself it
doesn't do much but provide an organization of how to do things. There are
reference 'board-less generic' designs that MIGHT build.. I stress MIGHT since
they probably do not work, they often do not build properly, and have no
optimization as they have no understanding of the underlying board implementation.
meta-xilinx-tools and meta-xilinx-standalone-experimental each provide a
different (and incompatible) way of using this foundation, adding in the board
information and controlling the build of the firmware components.
Currently the ONLY supported mechanism is XSCT based.
The experimental mechanism requires use of the System Device Tree framework. It
is enabled and public for experimenting, but it likely has significant flaws in
it. If you are interested in trying the system device tree framework instead of
XSCT to build your firmware components you first need to use DTG++ to generate
your system device tree. You _WILL_ still need Vivado and/or XSCT in order to
run the system device tree generator (this does NOT run inside of Yocto Project
context!)
https://github.com/Xilinx/system-device-tree-xlnx/tree/xlnx_rel_v2023.1
Once you have a system device tree, everything else is document as part of the
layer README and 'meta-xilinx-setup' SDK's README file, also available here:
https://git.yoctoproject.org/meta-xilinx/tree/meta-xilinx-standalone-experimental/README.md?h=mickledore
and
https://git.yoctoproject.org/meta-xilinx/tree/meta-xilinx-standalone-experimental/recipes-core/meta/files/README-setup?h=mickledore
(This is where meta-microblaze, meta-xilinx-standalone, and
meta-xilinx-standalone-experimental will all three be required instead of
meta-xilinx-standalone and meta-xilinx-tools.)
There is an alternative that uses pre-built binaries that you can use instead.
You will still need to acquire the binaries, but simply do _NOT_ use
meta-xilinx-standalone layer. You then need to use the fsbl and pmufw ...
https://git.yoctoproject.org/meta-xilinx/tree/meta-xilinx-core/recipes-bsp/embeddedsw/fsbl.bb?h=mickledore
https://git.yoctoproject.org/meta-xilinx/tree/meta-xilinx-core/recipes-bsp/embeddedsw/pmufw.bb?h=mickledore
... recipes in your build. (We also do not support u-boot spl flow, you are
welcome to get it working... and everyone who says they want to use it I asked
them to write up HOW they got it working and send patches, and I've yet to get
anything I was able to make into something repeatable. The supported framework
is fsbl -> pmufw/atf -> u-boot-xlnx -> [whatever you load]. It's not that we
don't want to support the spl flow, it's that it does not support signed boot
infrastructure [from chip power on] like the supported flow does. There are
alternative versions of the supported flow that can also start the fsbl boot
process on the R5 instead of the Cortex-A.. but that isn't part of the YP
integration.)
Looking at those recipes, to use a binary, you need to provide correct
dependencies. To use a prebuilt binary, set:
PMU_DEPENDS = ""
PMU_MCDEPENDS = ""
Set the location of the binary:
PMU_FIMRWARE_DEPLOY_DIR = "<path to your binary>"
Set the name of the binary. You MUST have _both_ a .bin and .elf version with
the same base name!
PMU_FIRMWARE_IMAGE_NAME = "<name of binary without suffix>"
Each of those can be set in your local.conf, your machine.conf or in a bbappend,
up to you.
Once set, your recipe(s) can properly depend on 'virtual/pmu-firmware', the
binary will get packaged and deployed, thus will be available for system
construction. For the SPL flow, you should depend on this
(virtual/pmu-firmware) and then use the binary from either the deploy directory
(or preferably) the "${RECIPE_SYSROOT}/boot/pmufw.elf" location. (The .bin is
required in the deploy directory in order for qemu to boot a reference system,
this is NOT automated in the recipe as we may not have access to an objcopy that
is microblaze compatible in order to generate the .bin, so you are responsible
for providing it.) Following this approach will ensure your implementation will
work equally well for all three approaches (XSCT, binary or System Device Tree.)
If you use FSBL, the same steps can be done in the FSBL and it's documented in
that recipe body as well.
So to swing back to your original question:
Supported method - XSCT:
meta-xilinx-core
meta-xilinx-standalone
meta-xilinx-tools
Alternative method - (prebuilt binaries)
meta-xilinx-core
[local configuration and binaries]
Experimental flow - (system device tree)
meta-microblaze
meta-xilinx-core
meta-xilinx-standalone
meta-xilinx-standalone-experimental
Once you have the board's system device tree, follow the README (and SDK README)
in the experimental layer.
--Mark
Regards,
Adrian
On 27.07.2023 16:45, Mark Hatle wrote:
On 7/27/23 7:18 AM, Adrian via lists.yoctoproject.org wrote:
Hi Mark,
It seems that when zynqmp-pmufw is built through multiconfig,
PREFERRED_VERSION_pmu-firmware and PREFERRED_VERSION_fsbl-firmware
assignments from meta-xilinx-standalone/conf/layer.conf are ignored and
respectively 'git' versions of pmu-firmware and fsbl-firmware are being
built instead of the default 2023.1 version, resulting fetching error of
embededsw (as commits for git version are not defined, 'invalid' branch
is tried to be fetched). Setting 'XILINX_RELEASE_VERSION ??= "v2023.1"'
in local.conf, as it's done in meta-xilinx-core/conf/layer.conf doesn't
resolve the issue. Mark, as you are the author of those configuration
knobs, what's is your intention of using them in case of multiconfig?
Thanks in advance.
Currently the supported method is for you to use meta-xilinx-tools
layer. This will configure the system to use the XSCT tool to control
the build of the software components.
With meta-xilinx-tools you have the option to build the components
either inline (default) or using the multiconfigs. Multiconfig is not
required.
The experimental flow is to use multiconfigs WITHOUT
meta-xilinx-tools. This requires the use the in-progress development
code (git based), we do not recommend this approach as it is currently
unstable and fragile.
We recently updated master to try to make this more clear (in the README)
https://git.yoctoproject.org/meta-xilinx/tree/README.building.md
(master was working as of Friday)
--Mark
Regards,
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5256):
https://lists.yoctoproject.org/g/meta-xilinx/message/5256
Mute This Topic: https://lists.yoctoproject.org/mt/100389153/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
