[ERROR] [tree.py][WARNING]: Exception (tunes) raised by code block:

[likewise]

How can I debug this issue?

This seems a piece of dynamically generated Python code to be executed which then raises an exception.

../sources/meta-xilinx/meta-xilinx-core/gen-machine-conf/gen-machine-conf --hw-description ../sdt -c ./conf/ 
NOTE: Starting bitbake server...
NOTE: Started PRServer with DBfile: /project-on-host/build/cache/prserv.sqlite3, Address: 127.0.0.1:37693, PID: 66303
NOTE: Unpacking /project-on-host/sdt to /project-on-host/build/hw-description/
[INFO] Using HW file: /project-on-host/build/hw-description/project-on-host/sdt/system-top.dts
WARNING: XSCT has been deprecated. It will still be available for several releases. In the future, it's recommended to start new projects with SDT workflow.
[INFO] Getting Platform info from HW file
[WARNING] The lopper 'lops' or 'embeddedsw configuration' files are missing, Trying to get recipe sysroot using bitbake
[WARNING] Unknown CPU xlnx,microblaze-11.0
[WARNING] Unknown CPU xlnx,microblaze-11.0
[INFO] Silentconfig project
[INFO] Generating configuration files
[INFO] Generating cortex-a53 Linux configuration [ None ]
[INFO] Generating cortex-a53 baremetal configuration for FSBL
[INFO] Generating microblaze baremetal configuration for ZynqMP PMU
[INFO] Generating microblaze processor tunes
[ERROR] 

[tree.py][WARNING]: Exception (tunes) raised by code block:
def __node_test_block():

                                   if __selected__:
                                       for n in __selected__:
                                           n.tunes['reorder'] = 'reorder'
                          
__nret = __node_test_block()

[zeddii]

The exception in itself isn't an error (it is how the framework catches issues with the python in lopper operations (lops)), which is what is happening here.

It isn't that hard to debug, but the raw lopper command and inputs are needed, since we need to add some verbosity to the run and look at the files.

Looking at the thrown exception, in this case the lop is looking at nodes in the device tree and accessing a field called "tunes", the nodes that have been selected in the other lopper operations (selected) don't have that field, so we get the exception.

Since this works in other scenarios (that specific lop, not lopper itself), there's likely something wrong with the inputs which also likely stem from the WARNING lines in the log (But I know nothing about gen-machine-conf, so I can't say more than that).

If you can find the inputs and lopper command line, I can definitely have a look.

[likewise]

Thanks, Lopper is called as follows:

LOPPER_DTC_FLAGS="-b 0 -@" /project-on-host/build/tmp/work/x86_64-linux/esw-conf-native/2025.1+git/recipe-sysroot-native/usr/bin/lopper -O /project-on-host/build/output/system-top -f --enhanced   -i /project-on-host/build/tmp/work/x86_64-linux/esw-conf-native/2025.1+git/recipe-sysroot-native/usr/lib/python3.12/site-packages/lopper/lops/lop-microblaze-yocto.dts /project-on-host/build/hw-description/project-on-host/sdt/system-top.dts

and the DTS where it seems to not find the tunes has two microblaze softcore CPUs, which are defined as below.

What does the exception try to tell me? Should the dts for microblaze always have the tunes item in the DTS?

