[PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Manorit Chawdhry
m-chawdhry at ti.com
Wed Apr 3 12:34:58 CEST 2024
Hi Michael,
On 11:02-20240403, Neha Malcom Francis wrote:
> 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.
>
As I see it, it's not like we are making the fdt-0 non overridable, you
can still override it in your configs to make it cleaner if you want for
your board template, I don't think that -
tispl {
insert-template = <&ti_spl>;
fit {
images {
fdt-0 {
...
};
fdt-1 {
...
};
};
configurations {
conf-0 {
...
};
conf-1 {
...
};
};
};
};
is not doable. It might be a bit duplicate but if I think about it but
we are not losing out on extending the templates for multiple DTBs even
with this design. I know it might not be what you want but I feel that
for single DTB it's really convenient with the macro stuff and we don't
have to override any of the other binman nodes.
Regards,
Manorit
> > > 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
More information about the U-Boot
mailing list