Hello.
Yes, I know about such an implementation.
But it seems a bit complicated to me compared to if it were possible to load
the full devicetree.
Also, the overlay is a bit limiting functionality, for example I can't use
new aliases in the overlay. There are also difficulties with writing endpoints.
Thanks!
ср, 29 янв. 2025 г. в 11:50, Marco Felsch <m.felsch@xxxxxxxxxxxxxx>:
>
> Hi Alexander,
>
> thanks for reaching out to the ML.
>
> On 25-01-29, Alexander Shiyan wrote:
> > Hello All.
> >
> > The question arose whether it is possible to load an add-on into
> > devicetree, but NOT through an overlay,
>
> Why not dt-overlays?
>
> > i.e. as a full-fledged dtb?
> > Ideally, it should look like this: the main ENTRY_FUNCTION() loads the
> > base tree, then,
> > after initialization in device_initcall(), the board modification is
> > determined and the full devicetree
> > written for this variant is loaded.
>
> Sounds exactly like a dt-overlay use-case. As it sounds to me you do
> have common base for your platform/product family. This would be your
> base-dtb loaded for every product. Later on you need to apply the
> overlays accordingly.
>
> E.g. for the platform family I'm currently working with we do the
> following:
>
> base-dt:
> --------
> / {
> feat_a: feature-device-a {
> compatible = "xyz,feature-device-a";
> ...
> ...
> status = "disabled";
> };
>
> feat_b: feature-device-b {
> compatible = "foo,feature-device-b";
> ...
> ...
> status = "disabled";
> };
> };
>
> feat-a-dto:
> -----------
> &feat_a {
> status = "okay";
> };
>
> feat-b-dto:
> -----------
> &feat_b {
> status = "okay";
> };
>
> This way we define the whole node within the base-dt and the overlays
> only enable it. This makes the overlays very straightforwward and you
> still have the opportunity to reconfigure the device-node if you really
> have to.
>
> Regards,
> Marco