/ {
	cpus_microblaze_1: cpus_microblaze@1 {
		#cpu-mask-cells = <1>;
		compatible = "cpus,cluster";
		#address-cells = <1>;
		#size-cells = <0>;
		iop_pmod0_mb: cpu@1 {
			xlnx,reset-msr-dce = <0>;
			model = "microblaze,11.0";
			xlnx,addr-tag-bits = <0>;
			xlnx,d-axi = <1>;
			xlnx,interrupt-mon = <0>;
			xlnx,iaddr-size = <32>;
			xlnx,number-of-wr-addr-brk = <0>;
			xlnx,dynamic-bus-sizing = <0>;
			xlnx,temporal-depth = <0>;
			xlnx,use-interrupt = <1>;
			xlnx,optimization = <0>;
			xlnx,ip-axi-mon = <0>;
			xlnx,ip-name = "microblaze";
			d-cache-highaddr = <0x3fffffff>;
			xlnx,dcache-force-tag-lutram = <0>;
			xlnx,pc-width = <32>;
			xlnx,interrupt-is-edge = <0>;
			reg = <0x1>;
			xlnx,async-interrupt = <1>;
			xlnx,use-mmu = <0>;
			xlnx,reset-msr-ee = <0>;
			xlnx,icache-victims = <0>;
			xlnx,use-reorder-instr = <1>;
			xlnx,d-lmb-mon = <0>;
			xlnx,d-lmb-protocol = <0>;
			xlnx,ill-opcode-exception = <0>;
			xlnx,dcache-always-used = <1>;
			xlnx,use-div = <0>;
			xlnx,dc-axi-mon = <0>;
			xlnx,debug-trace-async-reset = <0>;
			xlnx,trace = <0>;
			xlnx,part = "xczu48dr-ffvg1517-2-e";
			i-cache-baseaddr = <0x0>;
			xlnx,use-config-reset = <0>;
			xlnx,pvr = <0>;
			xlnx,i-lmb-mon = <0>;
			xlnx,dcache-byte-size = <8192>;
			xlnx,fault-tolerant = <0>;
			xlnx,family = "zynquplus";
			compatible = "xlnx,microblaze-11.0" , "xlnx,microblaze";
			xlnx,data-size = <32>;
			xlnx,mmu-zones = <16>;
			xlnx,debug-trace-size = <8192>;
			xlnx,mmu-privileged-instr = <0>;
			xlnx,enable-discrete-ports = <0>;
			d-cache-line-size = <16>;
			xlnx,d-lmb = <1>;
			xlnx,sco = <0>;
			xlnx,reset-msr-eip = <0>;
			xlnx,debug-interface = <0>;
			clock-frequency = <99999985>;
			xlnx,use-ext-brk = <0>;
			xlnx,daddr-size = <32>;
			xlnx,debug-enabled = <1>;
			xlnx,reset-msr-ice = <0>;
			xlnx,num-sync-ff-dbg-trace-clk = <2>;
			xlnx,i-lmb-protocol = <0>;
			xlnx,endianness = <1>;
			xlnx,fsl-exception = <0>;
			i-cache-line-size = <16>;
			xlnx,use-extended-fsl-instr = <0>;
			xlnx,reset-msr = <0x0>;
			xlnx,dp-axi-mon = <0>;
			device_type = "cpu";
			xlnx,branch-target-cache-size = <0>;
			xlnx,dcache-use-writeback = <0>;
			xlnx,div-zero-exception = <0>;
			xlnx,mmu-tlb-access = <3>;
			bus-handle = <&amba_pl>;
			xlnx,cache-byte-size = <8192>;
			xlnx,pvr-user2 = <0x0>;
			xlnx,opcode-0x0-illegal = <0>;
			xlnx,icache-line-len = <4>;
			xlnx,ecc-use-ce-exception = <0>;
			xlnx,base-vectors = <0x0>;
			xlnx,edk-special = "microblaze";
			xlnx,use-dcache = <0>;
			xlnx,use-barrel = <0>;
			xlnx,reset-msr-bip = <0>;
			xlnx,allow-dcache-wr = <1>;
			xlnx,debug-external-trace = <0>;
			xlnx,addr-size = <32>;
			xlnx,piaddr-size = <32>;
			i-cache-highaddr = <0x3fffffff>;
			xlnx,num-sync-ff-clk-debug = <2>;
			xlnx,debug-event-counters = <5>;
			xlnx,fpu-exception = <0>;
			xlnx,allow-icache-wr = <1>;
			xlnx,g-use-exceptions = <0>;
			xlnx,i-axi = <0>;
			xlnx,g-template-list = <0>;
			xlnx,icache-streams = <0>;
			xlnx,dcache-line-len = <4>;
			xlnx,num-sync-ff-clk = <2>;
			xlnx,edk-iptype = "PROCESSOR";
			xlnx,use-stack-protection = <0>;
			xlnx,use-hw-mul = <0>;
			xlnx,num-sync-ff-dbg-clk = <1>;
			xlnx,interconnect = <2>;
			xlnx,debug-latency-counters = <1>;
			i-cache-size = <8192>;
			xlnx,exceptions-in-delay-slots = <1>;
			xlnx,use-fpu = <0>;
			xlnx,reset-msr-ie = <0>;
			xlnx,edge-is-positive = <1>;
			xlnx,use-pcmp-instr = <0>;
			xlnx,use-icache = <0>;
			d-cache-size = <8192>;
			xlnx,memory-ip-list = "iop_pmod0_lmb_lmb_bram_if_cntlr_memory" , "iop_pmod0_lmb_lmb_bram_if_cntlr_memory";
			xlnx,async-wakeup = <3>;
			xlnx,use-non-secure = <0>;
			xlnx,dcache-addr-tag = <0>;
			xlnx,number-of-rd-addr-brk = <0>;
			d-cache-baseaddr = <0x0>;
			xlnx,area-optimized = <0>;
			xlnx,avoid-primitives = <0>;
			xlnx,lockstep-slave = <0>;
			xlnx,use-ext-nm-brk = <0>;
			xlnx,instr-size = <32>;
			interrupt-handle = <&iop_pmod0_intc>;
			xlnx,icache-always-used = <1>;
			xlnx,i-lmb = <1>;
			xlnx,mmu-dtlb-size = <4>;
			xlnx,lockstep-select = <0>;
			xlnx,lmb-data-size = <32>;
			xlnx,ic-axi-mon = <0>;
			xlnx,enable-conversion = <1>;
			xlnx,num-sync-ff-clk-irq = <1>;
			xlnx,fsl-links = <0>;
			timebase-frequency = <99999985>;
			xlnx,icache-force-tag-lutram = <0>;
			xlnx,dcache-data-width = <0>;
			xlnx,dcache-victims = <0>;
			xlnx,use-branch-target-cache = <0>;
			xlnx,debug-profile-size = <0>;
			xlnx,unaligned-exceptions = <0>;
			xlnx,lockstep-master = <0>;
			xlnx,freq = <99999985>;
			xlnx,number-of-pc-brk = <1>;
			xlnx,mmu-itlb-size = <2>;
			xlnx,imprecise-exceptions = <0>;
			xlnx,use-msr-instr = <0>;
			xlnx,icache-data-width = <0>;
			xlnx,debug-counter-width = <32>;
		};
	};

[likewise]

This is the lop that is adding the failing code:

                lop_5_1 {
                      compatible = "system-device-tree-v1,lop,select-v1";
                      select_1;
                      select_2 = "/cpus_microblaze.*/cpu*.*:compatible:.*microblaze";
                      select_3 = ":xlnx,use-reorder-instr:!0";
                      lop_5_1_1 {
                          compatible = "system-device-tree-v1,lop,code-v1";
                          code = "
                               if __selected__:
                                   for n in __selected__:
                                       n.tunes['reorder'] = 'reorder'
                          ";
                      };
                };

[likewise]

And this is the lop that is setting up n.tunes for that microblaze softcore processor, which for my dts seems to go in the else condition where n.tunes is not declared and defined:

                                           n.tune_type = re.split('@', n.name)[0]

So the problem seems to lie in the lop data.

                lop_0_1 {
                      compatible = "system-device-tree-v1,lop,select-v1";
                      select_1;
                      select_2 = "/cpus_microblaze.*/cpu*.*:compatible:.*microblaze";
                      lop_0_2 {
                              compatible = "system-device-tree-v1,lop,code-v1";
                              inherit = "subsystem";
                              code = "
                                    for n in tree.__selected__:
                                        val = n['compatible'].value[0]
                                        if val == 'pmu-microblaze':
                                           n.tunes = OrderedDict()
                                           n.tunes['microblaze'] = 'microblaze'
                                           n.tunes['version'] = 'v9.2'
                                           n.tune_type = val.split('-')[0]

                                        elif val == 'pmc-microblaze' or val == 'psm-microblaze':
                                           n.tunes = OrderedDict()
                                           n.tunes['microblaze'] = 'microblaze'
                                           n.tunes['version'] = 'v10.0'
                                           n.tune_type = val.split('-')[0]

                                        else:
                                           n.tune_type = re.split('@', n.name)[0]
                        ";
                      };
                };

[likewise]

I think I can solve the issue, and close it here. One question is; how can I more easily debug similar issues next time? I mainly found the bug by reading code.

I noticed I cannot insert print() into the lop files, correct?

[zeddii]

Almost any core python can run inside of a lop code block (there are restrictions on some modules/commands, but that's not relevant here). So print is definitely available. You just can't use quotes, since it will cause a parse error. quotes need to be escaped, or just use single quotes (which is what I typically do).

You can also add increasing levels of verbosity to lopper with repeated -v arguments to get more information.

Let me know if there's anything more I can do to help solve the issue!

[zeddii]

Closing this out, since you found the cause and the debugging question is answered: print() works inside a code block, the constraint is on quoting rather than on the call itself.

Reopen if the tunes path bites again on a current release.