Hi, On 20.09.21 22:43, Trent Piepho wrote: > 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. Thanks for the clarification. Doesn't sound appropriate indeed. >> 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. Ye, that would be nice. >>> 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. If all you need to change is config/DT/environment, I guess this works. We often do need customer-specific board code (detect optional USB stick, apply device tree fixups, address some hardware quirk...), which is why this approach here was a bit new to me. > 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. I see. >>> 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. Thanks, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
