[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210121053426.4dw5oqz7qb4y7hvm@vireshk-i7>
Date: Thu, 21 Jan 2021 11:04:26 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Frank Rowand <frowand.list@...il.com>
Cc: David Gibson <david@...son.dropbear.id.au>,
Rob Herring <robh+dt@...nel.org>,
Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Masahiro Yamada <masahiroy@...nel.org>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Bill Mills <bill.mills@...aro.org>, anmar.oueja@...aro.org
Subject: Re: [PATCH V5 5/5] of: unittest: Statically apply overlays using
fdtoverlay
On 20-01-21, 23:14, Frank Rowand wrote:
> It is a convenient FDT to use because it provides the frame that the overlays
> require to be applied. It is fortunate that fdtoverlay does not reject the use
> of an FDT with overlay metadata as the base blob.
> This is probably a good idea instead of depending on the leniency of fdtoverlay.
I believe fdtoverlay allows that intentionally, that would be required
for the cases where we have a hierarchy of extension boards or
overlays.
A platform can have a base dtb (with /plugin/;), then we can have an
overlay (1) for an extension board (with /plugin/;) and then an
overlay (2) for an extension board for the previous extension board.
In such a case overlay-(2) can't be applied directly to the base dtb
as it may not find all the nodes it is trying to update. And so
overlay-(2) needs to be applied to overlay-(1) and then the output of
this can be applied to the base dtb.
This is very similar to what I tried with the intermediate.dtb
earlier.
--
viresh
Powered by blists - more mailing lists