On Mon, Sep 20, 2021 at 2:02 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > >>> Preprocessing the dts file gains another layer, where a generated dts > >>> source consisting of an include directive for the original dts source is > >>> followed by more includes for each fragment. This is piped to the > >>> existing preprocessor call on stdin to avoid another temporary file. > >>> cpp/dtc will correctly identify errors in the source files they occur > >>> in. The -MT option is used so the cpp auto-dependencies reference the > >>> original dts source and not the generated code passed on stdin. > >> > >> If you go this route wouldn't you want to apply device tree overlays? > > > > Can the Barebox apply overlays to the *Barebox dtb* when it starts? > > I meant overlay application at compile time. I have no experience with > that and was interested to hear your opinion on it. This could be done, but I think overall it is worse. Additional fragments can be made into dtbo files and then fdtoverlay from dtc package can apply them to the main dtb at compile time. But there are drawbacks: dtb must be compiled with symbols, which makes it larger. And non-fragment users get a different dtb than before for no reason. One can not use the preprocessor to control overlays per board. Such as changing a node name from <&nand> to <&emmc> based on board or enabling/disable the entire fragment. The overlay can not delete nodes or properties, i.e. /delete-property/ and /delete-node/ are not useful. A possible benefit of overlays is if an overlay is used in many different images, then it could be compiled only once. But dtc is not any slower to compile a dts fragment append to the main dts than fdoverlay is to apply an already compiled dtbo to the main dtb, so there is not even a build time improvement here. So, I can see only disadvantages and not advantages for compile time overlays. Maybe one could ship a firmware update with a pool of overlays, then firmware update installation could construct a final dtb from hardware variant appropriate overlays. That would be a way to make use of non-dynamic overlays. Otherwise I think there is no advantage to non-runtime applied overlays over appended dts fragments. > > There is an easy way out, define the (sanitized) board name as a macro > and let users worry about it. Ok, I can add that. I think the same identifier as constructed for the C symbol of the compiled in dtb bytes will work. > > > > That is the use case here. So I can use rauc with just the standard > > Barebox source without needing to patch it. > > I see the utility when using e.g. evaluation kits barebox already > supports. Could be useful for DistroKit if RAUC support were to > be added. I used this originally for a devkit. But it is Variscite's DART-6UL, which is not supported in Barebox. So I added support. But not just support for the one thing my FW does, support as a proper Barebox devkit target. Now I want to change the flash partitions for my specific FW design and also want RAUC and barebox-state. Should I include this in my Barebox devkit support? No one else wants it, at least not as I have implemented it. Should other users submit patches to Barebox to change the partitions to what they want? Of course not. My answer is I should not have to patch Barebox to do this. I do not patch Barebox to change the defconfig I'm building with. I do not patch RAUC to configure it. I do not patch wic to change my SD card partitions. Now we have made a custom board for the next phase and I have added a new board to Barebox for this. But still I use external dts fragments despite having my FW specific Barebox git repo. Because I do not want FW system configuration to be done inside the bootloader codebase. It is much better if it is part of my FW git repo that configures everything else in the system too. In the old days, we had to patch a header in U-Boot to change *any* bootloader configuration. Yuck! Then we had Barebox and it used the kernel config system and we could have an external defconfig. So much better! And Linux had board code with compiled in driver configuration data, but then we got OF device trees and it was much better. So I want external dts files with Barebox. Complete external dts is really hard to do with the way Barebox images work. But really, I never write a complete dts from scatch. It is always a modification of a base dts. This patch to Barebox is not very complex and it lets me do anything I have ever wanted to do with external Linux dts files in Barebox. > > > If I was building two different > > boards under yocto, I would have a machine specific override in my > > barebox bbappend to add the only dts fragment for board I was building > > for. Yocto builds a different copy of barebox for each > > target/machine. I do not need barebox to use the preprocessor to turn > > off the fragment I am not using. I would not have yocto give it the > > unused fragment in the first place. > > I usually avoid Yocto MACHINEs for board variants. Build same rootfs > for both variants, ship two device trees and reference them either > from FIT configurations or bootloader specs and let the bootloader worry > about selecting the correct DT to boot. When I have done one FW for multiple boards, I've always been able to use the same bootloader and have it, or a preloader, determine board, usually by resistor strapping on a GPIO or ADC, so it is easy to use without drivers and to keep consistent on each board variant. But if one simply could not do that, then I see that multiple images from a single Barebox machine target would be useful. Also useful for Buildroot, which is not as sophisticated as Yocto when it comes to building a package in different ways. One gets one target or one host. Not target-arm, target-arm-machineA, target-arm-machineB, etc. like Yocto. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
