[PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries

[Neha Malcom Francis]

Hi Michael

On 27-Mar-24 8:03 PM, Michael Walle wrote:
> Hi,
> 
> On Wed Mar 27, 2024 at 8:01 AM CET, Neha Malcom Francis wrote:
>> On 26/03/24 19:18, Michael Walle wrote:
>>> On Fri Mar 22, 2024 at 2:10 PM CET, Neha Malcom Francis wrote:
>>>> Clean up templatized boot binaries for all K3 boards. This includes
>>>> modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and
>>>> UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse
>>>> code.
>>>>
>>>> All k3-<soc>-binman.dtsi will contain only templates. Only required boot
>>>> binaries can be built from the templates in the boards' respective
>>>> -u-boot.dtsi file (or k3-<board>-binman.dtsi if it exists). This allows
>>>> clear distinction between the SoC common stuff vs. what is additionally
>>>> needed to boot up a specific board.
>>>
>>> I appreciate the cleanup. But as far as I can see, a board might
>>> only have one device tree. How would that work if the uboot proper
>>> must support multiple device trees?
>>>
>>
>>   From the discussions that took place in the mailing list [1] the consensus
>> seems to be to not focus on multiple devicetree support as it leads to confusion
>> for downstream users.
> 
> What are users in this regard? I don't think you'd confuse
> developers.
> 
> Anyway, I'm planning on upstreaming a TI board which will have
> different memory configurations and different variants of the board.

I am assuming you are reusing an existing TI SoC?

> And on top of that, it will just be a base board and there will
> likely be some carrier device trees (overlay? I'm not sure yet).
> 
> As far as I can tell, you've put the memory configuration into the
> device tree, so I'll probably need to switch between them somehow.

The "k3-<soc>-ddr.dtsi" file will be present in your k3-<board>r5.dts 
which makes sense, the memory configuration depends on the board.

> Also, regarding the board variants, I'll probably need to choose
> between multiple device trees. That is invisible to the user,
> because u-boot will choose the correct DTB according a board
> strapping, which btw. works really fine, see for example
> (boards/kontron/sl28/spl.c:board_fit_config_name_match).

Again, this is assuming that there is some HW blown register available 
for the board to use (or in our earlier K3 case, the EEPROM) but that is 
not necessarily true every time.

> 
> I don't think it makes much sense to hardcode your generic
> *-binman.dtsi to just one FIT configuration. I'd rather see a split
> between generic things which are shared across all boards and board
> specifics, like the FIT configuration. I mean I could just copy all

Correct me if I'm wrong, but my understanding is that you would want to 
add more FDT blobs in the *-binman.dtsi correct? That is still possible, 
adding another "fdt-1" and "conf-1" in the

Something like this in your <board>-u-boot.dtsi,

tispl {
	insert-template = <&ti_spl>;
	fit {
		images {
			fdt-1 {
				...
			};
		};
		configurations {
			conf-1 {
				...
			};
		};
	};
};

provided you have the support to handle this multi-dtb FIT. But as far 
as reusing the k3-binman.dtsi and k3-<soc>-binman.dtsi goes; you should 
be able to do it.

> the binman and tiboot3.bin and tispl.bin magic and put it into my
> own "-u-boot.dtsi". But I'm not sure that will make things any
> better.
> 
> -michael

-- 
Thanking You
Neha Malcom Francis