On 02/10/2023 20.56, Simon Glass wrote: > Hi Tom, > > On Mon, 2 Oct 2023 at 10:22, Tom Rini <tr...@konsulko.com> wrote: >>
>>> I'm really not sure that replacing build rules with a board CONFIG is >>> a good idea. I suppose part of my confusion is why the Makefile is >>> considered a problem? >> >> Because it's duplicative and as Rasmus points out, often wrong. > > To me, that is under the control of the board maintainers. They should > not put CONFIG_SYS_BOARD in the DT...it obviously goes against what DT > is for and I'm not sure what binding would allow it anyway. > > If it helps, I could do a little series to remove those? I think it is > just arch/arm/dts/rockchip-optee.dtsi ? > > This seems like a case of throwing the baby out with the bathwater. > Huh? I don't think you understood what Tom was referring to, and I certainly don't understand what you're talking about. (1) duplicative = the _defconfig already has the necessary information in *OF_LIST / DEFAULT_DEVICETREE (2) often wrong = people add .dts targets to dtb-y, not .dtb targets. They are harmless no-ops because people do get their .dtb files built due to (1). "often" is perhaps a bit of an overstatement. > We are trying to use DT (and not custom C code) to deal with the > differences between boards. So long as that is preserved, I am happy > enough. Of course. This has nothing at all to do with C code versus device tree(s). Just how we ensure that all relevant .dtbs that get built today with the massive [mostly redundant] lists will still be built if we remove all those dtb-$(FOO) += lists. >>> The OF_LIST option is a little vague but I think it means that the DTs >>> are packaged into a FIT in u-boot.img - is that right? But they >>> presumably have to be built first. >> >> No, they don't have to be built first because scripts/Makefile.dts >> ensures that we build everything in *OF_LIST. > > That is from this commit: > > 3609e1dc5f4 dts: automatically build necessary .dtb files > > which was for use by custom boards using a private branch. Did it have > a wider purpose that I didn't understand? Not at the time, but it turns out that since we now _do_ have it, new in-tree boards also don't have to modify an arch/*/dts/Makefile, and do it wrong. Rasmus