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