On 11/8/22 3:03 PM, Ulf Samuelsson wrote:
Den 2022-11-08 kl. 01:12, skrev Mark Hatle:
I've attempted to implement something to help, as well as revise the
README files. It's very much still a work in-progress. Look at
'langdale-next' in meta-xilinx and meta-xilinx-tools.
Specifically in meta-xilinx:
https://github.com/Xilinx/meta-xilinx/commit/51ffcebf0cd804e43c2d8d53bb0709a9480081bb
Other patches in this series cleanup things, as well as work to
implement mesa lima vs the libmali. I've no idea if or when this will
go into our regular tree, but it works (it's just slower then libmali.)
I am looking for feedback on this and the other patches in there.
Why not simply require that the XSA file is present in a git repo
looking like:
git repositories are horribly inefficient for this, as these are binary files
that can't be diffed to prior versions.
We're going to move away from this and move to distributing versions (not yet
sure how) XSA reference files with our releases. We've hit the point we are
bumping up on github file and commit size limits, if for no other reason.
But with this said, we're not intending to remove the ability to store XSAs
within a git repository, as we know some people ARE using this. (I also know
from various bug reports there are a large number of people who are not using
it, and want a file path or https path to pull from their artifactory or similar.)
xsa-repo.git/
├── machine1
│ └── machine1.xsa
└── machine2
└── machine2.xsa
a second repo could be:
xsa-repo3.git/
└── machine3
└── machine3.xsa
Then your recipe only needs to use the existing MACHINE value and not
HDF_MACHINE at all.
The bbappend:
SRC_URI:machine1 =
"git://github/mycompany/xsa-repo.git;branch=release;protocol=https"
SRC_URI:machine2 =
"git://github/mycompany/xsa-repo.git;branch=release;protocol=https"
SRC_URI:machine3 =
"git://github/mycompany/xsa-repo3.git;branch=release;protocol=https"
SRC_URI using override syntax breaks devtool/recipe tool. It has no idea what
overrides will be in place, so it attempts to use them all. Similarly we've had
bugs about this in the past, so for most cases I need to avoid SRC_URI overrides
(that are no through a bbappend or other external source.)
The microblaze toolchain inclusion is a good example. We don't use SRC_URI
overrides, but instead a .inc file that is only included if the override is present.
Alternatively:
xsa-repo4.git/
└── machine3
└── a-single-xsa-file-with-whatever-filename.xsa
so you only look for a directory with the same name as MACHINE and then
get the xsa file inside the directory.
This is where the combination of:
HDF_MACHINE
HDF_BASE
HDF_PATH
HDF_NAME
Can do git repository, local file and other protocol (like https)
I wasn't involved in most of these design decision, but the requirement was that
people WILL override the XSA often during development (before checking it into
an SCM or similar). I'm not sure I completely agree with that, but it's how the
existing design evolved to where it is.
In the end though, external-hdf just downloads the file and makes it available
in a standard location. As long as there is a recipe that does this the how is
far less important.
(In a custom BSP, I would probably not use external-hdf, but provide my own
PREFERRED_PROVIDER virtual/hdf provider that downloads from my location and puts
the file into the standard place.)
The verification in the commit above probably needs to be extended to check the
combination of HDF_MACHINE/BASE/PATH/NAME since one recipe changing one will
have an impact.. but I believe you can always 'unset' or set to blank in an
inheriting recipe if overriding isn't enough.
We just need a way to tell the user that the config is incorrect and point them
to how to fix it.
Thanks for the comments.
--Mark
Best Regards
Ulf Samuelsson
--Mark
On 11/7/22 12:04 PM, Mark Hatle wrote:
On 11/7/22 9:59 AM, Livius wrote:
I noticed that arhitect problem a half year ago, but nobody care
about, it, i
just i got a bullshit not working answer about this things. More
over, i could
provided a normal and maintanable style/architect with separated
qemu.conf and
generic.conf files to not lose key functionality in the HDF recipe with
automatic HDF_MACHINE assigning, but there were no any review or
discussion
about it, that it can bee better and more professional then now.
https://github.com/Xilinx/meta-xilinx/pull/41
<https://github.com/Xilinx/meta-xilinx/pull/41>
I DO care about this. I believe the architecture is right, but I
need to fix
the usage around the architecture.
github pull requests get handled, but it's slow. We're much faster at
responding to the mailing list.
Do you know that all of your Xilinx devboard machine configurations
<https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/conf/machine>
are corrupted in meta-xilinx-bsp
Yes, I know they are mostly broken. We're working on it. I expect
to have
something I can share in the next months. We're a small team, and
nobody
reported these things were not working (the meta-xilinx-bsp) pieces
until we had
no resources to work on them. And I see a completely lack of anyone
suggesting
patches for them as well.
<https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp>
and not
buildable because of your new hardcoded generic configs like foreign
HDF/XSA and
so on? It is little boring that in every half year in every new
release need to
deep dive in xilinx machine configurations and fix your mistakes to
be able to
use a standard developer board like ZCU104 or any own custom board
config which
perfect before.
And this is why I published langdale and master updates _NOW_ and not
in 6
months. I WANT feedback, I want patches, and I want discussions on
these items.
I expect in the next few days most of the remaining langdale/master
updates will
be in a state I can push them to github. Once that is done, the next
thing on
my agenda is to try to sync meta-xilinx-bsp and the XSAs.
While I can't promise it, my intention is to merge anything public to
github
langdale and master going forward. We're just beginning the process
so it's
taking longer then I hoped, but it is a process we're trying to do.
--Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5086):
https://lists.yoctoproject.org/g/meta-xilinx/message/5086
Mute This Topic: https://lists.yoctoproject.org/mt/94844586/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
