Hi Simon,
On 10:12-20240716, Manorit Chawdhry wrote:
Hi Simon,
On 10:39-20240711, Simon Glass wrote:
Hi Manorit,
On Wed, 10 Jul 2024 at 07:15, Manorit Chawdhry m-chawdhry@ti.com wrote:
Hi Simon,
On 09:36-20231217, Simon Glass wrote:
The existing bootph binding is defined such that properties in a subnode are also implied in the supernode also, as in this example:
buttons { /* bootph,pre-ram is implied by btn1 */ compatible = "gpio-keys";
btn1 { bootph,pre-ram; gpios = <&gpio_a 3 0>; label = "button1"; linux,code = <BTN_1>; };Provide an option to implement this in fdtgrep.
Signed-off-by: Simon Glass sjg@chromium.org
Coming back to this patch as am facing some issues with the bootph-all propagation to the parent nodes [0]. We have a dmsc/sms node in our devices and it is a parent node of k3_pds, k3_clks, k3_reset.
During U-boot proper we are initializing the serial console and during that time we have to make some calls to our Device manager for clocks and power domains. With the DT modelling, the clocks and power domains come under the device manager node ( dmsc/sms ) but interestingly that driver is not getting probed while putting bootph-all in the child nodes. Do you know anything about this? I thought putting it in child node will propagate it to the parent nodes as well so it'll be probed as well. We are having to put bootph-all explicitely in the dmsc/sms node for it to work.
Yes, that is because fdtgrep is only used with the SPL DT. The U-Boot one is used unmodified by U-Boot and it does not check parents for such properties (neither does SPL, but fdtgrep has logic to imply these properties internally).
The easiest way to fix this would probably be to process the DT in Binman for insertion into the final image, since Binman already does lots of other DT processing.
If you like, you could create an issue for it [1]. If you want to have a crack at fixing it, I could provide some pointers.
I am not sure if I'll be able to focus on this now but feel free to give your pointers, might help anyone else as well if they want to take a look at it.
Would you be able to give some pointers? Also I was wondering why do we even need to process the DT in binman, why isn't the parent node probed by default in this flow, is there some use case like that where the child needs to be probed but not the parent before it or is it some other bug?
Meanwhile I will open a issue as you mentioned for tracking this, trying to register on the URL that you provided. Thanks!
https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/21
Regards, Manorit
Regards, Manorit
Regards, Simon
[1] https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues
Regards, Manorit