On Wed, Jan 20, 2021 at 11:00:17PM -0600, Frank Rowand wrote:

+David

so I don't have to repeat this in another thread

On 1/19/21 11:06 PM, Viresh Kumar wrote:

quoted

On 19-01-21, 09:44, Frank Rowand wrote:

quoted

No.  overlay_base.dts is intentionally compiled into a base FDT, not
an overlay.  Unittest intentionally unflattens this FDT in early boot,
in association with unflattening the system FDT.  One key intent
behind this is to use the same memory allocation method that is
used for the system FDT.

Do not try to convert overlay_base.dts into an overlay.

Okay, but why does it have /plugin/; specified in it then ?

OK, so I sortof lied about overlay_base.dts not being an overlay.  It is
a Frankenstein monster or a Schrodinger's dts/dtb.  It is not a normal
object.  Nobody who is not looking at how it is abused inside unittest.c
should be trying to touch it or understand it.

In that case, it absolutely should not be used as your standard base
dtb.

Note that overlays in general rely on particular details of the base
dtb they apply to - they'll need certain symbols and expect certain
paths to be there.  So applying random overlays to a "standard" base
dtb sounds destined to failure anyway.

Also, whatever they hell you're doing with testcases.dts sounds like a
terrible idea to begin with.

unittest.c first unflattens overlay_base.dtb during early boot.  Then later
it does some phandle resolution using the overlay metadata from overlay_base.
Then it removes the overlay metadata from the in kernel devicetree data
structure.  It is a hack, it is ugly, but it enables some overlay unit
tests.

Quit trying to change overlay_base.dts.

In my suggested changes to the base patch I put overlay_base.dtb in the
list of overlays for fdtoverlay to apply (apply_static_overlay in the
Makefile) because overlay_base.dts is compiled as an overlay into
overlay_base.dtb and it can be applied on top of the base tree
testcases.dtb.  This gives a little bit more testcase data for
fdtoverlay from an existing dtb.

If you keep trying to change overlay_base.dts I will just tell you
to remove overlay_base.dtb from apply_static_overlay, and then the
test coverage will become smaller.  I do not see that as a good change.

If you want more extensive testing of fdtoverlay, then create your
own specific test cases from scratch and submit patches for them
to the kernel or to the dtc compiler project.

quoted

And shouldn't we create two separate dtb-s now, static_test.dtb and
static_overlay_test.dtb ? As fdtoverlay will not be able to merge it with
testcase.dtb anyway.

Or maybe we can create another file static_overlay.dts (like testcases.dts)
which can include both testcases.dts and overlay_base.dts, and then we can
create static_test.dtb out of it ? That won't impact the runtime tests at all.

Stop trying to use all of the unittest .dts test data files.  It is convenient
that so many of them can be used in their current form.  That is goodness
and nice leveraging.  Just ignore the .dts test data files that are not
easily consumed by fdtoverlay.

The email threads around the various versions of this patch series show how
normal devicetree knowledgeable people look at the contents of some of the
.dts test data files and think that they are incorrect.  That is because
the way that unittest uses them is not normal.  Trying to modify one or two
of the many unittest .dts test data files so that they are usable by both
the static fdtoverlay and the run time unittest is not worth it.

-Frank

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson