Hi Michael
Sorry for the late response.
On 28/03/24 17:26, Michael Walle wrote:
Hi,
On Thu Mar 28, 2024 at 12:18 PM CET, Neha Malcom Francis wrote:
On 27-Mar-24 8:03 PM, Michael Walle wrote:
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?
Not really yet. It's the j722s.
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.
k3-<board>-ddr.dtsi* (e.g J721E EVM vs. SK boards consume different memory
configurations.
And one board might have multiple configuration depending on the
variant of the board. Typically, one board is available with
different memory options. i.e. 1GiB, 4GiB and so on. The actual RAM
chips can come from different manufacturers. So all all, I presume
there will be different RAM settings, i.e. different
k3-<soc>-ddr.dtsi. But I have to switch between the setting during
runtime because there will be only one boot image for that board.
This is a runtime dynamic DDR configuration support you are describing correct?
This means you would be including all the supported memory option DTSIs in your
k3-<board>-r5.dts correct and probably do some board magic code in the SPL DDR
driver to choose the DTB. How is this affecting the packing of the final
bootloader which will anyways pack the whole R5 DTB?
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.
No, that is of course board dependent. It is just an example that
there are boards with more than one DTB.
Let's step back a bit. Right now, there is
k3-<soc>-<board>-binman.dtsi
which is fine. But it seems, that TI is heading towards a common
k3-<soc>-binman.dtsi
which is intended to be used by all the boards that are using that
particular SoC, correct me if I'm wrong here. Now the problem with
that is that you hardcode the FIT configuations which are really
board dependent and assume that there will be exactly one DTB per
board, i.e. your "#define SPL_BOARD_DTB" etc.
Correct, but as I mentioned in the earlier message, if your board supports more
than 1 FIT configuration, you can easily extend the image and add more
configurations.
Thus, what I was trying to say is that you should split all the
board independent configuration (dt fragments) from the board
specific configuration.
And again, of course I could just ignore the k3-<soc>-binman.dtsi
and just use a suitable copy "k3-<soc>-<myboard>-binman.dtsi" for my
board. But as I said, I'm not sure, this is the way to go and I have
a slight feeling I will be asked to reuse the "k3-<soc>-binman.dtsi"
when I submit my board support.
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 {
...
};
};
};
};
Then you have the information at two places. One being the "#define
SPL_BOARD_DTB" stuff and the other one being in this additional DT
fragment. That is really confusing.
Hm... maybe. I personally don't see it as confusing. Even when picking between
multiple DTBs, you will have a default DTB in any case, marking that as a macro
wouldn't be confusing right? We'll need to get a third opinion on here then, I
had seen your ping on IRC [1], putting it here for the others as well.
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
[1] https://libera.irclog.whitequark.org/u-boot/2024-03-28
--
Thanking You
Neha Malcom Francis
