[PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD

[Tom Rini]

On Wed, Oct 27, 2021 at 11:33:53PM +0200, François Ozog wrote:
> Hi Tom
> 
> Le mer. 27 oct. 2021 à 21:12, Tom Rini <trini at konsulko.com> a écrit :
> 
> > On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
> > > Hi Simon,
> > >
> > > On Tue, 26 Oct 2021 at 18:27, Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > Hi Ilias,
> > > >
> > > > On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas
> > > > <ilias.apalodimas at linaro.org> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > As I said here [1], this is moving on an entirely different
> > direction I had
> > > > > in mind. I'd much prefer starting the discussions for a solution that
> > > > > allows us to scale.
> > > >
> > > > I am missing the point here. Is there something in the plans that I
> > > > don't know about?
> > >
> > > I have some ideas, but haven't found time to code it and send patches
> > yet.
> > >
> > > >
> > > > > FWIW I think the current code is still not clean for my taste.
> > Commit
> > > > > 3b595da441cf ("fdtdec: allow board to provide fdt for
> > CONFIG_OF_SEPARATE")
> > > > > allowed this function to be used regardless of the config options.
> > IMHO we
> > > > > should have 2 clear options:
> > > > > - U-Boot provides the DTB
> > > >
> > > > Supported with: OF_SEPARATE
> > > >
> > > > > - It's somehow passed over to U-Boot
> > > >
> > > > Supported with: OF_SEPARATE + OF_BOARD
> > >
> > > That's exactly what I don't personally like. In your example OF_BOARD
> > > means "U-Boot has a DTB and here's a way to override it".  In my head
> >
> > In some ways this is just highlighting a long standing problem of
> > working with DTB.  There's certainly been some places where splitting
> > the data from the driver has helped.  But in some other places, my
> > goodness has it made the development cycle worse.  Doing this on QEMU
> > probably is on one of the most annoying cases too since yes, you start
> > by dumping the dtb you would get, then iterating the dts outside of the
> > rest of the scope of your build.  In the kernel you can "make dtbs" at
> > least and get things spit out.  I'm just repeating over here that the
> > development cycle of working on device trees is at times not great.
> 
> In general you do this only once, unless you use the virt machine and in
> that case there is no documentation about DT generated for each device
> added on the command line.
> I had lots of difficulties getting all UART possibilities: virtio <1.0,
> 1.0,1.1; mmio or pci.
> But once you get the command line, the dTB is fixed.
> Of course it would be better to get Qemu document DT generation of its
> devices.

In a lot of ways QEMU isn't even the real problem, unless it's applying
rand() to some parts of where devices end up, etc.  The cycle there
isn't any worse than where the device tree resides in hardware.  The
device tree development cycle is a pain.  QEMU is actually not so bad in
this regard really since it's just dumpdtb and pass back the modified
one, it takes care of then ensuring it's in the correct spot.  The part
where every blob must be in the right place is another part of that
horror show that binman and fconf both try and address.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211027/42208175/attachment.sig>