On 5/4/22 12:27 AM, Mike Looijmans wrote:
I don't understand it at all.

What's the CONFIG_DTFILE variable supposed to point at?

Your system may have a single device tree (Linux) or a system-device tree (see https://static.linaro.org/connect/san19/presentations/san19-115.pdf). My comments below are specific to the Linux device tree (CONFIG_DTFILE).

The "device-tree" recipe is supposed to BUILD my devicetrees. I have dts
files, that must be compiled into dtb files, and so far, device-tree was the
recipe to do that.

If you are NOT use meta-xilinx-tools, which will generate your device-tree components for you...

The variables:
SYSTEM_DTFILE ??= ""
CONFIG_DTFILE ??= "${SYSTEM_DTFILE}"
DT_FILES_PATH = "${@os.path.dirname(d.getVar('CONFIG_DTFILE')) if 
d.getVar('CONFIG_DTFILE') else d.getVar('S')}"

DTB_FILE_NAME = "${@os.path.basename(d.getVar('CONFIG_DTFILE')).replace('.dts', 
'.dtb') if d.getVar('CONFIG_DTFILE') else ''}"


The steps run more or less with the above variables...


The path CONFIG_DTFILE is to a file. It should be either a .dtb or .dts file. The end result will be a .dtb, as that is the compiled version. So you can provide either precompiled device tree or the source file.


If it sees a source file, it is supposed to compile it. But you point to a single file (that single file may have includes that span to other files in the same directory as the config file.)

i.e. it's common to have something like:

my_device_tree/system-top.dts
my_device_tree/mac/ethernet.dts
...

where you would set CONFIG_DTFILE to system-top.dts and it would include ethernet.dts.

If I just remove the "python()" function from device-tree.bb, everything works
fine. I haven't found a way to get rid of that code from a bbappend though.

The anonymous python chunk can't be disabled in a bbappend.  You have to run it.

The code:
def check_devicetree_variables(d):
    # Don't cache this, as the items on disk can change!
    d.setVar('BB_DONT_CACHE', '1')

    if not d.getVar('CONFIG_DTFILE'):
        raise bb.parse.SkipRecipe("CONFIG_DTFILE or SYSTEM_DTFILE is not 
defined.")
    else:
        if not os.path.exists(d.getVar('CONFIG_DTFILE')):
            if not d.getVar('WITHIN_EXT_SDK'):
                raise bb.parse.SkipRecipe("The device tree %s is not 
available." % d.getVar('CONFIG_DTFILE'))
        else:
            d.appendVar('SRC_URI', ' file://${CONFIG_DTFILE}')
            d.setVarFlag('do_install', 'file-checksums', 
'${CONFIG_DTFILE}:True')
            d.setVarFlag('do_deploy', 'file-checksums', '${CONFIG_DTFILE}:True')

python() {
    # Need to allow bbappends to change the check
    check_devicetree_variables(d)
}

You need to have something defined in CONFIG_DTFILE.

Whatever the file is you define must exist.

That is it, that is all that is needed.

I do not have an XSA. Never used that flow, it's more work to fix the issues
in the generated trees than to just hand-craft them properly.

I guess the only way around it is to provide my own device-tree recipe, and
avoid the device-tree inclusion?

This was specifically designed to support your configuration. You don't NEED an XSA, but you do need a device tree (compiled or source).

Apart from that all...

Suppose I did have an xsa file, what would be the workflow?

You would bring in meta-xilinx-tools.

You would define in your machine.conf (or local.conf) where the XSA is:

HDF_BASE ?= "git://"
HDF_PATH ??= "github.com/Xilinx/hdf-examples.git"
HDF_NAME ?= "system.xsa"

The above points to the default reference XSAs.  If you have a local copy:

HDF_BASE = "file://"
HDF_PATH = "/my/magic/xsa/goes/here"
HDF_NAME = "my_custom_board.xsa"

--Mark


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: [email protected]
W: www.topic.nl

Please consider the environment before printing this e-mail
On 03-05-2022 16:32, Mark Hatle wrote:
You need to either provide a device tree.

Most users should be using meta-xilinx-tools layer, and providing their XSA
file (or using one from the default set).  This will generate the device tree
for you.

If you have your own pre-generated device tree you need to provide a reference
to it using CONFIG_DTFILE (for a Linux specific device tree) or SYSTEM_DTFILE
(for a system wide device tree).

meta-xilinx-tools is optional, but currently recommended for most users.

On 5/3/22 2:36 AM, Mike Looijmans wrote:
I'm trying to upgrade from gatesgarth to honister, for our (custom zynq
and zynqmp) boards.

Quite a lot has changed, and apparently most of the README files weren't
updated.

This is why we're doing our best to release updates to honister as early as
possible.  To give you time to move before it becomes urgent.

--Mark

I managed to glork most of the changes from the recipes, but I'm
currently trying to figure out what I'm supposed to do with the
devicetree recipes. I have a device-tree.bbappend that builds the
devicetrees for our boards. However, it won't compile any longer, I get
this:

ERROR: Nothing PROVIDES 'device-tree' (but
/.../meta-xilinx/meta-xilinx-core/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb
DEPENDS on or otherwise requires it)
device-tree was skipped: CONFIG_DTFILE or SYSTEM_DTFILE is not defined.

I grepped on CONFIG_DTFILE and SYSTEM_DTFILE in meta-xilinx, but they
seem to drop out of thin air or so. Nothing ever defines them, so how do
other boards get them defined? It's also unclear what they mean and
what's expected of me.

-
Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: [email protected]
W: www.topic.nl

Please consider the environment before printing this e-mail





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4999): 
https://lists.yoctoproject.org/g/meta-xilinx/message/4999
Mute This Topic: https://lists.yoctoproject.org/mt/90854471/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to