From: Michael Tretter <m.tretter@pengutronix.de>
To: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Cc: barebox@lists.infradead.org, Marco Felsch <m.felsch@pengutronix.de>
Subject: Re: Barebox OF-Overlay Handling
Date: Wed, 13 Jan 2021 15:52:23 +0100 [thread overview]
Message-ID: <20210113145223.GD29774@pengutronix.de> (raw)
In-Reply-To: <6d092867cfc86c63c2eb12fd7a156769d8a8d1f1.camel@pengutronix.de>
On Wed, 13 Jan 2021 15:07:48 +0100, Rouven Czerwinski wrote:
> On Wed, 2021-01-13 at 12:07 +0100, Marco Felsch wrote:
> > Hi there,
> >
> > I have the following problem. My customer is using overlays for
> > external devices like: display, camera, etc. The current overlay support
> > is awesome and most of it works out of the box. There is only one
> > nitpick: If Barebox isn't build with CONFIG_OF_OVERLAY_LIVE enabled many
> > error's are printed during boot. Those error's are ignored but let the
> > user assume that something went really bad:
> >
> > ERROR: of_resolver: __symbols__ missing from base devicetree
> > ERROR: of_overlay: fragment 30164b88: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 30164c84: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 3012fb08: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 3012fc34: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 3012fd60: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 3012fe8c: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 3012ffb8: phandle 0xffffwfffffff not found
> > ERROR: of_overlay: fragment 301300e4: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 30130210: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 3013033c: phandle 0xffffffff not found
> > ERROR: of_resolver: __symbols__ missing from base devicetree
> > ERROR: of_overlay: fragment 30130e94: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 30130fc4: phandle 0xffffffff not found
> > ERROR: of_resolver: __symbols__ missing from base devicetree
> > ERROR: of_overlay: fragment 30131a14: phandle 0xffffffff not found
> > ERROR: of_overlay: fragment 301342d4: phandle 0xffffffff not found
> >
> > The of_firmware_load_overlay() calls triggering those errors.
> > The error's by itself are correct and I don't wanna change them but the
> > context must be correct by context I mean:
> >
> > - barebox-dt on fpga-platform: An FPGA platform needs a barebox
> > base devicetree with __symbols__ and those error are correct because
> > the firmware manager needs to load the firmware.
> > - barebox-dt on non fpga-platform: Those errors are not correct.
> > We don't need __symbols__ for the barebox base devicetree.
>
> I was wondering why you were getting this error even on a platform
> without FPGA, turns out of_firmware_load_overlay() is always called if
> a devicetree overlay is passed via the DT. This in itself isn't a
> problem, but IMO of_firmware_load_overlay() should check first whether
> the overlay contains the right compatible ("fpga-region") and property
> ("firmware-name") before doing of_resolve_phandles and
> of_process_overlay. This way we can skip a lot of unnecessary overlay
> handling if we don't end up loading a firmware.
At the moment, the check and firmware load path use the same code path,
because there is no difference except that firmware load requires a resolved
overlay and the check does not. This is a viable solution and there is even a
helper to iterate the fragments and call a check function for each fragment.
However the helper calls find_target, which is responsible for most of the
error messages, and therefore, does not completely resolve the issue.
(Indeed, the check if the fragment has the "fpga-region" compatible is
missing. That's a bug.)
I would rather change the error logging to only log errors if actually
something goes wrong. Because none of the aforementioned errors is actually
fatal from a system perspective, but only from a function perspective.
Furthermore, the messages are not helpful at all to actually find the problem
in case of a unresolved overlay.
>
> > - kernel-dt on any platform: Those error's are correct if
> > the overlays are using phandles which should be the case most the
> > time.
>
> AFAICS this should also fix this case.
>
> > My proposed solution would be a stub like this:
> >
> > #ifdef CONFIG_OF_OVERLAY_LIVE
> > int of_firmware_load_overlay(struct device_node *overlay, const char *path);
> > #else
> > static inline int of_firmware_load_overlay(struct device_node *overlay, const char *path)
> > {
> > return 0;
> > }
> > #endif /* CONFIG_OF_OVERLAY_LIVE */
Nack. of_firmware_load_overlay must fail if the overlay describes an
fpga-region. Otherwise the device tree that is passed to the kernel might have
an fpga-region with a firmware-name property and that per specification
requires that the fpga is programmed.
Michael
>
> While correct in case all firmware overlays use phandles, in theory
> overlays could be purely path-based, with not dependency on the
> __symbols__ node. Not sure how common this is.
>
> > The disadvantage of this solution is that it can happen to end in a
> > non-booting device for FPGA platforms using overlays to programm the
> > bit stream and forget to enable CONFIG_OF_OVERLAY_LIVE because the
> > kernel tries to access regions not existing.
> >
> > I've discussed this with Michael in private but we didn't came to a
> > conclusion. Therefore I'm asking here any input would be helpfull :)
>
> Regards,
> Rouven Czerwinski
>
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2021-01-13 14:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-13 11:07 Barebox OF-Overlay Handling Marco Felsch
2021-01-13 14:07 ` Rouven Czerwinski
2021-01-13 14:52 ` Michael Tretter [this message]
2021-01-15 13:47 ` Michael Tretter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210113145223.GD29774@pengutronix.de \
--to=m.tretter@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=m.felsch@pengutronix.de \
--cc=r.czerwinski@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.