Boot failures in -next due to 'ARM: dts: imx: Remove skeleton.dtsi'

[Mark Rutland]

On Thu, Nov 17, 2016 at 08:17:00AM -0800, Guenter Roeck wrote:
> On 11/17/2016 07:05 AM, Mark Rutland wrote:
> >On Thu, Nov 17, 2016 at 06:44:55AM -0800, Guenter Roeck wrote:
> >>On 11/17/2016 02:55 AM, Mark Rutland wrote:
> >>>Memory nodes require this property per ePAPR and the devicetree.org
> >>>spec, so the bug is that we didn't add those when removing the
> >>>skeleton.dtsi include.
> >>
> >>The downside from qemu perspective is that the real hardware seems
> >>to add the property unconditionally, or the boot failure would have
> >>been seen there as well.
> >>
> >>I submitted https://patchwork.ozlabs.org/patch/695951/; we'll see how it goes.
> >
> >Sure, the firmare/bootlaoder you're using may add this automatically.
> >
> >My worry is that adding this to a generic file in QEMU only serves to
> >mask this class of bug for other boards (i.e. they'll work fine in QEMU,
> >but not on real HW using whatever bootlaoder happens ot be there).
> >
> Good point.
> 
> What would be the correct behavior for qemu ? Adding a chosen node if it does
> not exist is one detail we already established. Also, I think a check if
> /memory/device_type exists (and to bail out if it doesn't) would make sense.

We'd also need to check for /memory@<n> nodes, as they can validly have
unit-addresses (and many do).

Generally, the "correct" way to find them is to iterate over all ndoes
with device_type = "memory", so one could do that and give up if none
are found, ignoring the naming entirely.

> What about the memory node ? Does it have to exist, or should it be added
> (including the device_type property) if not ?

I'm not sure what QEMU does in this area. I suspect it may expect a node
in some cases, or may generate one in others.

There's no point generating one when we don't have the information to
hand, certainly.

Thanks,
Mark.