See: https://lists.yoctoproject.org/g/meta-xilinx/message/5354
On 6/5/24 6:22 AM, Adrian via lists.yoctoproject.org wrote:
Hi Mark,
As you are the creator of the 'scarthgap' branch, could you please share its
current status?
In development. scarthgap-next recently had the 2024.1 work merged into it.
Likely that will go to scarthgap today (same with master).
Currently, my Yocto layer is based on the Poky 'honister' release, including
meta-xilinx version c165574c (it was stable when I froze our version).
The past migrations have been time-consuming. This was mainly due to the lack of
clear migration notes (poky is a good counterexample, link
<https://docs.yoctoproject.org/migration-guides/migration-5.0.html#migration-notes-for-5-0-scarthgap>) for the meta-xilinx layer, necessitating code reading and information gathering from this email group. Has this situation improved recently?
The PetaLinux note for 2023.1, 2023.2 and 2024.1 information should have
additional information, additionally there are numerous readme and related in
the 'docs' directory of meta-xilinx.
Also
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2613018625/Yocto+Project+related+Release+Notes
Note this covers _LANGDALE_ since that is the current version that we release
2024.1 against. Most of the things there will also be applicable to scarthgap
and master.
I'll double check internally to see when this will be updated to 2024.1, but
there were not many updates with the exception that the 'System Device Tree'
model of building the firmware is now supported. XSCT (meta-xilinx-tools)
approach is still the default, but we've added a warning it will be going away.
Due to the required effort, we would like to address directly the latest LTS of
Yocto, aka 'scarthgap'. After switching our layer from 'honister' to 'scarthgap'
and aligning with Poky following Poky's migration notes, I encountered bitbake
errors already at the parsing stage when processing meta-xilinx recipes, e.g.,
firmware_git.bb:
bb.data_smart.ExpansionError: Failure expanding variable
fetcher_hashes_dummyfunc[vardepvalue], expression was
${@bb.fetch.get_hashvalue(d)} which triggered exception FetchError: Fetcher
failure: Unable to resolve 'invalid' in upstream git repository in git
ls-remote output for github.com/Xilinx/embeddedsw.git
"invalid". Your configuration is pointing to an ESW version that the code
doesn't know about. Thus we set the value to 'invalid' as a trigger.
Check
https://github.com/Xilinx/meta-xilinx/blob/e59299a3016e7b814591400d1a2a5a08d3342ae2/meta-xilinx-core/conf/layer.conf#L45
This is the default. Currently valid values include:
v2022.1, v2022.2, v2023.1, v2023.2, and v2024.1
ONLY the v2024.1 version has been tested, so any issues older versions are your
responsibility to report. I'll do my best to address them.
The variable dependency chain for the failure is:
fetcher_hashes_dummyfunc[vardepvalue]
Is the meta-xilinx 'scarthgap' branch stable? Or should we focus on a recent
version from the master branch? Any recommendations?
No. It is not. Our later half of the year release, 2024.2 will be the first to
use Scarthgap. By that point we expect it to be 'stable', until then we will be
making significant changes to align everything. As noted in the email
referenced at the top of this reply, we have a lot of restructuring and cleanup
planned.
My recommendation is to start merging to Scarthgap now, and then updated early
and often, reporting any issues you find along the way so that we can get these
addressed before the fall release.
Once scarthgap-next/master-next get pushed, I'll start sending up some of the
core restructing work that we've got pending. Likely this week.
We are targeting ZynqMP with U-Boot SPL. We aim to have a clean Yocto build,
avoiding dependencies on external Xilinx tools (e.g., meta-xilinx-tools): the
only input to the build is the bitstream and the platform initialization files
(_init.c) from the *hdf file.
As part of the restructing work, we will be separating the Linux, firmware and
boot process pieces. Currently when you build a Linux system, it has hard
dependencies on the firmware and boot pieces, which in turn construct the
firmware images. This is primarily because the normal implementation we suggest
people to start with is an SD-Card/EMMC boot process so all of the pieces are
easy to see and manipulate for new users.
Breaking this into it's pieces and relying more on the dependency cycles will
allow us and our users to better control and match the physical board settings
between where Linux will be and the firmware components which may be sitting in
flash somewhere instead of in a filesystem.
With that said, as I've said repeatably for the past 4 years. AMD does not
support the u-boot SPL flow, HOWEVER, if someone in the community will submit
patches and test cases I will be happy to include it in the layer. The reality
is that I don't have time to support a flow I don't understand. The default,
supported blow uses the bootgen/boot.bin mechanism that starts with 'fsbl' ->
'pmu-firmware'/'atf' -> u-boot. Deviating from this flow will prevent certain
on-chip security features, which is why we don't support it as an organization.
Again, I want to have this support added to meta-xilinx but I won't be the one
implementing it, I simply do not have the time.
--Mark
Thank you in advance for your input.
Regards,
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5366):
https://lists.yoctoproject.org/g/meta-xilinx/message/5366
Mute This Topic: https://lists.yoctoproject.org/mt/106501087/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
