![](https://seccdn.libravatar.org/avatar/1cd903ce739b05e07b73c4db146530d7.jpg?s=120&d=mm&r=g)
Am 22.11.2015 um 09:47 schrieb Matwey V. Kornilov:
21.11.2015 22:40, Andreas Färber пишет:
Am 21.11.2015 um 18:33 schrieb Matwey V. Kornilov:
21.11.2015 15:59, Andreas Färber пишет:
Do we have any actual example of such a cape dtb package that's not self-made? I encountered and dropped some binary .dtb files in raspberrypi-firmware package, other than that I am not aware of any. And when self-made, doesn't that involve having a modified kernel-source package?
Not necessary. I may enable UART number N or change pin multiplexing for BBB just editing (patching) .dts file, and this operation is safe. I don't need recompile the kernel.
My point was that .dts files are in kernel-source. So either you need a patch in kernel-source, which leads to a differing %{kernel_release}, or you have a patch in a dtb-source. If you locally patch a .dts file that's what I meant with "self-made".
Nothing can prevent me from branching dtb-source and do the following:
cp /usr/src/linux/COPYING . cp -r /usr/src/linux/ . chmod -R ug+rw linux %patch0 %patch1
And introduce a couple of new subpackages.
Right, that's my dtb-source case above, and as long as that is a branch in your home only, it remains your own problem... The easiest solution then is to patch the one .dts for the board if you always use that cape (see below), then nothing needs to be done on the perl-bootloader side. Otherwise if it's multiple files or even new subpackages, please give concrete examples (package URLs), so that we can either adapt them or use them as test cases for perl-bootloader. E.g., I found some instructions for TI PRU Cape, but for downstream SDK: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#Modify_D... Someone would need to maintain such .dtsi files and patches for our kernel versions. Today there is no Contrib project for TI, and if you submitted any extra dtb packages to Base:System or wherever then I am not aware... There is a binary (and questionably labeled GPL-2.0) .dtb file for Moonshot: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:m400/dtb-m... And .dts and .dtsi files for Efika MX: https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:EFIKAMX/dt... In all other Contrib cases they seem to be from some kernel-source. Anyway, in particular I had in mind that it's quite possible that someone removes a cape before powering on the device and thus before being able to install a different dtb package. Therefore elsewhere I suggested having the core board plus some cape in the menu, which would mean either a) having new subpackages per cape with special %post handling adding that one cape to the menu or b) having packages any way the packagers see fit but letting the user configure which ones to show in the menu, which also requires having a way to regenerate extlinux.conf after updating /etc/sysconfig/bootloader without needing to reinstall all kernel and dtb packages. One concern I have with naming the board filename in a config is that .dtb names can change over time. My ODROID-XU .dts is still not accepted upstream, meaning exynos5410-smdk5410.dtb needs to be used until exynos5410-odroidxu.dtb is available, and for the Parallella we were discussing splitting zynq-parallella.dts into zynq-parallella1-*.dts for handling models with and without USB. One solution might be to allow for kernel-version-specific /etc/sysconfig/bootloader options to override the generic one. Another would be integrating scripts in some extlinux.d dir that dtb-zynq etc. could install. No perfect idea yet. FPGAs also pose further problems for .dtb handling, i.e. the physical board with or without extension boards plus software-defined hardware. Not yet sure whether the new FPGA Manager drivers in 4.4 interact with DT somehow... Do you see a way to configure the location of extlinux.conf maybe? U-Boot only searches in extlinux/extlinux.conf, so if we could optionally tweak that in /etc/sysconfig/bootloader then we could have U-Boot auto-load /boot/boot.scr and load /boot/extlinux.conf (instead of /boot/extlinux/extlinux.conf) from there after doing any env tweaks. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org