On Fri, Apr 15, 2016 at 11:37:40AM -0600, Stephen Warren wrote:
> On 04/15/2016 11:11 AM, Tom Rini wrote:
> >On Fri, Apr 15, 2016 at 10:56:40AM -0600, Stephen Warren wrote:
> >>On 04/15/2016 10:30 AM, Tom Rini wrote:
> >>>On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
> >>>>Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
> >>>>>Fix following warnings for all mips based boards:
> >>>>> mips: + pic32mzdask
> >>>>>+Warning (unit_address_vs_reg): Node /memory has a reg or ranges
> >>>>>property, but no unit name
> >>>>>+Warning (unit_address_vs_reg): Node /cpus/cpu@0 has a unit name, but no
> >>>>>reg property
> >>
> >>Note that I am quite out-of-the-loop on these warning. I wrote the
> >>dtc patch that triggers them years ago, but it's only recently been
> >>applied due to Rob's efforts. I'm at most tangentially aware of the
> >>discussions surrounding applying it now.
> >>
> >>
> >>>>>diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
> >>
> >>>>> cpus {
> >>>>>- cpu@0 {
> >>>>>+ cpu {
> >>>>> compatible = "mips,mips14kc";
> >>
> >>Surely the correct fix is to add a reg property? (Of course, this
> >>depends on the binding definition; for ARM my assertion would
> >>certainly be true). If not, what does MIPS do about SMP? Even if you
> >>write, say, 4 nodes with name "cpu" they'll all become the same
> >>single node in the DTB.
> >
> >So the likely answer here is that the dtsi is wrong and needs to be
> >fixed rather than just dropping @0.
> >
> >>>>>diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
> >>
> >>>>>- memory {
> >>>>>+ memory@0 {
> >>>>
> >>>>I have just been told on linux-rockchip mailing list that such a change
> >>>>should not be done as /memory is being special-cased in dtc warnings for
> >>>>the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory
> >>>>size on /memory@0.
> >>>>
> >>>>If that is untrue, please someone object on the Linux mailing lists.
> >>>
> >>>Uh, what? From dtc:
> >>
> >>I vaguely recall seeing discussion that /memory *would* be
> >>special-cased, but as you point out obviously isn't yet. I doubt
> >>it's anything to do with U-Boot itself, but rather the more general
> >>problem that if /memory@NNNN changes name based on what RAM is
> >>present, it's not possible for any bootloader to update it in a sane
> >>way (what node name do you search for to edit), or any OS to read it
> >>in a sane way (what node name do you search for to find out where
> >>memory is). As such, a special case is logically required.
> >
> >Right, makes sense. But it'll also have to handle that today (nearly)
> >everyone is /memory@NNNN.
>
> Nodes without a unit address are far more common currently, on ARM at least:Brain fart, you are correct. I git grepped both memory and cpu and then got 'em backwards in my reply. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
