qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 24/51] meson: compile bundled device trees


From: Peter Maydell
Subject: Re: [PULL 24/51] meson: compile bundled device trees
Date: Mon, 11 Sep 2023 16:16:22 +0100

On Fri, 8 Sept 2023 at 21:08, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> On Fri, 8 Sep 2023, Michael Tokarev wrote:
> > 08.09.2023 22:21, BALATON Zoltan:
> >> I was about to ask, since when but probably nobody knows then. AFAIR I had
> >> no such errors for the canyonlands one when I've added it but that was
> >> quite some years ago and things in dtc for example could have changed so it
> >> now gives these warnings.
> >
> > I think it can be said based on debian build logs. Lemme see..
> >
> > https://buildd.debian.org/status/logs.php?pkg=qemu&arch=all
> >
> > The first log entry there is from 2018-12-12, for qemu 3.1, dtc 1.4.7.
> > It has:
> >
> > dtc -o b/qemu/pc-bios/bamboo.dtb pc-bios/bamboo.dts
> > b/qemu/pc-bios/bamboo.dtb: Warning (unit_address_vs_reg): /memory: node has 
> > a
> > reg or ranges property, but no unit name
> > b/qemu/pc-bios/bamboo.dtb: Warning (unit_address_vs_reg): /plb/opb: node has
> > a reg or ranges property, but no unit name
> > b/qemu/pc-bios/bamboo.dtb: Warning (chosen_node_stdout_path):
> > /chosen:linux,stdout-path: Use 'stdout-path' instead
> > b/qemu/pc-bios/bamboo.dtb: Warning (interrupts_property): /plb/opb: Missing
> > interrupt-parent
> > b/qemu/pc-bios/bamboo.dtb: Warning (interrupts_property): /plb/opb/ebc:
> > Missing interrupt-parent
>
>
> OK so bamboo was likely always like that. Sam460ex (aka canyonlands which
> is the devel board it is based on) was added in February 2018 so that was
> OK back then but later dtc versions may have become pickier somewhere
> between 1.4.7 and 1.6.0.

Yeah, at some point dtc started warning about a lot of these
things, I think in the hope that people writing dt files would
fix them before the dt got into wide circulation.

> > next it was moved to one of the subpackages, and moved back to
> > arch-independent package in 6.2 (2022-01-09, dtc 1.6.0), which has:
> >
> > dtc -o b/misc/bamboo.dtb pc-bios/bamboo.dts
> > pc-bios/bamboo.dts:45.9-48.4: Warning (unit_address_vs_reg): /memory: node
> > has a reg or ranges property, but no unit name
> > pc-bios/bamboo.dts:87.13-154.5: Warning (unit_address_vs_reg): /plb/opb: 
> > node
> > has a reg or ranges property, but no unit name
> > pc-bios/bamboo.dts:198.3-50: Warning (chosen_node_stdout_path):
> > /chosen:linux,stdout-path: Use 'stdout-path' instead
> > pc-bios/bamboo.dts:87.13-154.5: Warning (interrupts_property): /plb/opb:
> > Missing interrupt-parent
> > pc-bios/bamboo.dts:100.14-108.6: Warning (interrupts_property): 
> > /plb/opb/ebc:
> > Missing interrupt-parent
> > dtc -o b/misc/canyonlands.dtb pc-bios/canyonlands.dts
> > pc-bios/canyonlands.dts:47.9-50.4: Warning (unit_address_vs_reg): /memory:
> > node has a reg or ranges property, but no unit name
> > pc-bios/canyonlands.dts:210.13-429.5: Warning (unit_address_vs_reg):
> > /plb/opb: node has a reg or ranges property, but no unit name
> > pc-bios/canyonlands.dts:464.26-504.5: Warning (pci_bridge):
> > /plb/pciex@d00000000: node name is not "pci" or "pcie"
> > pc-bios/canyonlands.dts:506.26-546.5: Warning (pci_bridge):
> > /plb/pciex@d20000000: node name is not "pci" or "pcie"
>
> Linux has this in arch/powerpc/boot/dts/canyonlands.dts and at least had a
> change of the pciex names to pcie that should fix some of these but if the
> u-boot still uses older names then could updating this result in different
> results between using -kernel and without that? I don't know how guests
> use the dtb so can't tell what to do but keeping it consistent with the
> older u-boot this board has seems like a safer option.

At least in theory, guest code looking at a device tree blob
should be searching it by 'compatible' property name, not
by the name of the node itself. So changing node names is
a fairly safe change, though as you say the absolute safest
thing would be to not change at all.

Did we get these dts file from some other "upstream" source?
If so then the best thing is probably either to just update
from that upstream source again, or else say "these aren't
files the QEMU project is writing, so there's no point in
having the compile process warning about them, turn all the
dtc warnings off using the '-q' option".

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]