Re: Duplicated memory node in the Device-Tree (WAS [XEN] Re: Duplicated memory nodes cause the BUG())

[Andrew Cooper <andrew.cooper3-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>]

On 25/07/17 17:02, Andrii Anisov wrote:
> Hello Julien,
>
>
> On 25.07.17 18:44, Julien Grall wrote:
>> I have seen work on this board for the past year and it is the first
>> time I have seen a complain about memory overlap. So why this sudden
>> change?
> It just an approach change. I'm cleaning up nits for the board.
>
>> Is that a comment from the vendor or your guess?
> It is my impression.
> But yes, it could be worth to ask them why do they hardcode the memory
> layout in their u-boot but stuff the dts with number of memory nodes.
> Actually from the beginning of our time for this board the solution
> was merging all memory description nodes in one in a dts for XEN, like
> [1]. So u-boot runtime updates to the dtb were just ignored.
>
>> You need to differentiate the device-tree spec itself and Linux
>> implementation. memblock is something common to all architecture. It
>> does not mean it is something valid to do.
> That is why I asked for an advice.
>
> [1]
> https://github.com/xen-troops/meta-demo/blob/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas/r8a7795-salvator-x-xen.dts#L61

As a general rule, Xen needs to be able to tolerate and cope with any
quantity of crap described by the firmware.  On the x86 side, we have
large quantities of workarounds for buggy ACPI/MP/SMBIOS tables.

It might be the case that the best Xen can do is give up, but it should
do so with a clear error message identifying what the firmware has done
which is sufficiently crazy to prevent further booting.  Hitting a BUG()
is not a user friendly thing to do, so should be fixed.

~Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html