[PATCH] spl: fit: List DTOs applied by SPL in U-Boot control DT

[Quentin Schulz]

Hi Marek,

On 7/7/24 2:29 AM, Marek Vasut wrote:
> On 7/1/24 10:42 AM, Quentin Schulz wrote:
>> Hi Marek,
> 
> Hi,
> 
>>>>>> Shouldn't this rather be in /config node?
>>>>>
>>>>> This is what I had there originally, but then I realized that some 
>>>>> DTs might not have the /config node in them (or am I mistaken?), so 
>>>>> I moved the new properties into the root node, which surely exists.
>>>>>
>>>>> It also keeps the code simpler, as it doesn't have to fiddle with 
>>>>> creation of the /config node if it doesn't exist.
>>>>>
>>>>
>>>> I don't think we should pollute the root node with this. If we want 
>>>> to be able to expose this in a proper binding to the upstream DT 
>>>> binding repo, I'm not sure this is going to fly :/
>>>
>>> The other option is to add more code into SPL, that's not great.
>>>
>>> I can check if /config node exists, and if so, add it there, 
>>> otherwise do nothing. That should be some sort of compromise between 
>>> bloat and config node. What do you think ?
>>>
>>> [...]
>>>
>>
>> Considering that we're trying to have the same DT for U-Boot and Linux 
>> kernel in the long run and that `git grep "\s+config {"` returns 
>> nothing in dts/upstream/src, I'm not sure this amounts to anything but 
>> dead-code? We could also always insert this node as pre/post process 
>> of the DT compilation? But I think some people want to reuse the exact 
>> same DTB (like, the binary itself) between U-Boot and the Linux kernel.
> 
> In my case, the /config node is inserted via *-u-boot.dtsi , I don't 
> think those DT extras are going away anytime soon, esp. because of the 
> 'bootph-*' properties.
> 

The bootph properties are standardized (?) now. The kernel accepts them 
(see the ti and xilinx DTSes for Aarch64 for example) and it's part of 
the dt-schema now: 
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml 
though I cannot find it in the DT specification (not sure they need to 
be there though).

>> I guess we can start with checking if the /config node exists and we 
>> can figure something smarter once we need it?
>>
>> [...]
>>
>>>> 2- Add info about which DTBOs were applied to the kernel DTB?
>>>
>>> SPL DTOs or DTOs applied from kernel fitImage ? Or a merging of those ?
>>
>> DTOs that U-Boot proper applies to the kernel DTB either via fitimage 
>> configs, maybe also via syslinux (via 
>> `fdtoverlays`/`devicetree-overlay`) and the like?
> 
> Isn't that something that would be better (=more flexible and fixable if 
> broken without bootloader update) done in a boot script which could be 
> embedded in a fitImage ?

That's one way to do it though you risk desynchronization between the 
boot script and which overlays are applied and in which order. 
Additionally, can we actually already run a boot script from a 
configuration node? Because one can simply boot with a fit configuration 
and all of its DTBOs will be applied (if I'm not mistaken), if the boot 
script needs to be executed standalone before booting the configuration 
node, that's quite a surprising workflow (but that would work; we could 
probably also have the boot script directly call the bootm command with 
the proper configuration node, but then one would have to find a way on 
how to select which boot script to use between each representing their 
own configuration node?).

Cheers,
Quentin