Devicetree add-on

Devicetree add-on

[Alexander Shiyan]

Hello All.

The question arose whether it is possible to load an add-on into
devicetree, but NOT through an overlay,
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.

Thanks!

Re: Devicetree add-on

[Marco Felsch]

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

Re: Devicetree add-on

[Alexander Shiyan]

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@pengutronix.de>:
>
> 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

Re: Devicetree add-on

[Sascha Hauer]

Hi Alexander,

On Wed, Jan 29, 2025 at 09:10:58AM +0300, Alexander Shiyan wrote:
> Hello All.
> 
> The question arose whether it is possible to load an add-on into
> devicetree, but NOT through an overlay,
> 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.

exchanging the device tree during runtime is not a good idea. Pointers
from the old tree might still be in use. Also it's not easy to track
which devices have been probed already and which have to be probed from
the new tree. Exchanging the device tree might work at first, but opens
the door for some bad surprises.

Do you need the full device tree in barebox itself or just in the
Kernel? If the latter I would just start the kernel with the full device
tree and keep the original one in barebox.

There are also some boards in the tree in which we use I2C EEPROM
support in PBL, so we can pick the correct device tree from the start
rather than starting with a base device tree.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Devicetree add-on

[Alexander Shiyan]

Hello.

Yes, I understand that.
But maybe we can make another entry point to start from scratch,
but with another tree, roughly the same way we do with pbl?

Thanks!

чт, 30 янв. 2025 г. в 16:39, Sascha Hauer <s.hauer@pengutronix.de>:
>
> Hi Alexander,
>
> On Wed, Jan 29, 2025 at 09:10:58AM +0300, Alexander Shiyan wrote:
> > Hello All.
> >
> > The question arose whether it is possible to load an add-on into
> > devicetree, but NOT through an overlay,
> > 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.
>
> exchanging the device tree during runtime is not a good idea. Pointers
> from the old tree might still be in use. Also it's not easy to track
> which devices have been probed already and which have to be probed from
> the new tree. Exchanging the device tree might work at first, but opens
> the door for some bad surprises.
>
> Do you need the full device tree in barebox itself or just in the
> Kernel? If the latter I would just start the kernel with the full device
> tree and keep the original one in barebox.
>
> There are also some boards in the tree in which we use I2C EEPROM
> support in PBL, so we can pick the correct device tree from the start
> rather than starting with a base device tree.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Devicetree add-on

[Sascha Hauer]

On Thu, Jan 30, 2025 at 04:45:48PM +0300, Alexander Shiyan wrote:
> Hello.
> 
> Yes, I understand that.
> But maybe we can make another entry point to start from scratch,
> but with another tree, roughly the same way we do with pbl?

It's not universally possible to jump into the currently running image.
Static variables in the data section might be modified already.

Of course you can load the barebox image from the boot device again
manually and jump into it, with a device tree passed in a pointer this
time.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |