We are planning to do a number of additional refactoring in both Scarthgap and
master (and beyond).
Over the next 3-6 months we're planning to do the following changes which MAY
adjust the way some of the components are integrated.
* vcu recipe naming (already sent)
* xrt / zocl recipe renaming (already sent)
* Remove 'SOC_FAMILY_VARIANT', and move to MACHINE_FEATURES, adjust default
tunes
- We plan to have the following SOC_FAMILY
1) zynq (a.k.a. zynq7, and zynq7000)
DEFAULTTUNE: cortex-a9
2) zynqmp (a.k.a. zynq Ultrascale+)
DEFAULTTUNE: cortex-a53, alternatives a72_a53, and r5
- dr - not sure if we need a MACHINE_FEATURE for the rfsoc components
- cg - (no machine_feautres)
- eg - mali400 (already defined)
- ev - mali400, vcu (already defined)
3) versal (a.k.a. versal gen 1)
DEFAULTTUNE: cortex-a72, alternatives a72_a53, and r5
- vdu (already defined)
- aie (ai-engine, TBD)
- other TBD
4) versal-net
DEFAULTTUNE: cortex-a78, alternatives a72_a53, r52 and r5
5) versal-gen2
DEFAULTTUNE: cortex-a78, alternatives a72_a53, r52 and r5
- MACHINE_FEATURES TBD
The key with the above is that the defaults (for Yocto Project) will be the
tuning that matches the CPU, vs a more generic alternative. We do plan to
maintain compatibility with the alternatives as well as armv8-... generic as
well. (The r52 or r5's are used for standalone applications, so really only
useful in a multiconfig environment.)
This will help us better enable ARM System Ready, where we may have a kernel,
userspace and filesystem image that works across a set of various hardware
components. It will require the user to manually configure pieces as the
automatic configurations will be more 'optimized' for the target devices.
* Split "Boot" and Kernel/Userspace [filesystem] generation
Today the machine.conf has a number of essential components specified that are
automatically built to generate the boot.bin, which is then always included into
the /boot of the filesystem image.
We plan to break this build apart. This will change system behavior that if
(default) you want the boot.bin on the filesystem, it will come in via a
dependency on the boot.bin itself. However if you plan to boot from jtag, qspi,
ospi you will need to explicitly build the firmware, as it will be a separate
output from the filesystem.
This is planned for a few reasons. First, we've had requests to be able to
build the kernel, filesystem and even disk images without depending on any AMD
(Xilinx) firmware components. This is needed to support Arm System Ready. (We
are not yet committing to supporting ARM system ready, but will be working
toward making it work properly.)
Additionally we've had requests to be able to build the firmware WITHOUT
building anything else in the system. We can build the components that make up
the firmware today, but not really the boot.bin without other system parts.
* We plan to make more use of multiconfigs to enabling building firmware,
applications and other non-Linux components. (Much of this is implemented
today, but not used by default.) While we don't expect major changes, as it's
being used more we might find issues that could break compatibility with what is
implemented today.
We don't yet have a lot of detail for the above, but we'll share details and
code when we have it. We want to publish these changes for review 'early and
often'.
Any questions please ask. I want to be completely transparent on these changes
and make sure people expect things will be changed in the next few months, even
in Scarthgap, as we work to address the items above.
--Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5354):
https://lists.yoctoproject.org/g/meta-xilinx/message/5354
Mute This Topic: https://lists.yoctoproject.org/mt/106210880/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
